インフラエンジニアの平塚です。
今回は昨年紹介しましたランサーズのリリースシステムを刷新したのでご紹介します。
背景
理由としては増えてゆくサービスを個別にリリースしていくのは手間がかかり、
これを1つのWeb UIからリリースできるようにすることでリリースを容易にしたい。
また、スケールアウト時に最新ビルド済みソースコードを取得したいと思ったからです。
これまでの課題
- リリース対象のIPアドレスをconfigファイルに直接記述していてスケールする度に修正が必要
- https://www.lancers.jp以外はCLIベース又は手動でのリリースを行なっていたので手順を確認しながらリリースする必要があった。
これまでと現在の比較
簡単にこれまでと現在のリリースシステムの違いを説明します。
【以前】
・社内オンプレミスサーバに構築
・fabricsを使用したデプロイ
・デプロイ対象はhttps://www.lancers.jpのみ
・buildは手動実行
【現在】
・AWS EC2上にリリースシステム構築
・Ansible + rsyncを使用したデプロイ
・ランサーズが運営するすべてのサービスのリリースをWeb UIにて実行可能
・リリースシステム上でDockerコンテナを立ち上げ、コンテナ内で自動build
Ansible、rsync、Dockerをどのように使ったのか
【Ansible】
リリース対象のサーバにシェルスクリプト配布し、そのシェルスクリプトを実行する。
※このシェルスクリプトにはrsyncを実行する処理が書かれています。
【rysnc】
Ansibleで配布したシェルスクリプトは実はrsyncを実行しているだけなのです。
例えばWordPressであれば以下のようなものになります。
rsync --delete \ --exclude "wp-content/uploads/" \ --exclude "wp-content/cache/" \ --exclude "wp-content/backups/" \ -avuC -e ssh XXX.XXX.XXX.XXX:/var/www/XXX/ /var/www/XXX/
ここでなぜリリースシステムからではなくリリース対象からrsyncを実行しているのかと言うと、
Amazon Linuxを使用しているので cloud-initにこのスクリプトを登録しておけば
AWSのAuto Scaling機能を使用した際、インスタンス起動時にビルド済みソースコードを
取得してきてくれるためです。
【Docker】
ソースコードは全てリリースサーバ上でgit pullを行なっていて、
リリースサーバ上でビルドも実行します。
この際問題になるのはサービス毎にプログラミング言語のバージョンが異なる場合があるので
Dockerコンテナを起動しておき、Dockerコンテナ上でビルドを実行させている。
【その他】
リリースシステムのWeb UIはRuby on Railsで作成しました。
そこらへんは今後書いていればなと思います。
まだリリースシステムを刷新して間がないので結構泥臭くやっていますが、
今後この辺りも整理していこうと思うので、整理後に技術詳細を書いていければと思います。
このようにしてより安全によりスピィーディーにリリースし、より良いものを
より早くプロダクトをユーザ様に提供できればと思っています。