ランサーズ(Lancers)エンジニアブログ > DevOps > リリースシステムを刷新したはなし

リリースシステムを刷新したはなし

blog_admin|2016年12月04日
DevOps

インフラエンジニアの平塚です。
今回は昨年紹介しましたランサーズのリリースシステムを刷新したのでご紹介します。

背景

 

理由としては増えてゆくサービスを個別にリリースしていくのは手間がかかり、
これを1つのWeb UIからリリースできるようにすることでリリースを容易にしたい。
また、スケールアウト時に最新ビルド済みソースコードを取得したいと思ったからです。

 

これまでの課題

  • リリース対象のIPアドレスをconfigファイルに直接記述していてスケールする度に修正が必要
  • https://www.lancers.jp以外はCLIベース又は手動でのリリースを行なっていたので手順を確認しながらリリースする必要があった。

これまでと現在の比較

簡単にこれまでと現在のリリースシステムの違いを説明します。

【以前】

・社内オンプレミスサーバに構築
・fabricsを使用したデプロイ
・デプロイ対象はhttps://www.lancers.jpのみ
・buildは手動実行

old

 

【現在】

・AWS EC2上にリリースシステム構築
・Ansible + rsyncを使用したデプロイ
・ランサーズが運営するすべてのサービスのリリースをWeb UIにて実行可能
・リリースシステム上でDockerコンテナを立ち上げ、コンテナ内で自動build

new

 

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で作成しました。
そこらへんは今後書いていればなと思います。

まだリリースシステムを刷新して間がないので結構泥臭くやっていますが、
今後この辺りも整理していこうと思うので、整理後に技術詳細を書いていければと思います。

このようにしてより安全によりスピィーディーにリリースし、より良いものを
より早くプロダクトをユーザ様に提供できればと思っています。