今自社のサービスをAWS上で運用していますが、CI/CDの仕組みを整備しなければなあと思っていたところで、ひとまずAWS上で提供されているCI/CDサービスをさらっと理解したく、「Amazon Web Services アプリ開発運用入門」をトレースしてみました。

AWSが提供するCI/CDサービスの中で、本書では以下の利用を体験できます。

CodeCommit : ソースコード管理サービス
CodeBuild : ビルドサービス
CodeDeploy : デプロイサービス
CodePipeline : リリースプロセスの自動化サービス

いずれもAWSではごく当たり前となっているフルマネージドサービスで、利用者からするとごく簡単なCUI, GUI経由の操作だけで環境構築ができます。

参考までに、フルマネージドサービスの定義をこちらから引用しておきます。

「フルマネージドのサービス」は、利用者がサービスを利用する際に、「コンピュータ障害監視・バックアップ・ソフトウェアのバージョンアップ」など「運用に関わる作業」をクラウド業者が行ってくれる形態のサービス

最終目的である、CodePipelineでのCI/CIパイプラインの構築がChapter4（全部でChapter8あります）ですが、Chapter4まで終えるのに、自分の場合2時間程度で済みました。

内容がそんなに濃くない？とも言えますが笑、さらっと体験したい方には打ってつけではあると思います。

さて、本書の内容は手取り足取り丁寧な内容となっているので、書籍の発行日が2019年2月1日で本記事執筆日(2020/4/26)から1年以上前であるものの、多少の画面の変更はありつつ、今でも十分トレースできる内容となっています。

ですが、一瞬詰まったところがないではなく、せっかくなのでメモしておきます。

Chapter2-2 Step9 Gitクライアントの設定

GitクライアントにAWS CLIの認証情報ヘルパーを使用する設定するプロセスがあります。

ここで以下のコマンドを実行しろ、とあります。

$ git config --global credential.helper "!aws codecommit credential-helper $@"

しかしこのまま先のプロセスに進むと、ローカルレポジトリからコミットをプッシュするgit pull時にusernameを聞かれてしまい、認証情報の設定がうまくいっていないことが分かります。

原因と対処方法はこちらの記事にありました。

vi ~/.gitconfigでgitconfigの内容を確認してみると、

[credential]
helper = "aws --version codecommit credential-helper "

となっているので、これを修正しましょう。

[credential]
helper = "!aws codecommit credential-helper $@"

Chapter2-3 Step1 CodeCommitリポジトリURLを取得

リポジトリのURLのクローンのところで、「HTTPSのクローン」が指定されています。

これで初回のリポジトリアクセスは可能なのですが、しばらく経ってからアクセスすると、

$ git pull origin master
fatal: unable to access 'https://git-codecommit.us-east-1.amazonaws.com/v1/repos/awesome-app/': The requested URL returned error: 403

と、403エラーが返ってきてしまいます。

これの原因と対処方法ですが、こちらの記事にありました。以下、引用します。

OSXにプリインストールされているGitは、credentialを保存するのにKeychain Accessを使います。ですが、セキュリティ上の理由からCodeCommitへアクセスするためのcredentialはテンポラリなものであるため、リポジトリに初回アクセスした際に保存されたcredentialは約15分後には使えなくなります。

なんと。そういう仕様にせざるを得ないんでしょうか。

とにかく、Keychain Accessは運用上は使えないので、引用記事中に示されているいずれかの方法を代替として対処する必要があります。

個人的には、sshでアクセスするのが最も楽で、環境も汚さなくて良いと思います。

手順は以下公式にある通り。手順通りにやれば問題なくできます。

Chapter4-3 Step1 アプリケーションの差分ファイルをリポジトリにマージ

最後に、些細な点。

アプリケーションの差分ファイルが含まれる4-3.zipのsrcディレクトリに、Application.javaが含まれていないので、srcディレクトリごと上書きするとbuildに失敗します。

ここは表示メッセージを書き換えるだけですし、HelloWorldController.javaを直接書き換えてしまうのが良いと思います。

AWSのCI/CDサービスに対する所感

実際にCodePipelineでリリースプロセスの自動化を体験してみましたが、一度パイプラインを作ってしまえばデプロイまでは非常に早く、開発環境のようにテスターとインタラクティブにやりとりしたい環境ではなかなか有用ではないかと思いました。

CodeCommitについてはGitHubやBitbucketといった他のVCSと比較して細かい機能が十分でないという話を聞いたりするので、実際に業務で利用するには「痒いところに手が届かない」があるのかもしれませんが、CodeCommitの代わりにGitHubを使うことはできるので、マイクロサービスとしての利点を生かせばやはり有用なのかなと思っています。

あとはAWSのサービスに限らないですが、CI/CDのプロセスを作り込むことでリリースプロセスの柔軟性はなくなるわけなので、人間がプロセスに合わせていくのか、プロセスを人間に合わせていくのか、という問題は残るかと思います。