CodeDeploy を導入したときに調べたことなど

はじめに

大分前に CodeDeploy について少し調べたことがありました。

tkaaad97.hatenablog.com

その後実際に CodeDeploy を導入する機会があってもう少し色々調べたり試したりしたことがあったのですが、導入したことに満足して調べたことをまとめていませんでした。

しばらく時間がたって忘れてるところもありますが、また使う機会もあるかもしれないのでここに書いておきます。

リビジョン作成

CodeDeploy ではデプロイするソースとして S3 か GitHub が使えます。 しかしデプロイ時に展開するものは GitHub で管理されているソースだけでは無いことが多いので S3 を使うことの方が多いと思います。 スクリプト言語の場合は依存ライブラリなども取得してデプロイする必要があります。 コンパイルする場合バイナリは Git 管理しないことが多いと思います。

S3 にファイルをアップロードしてリビジョンを作成するためのコマンドがあります。

docs.aws.amazon.com

しかしこのコマンドではあまり細かい制御ができないため結局使いませんでした。 隠しファイルを含めるかどうかというオプションがあるのですが一部だけ含めたりという指定ができませんでした。

dev.classmethod.jp

こちらの記事を参考に aws deploy push に相当する処理を行うスクリプトを作成してリビジョン作成を行うようにしました。

場合によっては CodeDeploy でのインストール処理とは別に Ansible Playbook などを実行して独自にインストール処理を行うということもあるかもしれません。 この場合は CodeDeploy でインストールするのは Ansible のファイルだったりリビジョンに含めるものは変わってくると思います。

ソース配置ディレクトリをアプリケーションによって変えたい

CodeDeploy でどのディレクトリにソースを配置するかは appspec.yml で指定します。 files の destination の部分です。

docs.aws.amazon.com

あまり普通はやらないし推奨されないと思いますが 複数のアプリケーションを同一のサーバーにデプロイする場合 ソース配置ディレクトリが同じになってしまいます。

アプリケーションごとに appspec.yml を変えるといった方法は無いようでした。 しかしリビジョン作成時に appspec.yml を書き換えるという無理やりな方法で一応は目的のことができました。

デプロイグループごとにデプロイ処理を変えたい

同じソースをデプロイするサーバーでも色々と役割が違うものがあります。 例えばウェブサーバーがあったり、分析や集計などを行うサーバーがあったりして、 役割ごとにデプロイグループを分けるのが普通だと思います。

デプロイグループごとに変えるには CodeDeploy で提供されている環境変数を使うことができます。

docs.aws.amazon.com

APPLICATION_NAME と DEPLOYMENT_GROUP_NAME の環境変数があるので これに基づいて設定ファイルを読み込んだり、AWS Systems Manager パラメータストアから設定を取得し デプロイの処理を変えることができます。

オートスケーリンググループに複数のデプロイグループを付けられるか

複数のデプロイグループに同じオートスケーリンググループを設定することはできるんですが、 試したところこれはやめたほうがいいということが分かりました。

問題はオートスケーリングでインスタンスが新しく追加されたときに 両方のデプロイグループのデプロイ処理が同時に動いて正常に動作しないという点でした。 オートスケーリングを使っていない EC2 タグでデプロイを行っている場合はそんなに問題ないかもしれません。 同時にデプロイしたりするとエラー起こりそうですが。

デプロイごとに処理を変えたい

複数デプロイグループを作ろうとしたのは同じ役割のサーバーでもデプロイを行うときに処理を変えたい場合があったからでした。 先に書いたように複数デプロイグループで分岐するのは上手くいかなかったため、 リビジョン作成時にファイルを追加してこのファイルを読んで処理を分岐するというような方法を使いました。

オートスケーリンググループに複数のロードバランサーが付いている場合

複数のロードバランサーには CodeDeploy は対応していないようです。 複数のロードバランサーを使うのは諦めるか、自前でロードバランサー関連の処理を行うことになります。

オートスケーリンググループのインスタンスは全てをロードバランサーに付けるか外すかの二択かと勘違いしていたのですが、 オートスケーリンググループ中の個々の EC2 インスタンスごとにロードバランサーから一時的に外したりということができます。

docs.aws.amazon.com docs.aws.amazon.com

インプレースデプロイの場合はアプリケーションストップ時にロードバランサーから一時的に外し、 デプロイが終わってアプリケーションスタート時にロードバランサーに付けるという感じのことができるようです。

この処理については GitHub に公開されていたサンプルが参考になりました。

github.com

Blue/Green デプロイの場合はオートスケーリンググループ自体が複製されてインスタンスも全て入れ替わるということになるらしいです。 この場合ターゲットグループやロードバランサーとの紐付けもそのまま引き継がれるのかどうか疑問ですがインプレースデプロイを使うことにしたため詳しく調べていません。

シンボリックリンクが壊れるバグ

github.com github.com

シンボリックリンクが通常のファイルに変わってしまうという問題が起こる場合があるようです。 この挙動で問題が起こる場合はデプロイ処理内でシンボリックリンクを作るようにするなどの対応が必要になりそうです。

導入してみての感想など

少し融通がきかないところがあったり、色々と疑問に思ったところがドキュメントに書かれていなかったりして 全く不満が無いわけではないですが CodeDeploy まあまあ便利だと思います。 CodeDeploy 前に使っていたデプロイ方法が色々と問題があったためそう感じるというところもあると思います。

便利と感じるところはオートスケーリングと一緒に使えて新規インスタンス追加時に色々な処理が行えるところや、 デプロイの履歴やインスタンスごとに起こったエラーなどが簡単に調べられることなどです。