[和訳] Release: Chef Container 0.2.0 (beta) #opschef_ja #getchef_ja #dockerjp

この記事は Release: Chef Container 0.2.0 (beta) (2014/07/15) の和訳です。

注意: Chef Provisioning と Docker の組み合わせとして knife-container がありましたがプロジェクト終了しており、現在は chef-provisioning-docker の利用が推奨されています。Chef Provisioning Docker については Chef ProvisioningとDockerでSerfクラスタ環境を作成する を参照してください(2015/07/08 追記)。

訳注: 実際にこの手順を検証した結果を「Chef Container 0.2.0 (beta) で Docker コンテナを作成する」にて公開しています(2014/07/17 追記)

今週、Chef社は Linux コンテナ内で動作できる Chef クライアントの 1バージョンをリリースしました。このコンテナに親和性の高いクライアントは chef-container と呼ばれています。この記事では、chef-container の紹介と、意図とコンポーネントを説明します。また、コンテナイメージを管理するための新しい knife プラグインも紹介します。そして、Docker コンテナ内で動作する apache2 のインスタンスをどのように起動するかを例示します。

なぜ chef-container？

Linux コンテナとコンテナ技術は以前から存在していましたが、Docker のようなツールの人気の急上昇やそれらのツールによる恩恵、そして Immutable Infrastracture のコンセプトで、再び注目を集めています。より詳しくは、Julian の記事 "Immutable Infrastructure: Practical or Not?" を読むとよいでしょう。

Linux コンテナ内にアプリケーションを組み込んでおくことは、VM 上で動作させるよりも早くて柔軟性がありますが、それらのコンテナはまだ適切な構成管理を必要としています。ほとんどの人はシンプルなシェルスクリプト以上の何かを選択します。Docker の Dockerfile は Infrastracture as code のいくつかの特徴を持っていますが、実際は、シェルコマンドとして受け取れる動作を定義しているに過ぎません。既存のアプリケーションスタックをコンテナに移行しようとしているシステム管理者や開発者にとって、完全に理解していないかもしれないアプリケーションスタックに対するすべてのインフラコードを書き直さなければいけないかもしれなかったら、とても恐ろしいでしょう。

これが、我々が chef-container を作った理由の 1つです。我々は自動化プラットフォームはフルスタックを管理できるべきだと信じています。言い換えると、肥大化したベアメタルサーバであっても小さな Linux コンテナであっても、既存の Cookbook ライブラリを使えるべきだということです。自動化プラットフォームが提供するいかなる恩恵を失うことなく、すべてが可能であるべきです。

chef-container とは？

chef-container は、さまざまなコンテナソリューションに対して一貫した構成管理を提供します。これは runit と chef-init を組み合わせた Chef クライアントによってなされます。runit は軽量でクロスプラットフォームなオープンソースの init システムで、chef-init はコンテナへのエントリポイントとして動作する RubyGem です。これは Chef で構成するインフラの他の要素と同じように、コンテナイメージを構成するために必要な抽象化も提供します。同時に、ソフトウェアのこれら 3つの要素は、開発から生産へと導くすばらしいコンテナ管理ワークフローを作成します。

chef-container の最初のリリースは、現時点では重大なワークアラウンドを必要とする Docker 内の環境でのみ動作するようになっています。デフォルトでは、Docker コンテナは init システムのみならず、コンテナ内の TTY にアタッチするための機能を欠いています。これらの特徴は Docker コンテナをブートストラップしたり、既存の Chef ワークフローを用いて Docker イメージをビルドしたりすることを困難にしています。chef-container は、knife container プラグインと用いることで、これらの問題を解決し、Docker のベストプラクティスに忠実なままで Docker イメージのビルドとローンチを可能とします。

knife container とは？

knife container プラグインは、コンテナイメージのライフサイクルを Chef で管理できるようにします。knife container の最初のリリースは、Docker イメージの管理に特化したワークフローを提供します。これによって、Docker イメージの作成・削除・管理が行えます。

例: Apache2 Docker インスタンスをローンチする

では chef-container と knife container を用いて、どのように Apache2 Docker インスタンスをローンチするか見ていきましょう。

ソフトウェアのインストール

まず、ワークステーションにソフトウェアの 3要素のインストールが必要です。

1. Docker をインストールします。Docker installation ページを参照してください。
2. Chef DK をインストールします。Chef Development Kit ページを参照してください。
3. 次のコマンドで knife container プラグインをインストールします。


chef gem install knife-container


デプロイ計画

ソフトウェアをインストールしたら、次の 4点を決定しましょう。

1. Docker イメージの名前はどのようにしたいか？
2. Docker イメージに対してどのような run-list を使いたいか？ 言い換えると、どの Recipe を用いて設定したいか？
3. イメージは local モードと server モードのどちらで管理したいか？
4. Cookbook は手動と Berkshelf のどちらで管理したいか？

デモ

具体例として、Docker イメージを作成してローンチしましょう。apache2 という名前の単一の Recipe で run-list を構成します。イメージはローカルで管理し、Cookbook は Berkshelf で管理します。

Docker コンテキストの初期化

Docker コンテキストの初期化には、init コマンドを用います。knife container は管理するすべての Docker コンテキストをまとめる dockerfiles というディレクトリを用います。デフォルトでは、dockerfiles ディレクトリは chef-repo 内に作成されます。

Docker コンテキストを初期化するには、次のコマンドを実行します。


knife container docker init demo/apache2 -r 'recipe[apache2]' -z -b


この例ではイメージの名前を demo/apache2 とし、run-list、-z オプション、-b オプションを渡しています。-z オプションはローカルモード、-b オプションは Berksfile の生成を意味します。

Node Attribute の定義

管理したい Chef コンテナの service Resource に対する Node Attribute を定義する必要があります。Docker は init の仕組みを欠いているので、chef-container は runit を含んでいます。chef-init gem は service Resource に優先して runit への橋渡しを務める container_service Resource を提供します。runit は通常の upstart サービスが行うのとは異なる動作をするので、runit がサービスを動作させるためのコマンドである追加的な文字列を提供する必要があるからです。

コマンド文字列は Node Attribute を通して渡され、自動的に chef-init によって解釈されるので、既存の Cookbook を変更する必要はありません。この値は Node Attribute のどこでも指定できます。この例では、初期化プロセスの一部として作成される first-boot.json ファイルで指定しています。次はデモで用いる Node Attribute です。


{
"run_list": [
"recipe[apache2]"
],
"container_service": {
"apache2": {
"command": "/usr/sbin/apache2 -k start"
}
}
}


Docker イメージのビルド

Docker イメージを作成するには build コマンドを用います。値として渡す必要があるのは、先程 init コマンドで指定したイメージの名前だけです。この例では Berkshelf を用いているので、Cookbook の依存関係は最初に自動的に解決されます。次にこのコマンドは Docker コンテキストで docker buiild を実行し、Docker イメージを生成します。

この例では、イメージの名前は demo/apache2 です。


knife container docker build demo/apache2


コンテナのビルドが成功したら、次のコマンドでイメージが存在していることを確認できます。


docker images


これで、イメージをレジストリにプッシュして、好きなマシンでローンチすることができます。

Docker イメージのローンチ

docker を実行して Docker イメージをインスタンスとして動作させる準備ができました。
次のコマンドを実行してください。


docker run -d demo/apache2


インスタンスがローンチしたら、まずは Chef クライアントが必要とする最後の構成変更のために動作します。この収束動作はとても高速でしょう。重要な点として、Chef はコンテナがローンチした後で設定を行うということです。例えば、お互いに通信する 2つのコンテナがあるとして、ローンチするまでそれらの IP アドレスがわからないので、ローンチの後でしか設定できないということです。

動作中のコンテナ一覧は次のコマンドで確認できます。


docker ps


コンテナ内で動作しているプロセスは次のコマンドで確認できます。


docker top コンテナID


ビデオ

もっと詳しく

Chef のコンテナサポートについてより詳しく知りたければ、Chef for Containers を参照してください。

chef-init、knife-container プロジェクトにフィードバックがあれば、GitHub の issue でお知らせください。

• knife-container Issues
• chef-init Issues