AWSでCI/CDを200%活用する方法【MEGAZONECLOUD CTCブログ翻訳】

はじめに

この記事はMEGAZONECLOUD Cloud Technology Center Tech Blog記事の翻訳版です。

AWS CodePipelineを活用しCI/CDを適用する

執筆者: ペク・ソジョン

最近アプリケーションの開発、どのようにしていますか？ モダンアプリケーション開発方法論ではCI/CDはすでに基本となっていますが、AWSでもこのようなCI/CDを200%活用することができます。😎

AWSではCI/CDを適用するためAWS Code Seriesというサービスを提供しています。 ここにはCodeCommit、CodeBuildおよびCodeDeployが該当しますが、このサービスを利用するとコードパイプラインを構成し、便利にコードを管理、ビルドして配布することができます。 何よりもAWS Code Seriesを利用すると、他のCI/CDサービスよりも簡単かつ強力にAWSサービスと連動できます。

CodeDeployはコードパイプラインを構成する最も中心的なサービスです。 EC2のようなサービスにコードを配布すると仮定すると、直接コミットとビルドした後、ターミナルを接続してリポジトリから再び持ってきて配布するなどの様々な手順を直接進める必要があります。(ft.intergration hell🤯)

一方、CodeDeploy使用してAWSリソースにコード配布を自動化すると、上記のような作業をいちいち行う必要ありません。 単純なコードの修正が発生したり、Auto Scaling Group内のインスタンスが新しく生成されるたびに、CodeDeployが私たちの代わりにコード配布してくれますので！

今回AWS Code Seriesを学習しながら、Githubのリポジトリに保存されたソースコードをCodeCommitでマイグレーションし、CodeDeployでコードを配布するコードパイプラインを生成してみました。
全体過程を復習することを兼ねて、整理して共有したいと思います。

過程

　　　　　　　　　　　　生成するAWS CodePipelineの流れ

AWS Code Seriesを200%活用するためには、既存のGithubで管理中のソースコードをCodeCommitにマイグレーションする必要があります。

GithubからCodeCommitへのコードマイグレーション手順は以下の通りです。

1. IAMページでユーザーにCodeCommitPowerUser policy指定
2. HTTPS Git credentialsダウンロード
3. CodeCommitページでリポジトリ作成
4. git cloneコマンドでGithub内のコードをローカルPCに移動
5. git pushコマンドでGithubに保存されたコードをCodeCommitに移動

IAMページでCodeCommitを使用するユーザーにAWSCodeCommitFullAccessポリシーを追加します。 該当ポリシーがないと、ユーザーがCodeCommitリポジトリを生成し、その中にコードをpushするなどの作業を進めることができません。

該当ユーザーページ内のSecurityCredentialsタブ内のHTTPS Git credentials for AWS CodeCommitをダウンロードします。該当Credentialを通じてCodeCommit作業に対する認証が必要なときにHTTPSで認証します。

CodeCommitを使用するための事前準備を終えたので、 CodePipelineページ内のCodeCommit タブでリポジトリを生成します。

リポジトリが生成されると、次のような画面が表示されます。 該当ページのStep3にあるリンクがリポジトリリンクです。

git clone ${GitHub URL} ${Local Directory Name} コマンドで、GitHubからローカルPCにコードをcloneします。ls コマンドでコードがローカルPC内のcode-test-scriptディレクトリにcloneされていることを確認しました。

git push ${CodeCommit URL} コマンドでローカルPCにあるコードをCodeCommitにpushします。

Pushするときに入力するように出てくるUsernameとPasswordには、先ダウンロードしたユーザーのHTTPS Git Credentials情報を入力します。Credential情報を正しく入力すると、コードがpushされます。

CodeCommit内のリポジトリにコードがpushされていることを確認します。

次に、CodeCommit 内のコードがAuto Scalingグループ内に自動配布されるようにCodeDeployと接続してパイプラインを作ります。 順番は下記の通りです。

1.IAMページでCodeDeployおよびEC2に対するロール生成
2.CodeDeploy agentをインストールしたAMIでASG Launch Template生成およびASG 生成
3.CodeDeployページでApplicationおよびDeployment group生成
4.CodePipelineページでSource providerおよびDeploy providerを選択し、パイプライン生成

IAMロール生成ページでTrusted entityをCodeDeployに選択するとAWS Code Deploy Roleポリシーの1つだけ表示されます。 該当ポリシーを選択してロールを生成します。

このロールを通じてCodeDeployがEC2またはAuto Scaling Groupにコードを配布し、一連の作業を進めます。

EC2に対するロールも生成します。Trusted entityはEC2を選択し、ポリシーはAmazon EC2 Role for AWS CodeDeployを選択します。
該当するロールを通じてCodeDeploy agentがインストールされたEC2はS3からRevisionを受けます。 Revisionは、CodeDeployがインスタンスに配布するソースファイルのバージョンを保存し、S3に保存されています。
IAMロール作成が終わったら、CodeDeploy agentがインストールされたインスタンスAMIを作成します。EC2にCodeDeploy agentがインストールされていないと、CodeDeployがそのインスタンスターゲットにコード配布することができません。

sudo yum update
sudo yum install ruby
sudo yum install wget
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto

上のスクリプトでCodeDeploy agentをインストールします。

CodeDeploy agentインストールが完了したら、そのインスタンスのAMIを生成します。 生成したイメージでLaunch Templateを生成した後、そのテンプレートでAuto Scaling groupも生成します。

ASG設定完了後、CodePipelineサービスページに戻り、CodeDeploy Application およびDeployment groupを生成します。

Applicationは簡単に一つの配布単位と見ることができ、Deployment groupは当該Applicationに対する配布対象および配布方式を設定するグループだと理解できます。

DeployタブでApplicationを生成します。
ここでコード配布をAuto Scaling group内のEC2に配布する予定なので、Compute platformをEC2/On-premisesとして選択します。Applicationはこのように簡単に生成が終わります。

次に生成されたApplicationページ内でDeployment groupを生成します。
Service roleはIAMページでCodeDeployをTrusted entityとして生成したCodeDeployServiceRoleを選択します。

Environment configurationではAuto Scaling group内のEC2ターゲットへのコード配布のためにEC2 Auto Scaling groupsおよび生成したグループを選択します。
CodeCommitリポジトリおよびCodeDeploy Application & Deployment groupがすべて用意されましたので、待望のパイプラインを生成してみる番です。

パイプラインタブでパイプラインを生成します。 パイプラインについては、別途生成したロールがないため、コンソールで生成するようnew service roleを選択します。

新しく生成したCodeCommitのリポジトリ内にソースコードがあるので、ソースでAWS CodeCommitを選択します。 Githubで管理するコードで配布したい場合は、Githubをソースで選びます。 その後、一連の認証を経れば、Githubソースを設定することができます。
CodeCommitに保存されたコードは、ビルドステップが別に必要ではないため、ビルドステップはスキップします。

Deploy stageでCodeDeployをDeploy providerに選択し、生成しておいたApplicationとDeployment groupを選択します。

パイプラインが生成されると、自動的にパイプラインが実行され、CodeCommitからコードを持ってきて、Auto Scaling group内の配布まで進みます。

インスタンスIPを入力して確認してみたらコードがうまく配布されました！🎉

CodeCommit内のコードを修正したら、すぐにトリガーされて再び配布されます。

Tadaa!! 修正されたコードが反映され配布されたことを確認しました。

Auto Scaling groupで新しいインスタンスが起動されると、このインスタンスと同様にコードが自動的に配布されます。
Initiated byを見ると、Autoscaling group actionとなっています。 つまり、Auto Scaling groupで新しいアクションがあって、これによって自動的に配布されたという意味です。

最後に

AWS Code Series 入門者が該当サービスを使用しながら感じた最大の長所は、断然強力なAWSサービスとの連動です。AWS上で開発·配布を進める際には、AWS CodeSeriesのような強力なツールを使ってみることをおすすめします。👍

その他のエラー事項

CodeDeployで数多くのエラーを見ながら記念に撮っておいた写真

初めてCode seriesを学習しながら上のイメージのように数え切れないエラーメッセージを見ました。🙄しみじみリサーチしながら解決してみたら些細なミスが多かったです。もし私のようなエラーメッセージを見ることになる方がいたら参考できるよう、記録しておきたいと思います。

1. パイプラインが実行され、配布段階で‘CodeDeploy agent was not able to receive the lifecycle event’のようなエラーメッセージが出てきました。

インスタンスに入ってCodeDeploy Agentが順調に実行されているか確認してみました。
Agentはちゃんと起動していたのでless /var/log/aws/codedeploy-agent/codedeploy-agent.log コマンドでCodeDeployログを確認してみました。

Credentialがなく、IAMインスタンスプロフィールがあるか確認するようにという部分がヒントでした。 考えてみたらEC2に対するロールを作っていなかったんですね。

IAMページに戻ってAmazonEC2RoleforAWSCodeDeploy policyを追加したEC2ロールを生成しました。
そのロールを連結したインスタンスイメージをASGテンプレートイメージに修正し、ASG内にあるインスタンスを再びrefreshさせました。 IAMロールが関連付けられていない既存のインスタンスは削除され、新しいインスタンスが生成されました。

CodeDeploy Deployment group再生成後に再びパイプラインを回すと問題が解決されました！

2. 配布が始まると、Deploymentページで配布のどの段階が進んでいるかを確認することができます。 Installの段階でエラーが出たりもしましたが、これは(当然ながらその時は知らなかった..)スクリプトの問題でした。 例とえば、「yum install」の後ろに「-y」がなく、インストール確認について回答を受けられないため、Install段階でエラーが発生しました。

3. 確かにAuto Scaling group内にrunning状態のインスタンスがあるにもかかわらず, ‘No instance found..’のようなエラーメッセージが表示されました。 この時は主にASGに対する修正があった時でしたが、この時Deployment　groupを再生成していただければ問題なく再配布が行われました。

Fin.