はじめに
CI/CDのパイプライン導入のための学習のモチベがあったので、AWSで何か使えそうなハンズオンないかなと見てたところ、CodePipelineでCI/CD導入というよさそうなハンズオンがあったので学習記録を残しました。
ちなみに僕の経験でいうと、過去CodePipelineを使ってリリース作業を簡略化したプロジェクトのシステム開発に携わっていたのでリリースで日常的に行った経験がありメリットは把握してるが、CodePipelineの構築には関わってないので、0ベースで構築する方法を知らないというレベル感で、そこそこのモチベーションがありました。
記事は下記の流れで行きます。
- CodePipelineの概要
- CodeDeployの概要
- ハンズオン学習記録
- 感想
CodePipelineの概要
CodePipelineはデプロイメントパイプラインのサービス。
デプロイメントパイプラインとはアプリケーションリリースに欠かせない下記工程を自動化するプロセスのこと。
- ソースコードビルド
- テスト
- ステージングデプロイ
- 本番デプロイ
上記資料では、よくある課題としてデプロイ職人の記載があり、デプロイ担当者にありがちな項目が記載がされています。
この課題解決のためにCodePipelineが提供されています。
ビルド・テスト・デプロイのワークフローをAWSのUI上から行うことができ、各ワークフローの振る舞いはデフォルト提供されてるアクションやカスタムアクションから選べるので、デプロイ時に手動で行っていた工程の要件を満たすカスタムを定義することでデプロイ自動化をすることができる。
CodeDeployの概要
サーバにアプリケーションコードを反映するサービス。
CodePipelineのワークフローにおいて各サーバへのコードデプロイするのはこのサービス。
ハンズオン学習記録
今回使うハンズオン下記です。
「AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, Amazon ECRを使って、N-Queens問題 を計算するAWS Batchをデプロイするパイプラインを作成します。」というセッション内容です。
選んだ理由はシンプル構成で、メインで学習したい自動デプロイ(CodePipeline)のコンテンツに重きがあるためです。
では早速やってきます。
特に記載ないセクションはガンガン飛ばしていきます。
あとハンズオン資料とのバージョン違いで微調整した箇所は軽く記載しておきます。
1.事前準備
1.1.1. 実行するIAMユーザー/ロールの確認
まだアカウント作成後間もないので、IAMユーザー作成とロール付与をしていく。
検証用で適当にユーザ作成、AdministratorAccessの権限付与をして完了。
コンソールアクセス時は忘れず東京リージョンを選んでおく。
1.1.2. Cloud9環境の作成
アクセス権付与
rootユーザのままCloud9にアクセスはできない...?
一旦実行ユーザーからコンソールへのアクセス権を付与する。
画面操作をすすめるとサインインURLや認証情報が発行されるのでメモっておく。
再度実行ユーザからcloud9にアクセスしてみる。
アクセスできないだと...。
リンクをみるとcloud9への新規アクセスは終わったとのことで、AWS IDE ToolkitsかAWS CloudShellを使ってねとのことだった。
Toolkitはvscode用が提供されてるのでそれで進めて、必要に応じて資料を読み替える。
1.2. AWSリソースの作成
1.2.2. CloudFormationの実行
CloudFormation構築時にファイルインポートを選んで1.2.1でダウンロードしたファイルを指定する。
スタックはデフォルトで作成。
作成後しばらくすると、ステータスがCREATE_COMPLETEとなることを確認できる。
作成されたCloudFormationのスタックのリソースを見てみると、サブネットやbatchなどハンズオンで使うリソース諸々の紐づけが確認できる。
2. 手動デプロイ
2.2.2. アプリケーションの準備
N-Queens問題のコンパイルはターミナルからすすめる。
curl -O https://www.arch.cs.titech.ac.jp/~kise/nq/package/qn24b-version1.0.tgz
tar -zxvf qn24b-version1.0.tgz
gcc -O2 version1.0/base/queens.c -o queens
./queens 16
qn24b base version 1.0.1 2004-09-02
...
2.2.3. アプリケーションのコンテナ化
コンテナ化はCloud9ではなく、vscodeのtoolkitで行う。
コンテナ化の為にはdockerコマンドを叩ける環境で、ECRにコンテナ登録するために予めtoolkitからawsへのアクセス設定が必要。
dockerまわりの記載は割愛。
toolkitからawsへのアクセス設定
アクセス設定のためにこの設定が必要と思われる。
IAMに対しCLIで使う認証キーを作成。
作成完了したら認証情報をメモっておく。
そしたらvscodeのIAM Credentialsから接続する。
成功したようなレスポンスは帰ってきてるんだけど、ダッシュボード上は何も変わってないような...
接続はうまく行ってなさそうだけど、認証情報はローカル上に作成されていたので別の方法で再トライ。
コマンドパレットからAWS Connectionを選んでさっき作ったプロファイルを選択。
その後リージョン選択が出るのでTokyo選択し、接続成功。
ここまででアプリケーションのコンテナ化準備が整ったと思われるので、引き続き進める。
下記のDockerfileを作成する。
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
COPY ./queens /usr/local/bin/queens
# program execute
CMD /usr/local/bin/queens 16
dockerビルドからqueensコマンド確認まで。
❯ docker build -t queens .
[+] Building 9.5s (7/7) FINISHED docker:default
...
=> => writing image sha256:4e83c22fb34f658a80e372b61b19ada53bef960ab7b1805f4bb43be3640d01fc 0.0s
=> => naming to docker.io/library/queens 0.0s
...
❯ docker run queens
qn24b base version 1.0.1 2004-09-02
これでqueensコマンドを集約したコンテナイメージができたので、ECRへの登録を進める。
2.2.4. コンテナイメージをレジストリへ登録
さっき作成したECRの詳細を見るとプッシュコマンドが見れるので、手順通りコンテナイメージをレジストリへ登録する。
手順中でAWS CLIが必要だったので下記参考にインストール。こちらもざっくり割愛。
ちなみにプッシュコマンドの実行は予めaws configureで認証を通す必要があった。
2.2.5. 登録したイメージの動作確認
前手順で登録されたイメージの動作確認のために、ECRのURIをコピーしてdocker runにつなげて実行する。
❯ sudo docker run ***.dkr.ecr.ap-northeast-1.amazonaws.com/queens
qn24b base version 1.0.1 2004-09-02
...
無事にローカルでの実行時と同様の動作確認がとれたので問題なし。
2.3. AWS Batchジョブ定義の更新
2.3.2. Job Definitionの更新
ファーゲートのOSのLinux選択と、タグ名の微調整が必要なこと以外はハンズオンと同様。
2.4. AWS Batchジョブの実行
バッチ実行後は成功してるがログが遅延があるが、cloudWatchには早めに出力されていて、queensコマンドの実行結果が確認できる。
3. 自動デプロイ
自動デプロイがテーマなので、本腰入れて学習したいのは特にこのあたり。
3.1. CodeCommitリポジトリの作成
CodeCommitも使えなくなってるが、githubリポジトリとすり替えて確認をすすめる。
3.3.3. リポジトリへpush
この時点で一旦作成したリポジトリはこちら。
3.4.1. パイプラインの作成
パイプライン作成時にテンプレート・カスタム選べるが多分現行使用との差分。
今回のソースプロバイダはgithubを選ぶ。このときにaws連携用の設定が必要なのでポチポチして設定する。プライベートリポも難なく見れるようだった。
パイプラインの各ステージでアクションフックできるので、
本番デプロイ前の自動テスト稼働などする際の設定値はここをいじることになりそう。
ちなみにこのパイプライン画面の変更リリースボタンからもパイプラインが発火できる。
過去にリリース作業する際によく使ってたボタン。
ジョブ定義のテンプレートjsonのARN設定を忘れて権限周りで時間かかってしまったが、
気づいてからの修正後は、特に引っかからずにパイプライン成功までいけた。
3.6.3. 実行結果の確認
バッチの最終的な実行結果も問題なく行けた。
感想
ハンズオンの作成時期との差分で微調整は必要でしたが、最終章まで問題なく進めることができました。
CodePipelineの導入作業の流れを把握するために良さそうな資料探りで見つけたこのハンズオンは、
基本的なCI/CDを組む上で勉強になる内容が多く、短時間で学習することができておすすめでした。
監視対象のリポジトリへのコミットを検知してカスタムアクションを組めたり、段階的に成功した場合の処理を見やすいダッシュボード上から設定できるので、活用方法は様々だと思います。
ふと思ったんですが、vscodeに入れたtoolkitの出番が全然なかったですねー残念。
今後の学習では一歩踏み込んで、ビルドアクションでテスト稼働させる機構を組んで成功時だけEC2環境へのデプロイが可能になるような、割と実践的なパイプラインを組んでみるのも良さげに思ってます。
「ワークスタイルの未来を切り拓く」を理念に掲げ、リアルとデジタルの2つの働く場に向けた事業展開に留まらず、自社が率先して新しいワークスタイルに挑戦し、発信を行うことでワークスタイルの未来を切り拓いていきます。
Discussion