GitHub Actions移行時についでにやったやつ
新旧構成
モチベーション
capistrano-itamaeではインテグレーションテストのためにsshできるVMが必要だったのでVagrantとDigitalOceanを使ってました。
しかし下記のような理由でCIのDockerizeをしようと考えました
- VM作成にはDigitalOceanのアカウントが必要なので、第三者がPRを送る時にローカルで手軽に動作確認できない。（CIでは僕のアカウントでDigitalOceanが使えるようにしてます）
- リモートにVMを作るのでローカルにVMを作る場合と比べてオーバーヘッドがある
- 不慮の事故でリモートのVMが残り続けると課金が発生するので定期的にcronでチェックする必要がある
- CIで毎回Vagrantのインストールするのに時間かかる。（30秒程度）
- CIで起動されたDockerコンテナから別のDockerコンテナを起動するのはだいたいのCIサービスで対応してる
- Werckerが今の自分の中ではレガシー構成
実際の差分
Dockerコンテナに対してcap deployするのは下記エントリが参考になりました。
ちなみに最初はCircleCIを使う予定だったのですが、GitHub Actionsはローカルにコンテナを作るのに対してCircleCIだとリモートにコンテナを作る関係で
docker image build . -t ssh_server docker run -d -p 10000:22 ssh_server
のような感じでコンテナを起動した時に、CircleCIだと10000番ポートに通信できなかったためボツになりました。 *1
ボツPR
まとめ
- Dockerizeしたことによりモダンな構成になった
- CIからVagrant依存をはがせた
- リモートにコンテナを作るかローカルにコンテナを作るかの挙動の違いもCI選択の理由になるという学びがあった
*1: https://circleci.com/docs/ja/2.0/building-docker-images/ にも「ジョブとリモート Dockerはそれぞれ異なる隔離された環境内で実行されます。 そのため、Docker コンテナはリモート Docker 内で稼働しているコンテナと直接やりとりすることはできません。」って書いてる
