Docker Compose を使ったオープンソース PaaS: Paus のご紹介

Wantedly インフラチームエンジニアの藤田 (@dtan4) です。今回は、社内で運用している PaaS である Paus の紹介をします。

社内 PaaS の必要性

Wantedly ではデプロイ環境として本番環境とステージング環境が用意されていました。ここで、エンジニアが増えるに連れステージング環境の順番待ちが起こるようになってきました。原則として、フィーチャブランチはステージング環境で動作確認をした後本番環境にデプロイすることになっています。そのため、ステージング環境での確認が遅れることは新機能 / 修正のリリース速度低下につながっていました。

また、新サービスを開発する際の動作基盤構築にかかる工数も問題になってきました。従来だと新しいサービス向けの動作基盤を構築するのに丸1日費やしていました。これはリリース前の検証環境においても同様です。このため、メインサービスの www.wantedly.com とは切り離して運用したいという場合でも、工数を考えやむなく同じコードベースに載せるといったことがありました。

現在は本番環境の置き換えとして Kubernetes を検証しています（参考）。が、Kubernetes もそれはそれで設定ファイルを用意するのが面倒です。

そんなわけで、アプリケーションエンジニアでも「簡単に」「好きな構成で」アプリケーションをデプロイして検証できるような環境が求められてきました。

既存の PaaS

Paus を作る前に既存の PaaS をマネージドサービスから OSS まで調査したのですが、その時点で我々の要求を満たすものは残念ながら存在しませんでした。

一番の懸念点は、Heroku 含む殆どの PaaS は buildpack + addons 構成に縛られるということでした。Web アプリケーション自体はまだいいのですが、カスタマイズした Elasticsearch などを使おうとするとたいてい難しいです。Wantedly ではその Elasticsearch も Docker コンテナとして本番稼働しているので PaaS 上でも Docker コンテナが立てばよかったのですが、調査した結果既存の PaaS だとできないという結論に達したのです。

Paus

Paus は、Docker Compose で構成された Web アプリケーションを簡単にデプロイできる PaaS です。Docker Compose は、複数コンテナで構成されるアプリケーションを簡単に立ち上げるためのツールです。例えば以下の様な docker-compose.yml を書いて docker-compose up コマンドを実行することで、 WordPress と MySQL を起動することができます。

version: '2'
services:
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  web:
    depends_on:
      - db
    image: wordpress:latest
    links:
      - db
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_PASSWORD: wordpress

Paus では、docker-compose.yml を書いて git push したらそれだけでアプリがデプロイできます。

とりあえず、下の動画で雰囲気を掴んでください。WordPress + MySQL アプリケーションを Paus にデプロイするデモです。

Paus のしくみ

Paus は CoreOS クラスタ上で稼働しています。その上で Docker Swarm クラスタが構築されており、1つの巨大なリソースプールができあがっています。アプリケーションはリソースの空いているマシンへよしなにデプロイされます。

最近は、バックエンドを Amazon ECS に載せ替えることも考えています。

アプリケーションのデプロイ

無作為にデプロイされても大変なので、デプロイするアプリは（Heroku のように）予め登録するようにしています。paus-frontend が Web ダッシュボードとなっており、この上でアプリケーションや環境変数を設定します。

Paus への git push は、paus-gitreceive モジュールが受け取ります。paus-gitreceive は受け取ったリポジトリの中身を展開し、Docker イメージのビルド (docker-compose build) とコンテナの起動 (docker-compose up) を行います。前述したように、Docker Compose は Docker Swarm クラスタ上で一連の作業を行います。

デプロイが成功すると、自動でそのコンテナにアクセスするためのサブドメインが割り振られます。

アプリケーションへのアクセス

アプリケーション自体へのアクセスは、リバースプロキシである Vulcand を経由して行われます。Vulcand は設定をすべて etcd に格納するリバースプロキシです。Vulcand サービス自体の再起動とアプリケーションのダウンタイムなしで即座に設定を反映できます。同様のことを etcd / Consul + registrator + Nginx でやる例は多いですが、Vulcand を用いるとよりシンプルに実現できます。

手元でお試し

https://github.com/dtan4/paus に、Vagrant で Paus を起動するための一式が含まれています。

まとめ

Wantedly 社内運用している Docker Compose PaaS: Paus の紹介と、開発するに至った経緯を紹介しました。Wantedly では Paus を Heroku ライクに使うだけでなく、GitHub に push されたら CI からデプロイするといったこともしています。

まだまだ荒削りで改善の余地はたくさんあります。オープンソースで公開しているので、ぜひ Issue, Pull Request をくださると幸いです。

---

ところで、先日 Heroku が Docker コンテナのデプロイに対応しました。Heroku の懸念点に「Web アプリのカスタマイズ自由度が低い」というのがありましたが、今回の対応でそれも解決しました。多くのケースでは自分たちで PaaS を運用しなくとも、この機能を使えば十分に思われます。使えるものは大いに活用しましょう。