【参考訳】HashiCorp Vagrant 2.0

08.09.2017  in HashiCorp using tags Vagrant , HashiCorp , translation

概要

HashiCorp の blog に「 HashiCorp Vagrant 2.0 」というブログが投稿されました。例によって翻訳しましたので、参考程度にどうぞ。概要は、Vagrant 1.0 のリリースから今に至るまで様々な改良を施し、昨日安定版としての 2.0 リリースに至ったという内容です。

HashiCorp Vagrant 2.0

HashiCorp Vagrant 2.0 を発表します。Vagrant は開発環境の構築および配布用ツールです。

開発環境のプロビジョニング（訳者注；システム環境の環境構築を自動的に行う動作）において、 Vagrant 2.0 はVirtualBox、VMware、Hyper-V、Docker、AWS、GCP などをサポートしています。Windows や macOS 上で仮想化できるだけでなく、他の多くの新しいオペレーティングシステムにも対応しました。Vagrant 2.0 は Vagrant Cloud と連携し、box を検索・利用できます。Vagrant 1.0 から今日に至るまでは長い道のりでした。サポートしていたのは VirtualBox のみでした。また、リリース以降のコミュニティは著しく成長しました。

Vagrant 2.0 は Vagrrant のウェブサイト からすぐにダウンロードできます。直近の Vagrant リリースに関する変更点の一覧は Changelog からご覧いただけます。

HashiCorp Vagrant

Vagrant は 2009 年から開発が始まり、開発環境とインフラストラクチャ（訳者注；OSを実行可能なシステムおよびネットワーク基盤）の自動デプロイに対して、瞬く間に頼りになるツールとなりました。プロダクション（本番環境）の鏡となる開発インフラの構築を、１つのワークフローで作成することが Vagrant の目的です。

20013 年に安定版（stable）として Vagrant 1.0 がリリースされました。Vagrant 1.0 はプロバイダ（訳者注；Vagrantにおける用語で、インフラを操作する API ドライバのこと）としてサポートしたのは VirtualBox のみでした。また、Linux ゲスト OS としてサポートしていたのは一部のみです。それに、サポートしていたのは単純な起動（up）／停止（destroy）のワークフローのみでした。Vagrant 1.0 以降、私たちは VMware と Docker といった複数のプロバイダに対するサポート追加や、Windows と macOS のようなゲストの追加、そしてスナップショットを含む複雑なワークフローを追加しました。これらの主な変更は何百もの改良とバグ修正によるものです。

Vagrant 登場以前の開発環境は、ほとんどが手作業での構築、エラー解決であり、時間を浪費しました。また、インフラの自動デプロイには、実際のマシンを作成・破棄するように、極めて長いフィードバック・サイクル（訳者注；試行錯誤の繰り返し）がありました。Vagrant は、これら両者のプロセスを１つのコマンドで行えるように変えたのです。

HashiCorp Product suite は、あらゆるアプリケーションをあらゆるインフラ上にプロビジョンし（訳者注；自動的なインストールや設定）、安全であり、接続し、実行できるものであり、Vagrant はその一部です。Vagrant で開発環境のプロビジョンが可能ですし、HashiCorp Packer で Vagrant イメージを構築できます。そして、HashiCorp Terraform でインフラを構築し、Vault でシークレット（訳者注；APIやSSH鍵などの機密データ・情報）管理を扱い、Nomad でワークロードのスケジュール（訳者注；どのノードまたはホスト上で、どのようなジョブまたはプロセスを実行するか決めること）をし、Consul でインフラを連結します。

コミュニティとチーム

私たちは Vagrant 2.0 を作り上げたコミュニティと Vagrant コアチームに感謝を申しあげます！ HashiCorp Vagrant は過去７年で 750 人以上の貢献者がいらっしゃいます。何年もの間、貢献者の皆さんが機能を追加し、バグを修正し、Vagrant を前へと進めました。

Vagrant 互換性の領域が広がるにつれ、プロジェクトの維持にはコミュニティによる改善が不可欠でした。私たちのコミュニティには、あらゆる種類のプロバイダ、あらゆるオペレーティングシステム、あらゆるプロビジョナー等の専門家に溢れています。これらコミュニティのメンバーが協力し、多様性を持つツールとして作り上げたのが Vagrant なのです。

HashiCorp の Chirs Roberts が 2.0 に向けての変更を牽引しました。2016 年にプロジェクトの責任者となり、バージョン 2.0 に至るために不可欠である、重要な安定性に関する課題に取り組みました。Chris は Brian Cain および Justin Campbell と連携し、３人が一丸となって毎日 Vagrant の改善に取り組んでいます。

原文

【参考訳】Terraform 0.10 アップグレード・ガイド

04.08.2017  in HashiCorp using tags Terraform , HashiCorp , translation

概要

先日の 【参考訳】HashiCorp Terraform 0.10 に続き、数々の変更に伴う説明が書かれている Upgrading to Terraform 0.10 も重要だと思い、参考情報として翻訳しました（8月4日現在）。皆さまのアップグレードの手助けになればと思っています。

Terraform v0.10 へのアップグレード

Terraform v0.10 はメジャー・リリースです。従って、アップグレードにあたっては、検討が必要な複数の変更を伴います。当ガイドは、この検討の手助けとなるのを目指します。

ガイドの目的はアップグレードにあたり、一般的な懸念事項や課題解決に役立つ詳しい説明や背景を扱います。全ての変更項目は Terraform 変更履歴（Changelog） で常に網羅しています。このガイドを読み終えたら、リソースをプロバイダの利用に対して、変更履歴にある各項目の確認をお勧めします。

特にこのガイドでは v0.9 から v0.10 の変更に焦点をあてています。これまでのメジャー・リリースにも、それぞれに更新ガイドがあります。古いバージョンをお使いの場合は、必要に応じて各ガイドを直接ご覧ください。

プロバイダ・プラグインの分離

v0.10 現在、主となる Terraform 配布物（パッケージ）にはプラグインを同梱しません。そのかわり、プラグインは戸別配布となり、 terraform init コマンド で自動的にインストールします。

長期的には、この新しい手法はあらゆる皆さんに役立つでしょう。たとえば、特定のプロバイダをアップグレードして新機能に対応したいけれども、変更によって他プロバイダの互換性問題が心配な場合です。短期的には、配布パッケージが小さくなりますし、全く使わない多くのプロバイダをダウンロードする必要もありません。

また、プロバイダ・プラグインは Terraform 本体とは個別にバージョン管理されます。 バージョン制限（version constraints） を使えば、新しいメジャー・リリース（破壊的な変更を含む可能性）があったとしても特定のバージョンを利用し続けられます。

対策 ：アップグレード後は、必要なプロバイダ・プラグインをインストールするために、各 Terraform 設定ファイルのある作業ディレクトリで terraform init を実行します。もしも自動処理で Terraform を使っている場合は、バージョン・コントロールから Terraform 設定をクローンした直後の手順として、こちらのコマンド実行が必要です。また、必要なモジュールのインストールが必要だったり、リモート・バックエンドの設定が必要になったりするでしょう。

対策 ：「プロダクション」（本番環境）向けの設定にあたっては、 terraform init の出力で推奨される プロバイダのバージョン指定 の追加をご検討ください。この対策をしておけば、プラグインが将来的にバージョンアップしても、新しいメジャー・バージョンの自動インストールを防げます。

サードパーティ製のプロバイダ・プラグイン

プロバイダ・プラグインを分割しての初リリースで影響を受けるのは、HashiCorp がパッケージ化してリリースしているプロバイダに対してのみです。この方向性は、サードパーティ製プラグインの定期的サポートと似たような手法を目指しています。しかし、このような状態が一般的になる前に、私たちはインストールとバージョン管理の堅牢な仕組みを確保したいのです。

それまでの間、 サードパーティ製プロバイダをインストールする主な仕組み はサポートが続きます。サードパーティ製プロバイダのメンテナは、バイナリの名前による新しいバージョン管理メカニズムをオプションで取り入れることになるでしょう。例えば terraform-provider-名前-v0.0.1 の “0.0.1” にあたる部分を使う枠組みです。Terraform は セマンティックバージョン管理（semantic versioning） 手法をプロバイダが使っているとみなします。

しかしながら、現時点においてはサードパーティ製のプロバイダは自動的にバージョンを指定したインストールができません。 いずれ Terraform 0.10 は設定ファイルを通して指定されたバージョンをインストールするかどうか確認し、もしも指定されたバージョンが使えなければエラーがでるようになります。

対策 ：直ちに対策は不要ですが、サードパーティ製プラグインのメンテナは、利用者が今後のバイナリ配布にあたってバージョン番号を使えるよう、オプションとしての検討を始めたら良いかもしれません。

-target を使った再帰的なモジュール対象

-target 引数で各モジュールの場所を指定すると、（必要な）リソースの全てをターゲット（対象）にできるでしょう。

 $ terraform plan -out=tfplan -target=module.example

このコマンドは、 0.10 までは指定したモジュールのリソース のみ を、直接の対象としていました。0.10 では挙動が変わり、コマンドの実行によって、 派生した モジュールも対象リソースとして含みます。

たとえばモジュール自身が module.example であれば、 先ほどのコマンドを実行すると、対象となるリソースは module.example と module.example.module.examplechild の両方です。

また、 リソース割り当て（resource addressing） 構文を使う Terraform の機能も使えます。ここでは terraform state と同じサブコマンドを含みます。

対策 ：Terraform の自動処理で -target を使っている場合は、指定しているリソースに子モジュールがあったとしても、何ら動作上の問題がないのを確認します。 -target を使う場合は plan のレビューにあたり、作業にあたって必要なリソースのみインストールするのを、確実に確認してください。 -target を定常的に使うのは推奨しませんので、どうかご注意ください。これは例外的な利用であり、手動での介入なのです。

terraform apply のインタラクティブな承認

Terraform 0.10 から、plan 時にインタラクティブな確認による一時停止があれば、 terraform apply は新しいモードになり、plan 時に確認した項目のみ適用（apply）します。これは terraform plan を個々に実行可能な利便性を得るためですが、インタラクティブなコマンド入力がワークフローの簡素化に影響を与えてしまいます。

これまでのラッパー・スクリプトが期待通りに動かなくなるのを防止するため、0.10 ではこの機能は無効がデフォルトです。もし、こちらの挙動を使いたい場合は、特定の plan ファイルを指定せずに terraform apply 時に -auto-approve=false を指定します。

Terraform の将来的なバージョンでは、この挙動がデフォルトになるよう計画しています。そのため、ただちに対策は不要ですが、将来的な変更に備え、Terraform の自動化もしくはラッパーを用いている場合は、次の手法による調整を強く推奨します。

  • プロダクションのシステムに関わるインタラクティブではない自動処理では、 terraform plan -out=tfplan と、その後の（承認後の） terraform apply tfplan を 常に 分けるべきしょう。これは作業者が適用する（apply）前にレビュー（確認）する機会を設けるためです。

  • プロダクション以外 のシステムにおいて、plan ファイルのない自動処理で terraform apply を実行する場合、 -auto-approve=true をコマンドラインに追加するだけで、現在の 0.10 の挙動である自動承認がデフォルトで有効になります。

私たちは多くのチームがラッパー・スクリプトや自動化で Terraform をご利用されているのを把握しています。そのため、このような変更にあたり、移行期間を設けます。また、各チームには将来的な変更に備え、ツールを更新するための機会を確実に設けていただければと思います。

対策 ：0.10 はデフォルトでは以前の挙動と同じため、今すぐの対策は不要です。しかしながら、Terraform をラップしているようなツールのメンテナは、自動処理をするか別のコマンドライン UI を使うかどうかにかかわらず、将来的なバージョンに備えて活用方法や -auto-approve=... フラグを使うかどうかの明確な決定を考慮すべきでしょう。

原文

【参考訳】HashiCorp Terraform 0.10

03.08.2017  in HashiCorp using tags Terraform , HashiCorp , translation

“HashiCorp Terraform 0.10” 概要

HashiCorp の blog に、 Terraform 0.10 のリリースに関するブログ投稿 がありました。今回はコアとプロバイダの分離という大きな変更を伴っています。その背景の理解が、今後の Terraform を利用する上で欠かせないと感じ、共通認識を確保したく、例によって参考訳を作成しました。以下どうぞ。

HashiCorp Terraform 0.10

HashiCorp Terraform 0.10 のリリー発表を嬉しく思います。Terraform はインフラ（infrastructure、訳者注；システム基盤）を安全かつ効率的に構築、比較、起動するツールです。今回のリリースには多くの新機能と改良が含まれています。

前回の Terraform メジャー・リリース以降、11 のマイナー・リリースを行い、６つの新しいプロバイダ、24 のデータソース、60 以上の新しいリソースを追加しました！　それだけでなく、 Terraform プロジェクトは 1,100 名を超える貢献者からのコントリビューションを受けました。

Terraform 0.10 では、Terraform に多くの重要な新機能が加わります。重要なのはこちらです：

  • Terraform コアとプロバイダを分割
  • 数々のプロバイダを改良
  • Stete environments はワークスペース（Workspaces）に

Terraform コア（Core）と Terraform プロバイダを分割

terraform 0.10 では、プロジェクトを２つの論理コンポーネントに分割しました。それが Terraform コアと Terraform プロバイダです。Terraform コアは GItHub 上オリジナルの hashicorp/terraform に存続します。一方のプロバイダは新しい GitHub 上の Terraform Providers organization に移動しました。また、Terraform プロバイダのバイナリも Terraform コアからは独立してリリースされます。全てのリリースは releases.hashicorp.com からダウンロードできます。

GitHub リポジトリと配布用バイナリの分離によって目指すのは、コミュニティのメンバーが所有・貢献することによる Terraform 改良の加速です。

今後のプロバイダ・プラグインは Terraform のバイナリと共に配布されません。そのかわり、個々に配布されることになり、 terraform init コマンドにより、必要に応じて取得およびインストールが行われます。この新しい手法により、利用者は個々のプロバイダごとにアップグレード可能になります。また、プロバイダの調整やパッチをあて、プロバイダの削除を個別に行えます。

Terraform 本体のバージョンとプロバイダ・プラグインが切り離されましたので、個別にバージョン制限を行うことにより、上流側による破壊的な変更（breaking changes）から利用者を守ります。これは git init のようなもので、 terraform init が日々の Terraform ワークフローにおいて重要な部分になります。

分割に関する詳細な情報については、以前の投稿 Upcoming Provider Changes in Terraform 0.10 をご覧ください。

プロバイダの分割

各プロバイダのソースが現在置かれている場所は、 Terraform Providers GitHub organization にある個々のリポジトリ内です。 Terraform コアから各プロバイダが分割されたため、各プロバイダ自身がリリースの調整、バージョン指定、ドキュメントを持てるようになりました。

今後のプロバイダ・プラグインは Terraform のバイナリと共に配布されません。そのかわり、個々に配布されることになり、terraform init コマンドにより、必要に応じて取得およびインストールが行われます。新しいプロジェクトのスタート時に、あるいはプロバイダの追加・削除といった設定に関する変更時は、 terraform init を実行しますと Terraform は設定を読み込み、必要なバイナリを取得します。

Terraform Providers GitHub organization にある、あらゆるプロバイダを Terraform は自動取得します。各プロバイダのバイナリは、 HashiCop によって事前にビルドされ、 releases.hashicorp.com 上に置かれています。

プロバイダの制約

プロバイダとコアの分割により一部で重要なのは、今後のプロバイダはそれぞれがバージョン番号を餅、コアや他のプロバイダとは別に進むことです。Terraform は動的に利用可能なプロバイダを必要に応じて取得し、設定ファイル上でバージョン指定があれば従います。たとえば、AWS と Fastly の２つのプロバイダを使う設定を考えましょう。

provider aws {
  version = "~> v0.1.3"
  region  = "us-west-2"
}

provider fastly {
  api_key = "exampleapikey"
}

こちらには２つのプロバイダ・ブロックを宣言し、AWS プロバイダは少なくとも v0.1.3 であるべきと指定しています。Fastly プロバイダの宣言ではバージョン指定を省きましたので、Terraform は最新版を取得します。そのため、 terraform init を実行することで Terraform は設定ファイルを読み込み、それから、動的に必要なバイナリを取得するのが想像できるでしょう。

プロバイダの改良

Terraform プロバイダは、新しいリソース、新しいデータソース、バグ修正など、数々の改良や追加機能を導入しました。さらに進めているのは、Terraform コアの Changelog には Terraform プロバイダの変更に関する情報を記録しません。各プロバイダは既に GitHub 上に独立したリポジトリをそれぞれ持っており、自身の課題追跡（issue tracker）や変更履歴（Changelog）を持っています。例：

Terraform Provider GitHub organization リポジトリ一覧 で、すべてのプロバイダと対応している変更履歴を参照できます。

また、Terraform エコシステムを将来的に拡張するため、 Terraform プロバイダ開発プログラム も開始しました。これが目指すのは、自分たちのインフラをサポートする Terraform プロバイダを構築したい提供者（ベンダ）と利用者（ユーザ）のためです。Terraform プロバイダ開発プログラムは大部分が自己解決型であり、情報源へのリンク、明確なステップの定義、チェックポイントがあります。

State Environemnts はワークスペース（workspaces）へ

Terraform 0.9 は “State Environments” を導入しました。これは state （状態）ファイルに名前空間を使うことで、１つのフォルダ内で複数の明確なインフラ・リソースを管理する設定が可能にしました。初リリース以降、コミュニティからは用語が混乱を招くとの指摘を受けました。 Terraform 0.10 からは「State Environments」の用語を置き換え「Workspace」の概念を導入しました。それに伴い、 terraform env コマンド系列は terraform workspace へと名前が変わります。 env サブコマンドは後方互換性のためにサポートされ続けますが、将来的なリリースにおいて削除予定です。これらのコマンドを使う自動処理やスクリプトの書き換えを推奨します。

Terraform ワークスペースに関する詳しい情報は ドキュメントのページ をご覧ください。

アップグレード

コアとプロバイダが分離するため、私たちが作成したガイド Upgrading to Terraform 0.10 を注意深くお読みください。Terraform 0.10 のコアには後方互換性がありませんが、反対や変更があれば、可能な限り早く取り込むでしょう。0.9 にアップグレードする前に、アップグレード・ガイドを確認し、考慮点の全てをご検討ください。

これらの変更に加え、プロバイダやリソースに対する数々の変更が、皆さんのご利用方法によっては影響を引き起こす可能性があります。ほぼ全てのリリースにおいて、既存のプロバイダやリソースには何らかの変更があります。より詳しい情報については、適切な変更履歴（changelog）をご覧ください。

まとめ

Terraform はリリースの度に成長と成熟を重ねています。Terraform をコードとしてのインフラ（infrastructure as code）を管理する業界有数のツールにすべく尽力いただいている、Terraform のコミュニティのメンバーすべてに感謝を申しあげます。

Terraform コアについては、私たちはこれまで通りの基準でリリースを続けます。しかし、プロバイダを分割したことで、リリースは以前のペースよりは遅くなるでしょう。今後の Terraform プロバイダは、必要性に応じて個々にリリース・スケジュールを調整できるようになりました。

あとは Terraform をダウンロード して、試してみましょう！

原文

【参考訳】HashiCorp Nomad で Apache Spark を動かす

29.07.2017  in HashiCorp using tags Nomad , HashiCorp , translation

Apache Spark 版 Nomad のリリース発表

HashiCorp の blog で Spark のクラスタマネージャ・スケジューラとして Nomad がネイティブに対応したという 記事 がでていました。こちらも参考程度にどうぞ。

HashiCorp Nomad 上で Apache Spark を動かす

Apache Spark は人気のデータ処理エンジン／フレームワークであり、第三者によるスケジューラを使えるような設計がされています。スケジューラは利用可能ではありましたが、複雑さのレベルが高かったため、Spark ユーザの多くにとって不快だったでしょう。この溝を埋めるため、私たちは HashiCorp Nomad エコシステムを発表します。ここに含まれる Apache Spark バージョン（a version of Apache Spark） は、Spark クラスタのマネージャとスケジューラとして Nomad をネイティブに統合します。

なぜ Nomad で Spark を？

Nomad の設計（Google の Borg と Omega から影響を受けた）は、解析アプリケーションの実行をより適切に行えるようにするための機能セットを有効化することです。特に関係があるのは バッチ・ワークロード のネイティブなサポート、並列化、 高スループットのスケジューリング （Nomad のスケジューラ内部の詳細は、 こちら をご覧ください）です。また、 Nomad はセットアップや利用が簡単であり、Spark 利用者の学習曲線と作業負担を軽減できうるでしょう。使いやすい主な機能は、次の通りです。

また、Nomad は HashiCorp Consul や HashiCorp Vault の サービス・ディスカバリ 、 ランタイム設定 、 シークレット管理 とシームレスに統合します。

どのように動作するのか

Nomad 上で実行すると、Spark エクゼキュータはアプリケーション用のタスクを実行します。そして（オプションで）、アプリケーション・ドライバ自身が Nomad ジョブ内で Nomad タスクを実行します。

利用者は Spark アプリケーションをこれまで通り実行（submit）できます。次の例は spark-submit コマンドで SparkPi サンプル・アプリケーションを Nomad のクラスタ・モードで実行します。

$ spark-submit --class org.apache.spark.examples.SparkPi \
    --master nomad \
    --deploy-mode cluster \
    --conf spark.nomad.sparkDistribution=http://example.com/spark.tgz \
    http://example.com/spark-examples.jar 100

利用者は Nomad ジョブをカスタマイズできます。ジョブによって（上の例にあるような）設定プロパティの記述を明示して Spark を作成したり、開始時点でカスタム・テンプレートも用いられます。

job "template" {
  meta {
    "foo" = "bar"
  }

  group "executor-group-name" {
    task "executor-task-name" {
      meta {
        "spark.nomad.role" = "executor"
      }

      env {
        "BAZ" = "something"
      }
    }
  }
}

ジョブ・テンプレート（job templates）にてはメタデータや条件（constraints）の追加、環境変数の追加が可能です。ほかにも付随タスクや Consul と Vault を統合した利用もできます。

また、Nomad/Spark 統合は粒度の高い リソース割り当て 、 HDFS 、 アプリケーション出力の 継続的監視 をサポートしています。

はじめましょう

使いはじめるには、私たちの公式 Apache Spark 統合ガイド が役立つでしょう。あるいは Nomad の Terraform 設定例 や拡張 Spark クイックスタート によって AWS 上で統合のテストが行えます。Nomad 拡張ビルドは、現時点で Spark 2.1.0 と 2.1.1 に対応しています。

原文

【参考訳】HashiCorp Nomad 0.6

29.07.2017  in HashiCorp using tags Nomad , HashiCorp , translation

“Nomad 6.0” 概要

HashiCorp の blog に、 Nomad 0.6 のリリースに関するブログ投稿 がありました。Nomad は分散環境におけるジョブ管理に特化しているツールですが、最近の更新では Terraform 的な思想も受けている、あるいは継承しているように思えます。Terraform はインフラが主であるのに対し、Nomad はジョブやサービス視点でという違いはあります。

例によって詳細情報として参考訳を作成しました。以下どうぞ。

HashiCorp Nomad 0.6

HashiCorp Nomad 0.6 のリリース発表を、私たちは 嬉しく思います。Nomad は分散（distributed）、スケーラブル（scalable）かつ高可用性（highly available）クラスタ・マネージャであり、マイクロサービスとバッチ・ワークロード（batch workloads）の双方に向けて設計されたスケジューラです。

Nomad 0.6 は多くの改良やバグ修正に加え、ジョブ管理と設定の改良に集中した新機能を含みます。

  • ジョブのデプロイ
  • ジョブの履歴と、古いバージョンへの修復（revert）機能
  • 動的な環境変数
  • HashiCorp Consul でコンテナ IP アドレスの自動通知（automatic advertisement）

また、発表にあたりまして、現在は Apache Spark バージョンを含む Nomad エコシステムに感謝申しあげます。Apache Spark バージョン は Nomad を Spark クラスタ・マネージャとスケジューラとして、ネイティブに統合したものです。詳細については私たちのブログ投稿 Nomad で Apache Spark を動かす をご覧ください。

ジョブのデプロイ（job deployments）

Nomad 0.6 はアプリケーションのバージョン間における移行において、rolling（ローリング）、canary（カナリア）、blue/green upgrades（ブルーグリーン・アップグレード）によって、安全に行う仕組みを導入しました。また、この新機能により、デプロイが失敗した時は安定したバージョンに自動修復（auto-revert）できるようになりました。ジョブの更新をするには、更新ストラテジ（update strategies；更新方針）のうち１つを指定します。また、ジョブの詳細として、 update 区間で注釈を追加することもできます。以下の例は Nomad でジョブを更新する例です。時間と条件を２つ割り当ててており、ロールアウト（ジョブの展開）をする前に、少なくとも 30 秒は正常（healthy）である条件を指定しています。

group "api-server" {
  # api サーバを 10 インスタンス起動
  count = 10

  update {
    # 同時に２つを並列更新
    max_parallel = 2

    # 新規割り当てにあたり、更新のためのブロック解除（unblock）をする前に
    # 少なくとも 30 秒は正常（healthy）であることを確実に処理
    min_healthy_time = "30s"

    # デプロイが失敗したとみなす時間を5分と割り当てる
    healthy_deadline = "5m"

    # 新しい割り当てが正常ではない（unhealthy）であれば、直近の最新版に自動修復（auto-revert）
    auto_revert = true
  }

  # API サーバの実行に Docker を使う
  driver = "docker"
  config {
    image "api-server:0.1"
  }

  ...
  }

ジョブの更新とは、見方によっては、新しい割り当て（allocation）の作成が必要と言えるため、Nomad はグループの更新ストラテジ（update strategy）を適用します。先の例では、イメージのグループ定義を api-server:0.1 から api-server:0.2 に変更し、再送信（resubmitted）しています。すると、 Nomad はローリング・アップデートを行います。ローリング・アップデートとは、新しい２つの api-server:0.2 の割り当て（allocation）にあたり、１つが 30 秒は正常（healthy）になるまで待った後、新しく割り当てるものです。このヘルスチェックによる割り当てに失敗しますと、Nomad はデプロイが失敗したと印を付け（マークし）ます。 auto_revert （自動修復）がセットされていれば、全てのジョブが正常に割り当てられるまで、直近のジョブにロールバックします。

全てのタスクが実行中（running）の状態になり、登録した service checks （サービス・チェック）が全て通過（passing）したとき、全ての割り当て状態が正常（healthy）になります。正常な指標（health metrics）に至らない時のため、 Nomad はカナリア・アップグレード（canary upgrades）をサポートしています。カナリア変更における更新ポリシーでは、次のように注釈を追加できます。

update {
  # デプロイにあたって、２つのカナリアに対する変更テストを行い、
  # 処理が進行したら、ローリング・アップデートを恵贈
  canary = 2

  # 先ほどと同様の更新フィールド
  ...
}

説明を続けます。更新ストラテジ通りにイメージの更新処理ができれば、 Nomad は api-server:0.1 コンテナの実行を 10 インスタンス維持したまま、 api-server:0.2 を割り当てて実行するカナリア２つを作成します。作業者がカナリアの状態が正常であると確認したら、作業者は次のコマンドを使い、カナリアを昇格（プロモート；promote）できます。

$ nomad job promote api-server

カナリアの昇格後は、 Nomad は割り当てられている古いイメージからの置き換え、すなわちローリング・アップデートの準備に入ります。カナリア・カウント（canary count）を任意のカウントに至るようにしておけば、ブルーグリーン・デプロイメントも行えます。このようにして、作業者はバージョンの更新のために昇進またはロールバックを行うため、ブルーとグリーンの環境をクラスタ上で完全に実現できます（訳者注；更新前の環境と更新後の２つ環境を、１つの環境上で並行稼働でき、必要があれば切り替えや巻き戻しも Nomad を通して簡単に行えるようになりました）。

update で囲まれた区間の記述に関する詳細は、 job 操作ガイド または update stanza ドキュメント をご覧ください。

ジョブ履歴と復旧（job history and reverting）

現在の Nomad 0.6 は複数バージョンのジョブを追跡するため、作業者は直近の変更状態を調査できます。作業者が新しいバージョンのジョブを送信（submit）したら、Nomad は自動的に新しい Version フィールドを増やし、次のようなバージョン情報を追加します。

# -p フラグで違うバージョンのジョブを表示
$ nomad job history -p example
Version     = 2
Stable      = true
Submit Date = 07/25/17 00:08:57 UTC
Diff        =
+/- Job: "example"
+/- Task Group: "cache"
  +/- Task: "redis"
    +/- Resources {
          CPU:      "500"
          DiskMB:   "0"
          IOPS:     "0"
      +/- MemoryMB: "256" => "512"
        }

Version     = 1
Stable      = true
Submit Date = 07/25/17 00:08:45 UTC
Diff        =
+/- Job: "example"
+/- Task Group: "cache"
  +/- Task: "redis"
    +/- Config {
      +/- image:           "redis:3.2" => "redis:4.0.1"
          port_map[0][db]: "6379"
        }

Version     = 0
Stable      = true
Submit Date = 07/25/17 00:08:33 UTC

さらに、 Nomad はジョブのバージョン間の修復機能（reverting）をサポートしています。これにより、ジョブの挙動が正しくなければ、作業者は迅速に復旧できます。

$ nomad job revert example 1
==> Monitoring evaluation "98dd3a0a"
    Evaluation triggered by job "example"
    Evaluation within deployment: "810d5c19"
    Allocation "399ad719" created: node "24dc095f", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "98dd3a0a" finished with status "complete"

より詳細については history と revert コマンドのドキュメントをご覧ください。

動的な環境変数（Dynamic environment variables）

Nomad 0.5 から新しいテンプレート・ブロック（template block）を導入しました。これは設定ファイルに様々な値を取り込むのに便利です。たとえば、 Consul データ、Vault シークレットからのデータを取り出したものや、Nomad タスク内で処理する一般的な設定などです。この機能は非常に強力ですが、全てのアプリケーションが設定ファイルを利用できるわけではありません。

Nomad 0.6 はこの機能を拡張し、 template ブロックの機能で env パラメータを導入できるようになりました。こちらを設定すると、 Nomad はテンプレートやパーサの値に動的な環境変数を割り当てるだけでなく、開始したタスクに対しても同様に処理します。

以下の例は Consul と Vault 両方のデータを環境変数に割り当てます。また、テンプレートはジョブファイルの外に分けて保存できるので、別々に保存します。

task "example" {
  # ...
  template {
    data = <<END
  LOG_LEVEL={{key "service/geo-api/log-verbosity"}}
  API_KEY={{with secret "secret/geo-api-key"}}{{.Data.key}}{{end}}
    END

    destination   = "secrets/config"
    env = true
  }
  # ...
}

タスクの環境においては、次のように環境変数を保持します。

LOG_LEVEL=DEBUG
API_KEY=12345678-1234-1234-1234-1234-123456789abc

これにより、設定ファイルを用いながら twelve-factor 風の環境変数を扱えるようになり、しかも全ての機能が Nomad テンプレとの機能や構文と近いままなのです。

より詳しい情報は template stanza ドキュメント をご覧ください。

Consul でコンテナの IP アドレスの自動通知（Automatic advertisement of container IP addresses with Consul）

Nomad 0.6 は Consul との統合を拡張しました。オーバレイ・ネットワークと Docker ドライバを使うユーザが対象です。これは、ホストネットワークではなくネットワーク・プラグインによって割り当てられる、到達可能な IP アドレスを自動的に通知（Advertise / 広報）します。この通知機能のためにはConsul とは別に、コンテナ自身を Registrator のようなツールをつかって登録する必要があります。

より詳しい情報は Docker ドライバ・ドキュメント をご覧ください。

その他のバグ修正と改良（Other bug fixes and improvements）

以上の新機能だけでなく、多くのバグ修正や改良が施されています。変更点の一覧および詳細は v0.6.0 changelog をご参照ください。また、 ]更新ガイド](https://www.nomadproject.io/docs/upgrade/index.html) もご覧ください。

Nomad 0.6 のウェビナー

最近、 Armon Dadger （HashiCorp の共同創業者・共同 CTO）と Caius Howcroft（Citadel の計算・データインフラ部長）が、組織におけるあらゆるワークロードの実行にあたり、 あらゆるインフラで柔軟性を確保しつつ、簡単に使え、安定して、性能を出す。そのために Nomad をどのように使うのかを議論しました。動画では次の内容を扱っています：

  • Armon Dadgar による Nomad ディープ・ダイブ
  • 最新の Nomad 機能を紹介するライブデモ
  • Caius Howcroft からは、Citadel は Nomad によって、複数のパブリック・クラウドを高いスループットで横断してバッチ解析ができるように

ウェビナーでは Nomad 0.6 の新機能の概要と、Citadel がどのように Nomad の機能を活用しているかを扱っています。

https://www.youtube.com/watch?v=faNBpxOo8FQ

Nomad の更に詳しい情報や、使い始めるにあたっては、 https://www.nomadproject.io/ をご覧ください。

原文

【参考訳】Vagrant Cloud へ移行のお知らせ（6月27日）

01.06.2017  in HashiCorp using tags Vagrant , HashiCorp , translation

概要

HashiCorp の blog に Vagrant イメージの保管サービス Atlas から、Vagrant に関連する機能を6月27日に新 Vagrant Cloud に移行するという発表がありました。

ポイントは以下の通りです。

  • 公開 box のみの Vagrant 利用者は、移行後も同じ作業フローおよび Vagrantfile を利用できる
  • Atlas アカウントを Vagrant Cloud で使うには、有効化が必要（使わないままなら10月に削除）
  • Atlas 認証トークンは利用できなくなるので、事前に作成＆移行設定が必要
  • 6月27日（日本時間28日午前7時）に30分以内のメンテナンスによる停止見込み

例によって詳細情報として参考訳を作成しました。以下どうぞ。

Vagrant Cloud 移行のお知らせ

6月27日、HashiCorp の Atlas から Vagrant に関する機能 を、自身のHashiCorp Vagrant クラウドへ移行します。

移行する機能は、以下の通りです：

  • Vagrant Box の作成機能（Vagrant Box Creation）により、誰でも利用できるパブリックまたはプライベートな box の公開
  • Vagrant Box のバージョン管理（Vagrant Box Versioning）により、box の更新と、利用者に変更の通知
  • Vagrant Box カタログ（Vagrant Box Catalog）による公開 Vagrant box の検索と発見

将来的に Vagrant Cloud の開発を独立させることで、現状の機能改善や、Vagrant 関連の新サービスを定期的に提供できるようになります。

もしも Vagrant を公開 box のダウンロードと実行のみに利用しているのであれば、これまでと何も変わりません。すべての box 名、バージョン、URL は同じままであり（あるいはリダイレクトします）、皆さんの作業フローや Vagrantfile に対する変更は不要です。

既存の Vagrant box やアカウントの移行に関する詳細を知りたい場合は、以下を読み進めてください。

背景

Vagrant Cloud は HashiCorp 初のホステッド・プロダクト（訳者注：データ等を預かる製品・サービス）であり、初めてのオープンソース・プロダクトである Vagrant 用に向けて、Vagrant box の検索、管理、共有機能を提供しています。これまでは Atlas として、そして Terraform と Packer 機能に特化した Terraform Enterprise として発展してきました。

HashiCorp のプロダクト一式（suite of product）に統合されたプラットフォームは、たとえば Terraform Enterprise、Consul Enterprise、Vault Enterprise、Vagrant Cloud、いずれは Nomad Enterprise があります。これらのプロダクトから、 Atlas は離れつつあります。今ある Atlas の全機能は、プロダクトごとに分けられています。現在、 atlas.hashicorp.com ドメインに存在している機能は Terraform Enterprise と Vagrant Cloud 機能のみです。そして、近いうちに Terraform Enterprise に関するドメインは移行します。移行が完了したら、Atlas ブランドを削除します。

Vagrant Box、ユーザ、organization、team

すべての Vagrant box は、6月27日に新しい Vagrant Cloud へ移行します。さらに、すべてのユーザと organization を複製します。既存の box に対するコラボレータやチーム制限（ACL）は、新しいシステム上でも同一です。

既存の box 名（hashicorp/precise64）と URL は現状のまま利用できます。あるいは、適切な場所へ恒久的にリダイレクトします。皆さんがパブリック Vagrant box しか使っていないのであれば、お使いの Vagrantfile や作業手順を変える必要はありません。プライベート Vagrant box の利用者は、新しい認証（詳細は後述）の作成と、移行完了後に Vagrant Cloud アカウントの有効化（アクティベート）が必要です。

Vagrant Cloud のユーザと organization のうち、Vagrant Cloud への移行した後でもログインしていないか Vagrant box を公開していなければ、使用していないものと判断します。使われていないアカウントは 2017年10月1日に削除します。

Vagrant Cloud アカウントの有効化

Atlas アカウントで Vagrant Cloud を使い始めたければ、まず Vagrant Cloud アカウントの有効化が必要です。そのためには Atlas へのログインとパスワード認証が必要です（設定している場合は、二要素認証も）。Vagrant Cloud ログイン画面上にも、同様のリンクや手順を表示します。

Vagrant Cloud アカウントが有効化されたら、Vagrant Cloud 用の新しいパスワードと、オプションで二要素認証も設定できます。これまでの Atlas アカウント、パスワード、二要素認証の設定を Atlas で変更せずに使い続けられません。

Vagrant Cloud の新しいユーザは、アカウントをいつでも無料で作成できます。

認証トークン

もしも現在 Atlas の Vagrant 機能を使うために認証トークンを使っているのであれば、新しい Vagrant Cloud トークンを6月27日よりも前に作成する必要があります。既存のトークンの確認と新しいトークンの作成には、アカウント設定にあるトークンのページ をご覧ください。

新しいトークンの作成時には “Migrate to Vagrant Cloud”（Vagrant Cloud へ移行）のチェックボックスを有効にします。

トークンの一覧から、との認証トークンを Vagrant Cloud に移行するかを確認できます。

（対象の）認証トークンは6月27日に Vagrant Cloud へ移行します。また、この時点で Terraform Enterprise からも削除され、Terraform や Packer 操作を行えなくなります。6月27日までに Atlas でトークンを作成していない場合は、Vagrant Cloud に移行後、トークンの作成が必要になります。

Packer と Terraform Enterprise

Terraform Enterprise (Atlas) における Vagrant box の作成にあたり、 Packer には２つのポスト・プロセッサ（post-processor）、つまり atlas と vagrant-cloud があります。atlas ポスト・プロセッサでは、6月27日以降 Vagrant box を作成できません。現在 Packer で Vagrant box の送信を行っている場合は、vagrant-cloud ポスト・プロセッサを使用中かどうかご確認ください。具体的には vagrantup.com の Vagrant Cloud 移行ドキュメント（英語） をご覧ください。

Vagrant Share

Vagrant Share 機能は廃止となります。そのかわりに Vagrant は ngrok とのネイティブな統合をサポートします。Vagrant Share の利用者は6月27日までに ngrok-powered Vagraht 共有ドライバ への切替を行うべきです。こちらは Vagrant の次期バージョンからデフォルトになります。

停止時間

Atlas/Terraform Enterprise 内の Vagrant サービスは 6月27日の午後6時（EDT;米国東部夏時間）/午後3時（米国太平洋夏時間/ タイムゾーンの確認 ）から（※日本時間6月28日(水) 午前7時～）移行完了まで少々の停止が発生します。かかる時間は30分以内を見込んでいます。移行状況に関する最新情報は status.hashicorp.com をご覧ください。

詳細な情報

直近の移行に関する詳しい情報は、 vagrantup.com の Vagrant Cloud ドキュメント をご覧ください。Vagrant Cloud や移行に関するご質問がございましたら、 support@hashicorp.com までメールをお送りください。

原文

【参考訳】Docker 1.13 の紹介

24.01.2017  in Docker using tags Docker , translation

概要

2017年1月19日(木)に Docker 1.13 のメジャー・バージョンアップが公開されました。新機能ポイントを整理すると、以下の通りです。

  • swarm モードで Compose ファイルのサポート（新しい docker stack deploy コマンド ）、Compose v3 フォーマット追加
  • docker コマンドラインの後方互換性に対応
  • docker system df の容量表示と、 docker system prune による不要なデータ削除コマンド
  • CLI の再編成（今のコマンドは維持するものの、 docker container xxx や docker image history の利用が可能に）
  • docker service logs でサービス全てのログを取得、Prometheus スタイルのエンドポイント
  • 構築時に --squash オプションを指定すると１つのレイヤを作成（オーバヘッドとなる可能性あり）、圧縮オプションのサポート
  • Docker for AWS / Azure はベータが取れ、プロダクション対応

Docker 社の blog にリリースノート相当の更新情報が掲載されていました。

例によって、自分用の翻訳ですが、参考情報としてここで共有いたします。

Docker 1.13 の紹介

今日、私たちは多くの新機能・改良・修正を施した Docker 1.13 をリリースしています。新年の決意を抱く Docker の利用者にとっては、コンテナ・アプリの更なる構築と改善の手助けとなるでしょう。Docker 1.13 はDocker 1.12 で導入した swarm モードを改良し、多くの修正を行っています。それでは Docker 1.13 の機能ハイライトを見ていきましょう。

compose ファイルを使い、swarm モードのサービスをデプロイ

Docker 1.13 は Compose ファイルにする「docker stack deploy」コマンドを追加しました。このコマンドは「docker-compose.yml」ファイルを直接使ってサービスをデプロイ可能です。この機能の強化にあたっては、swarm サービス API をより柔軟で有用にするために、大きな努力が払われました。

次のような利点があります：

  • 各サービスごとに希望するインスタンス数（訳者注：動作するサービス数）を指定
  • ポリシーのローリング・アップデート（訳者注：サービスを動かしながらイメージを更新）
  • サービスに対する constraint（訳者注：サービス実行時の制約・条件。どのホストやどの環境で実行するかなど）

複数のホスト上に複数のサービス・スタックをデプロイするのも、簡単になりました。

docker stack deploy --compose-file=docker-compose.yml my_stack

CLI 後方互換性の改良

Docker CLI を更新する時、「Error response from daemon: client is newer than server」というエラーが出る問題に怯えていました。ですが、古い Docker Engine を使い続けたい場合には、どうしたらよいのでしょうか。

1.13 からの新しい CLI は古いデーモンとも通信可能になります。そして、新しいクライアントは、古いデーモンでサポートされていない機能を使おうとした場合に、適切なエラーを返せる機能を追加しました。これにより、異なるバージョンの Docker を同じマシン上にインストールする時の管理を簡単にし、相互運用性を大幅に改善します。

クリーンアップ・コマンド

Docker 1.13 は２つの便利なコマンドを導入しています。Docker がどれだけディスク容量を使用しているのか調べるものと、使っていないデータを削除するために役立つものです。

  • docker system df は unix ツールの df 同様に、使用中の容量を表示
  • docker system purne は使っていない全てのデータを削除

prune（訳者注：プルーン、「不要なモノを取り除く」や「削る」の意味）は特定のデータ種類を指定した削除も可能です。たとえば、 docker volume prune は未使用のボリュームだけ削除します。

CLI の再開発（restructured）

この２年以上にわたり、Docker は多くの機能を追加してきました。そして、現在の Docker CLI には 40 以上ものコマンド（執筆時点で）があります。コマンドには build や run のように頻繁に使われるものもあれば、 pause や history のように余り知られていないものもあります。トップレベルに多くのコマンドがあるため、ヘルプページを混乱させ、タブ補完を難しくしています。

Docker 1.13 では論理的な目的の下に全てのコマンドがおさまるようにコマンドを再編成しました。たとえばコンテナの list （一覧）と start （起動）は新しいサブコマンド docker container で利用可能となり、 history は docker image サブコマンドになります。

docker container list
docker container start
docker image history

これら Docker CLI 構文のクリーンアップ（見直し）により、ヘルプ文書の改善や Docker をより簡単に使えるようになります。古いコマンド構文はサポートし続けますが、皆さんが新しい構文の採用を推奨します。

監視の改良

サービスのデバッグをより簡単にするため、docker service logs は実験的な新しい強力なコマンドとなります。従来はホストやコンテナで問題を調査するためには、各コンテナやサービスのログをそれぞれ取得する必要がありました。 docker service logs を使えば対象のサービスを動かしている全てのコンテナのログを取得し、コンソール上に表示します。

また、Docker 1.13 ではコンテナ、イメージ、その他デーモン状態といった基本的なメトリック（訳者注：システムのリソース利用状況など）を持つ Prometheus スタイルのエンドポイント を追加しました。

構築の改良

docker build に新しい実験的な --squash （スカッシュ；「押し込む」「潰す」の意味）フラグを追加しました。スカッシュを指定すると、Docker は構築時に作成した全てのファイルシステム・レイヤを取得し、それを１つの新しいレイヤに押し込み（スカッシュし）ます。これにより最小のコンテナ・イメージ作成に関わる手間を簡単にします。一方、イメージが移り変わる場合は（スカッシュされたレイヤはイメージ間で共有されなくなるため）、極めて大きなオーバヘッドとなる可能性があります。Docker は以後の構築を速くし続けるために、個々のレイヤのキャッシュを続けます。

また、1.13 では構築時の内容物（コンテクスト；build context）の圧縮をサポート しました。使うには CLI からデーモンに対して --compress フラグを使います。これにより、リモートのデーモンに大量のデータを送る必要がある場合は構築スピードが向上します。

Docker for AWS と Azure がベータ版の段階を終了

Docker for AWS と Azure はパブリック・ベータを終了し、プロダクション対応（実際に利用可能）となりました。皆さんからのフィードバックを取り込み、Docker for AWS と Azure の対応には半年を費やしました。そして、テストや個々の問題に取り組んでいただいた全てのユーザの皆さんに大きな感謝を申しあげます。また、更なる更新や拡張を調整したバージョンを数ヶ月のうちに提供します。

Docker 1.13 を始めましょう

Docker for Mac と Windows のベータ・安定版の両ユーザは、自動更新の通知を受け取っているでしょう（実際の所、ベータ・チャンネルのユーザには、半月前に Docker 1.13 を提供していました）。Docker が初めてでしたら、Docker for Mac か Windows で始めましょう。

Docker for AWS と Docker for Azure は、ドキュメントを確認するか、ボタンを押して始めましょう。

Linux に Docker をインストールしたい場合は、インストールの詳細手順（英語）をご覧ください。

原文

【参考訳】Docker の containerd 寄贈に関する発表

17.12.2016  in Docker using tags Docker , containerd , translation

概要

Docker が containerd を独立したファウンデーションに寄贈するという発表を 2016年12月14日に行いました。例によって、自分の整理用の翻訳ですが、公開します。

各発表に対する日本語訳は正式なものではありません。私が趣味で翻訳しているものです。訳注、様々な意図を持つ言葉に対しては、（ ）内で原文と訳注を補足しています。ただし、翻訳の専門家ではないため、表現に拙い箇所があるかもしれません。その場合は遠慮なくご指摘いただければと思います。

原文は https://www.docker.com/docker-news-and-press/docker-extracts-and-donates-containerd-its-core-container-runtime-accelerate です。

以下翻訳。

Docker Extracts and Donate containerd, its Core Container Runtime, to Accelerate Innovation Across the Container Ecosystem

Docker はコンテナ・エコシステム全体の革新を促進するため、自身のコア・コンテナ・ランタイムである containerd を取り出して寄贈。

Alibaba Cloud、AWS、Google、IBM、Microsoft は Docker と協調し、コンテナ・ランタイムのオープンソース・プロジェクト に対する支援（resources；人的・金銭的）と貢献を表明

サンフランシスコ―2016年12月14日―本日、Docker は、containerd（コンテナディー；Con-tay-ner-D）のスピンアウト（独立）を発表しました。Docker Engine は業界トップのコンテナ・プラットフォームであり、containerd とは Docker Engine の中心となる構成要素（コア・コンポーネント）です。そして、この containerd を新しいコミュニティ・プロジェクトに寄贈します。これまでの Docker Engine は利用者（エンドユーザ）向けのコンテナ・プラットフォーム一式として、Docker API 、Docker コマンドとサービス、containerd で構成されていました。これらの構成要素は業界向けにオープンであり、安定し、Docker を使わない製品やコンテナ・ソリューションを作るための基盤となるよう拡張可能です。有数のクラウド提供事業者である Alibaba Cloud、Amazon Web Services [AWS]、Google、IBM、Microsoft は、プロジェクトに対するメンテナとコントリビュータの提供を表明しました。

containerd の機能に含まれるのはコンテナ・イメージの転送手法、コンテナの実行と管理、ローレベルのローカル・ストレージとネットワーク・インターフェースであり、Linux と Windows のどちらも扱います。containerd はオープン・コンテナ・イニシアティブ [OCI] のランタイムを十分に活用します。たとえばイメージのフォーマット指定や OCI リファレンスの実装 []runC であり、OCI 認証が決まれば追従しています。皆さんは今日から containerd プロジェクトに貢献できるようになります。サードパーティのメンテナによる強力なサポートのもと、共同作業（collaboration）や貢献はオープンに行われます。

Docker の創業者・CTO・最高プロダクト責任者（Chief Product Officer）である Solomon Hykes は「この成果とは、何ヶ月にも及ぶ綿密な共同作業と、Docker コミュニティの今後の方向性を示すリーダー達らの情報提供によるものです。」と述べました。「containerd は新しい革新の段階に解き放たれ（unlock；アンロック）、エコシステム全体の成長をもたらすでしょう。言い換えれば、Docker の開発者と利用者のすべての利益となります。Docker は常に利用者の問題解決を優先して取り組んでいます。それゆえ、これまで課題として取り込んだ配下のプロジェクトを独立（スピンアウト）します。containerd プロジェクトが業界のリーダー達からサポートを得られることになり、私達は大きな刺激を受けています。そして、リーダー達の支援は、この共同プロジェクトの成長に対して原動力となるでしょう。」

Docker による containerd への寄贈は、配下の主要なオープンソース・プロジェクトをコミュニティに対して提供してきた従来の流れに沿っています。この取り組みは 2014 年に libcontainer を社がオープンソース化した時から始まりました。それから２年が経ち、Docker は同じような流れでコミュニティに対して libnetwork 、 notary 、runC [OCI に寄贈]、HyperKit、VPNkit、Datakit、swarmkit Infrakit を提供しています。containerd が特権を持つのは限定された機能の範囲に対してです。明確なゴールは Docker に安定して使われ続けることと、すべてのコンテナ・システムと優れたオーケストレータに対して拡張可能であることです。これらの結果、システム全体が共有する構成要素の配下にある「つまらない」（boring）基盤でも、Docker とコンテナのエコシステムによって、利用者が必要とする革新をもたらすでしょう。プロジェクトでは、新機能に対する品質強化のために、コミュニティが定義しているリリース手順を今後も続けます。そして、これらの活動は Docker のブランドとは切り離されます。

RedMonk の業界アナリスト Fintan Ryan は「技術組織はますますコンテナに対して注目しています。迅速なアプリケーション開発のためと、複数の環境に横断したデプロイを将来の成長のためにスケール（拡大・縮小）できるようするため。それと、エコシステム全体の互換性が重要な考慮点なのです。」と述べました。「コンテナのエコシステムに対する containerd の寄贈とは、幅広いコミュニティが構築に使う、標準化されたコア・コンポーネント（中心となる構成要素）を Docker が提供することです。コアが標準化されることにより、開発者は安定性を確保するための技術選択を、あらゆる基盤の互換性を保ちながら再検討できるようになるのです。」

利用とリソース

containerd リポジトリ https://github.com/docker/containerd/ は今日からオープンです。コメントや貢献をお待ちしています。リポジトリ内には詳細な情報があります。

containerd は 2017年の第1四半期（Q1）までに独立した財団（ファウンデーション）に寄贈します。財団はガバナンスの監督、商標の保持、商標の取り扱いを行います。

（Supporting Quotes、 支持に対する引用は省略しました）

原文

関連

【参考訳】HashiCorp の DevOps Defined とアプリケーション・デリバリ・プロセス

29.11.2016  in HashiCorp using tags HashiCorp , DevOps , translation

概要

HashiCorp のブログとサイトで、DevOps Defined（定義）に関する２つのドキュメントが公開されました。自分用に翻訳していたのですが、死蔵させておくのも無意味と思い、いつもの通り公開します。私はアプリケーションの開発者寄りではないため、開発寄りのキーワードの翻訳に誤っているところがあれば、ご指摘いただけますと幸いです。

HashiCorp、DevOps、そして、アプリケーション・デリバリ・プロセス

本日の DevOps Defined（DevOps定義）正式発表をとても嬉しく思います。DevOps Defined とは、DevOps の採用によりアプリケーション・デリバリ（application delivery）を速めるためのガイドです。２年前、私たちは Tao of HashiCorp （HashiCorp 道）を公開しました。これは、私たちのツールの背景にある設計原理や哲学について詳しく述べたものです。そして、それ以降は、HashiCorp 道を追求すべく Vault と Nomad など新しいオープンソース・プロジェクトを立ち上げました。これは私たちの技術を共有するという方向づけには、とても有用な財産となりました。

しかしながら、技術とはソフトウェア開発における１つの側面にしかすぎません。ソフトウェアの組織を構成するのは、働く人々、過程（プロセス）、技術です。技術のみに集中するのは簡単ですが、突き詰めていけば、人と過程に対する成功を目指すことになります。つまり、重要なのはソフトウェア組織を支える人々のワークフロー（作業の流れ）と生産性に対する理解です。自らの組織設計にあたっては、ワークフローの強化を通してチームが連携できるようにすべきでしょう。これこそ、私たちにとっての DevOps の本質なのです。

私たちの技術設計思想を HashiCorp 道として定義したように、DevOps Defined では、開発・運用・セキュリティを横断するソフトウェア・チームが生産性をいかに高め、そして、並行して働けるかを定義します。DevOps の目指すところを念頭に置き、私たちは明確な方向性を持ってツールの技術開発します。すなわち、開発・運用・セキュリティの各専門家が生産性をより高めるためのツールを作り上げるのです。

アプリケーション・デリバリの７つの要素、アプリケーション・デリバリを高めるために DevOps 組織をどのように構築するのか、組織内における開発・運用・セキュリティ専門家を強化する技術の使い方について、それぞれを学ぶには DevOps Defined ガイドの全文 をご覧ください。

DevOps Defined（DevOps 定義）

Accelerating the Application Delivery Lifecycle（アプリケーション・デリバリ・ライフサイクルの加速）

課題

DevOps の定義はビジネスによって変化しますが、DevOps におけるツァイトガイスト（zeitgeist、訳者注：ドイツ語の「時代精神」であり、時代背景といった意味合い）とは、ソフトウェア・アプリケーションの出荷（shipping、訳者注；日本でいうところの「ソフトウェアのリリース」）・素早い繰り返し（rapidly iterating）・安全性の問題（securing）を最小限に抑えることです。HashiCorp が DevOps として定義するのは、現代のアプリケーションの必要性、すなわち個人のアジリティ（agility；敏捷性）向上に力を入れるのに関連する、組織のプロセス（過程）なのです。

DevOps is about minimizing the challenges of shipping, rapidly iterating, and securing software applications. （DevOps とはソフトウェア・アプリケーションの出荷・素早い繰り返し・安全性の問題を最小限に抑えること）

DevOps が主に対象とするのは、アプリケーション・デリバリ（delivering applications）に関係する人々であり、開発者、オペレータ、セキュリティ専門家です。３つの役割は持ちつ持たれつの関係であり、アプリケーション配信に寄与するため、密接に連結したツールが必要です。

DevOps とはソフトウェア・デリバリ（配信）のウォーターフォール・モデルから離れる運動（movement、ムーブメント）です。ウォーターフォール・モデルでは、様々なグループを直線上に流れる滝（ウォーターフォール）を通し、ソフトウェア・アプリケーションがデリバリ（配信）されます。開発者は要件を受け取り、アプリケーションを書き、テストを行う品質保証（QA, Quality Assurance）に渡します。開発段階が終われば、アプリケーションはパッケージング（packaging）とユーザ受け入れテスト（user acceptance testing）を行うリリース・チームに渡されます。テストが完了したら、セキュリティ専門家を迎え入れ、コンプライアンス（整合性）とベスト・プラクティスを裏付けます。それから、オペレータがアプリケーションをデプロイしたら、滝（ウォーターフォール）の落下点である監視チームに最終段階として至ります。

伝統的なウォーターフォール・ソフトウェア・デリバリ・モデルの問題点とは、アジリティ（敏捷性）を最大化するのではなく、リスク（危険性）を最小限に抑えることです。ウォーターフォールは個々の自主性を制限し、フィードバック・ループを遅くし、アプリケーションの細やかな変更のたびに多くのチームとチェックポイントを必要とします。

また、DevOps の盛り上がりは、分散型サービスとデータセンタ資源（リソース）を特長づけるハイブリッド・クラウド基盤（インフラ）の台頭にも関係しています。最新のアプリケーションはインターネットに接続しており、ブラウザやモバイル・アプリなどのシン・クライアント（thin client）を備えています。更新を素早く提供できますので、専門的なリスク管理を必要とする「リコール」（recall）はほとんどなくなりました。

DevOps を正しく行えば、ソフトウェア・デリバリ速度を最大化します。配信プロセスのすべてを全体的に眺めれば、よく起こる（traditionally happen）ボトルネックを解消できます。ボトルネックとは、ある処理（プロセス）を担う役割（ロール）に対する負担が高まること。つまり、ソフトウェアは一日のうちで最も遅いチームと同じ速さでしか配信できなくなるのです。

DevOps Defined

Provision, Secure and Run Any Infrastructure For Any Application

あらゆるアプリケーションのインフラ（基盤）でプロビジョニング（供給）、セキュア（安全）、実行を。

組織によってソフトウェア・デリバリ・プロセス（配信手順）の要素が微妙に違います。これは、技術の選択、コンプライアンス要件、あるいはその他の要因によるからです。しかし、木だけではなく森全体を見渡せば、ソフトウェア・配信のライフサイクルには７つの要素があります。

BUILD （構築）

アプリケーションは開発者がコードを書くところから始まります。新しいアプリケーションであれば初期バージョンを書く必要があります。既存のアプリケーションであれば、新しい機能の追加や、バグ修正、性能向上のために、絶え間ないサイクル（繰り返し）があります。この要素は主に開発者が関わるだけでなく、運用チームでも開発者がコードを書くための環境やツールを提供する役割を担うことがあるでしょう。

TEST（テスト）

アプリケーションの作成段階やリリース前には、複数種類のテストを実施します。最も簡単なテストは開発者が行う単体テスト（unit testing）です。そして、統合テスト（integration testing）、受け入れテスト（acceptance testing）、エンドツーエンド・テスト（end-to-end tests）などに階層化できます。これはアプリケーション・デリバリのライフサイクルにおいて重要な部分です。なぜなら、自動的なフィードバックと重要なリスク管理の制御をするからです。開発者の大半のみ関わるだけでなく、専門の QA チームやテスト基盤を管理する運用チームも関わる場合もあるでしょう。

PACKAGE（パッケージ）

アプリケーションを作成し、テストを終えたら、そのアプリケーションをプロダクション（production）用にパッケージ化する必要があります。パッケージ化にあたっては、技術と対象となる環境により、大きく依存する場合があります。たとえば、JBoss の場合は WAR ファイルですし、Kubernetes の場合は Docker コンテナです。アプリケーションの土台（基礎）となるものは、ソースコードを元に、対象の環境上で実行可能なファイルとしてパッケージされています。これらのパッケージは Artifactory （アーティファクトリ、訳者注：Terraform のアーティファクトを置く場所）などのレジストリに格納されています。

PROVISION（プロビジョン）

アプリケーションはどこかしらで実行する必要があります。あらゆる抽象化レイヤの下では、コンピューティング、ストレージ、ネットワークといったリソースの提供が依然として存在します。これらはベアメタルや仮想マシンで直接提供される場合もあれば、PaaS や Lambda-as-a-Service（サービスとしてのラムダ）フレームワークを通して間接的に提供される場合もあります。どちらの場合でも、アプリケーション要件にあわせてプロビジョニングと設定をし、時間の経過とともに更新し、役目を終えれば最終的に廃止する必要があります。通常、運用チームがプロビジョニングを管理（owned）しており、開発者に対して提供します。

SECURE（セキュア）

連結が少なければ少ないほど（as weakest link）、システムの全体的なセキュリティが強力になります。これは、アプリケーション配信プロセスの最初から、セキュリティが関与しているのを意味します。セキュリティ・チームは、開発中にベスト・プラクティスを用いる手助けをし、ネットワーク・トポロジのモデリングを支援し、インフラのプロビジョンに使うプロジェクトの資格情報（credential）を保護します。また、データベースのパスワードや API トークンなど、アプリケーションのデプロイに必要な秘密情報（secret、訳者注：パスワードや秘密鍵などセキュリティ上の重要な情報）に対する権限を与えます。一般的にはセキュリティは専属チームの役割ですが、アプリケーションを提供する他のチームも関与します。

DEPLOY（デプロイ）

デプロイ（展開）とは、基盤となるリソースをプロビジョニング（提供）した状態において、パッケージ化したアプリケーションを取得し、実行するのを意味します。マシンまたは仮想マシンが単一のアプリケーションを実行するよう特化している場合であれば、プロビジョニングとデプロイを密接に連携できます。一方、（プロビジョニングとデプロイが）分かれている場合であれば、スケジューラを用いてマシン上に動的にアプリケーションを置きます。

MONITOR（モニタ）

実行中のアプリケーションに必要なのは、実行が継続し、正常でありつづけるのを監視することです。サービスは障害または劣化したインスタンスからの通信を回避しながら、相互に通信する必要があります。これを担うのがサービス・ディスカバリです（service discovery）。きめ細かい生存確認からログ（logging）とテレメトリ（遠隔測定データ）に至るまで、監視は広範囲に至ります。監視に含まれる担当は、アプリケーションの動作を理解したい開発者と、インフラを管理するオペレータ、アプリケーションの広範囲を維持管理するサイト信頼性チーム（site reliability team）です。

DevOps Delivered （DevOps をもたらす）

Provision, Secure and Run Any Infrastructure For Any Application

あらゆるアプリケーションのインフラ（基盤）でプロビジョニング（供給）、セキュア（安全）、実行を。

高い能力を発揮するチームを設計する（組織する）のは、高性能アプリケーションの設計と似ています。つまり、調整を最小限に（minimal coordination）することです。ソフトウェアの場合はアムダールの法則（Amdahl’s law、計算機システムの並列度を上げたときの性能上限、ウィキペディア ）で最も表されています。そこで、働く個人を「serial execution units」（連続実行ユニット、連続実行単位）と考えれば、同じように人間の生産性も調整（coordination）による支配を受けます。

アプリケーションを配信（デリバリ）するには、７つの要素を飛ばせません。つまり、各ステップの実行に必要な調整を最小限に抑えるのが最優先です。各チームが独立して働けるようになれば、調整を減らせられ、個々の生産性を高められます。すなわち、アプリケーションの配信速度を向上します。これこそが DevOps の中心です。そして、私たちが選択するツールは、これら重要な機能の優先度づけをする必要があります。一貫したプロセスを維持するには、大部分の組織の現実である技術的な不均質に対処するため、これらのツールは技術ではなくワークフローに集中する必要があります。

HashiCorp が提供するのは DevOps を考慮したツール一式であり、アプリケーション配信ライフサイクルの要素間における手動調整を減らすのに重点を置いています。

Vagrant（ベイグラント）

Vagrant は開発者が同僚やオペレータに相談しなくても、自分で開発環境を迅速にセットアップできるようにします。プロダクションのような環境を提供するだけでなく、開発者はより厳しいフィードバック・ループでコードを簡単にテスト可能となります。これは継続的インテグレーション（CI: Continuous Integration）の目標の１つであり、開発者は迅速なフィードバックを受け取ることで、個々の生産性を高められます。

Vagrant について学ぶ

Packer （パッカー）

Packer はアプリケーションをあらゆる環境で実行できるようパッケージするだけのワークフローを提供します。Packer の設定を共有することで、チームを切り離しても、調整をさけることが可能となります。調整に相当するのは Autifactory や Docker Hub のようなレジストリに送る（push）だけです。

Packer について学ぶ

Terraform （テラフォーム）

Terraform は共通のワークフローを使い、インフラとアプリケーション・リソースを提供（プロビジョン）するプロダクトです。Terraform はオペレータがプロダクション環境を安全かつ迅速に作成・変更・改善できるようにします。API を宣言的な設定ファイルで体系化しておく（まとめる）ことで、チームメンバ間での共有や、コードのように扱っての編集、レビュー、バージョン管理が可能となります。

Terraform について学ぶ

Vault （ボルト）

アプリケーション配信サイクルのすべての要素にわたり、秘密情報の管理を集中管理する手法を Vault がもたらします。Vault はアプリケーションとエンドユーザに対し、秘密情報を保管・公開するための高い可用性と安全な手法を提供します。たとえば、暗号化鍵、API トークン、データベースの資格情報です。Vault により、チームはセキュリティ・チームと調整することなく、必要なデータを利用できます。セキュリティ・チームは組織を横断した調整を必要なく、パスワードの変更、資格情報の更新、ポリシー変更が可能です。

Vault について学ぶ

Nomad（ノマド）

Nomad はクラスタ・マネージャかつスケジューラです。スケジューラを使えば、組織は懸念事項を解消し、開発者を完全にマシンから引き離せます。そうすることで、開発者は実行したいアプリケーションに集中でき、スケジューラを通してアプリケーションの配置とマシン性能を管理できるようになります。Nomad により、オペレータは多くのマシンに提供（プロビジョン）できるようになります。そして、このマシンは Nomad に対してジョブを送信した開発者とは切り離されているのです。Nomad はアプリケーションを実行可能なマシン上に配置するので、オペレータと開発者が主導で調整しなくても済むようにします。

Nomad について学ぶ

Consul（コンサル）

Consul は HashiCorp のサービス・ディスカバリと監視ツールです。Consul はアプリケーションの広範囲にわたる可用性を高め、他のアプリケーションから簡単に連携できるようにします。たとえば、ウェブサーバは Consul を使い、上流のデータベースや API サービスを見つけられます。また、Consul はアプリケーション全体の正常性を監視し、正常なインスタンスのみがトラフィックを受け取られるようにします。そして、問題があれば開発者やオペレータに通知します。これはマイクロサービスやサービス指向アーキテクチャとの登場と関連しています。モノリシックなコードを元にする場合の調整を行わなくても、サービス更新の更新は個々のチームが独立して並行して行うことにより、生産性が向上します。

Consul について学ぶ

DevOps done right - DevOps を正しく行うことにより、

Allowing Operations, Security and Development teams to work in parallel

（オペレーション、セキュリティ、開発チームが並行して作業できるようになります。）

すべての企業がソフトウェア会社になるにあたり、DevOps モデルを遂行することで、優れたアプリケーションを迅速に提供できるようになります。そして、これを実現すべく、世界中の何十万人ものソフトウェア専門家が HashiCorp DevOps Suite（DevOps ツールの一式）を使っています。

私たちがDevOps の各要素に特別設計したツールを提供することにより、ソフトウェア・サプライ・チェーンにおける様々な関係者（開発、運用、セキュリティ）が、同僚による障害を取り除き、主な関心事に集中できるようになります。つまり、直線的なウォーターフォールの手順（プロセス）を、３つのチームが並列して実行できる手順へと変えるのを意味します。

ワークフローの並行化こそが DevOps の本質なのです。すなわち、アプリケーションをあらゆるインフラ上に供給し、安全に、かつ実行できるのです。

原文

原文にはイラストも掲載されていますので、理解を深めるために是非ご覧ください。

HashiCorp, DevOps, and the Application Delivery process | HashiCorp - https://www.hashicorp.com/blog/hashicorp-devops-and-the-application-delivery-process.html

関連

【翻訳】Operator の紹介：運用の知見をソフトウェアに入れる

10.11.2016  in CoreOS using tags CoreOS , Kubernetes , Operator , translation

概要

CoreOS の Blog に “Introducing Operators: Putting Operational Knowledge into Software” という記事が掲載されました。先日の KubeCon でも Keynote で取り上げられていた、 Operator という Kubernetes 上で指定した状態を維持するためのツールについての概要です。

「運用知識をソフトウェアに」と興味深いタイトルに釣られ、ついつい読んでしまいました。記事を書かれた Brandon Philips さん（ @BandonPhilips ）に翻訳を許諾いただきましたので、ここで公開します。翻訳に間違いがありましたら、どうぞお気軽に @zembutsu までご指摘ください。

Operator の紹介：運用の知見をソフトウェアに入れる

サイト信頼性エンジニア（SRE; Site Reliability Engineer）とは、ソフトウェアを書いてアプリケーションを運用（operate）する人です。SRE はエンジニアであり、開発者でもあり、特定のアプリケーション領域に特化したソフトウェアをどのように開発するかを知っています。結果として、アプリケーション運用範囲の知識を、ソフトウェアの要素にプログラムとして入れ込むことになります。

私たちのチームは Kubernetes コミュニティの企画や実装に対し、今日に至るまでずっと取り組んでいます。実装が目指すのは、 Kubernetes 上の複雑なアプリケーションを、先の概念にもとづき確実に作成・設定・管理することです。

私たちはこの種のソフトウェアを Operator （オペレータ）と呼びます。Operator とはアプリケーションに特化したコントローラです。Kubernetes の利用者に代わり、複雑でステートフルなアプリケーションを作成・設定・管理するために Kubernetes API を活用します。kubernetes 上にリソースとコントローラの概念を構築します。それだけでなく、特定の範囲（domain）やアプリケーション固有の知識を一般的なタスクに自動化します。

ステートレスは簡単、ステートフルは難しい

ウェブ・アプリケーションやモバイル・バックエンド、API サービスの管理やスケールにあたり、Kubernetes では細かな設定をしなくてもすぐ使えるため、比較的簡単です。なぜでしょうか。理由は、これらアプリケーションは一般的にステートレスだからです。追加の知識がなくても、Deployments のような基本的な Kubernetes API によってスケールしたり障害から復帰したりできるのです。

データベース、キャッシュ、監視システムのように、ステートフルなアプリケーションの管理に取り組むのは大変です。これらのシステムでは、正確なスケール、更新（upgrade）、再設定といったアプリケーション領域の知識が必要です。これは単なる知識ではなく、データの欠損（loss）や利用できなくなるのを回避するものです。私たちはこのようなアプリケーション固有の運用知識をソフトウェア内にエンコード（変換）することで、高性能な Kubernetes の抽象化を活用し、アプリケーションを正確に実行・管理できるようにしたいのです。

Operator（オペレータ）はこの領域の知識を変換（encode）します。そして Kubernetes API の拡張により、サードパーティ・リソース（third party resources） メカニズムに対して、利用者によるアプリケーションの作成・設定・管理を可能とします。Kubernetes の内部リソースのように、Operator はアプリケーションの単一インスタンスを管理するのではなく、クラスタを横断する複数のインスタンスを管理します。

Operator の概念がコードをして動くのを実演（デモンストレーション）するために、今日、２つの実装例をオープンソース・プロジェクトとして公開します。

  1. etcd Operator は etcd クラスタの作成・設定・管理をします。etcd は信頼性のある分散キーバリュー・ストアです。CoreOS では分散システムにおいて最も重要なデータを維持するために導入しています。また、Kubernetes 自身の主要な設定データの保存先としても使います。

  2. Prometheus Operator は Prometheus 監視インスタンスを作成・設定・管理します。Prometheus は高性能な監視とメトリック（訳者注：監視データの数値化）とアラート（通知用）ツールです。そして、クラウド・ネイティブ・コンピューティング・ファウンデーション（CNCF: Cloud Native Computing Foundation）のプロジェクトとして、CoreOS チームが支援しています。

どのように Operator が構築するのか？

Operator は Kubernetes の中心となる２つの概念、リソース（resources）とコントローラ（controllers）に基づき構築します。たとえば内部の ReplicaSet リソースの場合、ユーザは実行したいポッドの数を設定します。次に、コントローラは ReplicaSet リソースで設定した数を Kubernetes 内で 常に維持するよう、ポッドを作成、あるいは実行中のポッドの削除といった動作をします。これらの動作は Services、[Deployments]http://kubernetes.io/docs/user-guide/deployments/() 、Daemon Sets でも同様な挙動であり、 Kubernetes におけるコントローラとリソースの多くの基本となるものです。

例1a：１つのポッドが動作中で、ユーザは希望のポッド数を３に設定

例1b：数秒後、Kubernetes 内のコントローラは、ユーザが要求した数と一致するようポッドを作成

Operator は Kubernetes のリソースとコントローラの概念を基盤として、その上に知識や設定を積み上げます。そのため、 Operator は一般的なアプリケーション・タスクを実行できるようになります。たとえば、etcd クラスタを手動でスケール（拡大）しようとする場合、利用者は数ステップを踏みます。具体的には、新しい etcd メンバ用の DNS 名を作成し、新しい etcd インスタンスを起動します。それから、etcd 管理ツール（ etcdctl member add ）を使い、既存のクラスタに新しいメンバを追加するのを伝えます。この手順ではなく、etcd Operator があれば、利用者は etcd クラスタのサイズのフィールドを１から単に増やすだけで済むのです。

例2：ユーザの kubectl をトリガにバックアップ

複雑な管理タスクの例としては、Operator でアプリケーションを安全な状態のまま更新や、離れた場所にあるストレージに設定ファイルのバックアップ、ネイティブな Kubernetes API を通したサービス・ディスカバリ、アプリケーションの TLS 認証設定やサービスディスカバリなどに利用できるでしょう。

Operator はどのように作成するのか？

Operator は性質上、アプリケーションごとに固有のものです。アプリケーション運用領域に関するすべての知識を、適切なリソース設定と制御のループにエンコード（変換）するのは大変です。ここでは Operator で構築するにあたり、私たちが発見した一般的なパターンを紹介します。これがあらゆるアプリケーションで重要となるものと考えています。

  1. Operator のインストールには、１つだけデプロイします。たとえば kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml を実行するのみであり、他にインストール作業はありません。

  2. Operator は Kubernetes に新しいサードパーティ・タイプを追加するでしょう。利用者はこのタイプを使い、新しいアプリケーションを作成するでしょう。

  3. 度重なるテストやコードに対する深い理解をする時に、 Operator は Kubernetes 内部のサービスやレプリカ・セットといったプリミティブのように扱います。

  4. Operator はユーザが作成したリソースの後方互換性と古いバージョンを理解します。

  5. Operator が停止または削除されても、Operator はアプリケーション・インスタンスが影響なく実行し続けられるよう設計しています。

  6. Operator は希望のバージョンを宣言し、希望のバージョンを元にしたアプリケーション更新のオーケストレートを提供するでしょう。ソフトウェアの更新を行っても、操作時のバグやセキュリティの問題を引き起こさないため、Operator を使えば確実に処理する手助けとなるでしょう。

  7. Operator は「Chaos Monkey」テスト・スイートによる試験を実施されることで、Pod や設定やネットワークに関する潜在的な障害をシミュレートするでしょう。

Operator の今後

CoreOS が提供する etcd Operator と Prometheus Operator は、今日時点での高性能な Kubernetes プラットフォームの例です。昨年より、私たちは幅広い Kubernetes コミュニティと行動を共にしています。焦点を当てているのは 、Kubernetes の安定・安全・簡単な管理・簡単なインストールです。

これでようやく Kubernetes の基本を構築できました。次に注力するのは、この上にシステムを構築することです。具体的には、新しい能力を Kubernetes に拡張するためのソフトウェアです。私たちが思い描く未来とは、利用者が自身の Kubernetes クラスタ上に Postgres Operator 、Cassandra Operator 、Redis Operator をインストールし、今日のステートレスなウェブ・アプリケーションを簡単にデプロイするかのように、これらプログラムのインスタンスをスケーラブルに操作できるようにすることです。

より詳しく学ぶには、GitHub リポジトリに飛び込むか、私たちのコミュニティ・チャンネルでの議論、あるいは、11 月 8 日に開催の KuberCon の CoreOS チームの登壇にお越しください。私のキーノートは 11 月 8 日(火) の太平洋標準時午後 5:25 です。そこで Operator とその他の Kubernetes トピックを話します。

FAQ

Q: StatefulSets （以前は PetSets ）との違いは？

A: StatefulSets は Kubernetes 用アプリケーションをサポートするよう設計されています。アプリケーションはクラスタ上で IP やストレージのような「ステートフルなリソース」を必要とします。よりステートフルなデプロイ・モデルを必要とするアプリケーションは、障害・バックアップ・再設定のためのアラートや処理のための運用自動化（Operator automation）が必要です。そのため、これらデプロイ特性を必要とするアプリケーションの運用担当者は、Replica Setsや Deployments を活用する代わりに、StatefulSets を使えます。

Q: Puppet や Chef のような設定管理との違いは？

A: コンテナと Kubernetes では、運用担当者が実現できるのに大きな違いがあります。２つの技術は新しいソフトウェアのデプロイ、分散環境における設定の調整、複数のホスト上のシステム状態を一貫性に保つ確認と、Kubernetes API の利用を簡単にします。運用担当者は、アプリケーション利用者が使いやすくなるよう、これらプリミティブを一つにつなぎ合わせます。つまり、これは設定ではありません。今現在のアプリケーションすべての状態を示すのです。

Q: Helem との違いは？

A: Helem は複数の Kubernetes リソースを１つのパッケージにまとめるツールです。概念は複数のアプリケーションを一緒にまとめるものです。Operator はアプリケーション管理で補助的に使えるでしょう。たとえば、traefik はロードバランサであり、etcd をバックエンド・データベースとして使います。皆さんは Helm Chart で treafik のデプロイと etcd クラスタ・インスタンスを一緒にデプロイできます。そして etcd クラスタは etcd Operator を使ってデプロイや管理することもできます。

Q: Kubernetes にとっては何が新しいのですか？ どのような意味があるのですか？

A: etcd や Prometheus や今後出てくる複雑なアプリケーションを簡単にデプロイしたい新しいユーザ以外は、これまでと殆ど変わらないでしょう。Kubernetes 上で実行するための推奨手法は、まだ minikube であり、kubectl run なのです。Prometheus Operator を使って監視するアプリケーションのデプロイには kuberctl run を使うでしょう。

Q: etcd Operator と Prometheus Operator のコードは今日から使えますか？

A: はい！ GitHub の https://github.com/coreos/etcd-operator と https://github.com/coreos/prometheus-operator をご覧ください。

Q: 他の Operator を予定していますか？

A: はい、近いうちに。また、コミュニティを通して新しい Operator が作られるのを歓迎します。皆さんの Operator で何か出来るようになれば、ご連絡ください。

Q: Operator はクラスタを安全にするために役立ちますか？

A: いいえ。ソフトウェアの更新は、一般的に操作時のミスやセキュリティ問題があり、Operator ができるのは利用者に対し、より確実に更新処理を行うことです。

Q: Operator はディザスタ・リカバリに使えますか？

A: Operator が簡単にするのは、アプリケーション状態の定期的なバックアップと、バックアップから以前の状態を戻すことです。私たちが目指す機能としては、ユーザが Operator さえ使えば、バックアップから新しいインスタンスのデプロイを簡単に行えるようにすることです。

原文