Deis を AWS でプロダクションに投入するための Tips

Deis は Docker/CoreOS/Fleet がベースになっている Heroku buildpack と互換性のある Private PaaS を実現する OSS です。

Deis には AWS で動かすための CloudFormation のテンプレートが公式で提供されているのですが、はっきり言ってお試し用であり、そのままプロダクションに投入するのは危険です。

[Install Deis on AWS
](http://qiita.com/ukitazume/items/5ce24e3abf3cc738ce0b)

ここでは、実際にプロダクションに投入した経験から得た Deis を AWS でプロダクションに投入するために必要なことを書いていきます。なお、Deis は絶賛 v2.0 が開発中ですが、ここで話すのは v1.12.3 の話です。

## まずは公式の情報を手に入れる

Deis をプロダクションに投入するする際の Tips を公式が提供しているので、まずはこれを読みます。

[Production deployments](https://deis.readthedocs.io/en/latest/managing_deis/production_deployments/)

色々と書いてありますが、特に重要なのは以下の3つ。

- [Running Deis without Ceph](https://deis.readthedocs.org/en/latest/managing_deis/production_deployments/#running-deis-without-ceph)
- [Isolating the Planes](https://deis.readthedocs.org/en/latest/managing_deis/production_deployments/#isolating-the-planes)
- [Isolating etcd](https://deis.readthedocs.org/en/latest/managing_deis/production_deployments/#isolating-etcd)

## Running Deis without Ceph

Deis は色々なクラウドやオンプレでも動くように、Dokcer Registry のバックエンド/PostgreSQL/ログ用のストレージとして [Ceph](http://ceph.com/) を使うようになっています。Ceph は OpenStack 版 S3 である [Swift](http://docs.openstack.org/developer/swift/) のバックエンドにも使われており、スケーラビリティが考慮されたストレージ管理のためのミドルウェアですが、2点問題があります。

- Control Plane が Stateful になってしまい、インスタンスの管理が難しくなる
- メモリを食う（1ホストあたり2GB）ので、その分、アプリケーションに配分できるメモリが減る

幸いにも AWS では S3 と RDS を使うことで、Ceph を使わない Stateless Plane モードで Deis を運用することができます。Stateless Plane モードでは、Ceph が担っていた役割を

- Docker Registry のバックエンド -> S3
- PostgreSQL -> RDS
- ログ -> Papertrail などの remote syslog を受けられる SaaS や サーバーに飛ばす

という風に置き換えます。これで、Deis サーバーが Stateless になるので、インスタンスの管理がとても楽になります。

設定の仕方は以下を参照。

[Running Deis without Ceph](http://deis.readthedocs.org/en/latest/managing_deis/running-deis-without-ceph/#running-deis-without-ceph)

## Isolating the Planes

Deis は Control Plane と Router Mesh, Data Plane という3種類のコンポーネント群があります。

<img width="980" alt="スクリーンショット 2016-02-27 11.52.05.png" src="https://qiita-image-store.s3.amazonaws.com/0/25774/ba88125b-cbb0-962e-abb1-d46897d76206.png">

http://carmstrong.github.io/ceph-days-sf-deis-2015/#/10 より引用

- Control Plane
  - API や Docker イメージのビルドや、ログの集約、Docker Registry を担当
- Router Mesh
  - リクエストのルーティングを担当
- Data Plane
  - Deis にデプロイされたアプリケーションの実行を担当

普通につくると、これらが同じインスタンスに同居するわけですが、Docker のビルドは処理が重く、同じインスタンス上で動くアプリケーションに影響がでないわけないですね。ということで、Control Plane とそれ以外が動作するインスタンスを分離します。

設定は以下を参照。cloud-config に Fleet metadata の設定を追加します。

[Isolating the Planes](http://deis.readthedocs.org/en/latest/managing_deis/isolating-planes/#isolating-planes)

Control Plane 専用インスタンスの設定

```
#cloud-config
---
coreos:
  fleet:
    metadata: controlPlane=true
```

Router Mesh / Data Plane 専用インスタンスの設定

```
#cloud-config
---
coreos:
  fleet:
    metadata: dataPlane=true,routerMesh=true
```

## Isolating etcd

Deis の設定情報の全ては etcd (正確には etcd2）に保存されています。etcd が壊れるということは Deis が壊れることを意味します。なので、etcd クラスタだけは絶対に死守しなければなりません。ということで、etcd クラスタを Control Plane, Router Mesh と分離しましょう。etcd クラスタを分離することで、Control Plane, Router Mesh のインスタンスの入れ替え、増減が簡単になるというメリットもあります。

また、etcd クラスタは最小3台から構成できますが、耐久性を考えると5台以上のクラスタにしておいた方が無難だと思います。

## nginx を前段に置き、Internal ELB を使う

公式の Tips 以外でオススメなのが、これ。前段に nginx を置くことで、ルーティングが自由になりますし、設定の変更もやりやすくなります。Deis の Router 自体も nginx なのですが、設定を変えるために以下のリンクにある設定をいちいちしていくのは面倒すぎて、実運用ではツライです。

[Customizing router](http://deis.readthedocs.org/en/latest/customizing_deis/router_settings/)

## 結論

ということでまとめると、こういう風に作ります。最小で11台からスタートになるので、お手軽感はなくなりますが、プロダクション環境ですからね。

![Deis Production Deployment](https://qiita-image-store.s3.amazonaws.com/0/25774/13226334-5efc-7a2e-9495-caa0dc3b7909.png)