なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

AWS CodeDeployについて書いておく

AWS 技術系 運用

CodeDeployはAWSが提供しているアプリケーションコードデプロイの仕組みで、各サーバに特権で動くagentをあらかじめインストールしておき、CodeDeployにデプロイ指示を出すと、agentがコードをダウンロードし、サーバ上で任意のコードを実行することで、アプリケーションのデプロイをするというもの。

これだと、単なるプル型デプロイの仕組みのように見えるが、実際には少しだけ高機能なところもあって、例えばAutoScalingGroupに対してまとめてデプロイしたり、EC2インスタンスに結びつけたタグを元にデプロイ対象を選択することもできる。

一番便利なところはおそらくロードバランサーとの強調動作で、ELBのようなロードバランサーから一時的に隔離しながらデプロイをすると綺麗にデプロイができる。

さらにはインスタンスごと切り替えるいわゆるBlue/Greenデプロイの仕組みも用意されているので、Javaのアプリケーションのように再起動を避けられないプログラムでも比較的安全な自動デプロイの仕組みを比較的簡単に用意できる。   とはいえ、この辺りはAWSの機能にベッタリなため仮にAWSから引き上げる時には足枷になるような気はする。 同じような仕組みを用意するのはやや骨が折れる。 まあ、AWSの場合はCodeDeployだけの問題ではなく、ELBやアクセス権限周りの話もあるのでどのみち引き上げる時は面倒か。   あと、EC2が提供しているイメージ以外は自前でagentをインストールする必要があるが、agentはruby製なのでシステムにRubyを入れる必要はある。

まあ、この点はRubyの場合アプリケーションコードを動かす目的ではよくrbenvが使われるため、システムワイドにインストールしたRubyの影響を受けることはほぼないと考えていいと思う。   特権で動く点も気になるという人もいるとは思うが、アプリケーションコードのデプロイ作業ではなんだかんだで特権が必要になるケースはある。

実際に動かすアプリケーションコードは権限を落として実行すればいい。 この辺りはsystemdになって書きやすくなったと思う。悪くない。  

CodeDeploy Agentのインストール

  CodeDeployの場合、特に公式ドキュメントの日本語がややおかしい気もするけど自動翻訳とか使ってる可能性もあるなーという感想です。   気が向いたらgithubに公開されているドキュメントにコントリビュートするといいかもしれない。(これは一般的な話なんですが、AWSでもよく使われる場所のドキュメントは整備されているので、裏返せばCodeDeployはあまり使われていないのかもしれないですね)   * Amazon Linux または RHEL の AWS CodeDeploy エージェントをインストールまたは再インストールします。 * https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/codedeploy-agent-operations-install-linux.html  

CodeDeployにサービスロールをつける

  CodePipelineとかはこの辺り自動的に設定してくれたような気もしていたけど、CodeDeployだと自分で用意する必要があるっぽい。面倒だがそういうものなら仕方ない。   codedeploy.amazonaws.com を信頼したエンティティにして、CodeDeployに適切に権限を与える。  

EC2インスタンスにS3のアクセス権をIAM Roleで与える

  CodeDeployのagentでS3からコードを取ってくるようにしている場合、取ってくるためのS3バケットへのアクセス権が必要になる。

これの設定自体は大したものではないので、単にEC2にアクセス権を与えておけばいい。  

s3バケットのバージョニング

  コードのバージョン管理にS3のバージョニング機能を使うことができる。これはコードが動かない場合にrollbackをしたい場合に便利。  

CodeDeployにpush

  アプリケーションコードをCodeDeployにpushすると、デプロイタスクが作られagentがコードを取りにいく。

gitリポジトリだとデプロイ対象には含めたくない例えば .git などがいるので、デプロイ前のタスクで対象のファイルのみ別ディレクトリに書き出しておき、アーカイブするのが綺麗な気はする。

で、実際にはこのタイミングではWebだとassetのビルドとかがあるし、いわゆるビルドタスクなのかもしれない。まあ普通か。   デプロイについて気をつけないといけないのは、サーバ台数が最低でも2台必要になる点。

これは最低でも1台ごとにアプリケーションを切り替える都合、1台では一時的にダウンしてしまうため、CodeDeploy側で制限されているため。

検証環境みたいなところだと、この制限がやや邪魔だなあと思うこともあるが、検証環境へのデプロイは別の方法でやればいい。共通ができないじゃないか。やれやれ。   最低台数の話ついでに、デプロイをどの程度まとまった台数行うかどうかは設定で決めることができて、1台ずつ、半分、全部と選ぶことができる。

1台ずつは徐々に切り替わっていくので、LBから外れる台数も少なくデプロイ時の負荷に余裕はあるが時間がかかる。

半分は速度優先。LBから外れる台数も半分なので、負荷が高い時には厳しい選択かもしれない。

全部はなんだ、ワイルドだな！  

終わり

  まあ、使えるといえば使えるんだけど、Webコンソールは開発者にはあんまり親切じゃないかも。雰囲気だけど。どうすればいいかというのも難しいので仕方ないか。   とりあえず使えはするし、AWSの仕組みとは親和性はそこそこよいという感想だけど、AWS以外で使えないんだよなあ...いやそれは違うか。使えはするけど利点があんまりないというか。

プル型のデプロイツールについてはあんまり調べてないけど、自前で作るのはそこそこ手間だし、何かないかなという気持ちはありますね。

クラウドだと、インスタンスをポコポコ立てたくなるし、そういう時にデプロイ対象を増やすよりは勝手に拾ってくれる方が向いてる。   とはいえ、作るのは多少手間ではある。やれやれ。