AWS CodeDeploy でデプロイしたときのhookスクリプトの場所

AWS CodeDeploy の hooks を使う際に直感と反する動きをする箇所があります。
その部分を予め理解しておかないと、罠にはまって悩みまくることになります。

CodeDeployのfilesセクションでコピーした後、コピー先のファイルを実行すると思いがちなのですが、そうではありません。
例えば以下のようなappspecを定義したとします。

version: 0.0
os: linux
files:
   – source: /
     destination: /home/ubuntu/hogeProject
hooks:
   ApplicationStart:
     – location: deploy.sh
       timeout: 180
       runas: ubuntu

この時に、「deploy.sh」は、「project-a」を暗黙的に期待します。
しかし、実際には、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive/deploy.sh」が実行されます。

これを図にすると下記になります。
「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive」にzipの中身が展開され、そこから、「files」セクションの内容に沿ってファイルがコピーされます。
コピーされた後、「hooks」セクションは定義に沿ってイベントハンドルをしますが、そこで指定したファイルは、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive」配下のファイルが実行されます。

image

なので下記のような処理をdeploy.shに記載すると問題が発生します。

docker-compose build
docker-compose restart

この際に、読み込まれるdocker-compose.ymlは、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive/docker-compose.yml 」になります。
ファイルコピー先を読み込ませたい場合は、次のようにしないとだめです。

docker-compose -f /home/ubuntu/hogeProject/docker-compose.yml build
docker-compose -f /home/ubuntu/hogeProject/docker-compose.yml restart

このあたりの説明は、公式ドキュメントだと、次のように記載されています。

DownloadBundle – このデプロイライフサイクルイベント中に、CodeDeploy エージェントはアプリケーションリビジョンファイルを一時的な場所にコピーします。

Amazon Linux、Ubuntu Server、および RHEL Amazon EC2 インスタンスの /opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive フォルダ。

クラスメソッドさんのBlogを読まないと理解できない部分がありますね。

参考

AWS CodeDeploy が途中で動かなくなった。次回はデプロイされない件の対応

EC2の載せているCodeDeploy Agentが不調かなと思いステータスを見たり、サービスをリスタートしたりしてみた。

sudo service codedeploy-agent status
sudo service codedeploy-agent restart
sudo service codedeploy-agent stop
sudo service codedeploy-agent start

それでも変化はなかった。仕方ないので、CodeDeploy Agentのログを確認してみた。

less /var/log/aws/codedeploy-agent/codedeploy-agent.log

ログを見ると不穏な文字が。

Could not acquire lock on /opt/codedeploy-agent/state/.pid/codedeploy-agent.pid.lock – aborting start!

なるほど。ロックが取れないから中断したぜと。
軽く調べても、あまりどうこうという情報が見つけられなかったので、消してみた。

いけた。

ネットワーク使用量が多すぎる?

Prometheus 2.7 の新しいサブクエリ機能は、一つのクエリでその可能性があります。

直近1時間のデータ受信量が、5分間の平均で1Mb/sを超えていた時間を知りたいでしょう。

bits/second で、5分間の平均使用量を取得する。

rate(node_network_receive_bytes_total[5m]) * 8

bool を使用して、値が大きいか小さいかに基づいて、0から1へ変更できます。

rate(node_network_receive_bytes_total[5m]) * 8 > bool 1000000

これまでは、記録ルールを作成するには次の行に進んでいました。
しかし、サブクエリはすることができます。

(rate(node_network_receive_bytes_total[5m]) * 8 > bool 1000000)[1h:]

1時間のRange Vector(範囲ベクトル)を取得するために計算できます。
通常は、「avg_over_time」を使用します。

avg_over_time((rate(node_network_receive_bytes_total[5m]) * 8 > bool 1000000)[1h:])

これは、アドホックに使用できます。

しかし、ルールで通常時に使用すると、サブクエリよりも記録ルールを使うほうが適切です。
サブクエリ結果の1時間の値を出すために、全間隔毎に再計算をすることを避けることができます。

Originalの意訳元:https://www.robustperception.io/how-much-of-the-time-is-my-network-usage-over-a-certain-amount

Git のGUIツールといえばGitKrakenで決まり!

永らく、Gitの管理ツールとして、Source Treeを使っていました。
4~5年使い続けてきて、これまでは乗り換えるほどの不満を持つことなく使ってきました。

しかし、今では、GitKrakenしか使っていません。
GitKraken はこんな感じの見た目のツールです。

image

こいつ見た目だけで選んだな?と思われたかはお待ちを!
見た目だけでなく、いくつかのお気に入りポイントがあって、これを使っています。

一つ目は快適
さくさく動きます。
カーソルをドーンと上下に動かしても、もっさりすることはないです。
開くまでも、まま早い。

二つ目はマージ衝突の解消がわかりやすくて、やりやすい
マージって、ストレスかかるじゃないですか。
やってて、なかなかぴんとこなくて、、、マージコンフリクトでマージし間違ったらイライラ。

GitKrakenで、コンフリクトした時の解消画面がこちら!

image

画面上部の左右に、コンフリクトしたコードが並んでいて、下部のウィンドウがマージ結果を表しています。
この状態で、上部のハイライトされている部分のチェックボックスにチェックを入れるとしたのウィンドウに反映されます。左右のチェックボックスにチェックを入れたり消したりすると、結果ウィンドウにそれらが反映されます。

めっちゃ視覚的いい。
これならマージの衝突解消頑張れる気がする。

三番目は操作が視覚的なところ。

マージやめたいなぁと思ったら、やめるためのボタンがあります。

image

マージしたいなーと思ったら、したいほうから、するほうにD&DすればOK。

D&Dすると、以下のようなメニューが表示されます。

image

あら素敵。

とまぁこんな感じで細かい些細な操作が一度使えば覚えられるわかりやすさがあるのです。
友達に教えてもらってGitKrakenを使い始めてから、SourceTreeをインストールしなくなりました。