冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Docker運用サービスのTutumをお試ししてみた

先日からdockerとdockerホストをハンドリングして保守部門を巻き込んで運用体制できないかなあ、と考えて作り始めたツールがあるんですが、それを完全にいらない子化してくれそうなサービスを見つけたので、期待を込めてお試ししてみることにしました。

なお、2015年11月3日現在、まだベータ版でプロダクション環境への適用は推奨されていませんので、これを参考にする方も検証のみにしておいてください。

Tutumとは?

何て読むんでしょうね?タタム?

japan.zdnet.com

上記記事を読む限り、以前からあったサービスをDockerが買収したようですね。不勉強で全く知りませんでした。DevOpsチーム向けのDocker分散アプリ開発と管理の利便性を追求したサービスのようです。まさに私が作ろうとしているツールと同じ目的を持っています。期待に胸が膨らみます。

準備

サインイン

利用にはDockerHubアカウントがDockerHubのアカウントでサインインできますが、パスワードはTutum内のレジストリで使ったりするのでTutum専用に作ります。

ログインしてざっとWelcome Tourの内容を見ていると、以下のような機能があるようです。

  • Node (dockerホストがデプロイされたイメージ)管理
  • Service (同じDockerリポジトリから取得可能なコンテナのセット、Tutum用語)の管理
  • Stack (docker-composeのようなオーケストレーション機能)
  • Repository (タグ付けされたイメージを管理する機能、おそらくTutum内にプライベートレジストリを組んでいるものと思われる)

Nodeは各種クラウドプロバイダ(AWS,Azure,Digital Oceanなど)と連携して配置されます。 ServiceNodeDeploy Tag と呼ばれるもので関連付けてコンテナのデプロイ先をコントロールします。

AWS

試すには自前サーバかクラウドプロバイダとの連携が必須です。AWSにクレジットカード情報を奉納しました。

一通り機能を使って見る

クラウドプロバイダの連携

一応、ドキュメントには公開されたサーバなら展開できる *1 とありますが、私は自宅サーバ持っていないので今回は試していません。

以下は、AWSとの連携です。詳しくは Link your Amazon Web Services account : Tutum のへんを読んでください。

まず、AWS IAMでtutum用ユーザを作成して、EC2を利用できるポリシーを適用します。適用すべきポリシーは以下です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:*",
        "iam:ListInstanceProfiles"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

作成したユーザにポリシーを適用して、Access KeyとSecretをTutumに連携すれば Node 作成準備の完了です。

Node を作る

コンテナをデプロイする先であるノードを作ります。以下のような作成画面が出てきます。

f:id:mao_instantlife:20151103183214p:plain

この中身を埋めるだけです。登録先のクラウドプロバイダが多ければもっと選択肢が出てきます。今回は名前以外はデフォルトにしました。ノードを作成すると、AWSのtutumユーザを通じてEC2インスタンスを勝手に作って起動してくれます。このEC2インスタンスにはDockerもインストールされています。以下を見る限りバージョンは1.8.3のようです。

f:id:mao_instantlife:20151103183234p:plain

ノードのコンソールで確認可能なことは、コンテナの状況、エンドポイント(これについてはよくわかってないので、後で調べようかと)、インスタンスのリソース(CPU、メモリ、ディスク、ネットワーク)モニタリング、タイムライン(イベント)です。

Githubの連携

ドキュメントなどを見ると自動ビルド、テストなどでTutumに一本化できるようにGithubとの連携ができるみたいです。

Automated builds : Tutum

が、マニュアルが若干面倒なのと、CircleCIでもpushできそうだし使い勝手良さそうなのでこれについては無視することにしました。

Service を作る

次に Service を作ってみましょう。 Service の作成は以下のワークフローで進むようです。

  1. イメージ選択
  2. Service の設定
  3. 環境(変数)の設定
  4. ボリュームの設定

f:id:mao_instantlife:20151103183422p:plain

f:id:mao_instantlife:20151103183430p:plain

イメージは、Jumpstartと呼ばれるtutum提供のレジストリ、DockerHubまたはサードパーティレジストリ、Tutumと連携しているプライベートレジストリから検索可能です。Jumpstartでは、それらを組み合わせてアプリケーションの骨格を作ることができるように、基本的なデータベースサービスやらアプリケーションコンテナ、プロキシやらのイメージが提供されています。環境変数などの設定では、他サービスとのリンクの設定なども可能です。

これらの値はサービスのコンソールから後で変更することもできます。

Deployment Strategy でデプロイノードの選択戦略を選択します。 Emptiest Node でコンテナ数が一番少ないノードに、 High Availability で当該サービスのデプロイ数が最も少ないノードを選択します。 Service のデプロイ先は、 Deploy Tag で配布先ノードを絞り込むので、ノードにしっかりとタグ付けして管理していくことが重要です。でないと予想してないデプロイが発生することになります。この辺りはタグの管理がもっとしやすくなると使いやすいですね。

コンテナ数も設定可能で、この辺はComposeっぽい。 Service 作成後のコンソールでデプロイや削除などの操作を行います。Startをクリックすると指定したコンテナ数をタグで関連づいたノードに作成します。

Jumpstartからテスト用のイメージをデプロイしてアクセスしてみました。

f:id:mao_instantlife:20151103183407p:plain

Stack を作る

Stack複数のイメージを取りまとめて Service に取りまとめていく機能です。ここは私の想像と少し違いましたが。 compose.yml だと思えばいいと思います。 tutum.yml というYAMLファイルの形式で書きます。ってかほぼ書式が compose.yml と同じなんですが。。。論理的につないでるだけなのかな?登録後は、 Stack としての管理も可能ですが、 Service ごとの管理も可能です。

書式を整理していないのでよくわからんのですが、サンプルを登録したらすぐにデプロイ始めようとしていました。特にタグを指定していないはずなので、要注意ですね。シンタックスでコントロールできるはずなので(できなかったら使い物にならない)、使う時になったらもう少し突っ込んで調べてみます。

まとめ

いやあ、完全に欲しかったやつ。今作ってるやつがいらない子確定になりました。やっぱみんな欲しかったんじゃん、そういうところに資本かけたもん勝ちだよなあ、と痛感しました。先に作られてたんで、自分としては設計思想が同じだったというあたりで満足するしかございません。

ちなみに、現在はベータ版につき無料で使えます。当然、現段階ではプロダクション環境で使うなというのが公式のアナウンスです。はやく料金プランが公開されて欲しいですね。

今回触っていない機能について幾つか。

プライベートなレジストリについて今回は調べていませんが、CircleCIからのpushについても調べてみたいので別にまとめることにします。料金プランでどうなるかわかりませんが、Docker Hubではプライベートレジストリが1つしか作れないので、この辺りが改善されるとありがたいです。

それから、Tutumの機能を使ったクライアントアプリが作れるように、CLIREST APIPython SDKGolang SDKの提供がされているようです。ってか、REST APIですか。Tutum4Sですか。

よくわからないのはマルチユーザ対応です。運用まで使うことを想定しているツールなので、マルチユーザでのログインと各種機能への設定権限など権限絡みは欲しいところ。ユーザはGithubアカウントでログインとかしたいですね。

*1:ポート解放の制限やtutum agentのインストールが必要です。 Bring Your Own Node : Tutum