capistrano-itamaeのCIをDockerizeした

GitHub Actions移行時についでにやったやつ

github.com

sue445.hatenablog.com

新旧構成

• æ—§
  • Vagrant
  • DigitalOcean
  • Wercker
• æ–°
  • Docker
  • 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が今の自分の中ではレガシー構成

実際の差分

github.com

Dockerコンテナに対してcap deployするのは下記エントリが参考になりました。

qiita.com

ちなみに最初はCircleCIを使う予定だったのですが、GitHub Actionsはローカルにコンテナを作るのに対してCircleCIだとリモートにコンテナを作る関係で

docker image build . -t ssh_server
docker run -d -p 10000:22 ssh_server

のような感じでコンテナを起動した時に、CircleCIだと10000番ポートに通信できなかったためボツになりました。 *1

ボツPR

github.com

まとめ

• Dockerizeしたことによりモダンな構成になった
• CIからVagrant依存をはがせた
• リモートにコンテナを作るかローカルにコンテナを作るかの挙動の違いもCI選択の理由になるという学びがあった

*1: https://circleci.com/docs/ja/2.0/building-docker-images/ にも「ジョブとリモート Dockerはそれぞれ異なる隔離された環境内で実行されます。 そのため、Docker コンテナはリモート Docker 内で稼働しているコンテナと直接やりとりすることはできません。」って書いてる