[和訳] 配達準備: Chef Deliveryに備えよう #getchef

本稿は Delivery Readiness: Preparing your team for Chef Delivery (2015/05/21) の和訳です。

昨日、「Chef Deliveryに備えよう」というwebinarを開催しました。継続的デリバリを簡単に定義し、継続的デリバリを組織に適用する価値とChef Deliveryがその青写真にどのように適合するかについて話しました。このwebinarにおける要点は、Chef Deliveryの最初の顧客達に上げられた共通の評価基準でした。

これらのパターンのいくつかはローカルで開発しているような既存のChefユーザにおなじみのもので、それ以外はソフトウェア開発におけるgitやフィーチャーブランチモデルを使うような新しい規則でしょう。webinarでは本稿の後に記載する20分程度の質疑応答を含んでいました。こちらで録画を見ることができます。

Chef Deliveryのより深いデモについて興味があれば、awesome@chef.ioまでメールしてください。Chef Deliveryは現在招待制のみの提供になっています。提供範囲の拡大について連絡がほしければhttps://www.chef.io/delivery/から登録してください。

Webinarでの質疑応答

Q: Chef Deliveryもオープンソースと「エンタープライズ」アドオンになりますか？

A: オープンソースではありませんが、delivery-cliとdelivery-truckというオープンソースのコンポーネントがあります。また構築用のCookbookをオープンソースにする予定です。

Q: 独自のPipelineテンプレートを作成できますか？ Pipelineは既製品だが必要あれば変更したいのですが？

A: いいえ。Pipelineは固定です。ただし、Pipelineの各フェイズで実行したいものをChef DSLで定義できます。

Q: Chef Delivery Truck Cookbookについて詳しく聞かせてください

A: delivery-truckは、Chef Cookbookの継続的デリバリのためのChef Deliveryの構築用のCookbookです。詳しくはhttps://github.com/opscode-cookbooks/delivery-truckを参照してください。

Q: ローカルから「staging/etc」へ、ローカルとJenkinsのbuild/coordinatorテストの上流について、いくつの部分がここで述べられたと仮定すると、Pipelineにおける次の要素について準備しておくおすすめは何ですか？

A: delivery-cliとdelivery-truckの利用です。

Q: Chef Deliveryは、サーバや収束について実際に変更を適用する何かがありますか？ もしなければ、収束は手動で行えばいいか、chef-clientをデーモンモードで動かして自動で行えばいいか、どちらがお勧めですか？ Chef Deliveryを使ってCookbookの修正版をリリースするのはどれくらい早くなりますか？ 悪いCookbookがすべてのテストを通すとしても、悪いロジックのせいで製品が失敗することがあると思います。

A: ユーザはデプロイの段階で何を実行するかを定義します。ユーザは変更によって影響されるすべてのNodeでのchef-clientを実行するかを決定したり、Chef Serverに配布するだけに留めるかを決定できます。

Q: Chef Deliveryは、例えばdev/cte/productionといった隔離されたOrganizationのような、複数のOrganizationにまたがって動作しますか？

A: もちろんです。Chef Deliveryはエンタープライズ/Organization/Project構造を含みます。

Q: Chef Deliveryは、テストにおけるインスタンス部分のような手動の手順もPipelineでサポートしますか？

A: Chef Deliveryは、受け入れ環境に対する変更に関連付けられた要素をデプロイし、追加的な自動結合テストと同じように、デプロイを検証する自動テストを実行します。Chef DeliveryはここでユーザがDeliverボタンをクリックするのを待ちます。よって、手動ユーザの受け入れテストは、受け入れ環境において、Deliverボタンを叩くより前に位置します。

Q: Chef Deliveryは異なるプロジェクトについて固定的な貸し切りシステムと動作しますか？

A: 質問がちょっとよくわかりませんが、そのシステムがAPIを持っているなら通信が可能なので、テストやデプロイを実行するために「貸し出し」インフラを用意できるでしょう。例えば、kubernetesのようなコンテナ管理ソリューションにその流儀に従ってデプロイできます。

Q: Chef Serverが動作不能だったら何が起きますか？

A: 構築NodeのためにChef Serverに問い合わせを行うので、構築Nodeが見つからないので構築を行いません。

Q: どのプログラミング言語をサポートしますか？

A: すべてです。

Q: Chef Deliveryは、Jenkinsのような既存のビルドツールを置き換えるようにデザインされているのですか？

A: Jenkinsはすばらしいジョブ実行ツールですが、ワークフローには無頓着です。Chef Deliveryもジョブ実行にすぐれていますが、これの真価はジョブを実行しないことです。それはつまりワークフローの管理です。ユーザは必要に応じてChef DeliveryとJenkinsを統合することができます。

Q: Chef DeliveryはマルチNodeのオーケストレーションデプロイをどのように扱いますか？

A: ユーザはデプロイフェイズで何を実行するかをコードを使って定義できます。ユーザは構築Recipe内でロジックを作ったり、外部サービスを呼び出したりできます。

Q: バージョン管理にgitを推奨しているようですが、我々は現在subversionを使っています。Chef Deliveryとsubversionの組み合わせが使えない理由は何ですか？

A: 現時点ではChef DeliveryはGitを必要としています。将来のバージョンで他のSCMとの統合ができないか考えてみます。

Q: 1レポジトリごとに1Cookbookという考えについて説明してください

A: 個々のCookbookは、すべてのCookbookを含んだ「Cookbooks」ディレクトリを持つようなすべてのCookbookのレポジトリに入れる代わりに、個々のレポジトリに格納すべきです。そのほうが変更点を追いやすくなり、共有もしやすくなります。

Q: オンプレミス版はオープンソースサーバを含みますか？

A: Chef Deliveryはオープンソースではなく、Chef Server 12とサブスクリプションが必要です。

Q: 実際のインフラに依存したコードのローカルでのテストや自動テストをどのようにしていますか？ 例えば、ある設定におけるEBSボリュームとか。自動テストはすばらしい理論ですが、実際は動かないんです。

A: EBSでのテストが必要であれば、コードをEBSで動かす必要があります。ただし、EBSの機能とコードがやりとりしない限り、EBSでコードをテストする必要はないわけです。ほとんどの場合、アプリのテストはローカル環境のVMやコンテナできちんと動作します。ディスクに関しては...特にパフォーマンスや信頼性をテストしない限りは。

Q: 継続的デリバリPipelineの6つのステージは、時間、日、週のどれだけかかりますか

A: Pipelineを通しての変更の持続時間は、Recipeのコードを実行するのにどれくらいかかるかに依存します。ほとんどの場合、数分です。ソースから環境を構築しなければ、ですが。そのような場合、事前にどんなに時間がかかっても環境を構築し、どんなに時間がかかってもコードを実行するでしょう。