TravisCIでGitHub上のファイルをAWS S3へデプロイし、結果をSlackに通知してみた。
はじめに
AWS S3にHTMLなどの静的ファイルを配置して公開しているWebサイトについて、修正のたびに手作業でデプロイするのが面倒だったので、できるだけ自動化したいと思って取り組みました。
もはや今更感のある内容ですし、公式ドキュメントや先人が残した分かりやすいページなど探せばいくらでもあるんですが、自身の文章化の練習のために敢えて書きました。
内容や記事の書き方など気になる点があれば教えていただけると嬉しいです。
よろしくお願いします。
どれだけ楽になったか
導入前
- GitHubの開発用ブランチで修正、masterブランチへマージ
- AWSマネジメントコンソールへログイン、S3の当該バケットに遷移
- ローカルのファイルをアップロード
導入前は、アップロードすべきファイルを選別したり配置したりといった手作業がとにかく面倒でしたし、しばしば作業ミスも起こしていました。
導入後
- GitHubの開発用ブランチで修正、masterブランチへマージ(変わりなし)
- TravisCIがmasterブランチの更新を検知し、AWS S3に自動デプロイ
- TravisCIがSlackへ完了通知を送信
TravisCIがリリース作業を全て肩代わりしてくれるようになったので、masterへマージしたら後は待ってるだけでデプロイが終わるようになりました。
ただ、常に全てのファイルを更新するため、1ファイルだけ修正したい時などは処理が冗長だと感じました。
(TravisCI側で何か設定したらうまく出来るのかも知れないけど、軽く調べた感触では出来なさそうだったのでそのままの状態。)
作業内容
作業環境はWindowsです。
GitHubにTravisCIをインストール
GitHub上部ナビバーにある[Marketplace]をクリック
TravisCIを検索してクリック
Priceを選択してインストール
(サンプル用なので無料プランを選択しています。)
認証が完了するとTravisCIの管理画面に自動遷移
この後の手順が親切に書かれています。こういうの本当に素敵。
対象のリポジトリのスイッチをOn
AWS S3にデプロイするためのユーザを作成
S3バケットの作成、公開(バケットポリシーの編集)※詳細は割愛
テスト用のS3バケット名はtravistest.s3
としました。
- 本番環境ではRoute53でドメイン取得なども行いました。※割愛
デプロイ用のIAMポリシーを作成
対象S3バケットに対して必要な権限を与えたIAMポリシーを作成します。
ポリシー名はtravistest.policy
としました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "XXX...",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObjectAcl",
"s3:GetObject",
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::travistest.s3/*"
}
]
}
デプロイ用のIAMユーザを作成
[プログラムによるアクセス]を有効にします。
アクセス権限に、先程作成したIAMポリシーを選択します。
IAMユーザを作成したら、Access key IdとSecret Access Keyを忘れずにコピー、またはCSVをダウンロードしておきます。
.travis.ymlを作成
作業環境にtravis.rbをインストール
Gemをインストールします。
$ gem install travis
.travis.ymlファイルを生成
リポジトリのルートディレクトリにてtravis.rbを実行します。
今回は、実行時にsetup
オプションを使いました。
$ travis setup s3
対象のバケット名などを順番に入力していくと、以下のようなファイルが生成されます。
(setup
オプションを使わずにテキストエディタ等で編集しても可能)
deploy:
provider: s3
access_key_id: XXXXX...
secret_access_key:
secure: XXXXX...
bucket: travistest.s3
local-dir: wwwroot
acl: public_read
on:
repo: [GitHub UserName]/[GitHub Repository]
travis.ymlファイルを修正
以下の理由で修正しました。
masterブランチが更新された時のみデプロイしたい
branches:
only:
- master
Rakeファイルがないって怒られる
デプロイ時に下記エラーが発生しました。
$ rake
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
言語設定のデフォルトはRubyなんですかね。
後々before_deploy
などのコマンドはbashで書きたかったので、Rakeファイルは作成せず、言語にbashを指定することで回避しました。
language: bash
中間ファイルが削除されないようにする
参考)https://docs.travis-ci.com/user/deployment#Uploading-Files-and-skip_cleanup
deploy:
skip_cleanup: true
endpoint指定がないって怒られる
デプロイ時に下記エラーが発生しました。
The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint. (Aws::S3::Errors::PermanentRedirect)
setupオプションではendpointなどが記載されないようなので、テキストエディタで追記しました。
deploy:
endpoint: s3-ap-northeast-1.amazonaws.com
region: ap-northeast-1
最終的な.travis.yml
language: bash
deploy:
provider: s3
access_key_id: XXXXX.....
secret_access_key:
secure: XXXXX....
endpoint: s3-ap-northeast-1.amazonaws.com
region: ap-northeast-1
bucket: travistest.s3
local-dir: wwwroot
acl: public_read
skip_cleanup: true
on:
repo: [GitHub UserName]/[GitHub Repository]
branches:
only:
- master
動作確認
masterブランチにPushし、Travis CIの動作を確認します。
↓
無事にデプロイされました。
デプロイの自動化自体はこれで完了ですが、完了したかどうかはTravisCIの管理画面にアクセスしないと分かりません。その手間を省くため、Slackに通知されるようにします。
TravisCIからSlackにデプロイ完了を通知する
SlackにTravisCIアプリを追加
(超シンプルなので割愛)
TravisCIアプリの設定
(画面の指示に従っていくだけなので、改めて書く必要はない気がしますが……。)
投稿するチャネルを選択して[インテグレーションの作成]をクリックすると、セットアップ手順が表示されます。
今回は暗号化の手順を参考にしました。
連携トークンやコマンドは以下からコピーしました。
travis.ymlを編集
.travis.ymlのあるディレクトリにて、travis.rbを実行します。
encrypt
オプションにより連携トークンを暗号化しつつ、--add
オプションにより.travis.ymlに追加します。
$ travis encrypt "[Slack Team]:[Token]" --add notifications.slack
.travis.ymlに追記されました。
notifications:
slack:
secure: XXX...
修正をコミットします。
動作確認
masterブランチに修正をプッシュしてみます。
TravisCIで自動デプロイされた結果がSlackに通知されました。
デプロイが終わったかどうかが、わざわざTravisCIの管理画面にログインしなくても分かるようになりました。
おわりに
がんばった甲斐あって、その後のリリース作業がとても楽になりました。
修正をmasterにマージしたらSlackに完了通知が来るまで待っているだけなので、一息ついたり、残課題を考えたり、気持ちに余裕が生まれるようになりました。
今更言うまでもなく、作業を自動化することは色々なメリットがあることだと思います。
ただ、この「自動化された仕組みそのもの」には、以下のような問題が出てきます。
- 最初に設定した人にしか分からない
- 設定した本人ですら忘れてしまった、など
何をどう設定したのか、必要に応じてドキュメント化して残しておくなど、忘れないための工夫が要ると思いました。今回この記事を書いたのは、それが目的でもあります。
また、今回は知らないことばかりの状態から始めて、色々調べたりエラーにハマったりしながら作ったので、とても時間がかかってしまいました(仕事ではなかったので、誰かにお咎めを受けることはないのですが)。
工数をかけて自動化したところで、将来的に浮く工数と比べればもしかするとマイナスになってしまうかも知れません。今回は自分の勉強だったので気にしませんでしたが、もしこれが仕事だったらそういった面での難しさも出てきただろうなぁと思います。
とはいえ、勉強したことや取り組んだこと自体は必ずプラスになると思っていますし、「未来を楽にするために今頑張ろう」という姿勢は大事にしたいです。
Author And Source
この問題について(TravisCIでGitHub上のファイルをAWS S3へデプロイし、結果をSlackに通知してみた。), 我々は、より多くの情報をここで見つけました https://qiita.com/ushibutatory/items/defffb4d2e95a311f021著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .