LCLの開発者ブログ2018-10-12CodePipeline/CodeBuild/ECR/ECS/Fargateのコンテナデプロイ基盤を構築してみましたAWSモバイルアプリエンジニアの山下(@yamshta)です。今回は、AWSの以下のサービスを用いてコンテナデプロイ基盤の構築を試してみました。CodePipelineCodeBuildECRECSFargateAWSのドキュメントは丁寧で情報も豊富ですが、サービス毎に手順が書かれているため一連の流れをまとめました。CLIでの操作のみで手順を進めています。アプリエンジニアがデプロイ基盤を構築するのか疑問に思った方もいらっしゃると思うので手短に書かせていただきます。LCLのエンジニアチームはスペシャリスト集団というよりはゼネラリスト集団に近く、特定の技術に縛られない文化とそれを推奨する環境になっています。そのため、メインに扱う技術力も伸ばしながらも別の技術を習得することができます。今回の経緯ですが、私個人としてはインフラには興味がありませんでした。Dockerは環境構築の手軽さから数年前から色々な場面で使っていました。業務改善が好きでDevOpsのような取り組みにも興味がありました。それゆえ、サーバ環境をコンテナで取り扱えるECSに興味を持ち、その流れでデプロイ基盤まで試してみることになりました。自動テストなどは含めず、純粋なデプロイフローのみで構築します。順番はコンテナ側からボトムアップで進めます。ECR、ECSの環境を用意されている場合はCodeBuildの手順まで飛ばしてください。FullAccessを割り当てるなど権限を大胆に与えていますが、あくまでドキュメントに沿った操作となります。権限の取り扱いは充分ににお気をつけください。事前準備IAM、ECS、ECRのアクセス権限があるユーザのアクセスキーとシークレットキーを用意してください。はじめに、CLIの操作をするためにaws-cliをインストールします。amazon-ecs-cliをインストールします。amazon-ecs-cliリージョンとECSクラスタ名を指定し設定ファイルを作成します。fargate-app認証情報ファイルを作成します。imageをECRへPUSHします。CodeBuild上で行うため、将来的には手動での操作は不要ですが手順を残しておきます。今回はRailsアプリケーションを扱うため、以下のDockerfileを利用します。$ROOT_PATHECRへのログイン情報を取得します。loginコマンドを実行します。evalを使うことで出力をそのまま実行できます。ap-northeast-1)リポジトリを作成します。imageをビルドして、イメージURLをタグ付けします。.ECRへPUSHします。<AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/app/rails:latest以上でECRへイメージがPUSHされたかと思います。ECSではこれを利用してコンテナを作成します。ECSここではクラスタを作成し、クラスタの管理下でサービス(≒コンテナ)を起動します。こちらもCodeBuild上で行うため、将来的には手動での操作は不要です。クラスタを作成します。succeeded.次にサービスを起動しますが、その前に以下のようなdocker-compose.ymlを用意してください。imageにECRのイメージURLをセットするとこで上でPUSHしたイメージを扱うことができます。ap-northeast-1さらに、ECSの設定をするためにecs-compose.ymlを作成します。DISABLED上のdocker-compose.ymlを元にサービス(≒コンテナ)を起動します。ファイル名に変更がない場合は省略可能です。taskDefinition="app:1"サービスのステータスを確認します。UNKNOWNRUNNINGとなっていれば正常に動作しています。サービスを停止する際は以下のコマンドを実行します。fargate-appトラブルシューティングmaximumPercent、minimumHealthyPercentを設定していない場合に、以下のようなエラーが発生しました。rmしてみると消せました。CodeBuildはじめに、CodeBuildを操作するための権限を付与します。サービスロールを作成します。]}JSONファイルを引数にしてcreate-roleコマンドを実行します。file://create-role.json次に、ECRやS3などの操作やリソースにアクセスするためにポリシーをアタッチします。]}こちらもJSONファイルを引数にしてput-role-policyコマンドを実行します。ユーザとして実行する際には許可をする必要があります。Userにアタッチします。いう名前のファイルを作成します。]}JSONファイルを引数にポリシーをアタッチする。file://put-user-policy.jsonここまででアクセス許可の準備ができたので、次にビルド内容を決定するビルド仕様ファイルを作成します。ソースディレクトリのルートに配置します。ビルド仕様に関するリファレンスプロジェクトによって設定が異なるため詳しい説明は省きますが、今回は上で示した構成を以下のように表現します。各変数は後述するCodeBuildのビルドプロジェクトから渡します。作成したら一度GitHubへPUSHします。imagedefinitions.json後はビルドプロジェクトを作成して、動作を確認するだけです。ビルドプロジェクトを作成するビルドプロジェクトのテンプレートを用意します。create-projectを実行して、CodeBuildでプロジェクトを作成するためのJSONテンプレートを取得します。--generate-cli-skeletonJSONファイルを作成し、出力されたJSONをコピペした後に以下のように編集します。false}編集したJSONファイルを元に、ビルドプロジェクトを作成します。コマンドで実行します。CLI)」の手順で説明されているのと同様のデータが出力に表示されます。...実行したビルドの詳細は、実行時に返ってきたJSONに含まれるidを引数にbatch-get-buildsコマンドを実行することで取得できます。build-app:ec61105c-c84d-4833-ac0b-44c170de73ccもし、ビルドプロジェクトの編集をしたい場合はJSONファイルの内容を変更してupdate-projectコマンドを実行します。file://create-project.jsonCodePipeline今回も先にIAMの準備から始めます。いう名前の管理ポリシーをユーザーにアタッチします。arn:aws:iam::aws:policy/AWSCodePipelineFullAccessサービスロールを作成します。今回はJSONファイルを作らずに、直接JSONを渡すやり方をしてみます。ファイルで管理したい場合は、CodeBuildと同様の手順で行ってください。'{"Version":"2012-10-17","Statement":{"Effect":"Allow","Principal":{"Service":"codepipeline.amazonaws.com"},"Action":"sts:AssumeRole"}}'次にポリシーをアタッチします。CodePipelineで必要なアクセス許可がデフォルトで含まれています。そのため、ここではデフォルトで含まれていないもの許可するようにします。今回は、ECSやCodeBuildの操作を許可する必要があるため、それらのポリシーをアタッチします。]}JSONファイルを引数にしてput-role-policyコマンドを実行します。file://put-role-policy.json準備ができたのでパイプラインを作成します。形式のファイルを作成します。使用してコードをテストし、ビルドを実行するGitHubと連携する際は、リポジトリのアクセストークンが必要です。}}create-pipelineコマンドを実行してパイプラインを作成します。形式のデータが出力に表示されます。file://create-pipeline.json問題なくパイプラインを作成できたら、パイプラインを手動で開始します。Userの権限が参照されます。"41cda22f-536c-43b9-9756-adc05711827a"}無事に実行されたか、パイプラインのステータスを確認します。pipeline-appパイプラインを編集する際は、JSONファイルを変更してupdate-pipelineコマンドを実行します。file://pipeline.json以上でデプロイ環境が構築できたかと思います。サービスディスカバリ等を利用してドメインに対してIPの自動割り当てなどの手順が必要になると思います。サービスディスカバリについては別記事で紹介しようと思います。ストレージおわりにデプロイ基盤を構築するのは大掛かりで大変な作業ですが、これらAWSのサービスを利用することあっという間に用意することができました。本日、Code4兄弟(CodeCommit、CodeBuild、CodeDeploy、CodePipeline)のコンソールUIが刷新されましたが、手順をCLIで追うことでUI変更に影響なくドキュメント管理できますね。インフラやAWSの知識が全く無い状態から触り始めましたが、試行錯誤していくうちに概念がわかるようになりました。Outumberのセッションも不自由なく把握することができたので、引き続き理解を深めて技術力を向上していきたいと思います。エンジニア募集LCLは、技術を特定の領域に絞りたくないエンジニアにとって働きやすい環境です。入社後しばらくはメインの技術に集中して取り組んで慣れてきたころに手を広げるという働き方を推奨しています。カジュアル面談から応募が可能なので技術や活動の幅を広げて働きたい・成長したいと思っている方は是非一度話を聞きにいらしてください。