CodepipelineでDockerを回してみる
はじめに
インフラアーキテクトのSanbongawaです。
AWSの経験が長くなってくるとそろそろコードを使いましょうと言われて、お悩みのインフラ屋さんは実は多いのではないでしょうか。
そんなインフラ屋の私がコードに挑戦した内容をご紹介するのが目的です。
今回は、"VS Cord"から"CodeCommit"に"Dockerfile"をアップロード、"Code Pipeline"を利用して"ECSでDockerを起動"させてみます。
(Dockerの継続的デリバリーを構築)
記載内容
今回はCordPipelineを構成するを記載します。
前回記事
- Visual Studio CodeでAWS CodeCommitを使う
- AWS CordCommitの構築
- VSCodeで接続する
- VSCordからPushする
- コンテナ動作環境を構成する
- ECRを構築する
- ECSを構築する
- タスクを定義してコンテナを動かす
今回記事
- CordPipelineを構成する
- CodeBuildを構成する
- CordPipelineを構成する
- 実際にCordPiplineを動作させる
- ECSでコンテナが起動する ※Buildとデプロイが完了する
Dockerの継続的デリバリーを構築
今回はこのような動作ができるように構成します。
まえおき
CordPipelineを作るのだからパイプラインからと初めて構築をしてみたときは、複数のタブを開いては足りないサービスを構築するを繰り返し、とても非効率でした。
ちなみに私の初めての構築では、20時間ほどかかりました。
ブログをご覧の皆様は同じ轍は踏まないように必要なところは解説しておきます。
今回最も効率が良い順番で記載しておきます。
必ずエラーが出るのですが、GUIで実施する場合にこの手順であれば簡単に構成できるように記載してますのでよろしくお願いいたします。
CordBuildを構成する
既にCodeCommitでリポジトリがある前提で進めます。
ない場合は作成してください。
DockerでのCordBuild環境とはDockerfileなどからDockerimageを構築する環境のことです。
CodeBuildのサービス画面にてビルドプロジェクトを構築します。
ビルドプロジェクトを作成するを選択します。
プロジェクト名を設定します。
それ以外オプションは適宜変更ください。
例えばDockerImageの更新を今回実施するため、Buildを複数実行すると時間がかかったりと問題が発生する可能性があるため、同時実行できるビルドは1つとしてみます。
デプロイする時のソースを求められますので、ソースにはCodeCommitを選択します。
Gitのクローンの深さは作成するソースによって変わる可能性があります。
そのためFullにしておいた方が後での変更点がないので、Betterと考えます。
Codeをbuildする際の環境について設定することができます。
私はプログラムはあまり詳しくありませんが、プログラムなどの場合は指定が必要になるとは思います。
Buildされる環境は、利用できるライブラリや実行環境で大きな影響がある可能性があります。
必要に応じてイメージの選択などは検討ください。
今回はCodeBuildによって管理されているイメージをBuild環境とします。
このページで重要なのは、特権付与にチェックを入れることです。dockerイメージの構築を継続的デリバリーをする環境を実現するためには必須要件です。
※最初に構築したときはデフォルトで、とりあえず作ったため複数回のビルドエラーに悩まされました。
その他追加設定については,基本はデフォルト値で問題ありません。
もしCodeBuildをVPC内で動作させたい場合は、AWS CodeBuild プロジェクトからアクセスする VPC を選択します。
今回は、マネジメントサービスとしてAWSの内部で動作させるため設定しません。
また環境変数を設定することでコード内や実行時に変数利用することができます。
コードにハードコートしたくない内容やコードを共有して利用したい内容を変数として格納することが望ましいです。今回は一旦なしで作成します。
Buildspecについてはちゃんと説明が必要なので、Docker回のブログ側で書くことにします。
buildspecファイルを使用するで問題ありません。
※とりあえず作る場合は、ログの設定はなしでも構いません。
実運用の場合はログの取り扱いはとても大切なのでしっかり吟味してください。
これでDockerfileからDocker imageを構築するビルド環境が完成しました。
CordPipelineを構成する
既にECR/ECSなどコンテナ環境がある前提で進めます。
タスク定義などで決めたサービス名などがこの環境を利用する上では大切になってきます。
最初の方で記載してますが、別途記事にしてみます。
さて、CordPipelineは継続的デリバリーの中で、アプリケーションなどのデプロイから実装までの流れをジョブ管理してくれるツールです。
実際は試験などを間に入れることで試験を自動化、またセキュリティの試験を入れることでセキュリティ試験の自動化できます。
セキュリティ試験は常に最新化しないと意味がないので仕組みもいると考えます。
これは今度時間があれば考えてみたいと思います。
CodePipelineのサービス画面にてパイプラインを構築します。
パイプラインを作成しますを選択します。
5つのステップで構成されてます。
まず名前と利用するサービスロールを新規作成 or 選択します。
利用するソース種類を選択します。ソースは元のプログラムやファイルを指します。
今回はCodeCommitを選択します。
次に利用するソースの詳細を設定します。
CodeCommitのどのリポジトリでどのブランチを対象にイベントを実行するのか?を設定します。
そのあとに対象のリポジトリで何が起きたら自動実行するのか?トリガーを選択。
排出される形式を選びます。基本はデフォルトで問題ありません。
そのソースをどこでビルド(構築)するのか?を選択します。
先ほど作成したCodeBuildのプロジェクトを選択します。
最後にビルドしたデータをデプロイして実行できるようにします。
今回はDockerの実行環境であるECSを利用します。
クラスター名とサービス名の記載が必要です。
最後は設定確認のページが表示されます。確認ページなのでここでは割愛します。
さて、最初にお伝えしたとおりこの手順だと必ずエラーがでます。
以下のエラー対応をお願いします。
現状の手順だと必ずでるエラーの対処
エラー その1
初期でPipelineが作成されるとこのようにエラーが表示されます。
エラー内容はざっくりと要約します。
”実行失敗したよ。指定したソースが使えないよ。codecommitへのアクセスするにはKMSの鍵などへのアクセス権が必要です。codecommitを使えるようにIAMロールに権限を与えてね。”
CodeCommitは読み込むだけでいいので、ReedOnly権限を付与します。
余計にfull権限をつけるのは最小権限の原則に反しますのでつけないでおきましょう。
このようにすることでエラーが解消されます。
エラー その2
次にこのまま実行するとBuildでもエラーがでます。
CodeBuildで表示から以下を表示します。(フェーズ詳細を選択)
COMMAND_EXECUTION_ERROR: Error while executing command: aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com. Reason: exit status 1
トラブルシューティングのページはこちら
完成
デリバリー環境は以上の手順で完了です。
お疲れさまでした。
さいごに
今年はやったことがない分野の技術について追及してみようとやってみましたが、
公式情報は思ったより優しくはできてないですね。
試行錯誤の毎日です。
今回のデリバリー環境を作って感じたのはDockerの知識が尋常なく必要だなと感じました。
Dockerを認識していたのは以下のニュースでDocker Desktopがある程度の規模の会社だと使えなくなるのかなどのゴシップ、社内の掲示板とかで知ったくらい。
Docker Composerというのがあって、複数のコンテナを同時に動かすができるというレベルの知識。別の人がやっていたのを真似て作ってみたが、タスクが動かない状態になり諦めたやつ。
今回の検証でも公式が提供するイメージなどでもうまく動かせないことがあったので、一度Dockerを責めてみたいなと感じました。
今回もAWSをやる上で必要なその他周辺知識への大切さを含めて、またご紹介していきたいと思います。
ちなみにBlogではMarkdown記法とMarmaid。
あとはキャプチャのみで作るというのも試行錯誤で頑張ってます。
検証後のアウトプットでも新たな技術を学ぶというのは楽しいですね。
以上です。
Discussion