fbpx

[和訳] Chef Delivery ガイドツアー #getchef

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Chef Delivery: A Guided Tour (2015/11/23) の和訳です。

Chef Delivery は継続的デリバリの適用を促進し、DevOps コラボレーションを推進します。Chef Delivery は、開発者のワークステーションから、進捗に応じて変更の管理をするための保証された再現可能なワークフローを提供します。いくつもの自動化テストを通し、本番環境に提供します。

2015年11月17日に開催した webinar の録画で、Nathen HarveyMichael Ducy が Chef Delivery について紹介しました。Chef Delivery に変更を送信する方法や、異なるパイプラインのステージを通して移動する際、UI を用いて追跡する方法などを紹介しています。実行可能なテストについても触れ、GitHub インテグレーションについて紹介し、パイプラインで発生する事柄について構築 Cookbook を用いてどのように対応するかの概要をお伝えします。Webinar ライブでの質疑応答について、ライブでは答えられなかった質問も含めて次でご覧になれます。

ライブ Webinar での質問

Q: Chef Delivery は SVN と統合できますか?

A: いいえ、現時点では SVN との統合は計画していません。我々はまず GitHub や Stash、Bitbucket のユーザーに良いサービスを提供することに注力しています。それから、他の SCM システムと統合する可能性について検討したいと考えています。

Q: Policy や Role の属性値が変更された場合でも、Approve や Deliver フェイズが推奨されますか?

A: はい。すべてのコード変更は同一のワークフローに従わなければいけません。ほんの些細な変更に思われるものでも、サービス停止につながることがあります。

Q: Chef Delivery のステータス名を、自分の環境で機能しているもの、例えば「sandbox → dev → stage → production」に変更することは可能でしょうか?

A: Chef Delivery のステージ名は変更できません。また、変更すると既存の環境や検証環境と直交になることがあります。このことについて考えるのに便利な方法は、Acceptance ステージは、商用環境やそれ以外の Delivered 先に変更を送信するのに必要な信用性を提供するはず、というものです。

Q: 既に Chef プレミアムサブスクリプションを持っている場合、どこで Chef Delivery をダウンロードできますか?

A: Chef アカウントの代表者の方の指示に従ってください。

Q: Hosted Chef は Chef Delivery を含みますか? それとも Chef Delivery はオンプレミス Chef 向けのものでしょうか?

A: Hosted Chef に Chef Delivery を追加する予定は現時点ではありませんが、需要を見て、定期的に再検討したいと考えています。

Q: Amazon に対してするように、VMware にプロビジョンやデプロイをすることはできますか?

A: もちろんです。お客様の中には、Chef Deliveryの最初の検証で vRealize を用いてそれを実行された方もいらっしゃいます。

Q: ユニオンが成功した直後にリハーサルが開始されていましたが、ユニオンとリハーサルの間に手動で承認する手順を挿入することはできますか?

A: いいえ、承認ステップは構成不可能です。リハーサルステージは、ユニオンの中断に対応するための解決策が有効であることを確認するための手段としてのみ存在します。

Q: Stash でも利用可能になると仰っていましたが、それは Git のみということでしょうか? それとも Mercurial もサポート対象でしょうか?

A: Stash と Bitbucket との統合は Git ワークフローのためのものになります。つまり、PR ベースのものです。

Q: Chef Delivery は Bamboo や TeamCity のような他の CI/CD プラットフォームと置換できる仕様ですか?

A: Chef Delivery は多くのお客様に対して成功するとして知られている、証明されたワークフローを強化するための仕様になっています。素晴らしい成果があり、安全かつ高速に移動ができると思われるツールやワークフローの実践を反映しています。

Q: Chef Delivery は社内で利用することが可能ですか?

A: はい。現段階では、オンプレミスインストールのみが利用可能です。Chef Delivery のセットアップ方法についてはこちらをご覧ください: https://docs.chef.io/delivery.html

Q: いつ Stash と連携するかについてのタイムラインはありますか? Github 以外の Git レポジトリとも連携することは技術的に可能ですか?

A: Stash や Bitbucket との統合は2015年第四期に完成する予定です。

Q: マージする際にこのパイプラインを用いて手動で介入する必要であるかどうかが明確ではありません。ツールの自動化と手動での決定や修正はどのように関係しますか?

A: 手動の操作は3か所で行われます。第一に、変更を作成しパイプラインに送信します。第二に、別の人物が自分の目でそのコードをレビューし、コードが正しく書かれているか(正しく構築できるか)を確認します。第三に、手動で、構築されたものがデリバリの準備ができているか(正しく構築できているか否か)を決定します。

Q: 例ではどのステージまたはタスクが test-kitchen を行っていますか?

A: test-kitchen はデモでは実行しませんでしたが、ローカルの開発ワークステーションでも稼働されるはずです。また、フェーズのどれかの間に稼働することもあります。

Q: 途中で何かが壊れた場合にそれを修正し再稼働するというデモをしていただけますか? 再稼働すると最初からになってしまうのでしょうか、それとも壊れた時点から継続できるのでしょうか?

A: パイプラインを通過する変更はそれぞれステージとフェーズの完全なセットを通過するため、壊れた時点からプロセスが開始するのではなく、最初から再び開始されます。

Q: 一つのアプリケーションインフラを別のプロビジョナ(AWS や vCenter)にプロモートすることができますか?

A: はい。パイプラインの中ではどのような自動化されたプロビジョニング技術も稼働させることができます。したがって、パイプラインの単一のプロビジョニングフェーズにおいて異なる API を用いて異なるクラウド内のインフラをプロビジョニングすることが可能です。

Q: Chef Delivery の価格設定はどのようですか? 価格は一定であるか、月ごとであるか、またはアプリケーションの数量に基づきますか?

A: Chef Delivery を含む Chef プレミアムサブスクリプションの基本的な価格設定についてはhttps://www.chef.io/pricing/ をご覧ください。Chef Delivery はサーバーごとやユーザーごとに単体の商品としてもライセンスを購入していただけます。詳細については Chef アカウントの代表者の方にご連絡していただければと思います。

Q: Stash とは統合されていますか?

A: Stash や Bitbucket との統合作業は進行中です。2015年第四期に完了する計画になっています。

Q: テストもすべて Chef Delivery によって扱われますか?

A: プロジェクトの構築 Cookbook に書く Recipe が、各フェーズで発生する事項について指示しています。例えば、自動化された機能テストを行うのに Cucumber をご利用の場合、Chef Delivery に指示して Cucumber を起動し、パイプラインの Functional Phase にてテストを実行することができます。

Q: 試用のための Chef Delivery の無料オープンソース版はありますか?

A: 利用可能なオープンソースコンポーネントが2点(delivery cli とdelivery truck)を GitHub に公開しています。https://github.com/chef/delivery-clihttps://github.com/chef-cookbooks/delivery-truck をご覧ください。

Q: GitHub Enterprise とはすでに統合されましたか?

A: はい、統合は完了しています。

Q: Chef Delivery と Jenkins 間の統合オプションは何がありますか?

A: Chef Delivery パイプラインを通して、フェーズのジョブから Jenkins のジョブを実行することができます。

Q: Cookbookと紐づけなくてもアプリケーションは伝達されますか?

A: はい。すべてのプロジェクトには構築 Cookbook があり、各フェーズで Chef Delivery に何をすべきか指示を出します。プロジェクトそのものは Cookbook ベースである必要も、Cookbook によって起動を制御されている必要もありません。

Q: Active Directory 統合は利用可能ですか?

A: Chef Delivery では AD のユーザー名・パスワードを通した基本的な認証がサポートされています。次の四半期ではLDAPの統合についてもさらに取り組む予定です。

Q: Chef Delivery はオンプレミス (VM と物理マシン)と、クラウド技術(AWS, Azure, Google)の両方と連携しますか?

A: Deliveryそのものはオンプレミスのソリューションであり、クラウド、データセンターまたはその両方にホストすることができます(複数のクラウド間で有効なノードを構築しているのは珍しいことではありません)。

Q: 承認フェーズと伝達フェーズは手動(人的)承認フェーズであると仰っていました。これは手動でなければならないのでしょうか? それとも、テストを通過した割合など、なんらかの基準に基づいて自動化することができるのでしょうか?

A: 承認ゲートは現段階では手動ですが、これらのステップを自動化するためのビジネスルールを決定したいとのお声を頂戴しています。この領域の製品変更が有意義であるか検討しています。

Q: なぜ誰かが変更をレビューした後に build フェーズがあるのでしょうか? レビューする前に build へのフィードバックが必要ではないでしょうか?

A: build ステージは承認(レビュー)後に発生します。この承認が、システムに変更を目的のブランチにマージさせ、build ステージを開始します。この指示の目的は、持続的な統合を促すこと、パイプラインの速度を上げること、そして build の QA をするのに費やしたリソースが解放されず、望まれない(承認されない)成果物に無駄に使われないようにすることです。

新規CTA