winds.from.oz 技術メモ

aws/codebuild

Posted:   |   Categories: AWS   |   Tags: AWS, CodeBuild

CodeBuildで設定した方が良さそう環境変数リスト

※ サービス固有に設定した方が良さそうな環境変数もあるので注意が必要( たとえば外部サービスの鍵など )

変数 用途 例
${AWS_ID} 開発と本番で共通のbuildspec.ymlを利用したい。それぞれAWS IDが異なるので環境変数で設定可能にする。
${API_ROOT} 開発時に参照するエンドポイントと本番系は異なるため 開発: dev.hoge.com 本番: wwww.hoge.com
${NODE_ENV} 開発時はdev、本番時はproductionを指定することが多い( productionを設定していると、yarn install時、devDependinciesが無視される) devはMac上の開発環境で使い、ECSはproductionを用いる 開発: dev 本番: production
${ECS_TASK} 開発時はenv**という名前でECSのリソース(タスク定義、サービス)をアサインする。本番系はenvではなくサービス名称を用いるため異なる。 開発: dev32 本番: wwwなど
${ECS_SERVICE} 開発、本番で異なるため
${ECS_CLUSTER} ECSクラスター名も開発と本番で異なる(開発環境は都度クラスターを構築するのは工数がかかりすぎるので統一している。が本番系は別にクラスターを構築し、コンテナ間でリソースの上限やお互いのサービスの負荷の影響を与える可能性を考慮して、クラスターレベルで分離している)
${API_SHARED_ACCCESS_TOKEN}
${AWS_ACCOUNT_ID}
${AWS_DEFAULT_REGION}
${HOST_NAME}
${IMAGE_REPO_NAME}
${IMAGE_TAG}
${PORT}
${WWW_ROOT}

ECRのタグ( buildspec内でdocker pushしている )ポリシー

開発用のECSタスク定義で使用するDockerイメージには dev のタグをつける

イメージに対しては必ずタグをつける( タグがないイメージにアクセスしにくいので、実質的にバックアップの意味にもならない。

  • 開発、本番のイメージpush時には Githubのcommit値 と latest をつける。

  • 開発環境用Dockerイメージ: dev のタグをつける。　基本的に開発サーバが参照するDockerイメージは dev のタグを参照する(ex docker-nginx:dev のように) デフォルトのlatestを参照する形だとlatestのイメージが起動失敗する状態になると、再起動を繰り返してしまう。

  • 本番環境Dockerイメージ: 要検討、現状 prod というタグをつけようかと思っています。間違って dev というタグが本番環境にpushされても、間違って参照されないようにしたい。

Githubのcommit値 のタグは このDockerイメージだけで、新しいDockerイメージを検証したい といったケースでつかう。 実際にはECSのタスク定義で検証したいタスク定義を更新、検証したいイメージの参照するDockerイメージのタグを変更して、サービス更新して検証する。

CodeBuild Bashスクリプト ベストプラクティス

変数は $hoge ではなく ${HOGE}のように呼び出す

  • bashの中では変数は大文字の方が見つけやすい
  • $HOGE だと $HOGEGE が変数として認識されない。${HOGE}GEであれば認識される。このミスは気づきにくい

Buildspecポリシー

ビルド開始時にSlackの #devops に通知

意図としては、

  • 自分がgit pushできたこと、GithubからWebhookが飛び、CodeBuildのフィルタに引っかかった事が確認できる
  • 関係する開発者が気づくことができる

通知内容

下記みたいな内容を通知する。 ※ 更に 開発環境なのか、本番なのか 分かるように通知したい。最低限、AWS_IDを通知内容に含める。

env28の更新を開始しました。反映まで5~10分程度おまちください。

      Github: https://github.com/コミットのURL
      CodeBuild: https://ap-northeast-1.console.aws.amazon.com/codebuild/home?region=ap-northeast-1#/builds/ビルド中のログのURL
      作業ブランチ: branch/env28
      実行環境: aws/codebuild/docker:17.09.0

CodeBuildで使用するIAMロール

IAMロールが複数あると情報セキュリティ的に管理コストが増す、上記のロールに限らないが、できればIAMロールはまとめていきたい

env28とかではなく develop みたいなありがちなブランチ名でフィルタしたい

[Webhook のイベントの確認手順]

  1. GitHub にてリポジトリのページに移動。
  2. ページ上部のタブより “Settings” を選択。
  3. ページ左部のナビゲーションペインから “Webhooks” を選択。
  4. ページ下部の Recent Deliveries を確認。

Recent Deliveries の Delivery 情報からは Webhook の際のリクエストとレスポンスを確認可能。 このリクエストの Payload に ref というパラメータがございます。この ref にブランチ名は含まれている。 そしてレスポンスの Body には開始したビルドページの URL の記載がある。 この URL のパスにはビルド名が含まれているので、実際に起動したビルドを CodeBuild コンソール等を使用して特定することが可能できる。 また、ブランチフィルタによりビルドが実行されなかった場合は Body は {“response”:“No build triggered for specified branch”,“statusCode”:200} となります。

なお、ref の値そのものがブランチ名として使用されているわけではなく、ref の中のブランチ名の部分のみがフィルタされている点に注意。

refの中身は ref/heads/develop の様な形だった。 なお、ref の値そのものがブランチ名として使用されているわけではなく、ref の中のブランチ名の部分のみがフィルタされているので ^develop$ で設定してみる。 <- ダメだった。正しくは ^refs/heads/develop$

設定はCodeBuildの[ source ]->[ Primary source webhook events ]->[ Event type ]->[ PUSH ]->[HEAD_REF ]->[ ^refs/heads/develop$ ]を設定する

トラブルシューティング

CodeBuildの設定が原因でマージできない

CodeBuildでGithubからのWebhookを受け取る設定を作成すると、 Github側に Branch protection rule が作成され、うまくプルリクを作成できなくなるケースがある、 この場合は、 [ レポジトリ ]->[ 歯車 ]アイコン->[ Branches ]-> [ Branch protection rule ]-> master の[ Edit ]でCodeBuildの設定を外すと通るようになる。

参考: https://help.github.com/articles/enabling-required-status-checks/

参考

AWSオフィシャルのトラブルシューティング情報: https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/troubleshooting.html

CodeBuildが持つ環境変数一覧

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-env-vars.html

注1) こちらはCodeBuildの環境変数から生成するように調整していきたい

User
CloudFront
ALB
EC2
RDS