Tectonic は Kubernetes の構築・管理基盤であるー概要の章ー

本投稿は、 さくらインターネットアドベントカレンダー2017 の、５日目の投稿です。都合により一日遅れましたが、今回は Tectonic（テクトニック）についてご紹介します。なお、前日４日目の投稿は blp1526 さんによる「さくらのクラウドのサーバの tig ライクな TUI ツール 」です。６日目の投稿は、hitsumabushiさんによる「 さくらのクラウドでN百台を管理するためにterraformとansibleを使っている話 」です。

はじめに

Tectonic は Kubernetes だけでなく、クラスタを管理するときに役立つ様々な機能をサポートしているツールです。本投稿では Kubernetes の是非を論ずるのではなく、眼前の Kubernetes クラスタを管理する必要が出る場合、どのような選択肢が生まれ得るのかという実地検証の報告が主体です。あくまでも、一利用者の視点で情報を共有いたします。

もともとの投稿では「さくらのクラウド」上で Tectonic が動きますよ！という手順のご紹介を考えていました。結論から申しあげると、PoC（技術検証）レベルにおいては、さくらのクラウド上でもベアメタル・セットアップの手順で動いています（ただし、サポート対象外の模様）。

しかしながら、単にセットアップ手順をご紹介するよりも、Tectonic とは何かあらためて共有させて頂いた上で、後日のエントリにて改めてTectonic環境構築のために必要な Matchbox、Terraform、Ignition の解説、そして、評価環境構築のための手順を皆さまに公開することを予定しています。

また、本エントリは、 先日の発表 の補足の意味も兼ねています。

そもそも Tectonic とは？

Tectonic ( https://coreos.com/tectonic ) は、Container Linux などでお馴染み CoreOS 社が提供しているエンタープライズ対応の Kubernetes です。さらに、実運用で必要な Prometheus の監視設定や、Grafana ダッシュボードの監視設定なども自動的に行えます。どちらかというと Tectonic は Kubernetes のラッパー（wrapper）であり、Kubernetes だけでは足りないエンタープライズ向け機能を、広く知られているオープンソースを使いながら、導入を促している点です。

Tectonic はサイトの記述によりますと「CoreOS の自動化技術を用い、プライベートやパブリック・クラウド間での可搬性（ポータビリティ）を保てるようにしたツール」とあります。サポート対象のプラットフォームは、AWS、Azure のようなクラウド・プロバイダだけではなく、ベアメタル・マシンも含まれています。そして、単に Kubernetes を動かすだけでなく、Tectonicを通して etcd クラスタの管理や、ノード障害時に向けた HA 的な機能も備えられています（ただし、現時点では Tectonic の Provisioner ホスト＝Matchbox 設置サーバの冗長化はサポートされていませんが、将来的には計画されています）。

つまり、プラットフォームがどこであろうとも Kubernetes が動作する環境を構築し、その上でコンテナ対応（クラウド・ネイティブ）アプリケーションを実行できるようにします。提供されている機能は、以下の通りです。

しかし、これだけでは Tectonic の機能が分かりづらいので、全貌を図に整理しました。

上図にあるように、物理またはクラウド上のサーバで Kubernetes クラスタを構築します。また、CoreOS 社のプロダクトではありますが、主要なコードやモジュール（Matchbox, Ignition 等）は GitHub 上で公開されており、必要があれば CoreOS 社の商用サポートも受けられます。

ノード管理の諸問題を解決してくれる

Tectonic のアーキテクチャは Rancher をはじめとして、既存のアプローチと一見すると似ているかもしれません。どちらも物理または仮想サーバ上でクラスタのをノード管理し、その上でコンテナを関する、あるいは、 Kubernetes クラスタの管理を GUI を通して行えるようにしています。

しかし方向性は明確に異なります（優劣ではありません）。

Tectonic は、あくまでも Kubernetes クラスタの大規模な自動運用であったり、セキュリティや監査など、大規模組織で求められる機能をまとめています。方向性としては、オープンソースで提供されている Kubernetes と、Kubernetes の運用・管理ツールとして広く知られている Prometheus および Grafana を始めから「何もせずに」使えるようにします。つまり、Kubernetes クラスタを運用するベストプラクティスが詰まっているのが Tectonic とも言えるでしょう。

一方、Rancher は何か動かしたいアプリケーションがあり、環境構築や管理に手間をかけなくない場合。あるいは、素早くサービス提供を進めたくて結果的にコンテナを効率的に使っていきたい場合に、手軽に Kubernetes クラスタを導入・管理・運用できる機能や、商用サポートを提供するものです。

おそらく、入口としての導入がしやすいのは Rancher に軍配が上がるでしょう。一方で、数百台規模以上のノードを効率的に管理する場合は、Tectonic のほうが必要な機能群が備わっているようにも見えます。また、Tectonic は既存のツールの組み合わせでもありますので、要素要素で Kubernetes ないし CNCF 関連エコシステムのツールやプロダクトとも連携しやすいとも言えるでしょう。

Tectonic は、ノード管理の煩雑さをなくしてくれる

実運用を考慮すると、どのようなツールであれ、クラスタを構成するノード（としてのサーバやインスタンス）の管理は頭の悩ましい問題です。たとえば、初期の環境構築であったり、ノード側の OS のセキュリティ対策です。

Tectonic はこの問題を解決するため、Matchbox というプロビジョニング用のサーバ機能と Terraform を連携し、自動的に CoreOS Container Linux のインストールと Kubernetes の自動プロビジョニングを行う仕組みを提供しています。

通常であれば、ノードごとに OS をゼロから構築し、 Kubernetes 用の環境をセットアップし、クラスタのワーカーとしての登録など諸作業が必要です。Tectonic であれば、必要なのは Terraform 用の変数設定ファイルに MAC アドレスの情報を記入し、terraform plan, apply を実行し、電源を入れるだけ。

概要の章まとめ

次回は、Tectonic を構成する要素のなかで、ノードのプロビジョニング（自動環境構築）に欠かせない Matchbox、Ignition、Terraform それぞれの役割詳細をお伝えします。

【参考訳】Terraform 導入の推奨手順（Recommended Practices）

Terraform Recommended Practices 推奨手順

「Terraformって何がいいんですか？」と訊かれる度に答えていた内容が、とても良い感じにまとまっていましたので、ここで紹介します。2017年11月28日現在の Terraform Recommended Practices の参考訳です。

自動化や運用に興味がある方にとって参考となるのは、HashiCorp の Terraform に興味が無くても、成熟度に応じた自動化の段階分けと、各々の段階からどのように発展すべきかという手順です。手動→半自動→インフラのコード化（Infrastructure as Code）への進歩と、最終的には協調的インフラのコード化（Collaborative Infrastructure as Code）を目指して、バージョン管理や構成管理ツールと連携するにはどうしたらよいのか。あるいは、そこに Terraform や Terraform Enterprise がどのように関わっているのか、自分のインフラを見直すための切っ掛けになると思います。

なお Infrastructure as Code は、日本語で一般的に「コードとしてのインフラ」や「インフラのコード化」という表現が用いられています。英語の訳としては前者が相応しそうですが、技術的な意味合いから当翻訳では後者を採用しています。これは、「Collaborative Infrastructure as Code」という見慣れない言葉を「協調的インフラのコード化」と訳すにあたり、整合性を維持するためでした（コードとしての協調的なインフラ、だと語呂がよくない感じがしたためです）。

（ここから訳）

本ガイドが想定しているのは、Terraform の利用を小数の個人から、組織全体への拡大を目指しているエンタープライズ・ユーザです。

はじめに

HashiCorp が専門としているのは、 IT 組織がクラウド技術を採用するための支援です。基礎となっているのは、私たちのこれまでの取り組みです。私たちはプロビジョニング（訳者注；システム基盤となる計算資源やネットワークの自動構築や自動設定）に対するベストな手法が collaborative Infrastructure as code （協調的インフラのコード化） であると確信しています。そのためには Terraform をワークフローの中心として使い、皆さんの組織における異なるチーム、役割、アプリケーション、開発層における境界を Terraform Enterprise を使い管理します。

協調的インフラのコード化は多くの他の IT ベスト・プラクティス（バージョン管理の利用や、手動での更新防止など）に基づいています。そして、皆さんが私たちの推奨するワークフローを完全に導入するためには、その前にこれら基礎の導入が必要です。最先端のプロビジョニング・プラクティスを達成するとは、いくつかの明確な段階を進んでいく旅なのです。

本ガイドで説明するのは、私たちの推奨する Terraform 手順（プラクティス）と、どのようにそれらを導入するかです。ステップはツールを使い始める所から始まります。これは、手順での作業に依存している場合、特に注意を払うべき基礎についても扱います。

• Part 1 : 推奨ワークフロー概要 は、Terraform Enterprise による協調的インフラのコード化・ワークフローの全体的な概要です。どのようにインフラを準備・管理し、私たちが情報をやりとりするかを扱います。

• Part 2 : 現在のプロビジョニング手順を評価 は、皆さんのインフラをプロビジョニングする現状の手順、これを評価する手助けとなる一連の質問です。私たちはオペレーションの成熟に応じて４つの段階を定義しました。これは皆さんが正しい方向に進むのと、手順採用に必要となる基礎を理解するのに役立ちます。

• Part 3 : プロビジョニング手順を発展するために は、４つの成熟度の段階を通し、プロビジョニング手順をどのように発展させるかを導きます。多くの組織において、既にこのプロセスの半分まで到達しているでしょう。パート２で学んだことを使い、この旅がどこに向かうかを決めます。

このパートは４つのページに分かれています。

• Part 3.1 : 手動から半自動に移行するには
• Part 3.2 : 半自動からインフラのコード化（Infrastructure as Code）に移行するには
• Part 3.3 : インフラのコード化から協調的インフラのコード化に移行するには
• Part 3.4 : 協調的インフラのコード化の高度な改善

Part 1 : 推奨ワークフロー概要

Terraform の目的とは、あらゆるインフラに１つのワークフローで自動構築（プロビジョニング）することです。このセクションでは、大きな組織を縦断して Terraform を扱うために、推奨する手順を紹介します。これが「collaborative infrastructure as code」（協調的インフラのコード化）と呼ぶ手順群です。

プロビジョニングの根本的な変化

プロビジョニング手順の改善を試みますと、誰もが２つの主な課題に直面します。それは、技術的な複雑さと、組織上の複雑さです。

　1. 技術的な複雑さ（Technical complexity） … 新しいリソースをプロビジョニングするには、インフラ事業者（プロバイダ）ごとに異なるインターフェースを使うため、日々のオペレーションにおいて、インターフェース間の差異に対する追加コストを負担させられます。扱うインフラ事業者が増え、多くの共同作業者が増えるほど、これらのコスト負担が増します。

Terraform が対処するのは、プロビジョニングにおけるワークロードから、この複雑さの分離です。リソース間の関連性を、インフラをコード化した設定ファイル群に定義します。そして、これらを１つの中心となるエンジンが読み込みます。それから、各インフラ事業者上のリソースを作成、変更、削除するために、多くの プロバイダ・プラグイン を利用できます。これらプラグインは IaaS （例：AWS、GCP、Microsoft Azure、OpenStack）や SaaS （例：Heroku）サービス群にアクセスできます。

つまり、Terraform が用いるのはリソース・レベルの抽象化ではなく、ワークフロー・レベルの抽象化モデルです。これにより、１つのワークフローでインフラを管理する手法を提供します。ここでは各事業者間で等価交換できないリソースを、一般的な概念として扱うのではなく、事業者ごとに固有のものとして扱います。

　2. 組織上の複雑さ（Organizational complexity） … インフラが拡大するにつれ、インフラを維持するためには多くのチームが必要となります。効率的な共同作業（コラボレーション）のために重要なのは、各チームを横断するインフラ所有権の権限委譲と、作業単位で並列に競合することなく権限を持たせることです。大規模アプリケーションでコンポーネントの権限委譲するのと同様の手法で、インフラの権限を委譲するのに Terraform と Terraform Enterprise が役立ちます。

大規模アプリケーションで権限を委譲するには、集団を徐々に小さく分割し、個々のチームが所有するマイクロサービスのコンポーネントに集約します。各マイクロサービスは API を提供します。そして、API に変更がない限り、お互いが機能的に依存しているのにかかわらず、マイクロサービス・チームは並列に変更を加えられるのです。

この手法と同様に、インフラのコードを、小さな Terraform 設定ファイルに分割可能です。設定は、チームごとに所有できる範囲を制限できます。これらの独立した設定ファイル群は output 変数 を使って情報を出力します。また、 remote state ステータス で、他のワークスペースにある出力データにアクセス可能です。これは、まるでマイクロサービスが API を経由して通信・接続しているように、 Terraform ワークスペースは remote state を通して接続できます。

Terraform の設定を緩やかに連携しますと、チームごとに開発とメンテナンスを委譲できるようになります。この効率性を達成するためには、コードとしてアクセス制限をする必要があります。バージョン管理システムには、誰がコードをコミットできるか制限できます。しかし、 Terraform は実際のインフラを扱うため、更に誰がコードを実行できるか制限する必要があります。

これこそが、Terraform Enterprise (TFE) が組織におけるプロビジョニングの複雑さを解決する手法です。つまり、Terraform の実行環境を集約することで、組織におけるアクセス制御を、全てのワークスペースを横断できるようサポート・実施します。並列な開発を可能にするためには、これがインフラ所有権を委譲する手助けとなります。

登場人物（ペルソナ）、責任、望ましいユーザ経験

スケールするインフラを管理する、４つの主な登場人物がいます。それぞれの役割で、異なる責任と課題があり、異なるツールと権限を Terraform Enterprise がサポートします。

セントラル IT（Central IT）

（訳者注；セントラル IT とは、大規模組織における情報技術を担うという意味の、専門用語。集約された情報システム部門に相当）

チームが責任を持つのは、共通のインフラ手順の定義、チームを横断するポリシーの執行、共有サービスの維持です。

セントラル IT の利用者は１つのダッシュボードを通して、全てのインフラの状態と整合性を閲覧できます。そのため、間違った設定や誤動作があれば、直ちに修正可能です。Terraform Enterprise は Terraform 実行時のデータと密に統合しています。また、Terraform Enterprise はワークスペース（workspace）における Terraform 概念と実行を包括するように設計しています。これにより、一般的なセントラル IT システムよりも、より統合されたワークフロー経験をもたらします。

組織アーキテクト（Organization Architect）

このチームが定義するのは、事業単位内部のチームが、グローバルなインフラをどのように分割・権限委譲するかです。また、このチームはワークスペース間の連携もできるようにするため、それぞれのワークスペースが公開すべき API の定義や、組織間にわたる変数やポリシーを策定します。

組織アーキテクトが欲しいのは、１つのダッシュボードを通して、全てのワークスペースの状態を表示し、ワークスペース間の連携状態をグラフ化することです。

ワークスペースの所有者（Workspace Owner）

複数の環境を横断する Terraform 設定ファイルを作成する所有者が、それぞれのワークスペースごとにいます。所有者が責任を持つのは各ワークスペースの正常性と、開発・UAT（ユーザ受け入れテスト）・ステージング・プロダクションというライフサイクル全体を通した管理です。所有者とは、各領域のプロダクションにおける変更を承認する主担当者です。

ワークスペース所有者が欲しいのは：

• １つのダッシュボードでコード化したインフラの全てのワークスペース状態を表示
• 環境間に影響がある変更を、効率的に伝えるための手法
• Terraform の設定ファイルで、環境間を横断して使う変数の設定用インターフェース

ワークスペース・コントリビュータ（Workspace Contributor）

ワークスペースにおけるコード化したインフラの設定ファイルを更新するには、コントリビュータが変更を実施します。通常、コントリビュータはプロダクションにおける変更を承認しません。しかし、開発・UAT・ステージングにおいては承認します。

ワークスペース・コントリビュータが欲しいのは、ワークスペース間の変更を実施して伝えるための、シンプルなワークフローです。ワークフロー・コントリビュータが編集できるのは、ワークスペースで共有する変数と、個人用に使う変数です。

大抵のワークスペース・コントリビュータは、Terraform の操作モデルとコマンドライン・インターフェースに慣れています。そのため、Terraform Enterprise のウェブ・インターフェースも迅速に採用できます。

推奨する Terraform ワークスペース構造

ワークスペースについて

Terraform Enterprise（以下 TFE ）を組織で使う主な単位（ユニット）がワークスペース（workspace）です。ワークスペースとは、 Terraform が処理を実行するために必要な全ての集まりです。これは、実行する度に操作を追跡可能とするため、設定ファイルの変数と状態データ（state data）のために必要となるものです。また、Terraform 設定ファイル（通常はバージョン管理システムのリポジトリを使用）と変数も含みます。

Terraform オープンソース版では、ローカルのディスク上にある個々の状態ファイルがワークスペースに相当します。TFE は共有リソースの一貫性を保ちます。そのため、共有リソースに対するアクセス制御や、実行状態の監視などが可能になります。

環境ごと Terraform 設定ファイルごとに１つのワークスペース

ワークスペースは TFE で権限委譲を管理する主要なツールです。つまり、ワークスペースの構造は、皆さんの組織における権限構造と一致すべきでしょう。ベストな取り組みは、インフラ・コンポーネントの環境ごとに、１つのワークフローを使うことです。言い換えますと、 Terraform 設定ファイル数 × 環境の数 ＝ ワークスペース数です。

これこそが環境を参照する他のツールとの明確な違いです。プロダクションやステージング環境の構築にあたり、全ての環境を１つの Terraform ワークスペースで管理すべきではありません。そうではなく、ワークスペースを小さくすることにより、権限委譲を簡単にします。また、環境が全く同じだとしても、全ての状況で同じ設定ファイルを使い回せません。例えば、ユーザ受け入れテストであれば、インフラに対する自社のセキュリティ基準をユーザには強制できないはずです。

ワークスペース名は、コンポーネントと環境の両方です。例えば、内部の請求アプリとネットワーク・インフラを関するための Terraform 設定ファイルがあるとしたら、ワークスペースの名前は以下のようになります。

• billing-app-dev
• billing-app-stage
• billing-app-prod
• networking-dev
• networking-stage
• networking-prod

ワークスペースの権限委譲

各ワークスペースは１つのインフラ・コンポーネントごとに１つの環境を持つため、ワークスペースごとにアクセス制御をし、コンポーネントの所有者への権限委譲と、環境を横断するコード統制を伝えられます。例えば、

• 開発やステージングにおいて、Terraform の実行と変数の編集により、チームがコンポーネントを管理し始めるのを支援します。
• コンポーネントの所有者又はシニア・コントリビュータは、プロダクションで Terraform を実行した後、他のコントリビュータの作業をレビュー可能になります。
• セントラル IT と組織アーキテクトは、全てのワークスペースの権限を管理可能となり、作業ごとに何か必要なのかを確実にします。
• コンポーネントに対する役割を持たないチームは、ワークスペースにアクセスできません。

TFE を効率的に使うには、ワークスペースと権限の分割を、皆さんの組織における権限分割と確実に一致する必要があります。もしもワークスペースの効率的な分割が難しければ、インフラのある領域がベールに包まれ、責任範囲が混乱し、不明瞭になってしまうでしょう。もしもそうであれば、コード化と所有権の境界を改善するために、糸をほぐす機会となるでしょう。

関連するワークスペース間で変更の周知 (Coming Soon)

今後のバージョンでは、TFE はワークスペースをまたがる周知用パイプラインを作成できます。

これまで説明してきたように、各ワークスペースは個々の環境ごとに Terraform 設定ファイルが与えられています。現時点では、コードの周知は手動で行う必要があります。進んだ環境にコードを切り替えるためには、以前の環境におけるコード実行に成功している必要があります。

いずれ、周知関連の設定もできるようになります。バージョン管理システムで直接コードを確認するのではなく、コードを受け入れるだけで、前の環境から新しい環境に切り替えられます。これにより、進んだ環境は正しいコードのみというのを保証します。

変数とポリシーの管理

Terraform Enterprise は変数を設定する複数の場所があり、階層的に相互に上書きできます。全ての階層レベルにおいて、 TFE は Vault に安全に変数を格納します。

Organization

あらゆるワークスペースで、組織レベルに応じたデフォルト変数を使えます。例えば組織においては、全てのリソースが使えるデフォルトの請求タグを指定できるでしょう。

これは階層の最も低いレベルです。続くレベルは上書き可能です。

Workspace

ワークスペースごとの変数です。大部分の変数はワークスペース・レベルに保管されます。これは、AMI ID やマシンのカウント、SSL 証明書等の保管に最も適している場所です。

User

個々のユーザに割り当てる変数です。全てのワークスペースで使うことができ、ワークスペース変数を上書きします。例えば、各ユーザに関連付けられた ARN に使えます。

次へ

これで Terraform Enterprise ワークフローの概要に詳しくなりましたので、皆さんの組織におけるプロビジョニング手順に進むときです。Part2 に続きます。

Part2 : 現在のプロビジョニング手順を評価

Terraform Enterprise は複数ある IT 手順の基礎に依存しています。Terraform Enterprise で協調的インフラのコード化を実装する前に、どの手順を既に使っているか、あるいは実装に何が必要かを理解する必要があります。

以下の本セクションはクイズやインビュー形式です。これまで見てきたように、組織で共通する成熟度に応じて、答えぶは複数の選択肢があります。メモ帳を手にして読み進めましょう。また、組織で自動化とコラボレーションを改善するために疑問があれば、あらゆることをメモしましょう。

このクイズには合格や不合格の基準点はありません。しかし最も重要なのは、皆さんの組織の答えを知ることです。どの IT 手順について最も注意を払うべきかが分かれば、現在の状態から推奨する手順に一直線で進むため、セクション 3 が役立つでしょう。

運用習熟における４つのレベル

運用の習熟度においてレベルが異なるため、それぞれの質問には複数の答えがあります。４つのレベルは以下の通りです。

1. 手動（Manual）
   • インフラを UI 又は CLI でプロビジョニング
   • 設定変更の履歴を追えず、可視化もない
   • 制限や名前付けに対する適切な標準がない
2. 半自動（Semi-automated）
   • インフラを UI/CLI 、インフラのコード化、スクリプト、構成管理ツールの組み合わせでプロビジョニング
   • 監査性（traceability）は制限があり、組織ごとに異なった記録手法を用いる
   • 組織ごとに記録手法が異なるため、ロールバックは大変
3. インフラのコード化（Infrastructure as code）
   • Terraform OSS（オープンソース版）を使ってインフラをプロビジョニング
   • プロビジョニングとデプロイ手続きが自動化されている
   • インフラの設定は一貫性があり、必要である詳細な全てがドキュメント化されている（システム管理者の頭の中でサイロ化されていない）
   • ソースファイルはバージョン管理され、編集履歴がきろくされている。また、必要があれば古いバージョンにロールバックする。
   • Terraform コードのいくつかはモジュールに分割され、組織内における共通的な設計パターンの一貫性を促す
4. 協調的インフラのコード化（Collaborative Infrastructure as code）
   • 組織内のユーザはお互いが競合せず、かつ、アクセス権限を明確に理解しながら、Terraform を使って安全にインフラをプロビジョニングできる
   • 組織内の上級ユーザは、インフラのテンプレートを標準化できる。また初心者は、組織におけるインフラのベストプラクティスに従いながら、これを利用できる
   • プロダクション環境のワークスペースを守るために、コミッターと承認者に対するワークスペース単位のアクセス制限が役立つ
   • 機能グループは直接 Terraform のコードを書けないが、Terraform Enterprise のユーザインターフェースを通してインフラ状態の可視化と変更を行える

このセクションを最後まで読めば、皆さんの運用習熟度がどの段階にあるか、明確に理解できるでしょう。セクション３では現在の段階から次に進むための推奨する手順を紹介します。

それぞれの質問に対する回答は、皆さんの組織におけるインフラのプロビジョニング、ワークフローの変更、運用モデル、セキュリティモデルの理解に役立ちます。

現在の手順を理解したら、Terraform Enterprise を実装するために、どの段階に進めば良いか認識できるでしょう。

現在の設定とプロビジョニング手順について

皆さんの組織では、インフラの設定とプロビジョニング手順を現在どのように行っていますか。自動化と一貫性のある手順こそが、インフラをより理解しやすく、信頼性があり、トラブルシューティングに費やす時間を減らすために役立ちます。

設定とプロビジョニングがどのレベルか評価するには、以下の質問が役立ちます。

Q1. 現在どのようにしてインフラを管理していますか？

1. UI 又は CLI を通します。一度限りの作業に対しては、最も簡単な手法に思えるでしょう。しかし、繰り返し行う作業はエンジニアの時間を大きく消費します。また、変更の追跡や管理は困難です。

2. コマンドライン・スクリプトの再利用を通してか、あるいは UI とインフラのコード化の組み合わせです。単なるその場限りの管理や繰り返し作業に比べ、より速く信頼できる手法です。しかし、一貫性とバージョン管理が欠如しているため、時間の経過とともに管理が困難になります。

3. インフラのコード化ツール（Terraform、CloudFormation）を通して行います。インフラのコード化により、インフラはスケーラブルで（訳者注；拡大・縮小を柔軟に行える）、再利用性があり、バージョン管理されます。各オペレータの生産性を著しく向上します。また、適切に使えば、環境を横断した一貫性を保てるようになります。

4. 汎用的な自動化フレームワーク（例：Jenkins + スクリプト / Jenkins + Terraform）を通して行います。これはツールを使いながらも管理ワークフローを集約するため、プロビジョニング・タスクを個々に作る必要はありません。

Q2. サービス・プロバイダのアカウントを、どのように管理しますか？

1. １つのアカウントを使う、平らな体制です。全てのインフラを同じアカウントでプロビジョニングします。

2. 複数のアカウントを使う、平らな体制です。インフラのプロビジョニングには、アカウント環境ごとに異なるインフラ・プロバイダを使います。

3. ツリー階層です。請求アカウント、監査、セキュリティ、ログ記録アカウント、プロジェクト／環境の用途ごとに、インフラのアカウントを使い分けています。

Q3. 異なる環境のインフラを、どのように管理しますか？

1. 手動です。全てが手動であり、設定管理は行われていません。

2. サイロ化しています。アプリケーション・チームごとに、独自の手法でインフラを管理します。あるチームは手動で、あるチームはインフラのコード化やカスタム・スクリプトを用います。

3. 環境ごとに異なるコードに基づく、インフラのコード化です。インフラをコード化する設定ファイルは、異なるコードを元にしています。そのため、環境内に変更が加えられたとしても周知できず、ある環境の設定は他の環境から追跡できません。

4. １つのコードに基づき、環境ごとで違う変数を扱うインフラのコード化です。環境に依存しない全てのリソースを、同じコードでプロビジョニングします。また、変更の周知を確実に行うため、何をデプロイするのか予測可能となる手法です。

Q4. インフラの設定とコードを、どのようにしてチームで協力して共有しますか？

1. 全くありません。インフラのコード化を行っていません。

2. ローカルです。インフラの設定はローカルに保存し、メールやドキュメントやスプレッドシートを通して共有します。

3. チケット管理システムです。変更リクエストや問題/インシデント・チケットによる日々のエントリを通して共有します。

4. バージョン管理はありませんが、集約しています。コードを共有ファイルシステムに保管し、セキュリティ・グループで安全を保ちます。変更はバージョン管理されません。ロールバックを行える可能性があるのは、バックアップ又はスナップショットによる修復のみです。

5. 設定ファイルの保管と共同作業をバージョン管理システム上（VCS）（Git リポジトリ、等）で行います。インフラ設定に関するチームの共同作業は VCS ワークフローを通して行います。また、これによりプロダクションに投入する前に、インフラの変更をレビュー可能にします。これが最も成熟した手法です。そのため、記録を保持しながら、異なる部署・異なるチームにおける可視化をもたらします。

Q5. インフラのコード化にあたり、再利用可能なモジュールを書いていますか？

1. 全てが手動です。現時点ではインフラのコード化をしていません。

2. モジュール化していません。インフラのコード化は行っていますが、設定ファイルの利用は一度限りがほとんどです。ユーザは通常コードの共有・再利用を行いません。

3. チームはモジュールを内部で使いますが、他のチーム間では共有しません。

4. モジュールを組織全体にわたって共有します。ソフトウェアのライブラリを共有するように、インフラの共通パターンをモジュールにするため、更新は１度だけで済み、それが組織全体の利益となります。

変更管理ワークフローについて

プロダクトやシステムにおいて、変更の調整や承認にあたり、変更管理（change control）は適切な工程です。変更管理工程のゴールに含むのは：

• サービス途絶を最小化
• ロールバックを減らす
• 変更に関するコスト全体を削減
• 不必要な変更を防ぐ
• ユーザによる変更を、他のユーザに対して影響を与えることなく実施

変更管理ワークフローの習熟度を評価するために、以降の質問が役立ちます。

Q6. インフラに対する変更に対して、どのようにアクセス制御を管理していますか？

1. アクセスに対する制限がされていないか、監査されていません。プラットフォーム・チームの誰もが柔軟に、全てのインフラを作成、変更、削除します。これにより、再利用できず管理が大変な、複雑なシステムになります。

2. アクセスに対する制限はありますが、監査はします。これにより、何か事故がおきた後の追跡を容易にします。しかし、インフラの安定性を積極的に守ることはできません。

3. サービス・プロバイダのアカウント・レベルに基づきアクセス制限を実施します。各チームのメンバが持つ管理権限は、環境ごとに責任範囲が異なるアカウントに基づいています。

4. ユーザの役割（ロール）に基づきアクセス制限を実施します。全てのアクセスは、インフラのプロバイダ・レベルでユーザの枠割りに基づき制限されます。

Q7. 既存のインフラを変更するのに、どのような手順で行いますか？

1. リモートマシンにログインし、手動で変更します。繰り返しの手動タスクは非効率であり、人的ミスを引き起こしがちです。

2. ランタイム構成管理（Puppet、Chef、等）です。構成管理ツールは、信頼できて監査できるコードに基づき、素早く自動的に変更を行います。しかしながら、作成する成果物は毎回同じではありません。特定の設定ファイルのバージョンを使ったとしても、必ずしも 100% の再現性はありません。また、信頼してロールバックできるのは一部のみです。

3. （イメージ、コンテナの）イミュータブル・インフラストラクチャ（Immutable Infrastructure＝訳者注；固定されて変わらないインフラの意味、不変のインフラ）です。固定されたコンポーネントでデプロイされたものは、（個々に置き換えるのと比較して）全てを置き換え可能です。もしも一時的なレイヤ（ephemeral layers）と状態を格納するレイヤ（state-storing layers）間にある明確な境界を管理するのであれば、イミュータブル・インフラストラクチャこそがテスト、検証、ロールバックに最も簡単です。

Q8. アプリケーションをどのようにデプロイしますか？

1. 手動（SSH、WinRM、rsync、robocopy、等）です。繰り返しの手動タスクは非効率であり、人的ミスを引き起こしがちです。

2. スクリプト（Fabric、Capistrano、カスタム・スクリプト、等）です。

3. 構成管理ツール（Chef、Puppet、Ansible、Salt、等）です。あるいは、ユーザデータ・スクリプトを経由して CloudFormation テンプレートや Terraform 設定ファイルに渡します。

4. スケジューラ（Kubernetes、Nomad、Mesos、Swarm、ECS、等）です。

現在のセキュリティ・モデル

Q9. インフラサービス・プロバイダの認証情報（credential）をどのように管理しますか？

1. ソースコードに決め打ちします。極めて安全ではありません。

2. インフラ・プロバイダのロール（AWS では EC2 インスタンス role のように）を用います。サービス・プロバイダはマシンを識別できますので、実際の認証情報のコピーを使うことなく、API リクエストを用いてマシンに対する権限を付与できます。

3. シークレット（訳者注；SSH鍵やパスワードのような、機密性の高い情報のこと）管理ソリューション（例：Vault、Keywhis、PAR）を用います。私たちはこの手法を推奨します。

4. 有効期間の短いトークンを使います。これは最も安全な手法の１つです。一時的な認証情報を用いるため、迅速な無効化ができます。そして、攻撃を非常に困難にします。しかしながら、シークレット管理ソリューションを使うよりも、より複雑になりがちです。

Q10. インフラ・プロバイダで、ユーザとオブジェクト保管をどのように管理しますか？（ログイン、アクセスやロールの制限、等）

1. 共通の admin や スーパーユーザ アカウントをエンジニアで共有します。インフラ・プロバイダ・アカウントの抜け道となる可能性が増します。

2. 個々のユーザ・アカウントです。これにより、認証情報の喪失を引き起こしても、復旧は簡単です。しかし、チームが成長するにつれ、規模の拡大がとても大変になります。

3. LDAP やアクディブ・ディレクトリとの統合です。アカウントを共有するよりも安全です。しかし、プロバイダから自社ネットワークへの接続が適切に行われる状態を確保するためには、設計上の熟慮を追加する必要があります。。

4. OAuth や SAML を通したシングル・サインオンです。インフラ・プロバイダにはトークンを基準としたアクセスを可能にします。認証のために、プロバイダが自社ネットワークに接続させる必要はありません。

Q11. 複数のユーザによるインフラ・プロバイダ環境の変更を、どのように追跡しますか？

1. ログを記録していません。誰がいつ何を行ったかの記録がないため、監査やトラブルシューティングが非常に困難です。

2. 手動の変更履歴です。共有ドキュメントにインフラの変更点をユーザが書き加えます。この手法は人的ミスを引き起こしがちです。

3. 監査追跡サービスやログ管理サービス（CouldTrail、Loggy、Splunk、等）のために、全ての API コールを記録します。私たちはこの手法を推奨します。これにより、監査追跡がトラブルシューティングやセキュリティ評価においても確実に利用可能となります。

Q12. 元従業員のアクセスを無効化するには？

1. 直ちに手動で行います。インフラのコード化を用いていない場合であれば、インフラ・プロバイダのコンソールを使い、手動で過去の従業員のアクセスを削除するのが、最も簡単かつ高速です。

2. 後ほど、次期リリースの一部として対処します。もしもリリース手順が極めて連結している場合や、プロダクションに反映する前に、セキュリティの変更に変更諮問委員会（CAB; Change Advisory Board）のミーティングに諮る必要がある場合は、遅れがちです。

3. 直ちにインフラのコード化のホットフィックスを書きます。これが最も安全かつ推奨する手法です。従業員がビルから退出する前に、アクセス権を削除します。

プロビジョニング手順の全体的な習熟度を評価

これら全ての質問に対する内容を検討したら、メモを振り返り、皆さんの組織全体の成熟度がどの段階にあるか評価しましょう。評価によっては、手順がほとんど手動ですか、半自動化ですか、インフラのコード化でしょうか、協調的インフラのコード化でしょうか。

現在の状態を心にとどめたまま、次のセクションに進みましょう。

次へ

現在の手順によって、厳しい表情になっているかもしれません。しかし、これからが改善するときです。

Part 3 プロビジョニング手順を発展するために

本セクションでは、組織における手動プロビジョニング手順を、協調的インフラのコード化に移行する手順を説明します。運用成熟度の各段階において、皆さんの組織が次の段階に進めるように手順を伝えます。最終的には、私たちの推奨するワークフローに到達します。

本セクションを複数のページに分割しました。そのため、既に実装を追えている手順があればスキップできます。Part 2 のメモを読み直し、運用習熟度がどのレベルにあるかを確認しましょう。

• Part 3.1 : 手動から半自動に移行するには
• Part 3.2 : 半自動からインフラのコード化（Infrastructure as Code）に移行するには
• Part 3.3 : インフラのコード化から協調的インフラのコード化に移行するには
• Part 3.4 : 協調的インフラのコード化の高度な改善

Part 3.1 : 手動から半自動に移行するには

インフラ構築を手動で（ CLI や GUI ツールを使って）行う結果、インフラは検査が大変で、再構築が困難で、規模の変更が難しく、インフラに対する知識の共有も困難です。

現在、プロビジョニング手順の大部分が手動でしょうか。そうあれば、インフラで小さく管理可能なサブセットに対し、オープンソースの Terraform を使い始めるのが最初のゴールです。Terraform を使い小さな成功を重ねますと、プロビジョニングの成熟度は半自動の段階に進みます。そして、Terraform の利用を拡大しますと、スケールアップができるようになります。

1. Terraform のインストール

こちらの手順に従って Terraform OSS をインストールします（英語） 。

2. コードを書く

Terraform 設定ファイル を書きます。

3. 導入ガイドを読む

Terraform 導入ガイド を読み進めます。ページではリソースの 変更 と 破棄 や、 リソースの依存関係 の働きなどを通して学びます。

4. 実際のインフラ・プロジェクトに導入

小さな実働中のプロジェクトを選び、そこへ Terraform を導入します。組織における次期プロジェクト一覧から、Terraform の概念実証となるプロジェクトを指定します。あるいは、既存のインフラを Terraform で再実装することも可能です。

プロジェクト選択の鍵は、範囲が限定され、明確な境界線があることです。例えば、AWS 上に新しいアプリケーションのインフラをプロビジョニングするケース。これにより、チームが機能や可能性に圧倒されるないために役立つでしょう。また、 プロジェクト例 から、他の選択肢を感じ取ることもできます。（スタート地点としては AWSの２層例 が良いでしょう ）

この時点でのゴールは、構築は小さいながらも、信頼性の中心である Terraform で経験を積むことです。そして、組織内の他人にとっても利点があると証明できます。

次へ

この時点で、プロビジョニング手順の半自動段階に到達しました。リソースのプロビジョニング手や変更のために、組織の１人又は複数人が Terraform のコードを書けます。小規模ですが、インフラのサブセットをコードとして管理し始めることに意味があります。これは他のチームに対してデモを行う良いタイミングです。インフラをプロビジョニングするには、Terraform の設定を書いて実行するだけです。Terraform がいかに簡単かを見せましょう。

次は、更に複雑なインフラのコード化・ワークフローに移行するときです。

Part 3.2 : 半自動からインフラのコード化（Infrastructure as Code）に移行するには

ここでは半自動プロビジョニングとは、次の手順の少なくとも２つの組み合わせであると定義します。

• Terraform でインフラのコード化
• 手動の CLI 又は GUI プロセス
• スクリプト

現在のプロビジョニング手順が以上の状況であれば、次のゴールは Terraform の利用を拡大し、手動の手順や命令的なスクリプトの利用を減らすことです。そして、インフラのコード化をより一貫性をもって使いやすくするために、基礎となる手法を採用することです。

メモ：まだインフラのコード化をインフラの一部でも採用していなければ、次に進む前に、前のセクションをお読みください。

1. バージョン管理の利用

もしも組織で バージョン管理システム（VCS; Version Control System）が使われていなければ、VCS を選択し、導入します。

おそらく最小の Git/Mercurial/SVN サーバを準備できるでしょう。しかし、私たちはより堅牢な協調的 VCS アプリケーションの導入を推奨します。API でのデータ音アクセスや、リポジトリやアカウントの管理が可能なものです。ここでは Bitbucket、GitLab、GitHub が有名なツールです。

既に VCS ワークフロー、レイアウト、アクセス管理手順を確立している場合は、素晴らしい！　もしまだであれば、これらを決定する良い機会です（私たちは このアドバイス がスタート地点として相応しいと考えています ）。どのような状況下で、誰が変更をマージ可能かを計画します。コードはインフラ全体を管理可能ですので、整合性と品質の維持は非常に重要です。

また、組織における期待を紙に書き出し、チーム間で幅広く共有しておきます。

VCS システムを選定したら、Terraform Enterprise はアクセスできます。現時点で、Terraform Enterprise による統合をサポートするのは GitHub、GitLab、Atlassian Bitbucket（Server と Cloud の両方）です。

2. Terraform コードを VCS リポジトリに置く

インフラのコードをバージョン管理に移行し始めましょう。新しい Terraform のコードは、全てバージョン管理かに置かれるべきです。つまり、既存の Terraform コードはバージョン管理外にあるため、移行を行います。これにより、組織内の誰でも特定の場所を見るだけで、変更の目的や履歴を追跡可能となります。

3. 初めてのモジュール作成

Terraform モジュール (module) は再利用可能な設定ファイルの単位（ユニット）です。これはインフラの部品を１つのパッケージとして管理可能にできます。そのため、主要な設定ファイルを、ワークスペースで何度でも呼び出し・書き込みできます。AWS 用にはオートスケーリング・グループを構成する Terraform モジュールの良い例があります。これは設定と、オートスケーリング・グループ、EC2 Elastic Load Balancer (ELB) を一まとめにします。もし既に Terraform モジュールを使っているのであれば、以下のベスト・プラクティスに従っているかどうかや、皆さんのモジュールを改善可能かどうか見落とさないでください。

次の図はモジュールを書くときに決める手助けとなります：

（フローチャートは提案中です。モジュールは構築パターンに応じて複数のリソースを再利用であるべきで、設定を削減したり、あるいは多くのリソース・タイプに応じてカスタムセットアップしたりします）

4. 知識の共有

Terraform のスキルを他のチームに展開します。そして、これまでのインフラ・チームのスキルを改良します。さらに、内部でのトレーニングや自習についても、検討するかもしれません。

• チームで HashiCorp 公式トレーニング に登録
• Terraform Up an Running: Writing Infrastructure as Code や Getting Started with Terraform のようなリソースの利用。これは組織内で誰も Terraform を使っていないとき、とりわけ効果があります。

5. ガイドラインの作成

Terraform のコードを書くガイドラインとして使うため、標準構築アーキテクチャを作成します。組織を横断して共有する場合は、モジュールの活用がベストです。そして、インフラを設計周辺で、誰もが持つ期待が共通している場合、その共有がより効果的です。IT アーキテクトは、皆さんの組織が必要とする標準的なアーキテクチャを構築できるように設計すべきでしょう。チーム間を横断する一貫性を保ちながら、高い可用性、柔軟性、障害復旧を考慮した構築を後押しします。

以下はクラウド・プロバイダごとに役立つ構築パターン例です：

• AWS: Well Architected Frameworks と the Architecture Center
• Azure: deploying Azure Reference Architectures and Azure Architecture Center
• GCP: Building scalable and resilient web applications
• Oracle Public Cloud: Best Practices for Using Oracle Cloud

6. 構成管理と Terraform を統合

もしも既に組織で構成管理ツールを導入している場合は、Terraform と連携すべきときです。 Terraform プロビジョナ を使えば、リソースの作成後に、設定管理を使った処理を引き渡せます。Terraform はインフラを取り扱うべきであり、他のツールはユーザ・データやアプリケーションを扱うべきです。

あるいは設定管理ツールを使っていない場合、厳密にはイミュータブル・インフラストラクチャではありません。そのため、設定管理ツールの導入を検討すべきでしょう。これは大きなタスクとなりうるのですが、インフラのコード化を採用するのと同じゴールに至るのです。つまり、アプリケーションの設定をより制御可能に、理解可能に、そしてチーム間を横断して再利用可能にするのです。

ここから始めるのであれば、 Chef クックブックを作成するチュートリアル を通して、ローカルの Vagrant でテスト可能です。また組織において 設定管理ツールの何がベストか を決めるのかに関する記事をお薦めします。

7. シークレットの管理

Terraform と Vault を連携するか、他のシークレット管理ツールを使います。サービス・プロバイダの認証情報のようなシークレットは、常に安全を保ち続ける必要があります。しかし、必要に応じて簡単に使えなくてはいけません。ベストな手法は、専用のシークレット管理ツールを用い、必要に応じて割り当てることです。私たちは HashiCorp Vault こそが多くの皆さんにとって最上の選択肢と考えますが、Terraform は他のシークレット管理ツールとも同様に連携可能です。

次へ

この時点で、組織は VCS で設定ファイルを管理し、インフラ管理の鍵となるのが Terraform となり、少なくとも１つ再利用可能な Terraform モジュールを手に入れました。半自動手順と比べ、皆さんの組織は一貫性のある言語とワークローを用いることにより、インフラ設定のより優れた可視化をもたらしました。

次は高度なワークフローが必要です。スケールと、多くの貢献者による権限を委譲可能であることです。

Part 3.3 : インフラのコード化から協調的インフラのコード化に移行するには

バージョン管理された Terraform 設定ファイルを用いることで、インフラ管理の鍵となる技術的な複雑さと一貫性のなさを解消できました。これで基本は抑えましたので、次は他の問題に取り組む準備が整いました。

次のゴールは以下の通りです：

• チーム間を横断して Terraform の一貫したワークフローを採用
• 中心となるエンジニアが Terraform コードを直接編集し、Terraform による利益を拡大
• ユーザとチームに対して、インフラをプロビジョニングする権限の管理

皆さんが直面しているのは、次のレベルにある問題です。これに対処するため、私たちは Terraform Enterprise (TFE) を作りました。以下のセクションでは、より効率的に使うにはどうしたら良いかを紹介します。

メモ：まだ皆さんのインフラの重要な部分で Terraform を使っていないのであれば、以下のステップに進む前に、前のセクションをご覧ください。

1. TFE のインストールかサインアップ

Terraform Enterprise の導入には２つの選択肢があります。SaaS かプライベートへのインストールです。SaaS バージョンを選択する場合は、次のステップを省略できます。そうでなければ、 インストール・ガイド から始めましょう。Terraform は output の出力として TFE の URL を表示します。

2. TFE 実行環境を学ぶ

TFE ではどのように Terraform を使うのか、慣れていきましょう。Terraform OSS では、一般的に外部の VCS ツールを使い、ファイルシステム上にコードを置きます。それからコマンドラインか汎用 CI システムを使い、Terraform を実行します。

TFE は違います。VCS リポジトリとワークスペース（workspace）を直接関連付けます。そして、TFE の UI や API を使い、開始や実行状況を監視します。この運用モデルに慣れるには：

• Terraform Enterprise で どのように Terraform の実行を設定し、処理するか のドキュメントを読む
• 概念実証のワークスペースを作成し、Terraform コードを VSC リポジトリを関連付ける。必要に応じて変数を設定し、Terraform Enterprise で Terraform の処理をするとき、コード内で参照する。

3. 組織のワークスペース構造を設計

TFE では、各 Terraform 設定は個々のインフラ・コンポーネントごとに管理されるべきです。また、環境ごとに設定ファイルを設け、ワークスペースは分割されるべきです。言い換えれば、Terraform 設定数 × 環境数 ＝ワークスペース数です。ワークスペース名は「networking-dev」のような形式です。そのため、一目見るだけで、どのインフラと環境を管理しているのか分かります。

「インフラ・コンポーネント」定義は、皆さんの組織構造に依存します。与えられたワークスペースはアプリケーション、サーバ、あるいはグループに関連するサービスを管理するでしょう。つまり、あるエンジニアリング・チームがインフラをプロビジョンするかもしれません。あるいはビジネス全体で使うインフラの基本部分、このプロビジョニングを共有するかもしれません。

ワークスペースの構造は、皆さんのインフラに対する部門間の責任と一致するようにすべきです。おそらく、最終的には混合型となるでしょう。ネットワークのような複数のコンポーネントは共有し、インフラの基本部分はセントラル IT スタッフによって管理されます。つまり、各エンジニアリング・チームは各アプリケーションに関連する部分しか管理しません。

また、以下の点に注意してください。

• ワークスペースによっては、他のワークスペースで使うためのデータを出力する
• ワークスペースは設定ファイルごとに環境（app1-dev、app1-stage、app1-prod）を作るので、コード全体が適切かどうか確認された状態を維持すべく、順番通りに実行すべき

１つ目の連携として、ワークスペース間の連携とはコンポーネントごとに異なります。しかし同じ環境では、ワークスペース間の依存性グラフ（訳者注；ノードの集まりとエッジの集まりで構成されるデータ構造）を作成します。これにまず注意を払うべきです。２つ目の連携は、同じコンポーネントを使うワークスペース間でも、環境が異なる場合は、ワークスペース間のパイプラインを作成します。現時点の TFE には、これらの関連性を処理できませんが、近い将来これらの機能を取り込みます。そして、ワークスペース間の連携について理解しておけば、より簡単に扱えるようになります。

4. ワークスペースの作成

TFE でワークスペースを作成します。そして VCS リポジトリをワークスペースに割り当てます。各ワークスペースはそれぞれが Terraform のコードをバージョン管理システムから読み込みます。ワークスペースごとにリポジトリとブランチの指定が必要です。

私たちが推奨するのはアプリケーションやサービスの全ての環境で、同じリポジトリとブランチを使うことです。Terraform コードを書くとき、環境の差異を変数で扱えます。また、ワークスペースごとに適切な変数を割り当て可能です。しかし、既存のコードでは実践的ではない場合があります。マージ方針によってはワークスペースごとにブランチを分けている場合もあるからです。しかし、私たちはブランチを１つに集約するモデルがベストだと信じています。

VCS ブランチの変更により、マスタにマージすることで、ワークスペースを通したステージング環境、UAT 環境、完全なプロダクション環境を促します。

5. ユーザとチームの作成

皆さんの同僚は、一人一人が TFE ユーザを作成する必用があります。そして組織の導入においては、適切なチームへの追加も可能です。

TFE チームとは、ワークスペースに対する権限を与えられたユーザの一覧です。つまりTFE チームはインフラごとに責任を持っている担当者と一致すべきです。これは、組織図とは一致しない場合もありえますが、組織にわたる人々をどうするかに時間を費やすべきですし、会話すべきです。次の点にご注意ください：

• あるチームは多くのワークスペースの管理が必要で、あるチームは１つか２つの権限のみ必要
• チームによっては全てのワークスペースで同じ権限が不要。例えば、アプリケーション開発者はアプリの開発とステージング環境のみ読み書き権限が必要で、プロダクションは読み込みのみ。

協調的インフラのコード化導入で最も難しい部分が、権限を正確かつ完全に委譲するために、どのように管理するかです。

6. 権限の割り当て

チームに対してワークスペースの所有権と権限を割り当てます。各ワークスペースは３つのレベルの権限があります。ユーザやチームごとに、admin、read/write、read-onlyを割り当て可能です。Admin は効率的にワークスペースを所有し、対象ワークスペース上のユーザにする権限を変更可能です。

多くのワークスペースは、複数のチームに対して異なる権限を与えられます。

ワークスペース          チーム権限
----------------------- ------------------------------------
app1-dev                Team-eng-app1: Read/write
                        Team-owners-app1: Admin
                        Team-central-IT: Admin

app1-prod               Team-eng-app1: Read-only
                        Team-owners-app1: Read/write
                        Team-central-IT: Admin

networking-dev          Team-eng-networking: Read/write
                        Team-owners-networking: Admin
                        Team-central-IT: Admin

networking-prod         Team-eng-networking: Read-only
                        Team-owners-networking: Read/write
                        Team-central-IT: Admin

7. Terraform を使わないアクセスの制限

クラウド・プロバイダの UI や API によるアクセスを制限します。インフラのプロビジョニングにおいて、Terraform Enterprise は組織における優先インターフェースです。そのため、TFE を経由しない他のあらゆるアクセスを制限すべきです。ほとんど大部分のユーザは、インフラの変更を手動では行えないでしょう。Terraform ワークフローの組織同意に基づかないためです。

誰もが Terraform を経由することで、コードレビューの手順や TFE ワークスペース権限によって、インフラに対して誰が変更を加えたのか明確に記録できます。これにより、インフラの全てを理解しやすく生業可能になるのです。Terraform Enterprise は１つのワークフローを学ぶだけで、１つの安全なワークフローや、そのほか組織における監査可能なプロビジョニングのためのワークフローとなるのです。

次へ

この時点で、Terraform Enterprise を使った「協調的インフラのコード化」の導入に成功しました。１つのワークフローを使い、複数のプロバイダを横断するインフラをプロビジョニングできます。そして、共通したインターフェースを通し、皆さんの組織における標準的なアクセス制御やコードのプロモーションなどに役立つでしょう。

次はワークフローと手順の改善を進めましょう。

Part 3.4 : 協調的インフラのコード化の高度な改善

これでプロビジョニングに対する協調的インターフェースとワークフローを手に入れました。手順をより改善するためには、決まったフレームワークがあります。

以下の提案は、順番に行う必要はありません。そしてビジネスによっては全て実現する必要はないかもしれません。私たちは可能性を示すだけであり、皆さんが次に何をすべきか、自分自身に問うときのご参考になさってください。

• 更に手順やリソースを TFE に移行します。TFE の導入に成功したら、まだ残っている手動・半自動のワークフローや手順を移行するチャンスです。私たちが提案するのは、インフラの実行維持に責任を持つ全てのチームにより、自動化の将来的な目標を明確にする発見（discovery）ミーティングの開催です。あるいは、セクション２で用いたガイドのメモをもとに、あるいは古い変更リクエストやインシデント・チケットも使えます。

• イメージ作成のために HashiCorp Packer の採用。Packer はメンテナンス可能で再利用できるマシンイメージの構築に役立ちます。また Terraform の利便性を倍増できます。

• Terraform 設定に Sentinel を適用し、ビジネスとコンプライアンスに準拠するように従います。

• TFE のために監査ログを設定します。Terraform Enterprise プライベート・インストールは、デフォルトで CloudWatch にログを送れます。

• インフラの監視と性能メトリクスを追加します。これにより、環境のプロモーションが安全になり、アプリケーションのパフォーマンスのセーフガードとなります。多くのツールが利用可能ですが、私たちが推奨するのはインフラ自身の管理と、ユーザ視点でのアプリケーション性能の監視の両方です。

• TFE API を使います。TFE API を汎用 CI/CD ツールと連携し、あらゆるイベントを Terraform の実行トリガにできます。

原文

• Index - Terraform Recommended Practices - Terraform by HashiCorp
  • https://www.terraform.io/docs/enterprise-beta/guides/recommended-practices/index.html
    
    

【参考訳】入れ替え可能なランタイム：containerdとCRI-Oと、Kubernetesユーザに与える影響

ここ数日の動きに関連して、 CoreOS の blog 投稿 で状況がよくまとめられていると思われた投稿がありました。参考情報として翻訳・共有いたします。内容間違い等ございましたら、ご指摘ください。

入れ替え可能なランタイム：containerdとCRI-Oと、Kubernetesユーザに与える影響

Pluggability（プラガビリティ ※1）とは Kubernetes のサクセス・ストーリー（成功談）の一部です。そして、Kubernetes ユーザ体験（user experience）を変えることなく、ストレージ、ネットワーク、スケジューラといった多くのレイヤを置換可能かつ改良可能なのを、コミュニティの皆さんにお約束するものです。今年の初め、 Kubernetes 上でのコンテナ実行をプラガブルにする手法として、Kubernetes プロジェクトはコンテナ・ランタイム・インターフェース（CRI; Container Runtime Interface）と呼ぶ API を作成しました。今週、Kubernetes CRI API を実装する２つのプロジェクトが成熟に向かいつつあります。 CRI-O はバージョン 1.0.0 に到達し、 containerd は 1.0.0-beta.2 ですが間もなくベータを外せる模様です。

（※1 訳者注；Pluggabilityとは、入れ替え可能な機能、の意味。システムなどが Pluggable、つまりプラグを差し替えるように、入れ替え可能なもの。ここではそのままにしました）

これらのリリースはプロダクション（本番環境）利用に向けての初期の通過点（マイルストーン）であり、プロジェクトに関わるチームの皆さんにお祝いを言わせてください。また、プロジェクト初期から今日に至るまでのほとんどの努力は、多くの人々にとって初めて知られることになるかもしれません。そこで、私たちは これらが Kubernetes エコシステムの中で使われるように至った経緯と背景をご紹介します。

もしも、皆さんが Kubernetes を日常でお使いであれば、ここで読むのを止めても構わないでしょう。CRI と Docker Engine、containerd、CRI-O のような様々な実装が目指すのは、ユーザに対する透明性と Kubernetes API から離れるのを、これまでの経験を変えずに実現するためです。これらの大部分は内部のシステム設計に関わる部分ですが、これらの 99% が同じ機能の実装です。似たような例としては、皆さんのノート PC 上における GNU sed 対 BSD sed です。そして、皆さんが CoreOS Tectonic （訳者注；CoreOS社が開発・サポートしている Kubernetes をベースとしたコンテナ管理プラットフォーム）ユーザであれば、デプロイと運用のために、私たちのフルスタックの自動運用と、クラウドおよびオンプレミスの柔軟なインストーラーにより、Kubernetes 内部の設定調整に時間をかけずに行える、ベストな選択肢であると自信をお持ちでしょう。

もしまた Kubernetes や CoreOS Tectonic を試していなければ、 Linux/Windows/macOS に対応した Tectonic Sandbox をお試しいただくか、 クラウド上で自由に お試しください。

コンテナ用語

Kubernetes コミュニティに対する各プロジェクトを扱う前に、まずは用語を簡単に復習しましょう。

• コンテナ・イメージ（Container images） とは、アプリケーションに対する依存関係全てを、１つの名前のアセット（asset；もの、存在）にパッケージしたものです。これにより、多くのマシン間にコピーできます。これはサーバ上におけるモバイルアプリの考え方と同じです。つまり、アプリの中に全てが入っており、簡単にインストールできます。
• コンテナ・ランタイム（Container runtimes） とは、Kubernetes エコシステムにおいて Kubernetes システムの内部コンポーネントです。このシステムは、コンテナ・イメージにパッケージ化されたアプリケーションをダウンロードし、実行します。コンテナ・ランタイムの例には containerd、CRI-O、Docker Engine、frakti、rkt があります。
• オープン・コンテナ・イニシアティブ（OCI）ランタイム仕様（Runtime Specification） とは、コンテナ・ランタイムのスキーマ（仕様）を明確に定義したものです。具体的には userid、bind mount、カーネル名前空間（kernel namespaces）、コントロール・グループ（cgroups）であり、これらはコンテナ・イメージの実行時に作成されます。この仕様はコンテナ・ランタイムの相互運用性を保証するために重要ですが、インフラ管理者が日々で扱う領域ではありません。

ここ数年、コンテナは広範囲かつ急速に広まり、開発者とインフラ管理者らに有名になりました。そして、皆さんが必要としたのは長期にわたるフォーマット（仕様）の安定性と、内部ツールの互換性です。私たちは 2014年に提供を始めた appc から、コンテナ相互運用に関して業界との対話に努めてきました。以降、コンテナ業界の他社とオープン・コンテナ・イニシアティブ（OCI）を組織し、２年の取り組みの後、最近 イメージおよびランタイム仕様 v1.0 の発表に至りました。

containerd が生まれたのは、この努力の一部です。Docker Engine のコードを上書きした containerd は、スタンドアロン（訳者注；単体で動作する、の意味）なコンテナ・ランタイム・コンポーネントです。これは OCI 仕様に則った実装です。そして、OCI が開発したコンポーネントである CRI-O プロジェクトも同様であり、その目標とするのは Kubernetes のためのコンテナ・ランタイム・インターフェースの実装をゼロから行うことでした。そして今、 CRI-O と containerd のどちらもコンテナ・イメージをダウンロード可能であり、OCI ランタイム仕様を用いるコンテナをセットアップし、実行可能になりました。

コンテナ・ランタイムと Kubernetes での動作について

2016年後半にリリースされた Kubernetes 1.5 は、コンテナ・ランタイム・インターフェースを Kubernetes に実装した初めてのバージョンです。抽象化レイヤの基盤は、 Kubernetes プロジェクト SIG Node と、Google や CoreOS やその他の皆さんとの協力作業によるものです。そして、 Kubernetes と他のコンテナ・ランタイム間における API インターフェースを、コンテナ・ランタイム・インターフェース（CRI）として定義しました。２つの要素がゴールです。テストとしてこのインターフェースをモックとして使える API を導入すること。それと、 Docker Engine や CRI-O、rkt、containerd のようなコンテナ・ランタイムを Kubernetes において置き換え可能とすることです。

より詳細な情報については、CRI を Kubernetes で利用可能にするプロジェクトの コンテナ・ランタイム・インターフェースのブログ投稿 をご覧ください。

コンテナ・ランタイム・インターフェースの影響

containerd と CRI-O のようなプロジェクトの開発は興味深く、情報を追う価値がありました。これまでのところ、Kubernetes コミュニティに対する CRI の主な恩恵は、より優れたコードの体系化と、Kubelet 自身が扱う範囲のコード改善でした。得られたコードをもとに、従来よりも高い品質と全面的なテストの両方を得ました。

ほとんど全てのデプロイにおいて、まだしばらくは、私たちは Kubernetes コミュニティが Docker Engine を使い続けると予想しています。なぜならば、新しいコンテナ・ランタイムの導入により、既存の機能性を壊す可能性が潜在しており、既存の Kubernetes ユーザに対して新しい価値を直ちにもたらせないからです。

CRI の働きにより、Kubernetes 内部のコンテナ・ランタイムの入れ替えが簡単になりました。そして、エンド・トウ・エンドのテストも通過しています。これまでの３年、Kubernetes と Docker Engine 間にわたる多くの統合により、依存関係が作り出されました。想定しているのは、ディスクに対するログの保存場所、Linux コンテナ内部、コンテナ・イメージの保管、そして、その他の細かな相互関係です。

依存性に対する取り組みには、抽象化の調整と改良が必要であり、開発には時間を費やすでしょう。そして、containerd、CRI-O、あるいは他の CRI 実装がありますが、プロダクションのほとんどの場面で利用するにあたり、理論的に何がベストなものとしてあり続けるのか、Kubernetes コミュニティで何を変えて行くのかの議論が続くでしょう。

コンテナ・ランタイムの更なる選択肢？ 問題ありません

皆さんが Kubernetes ユーザであれば、CoreOS が優れたコンテナ基盤へと案内・導入する手助けを続けますので、ご安心ください。これまで通り、一貫して行います。エコシステムに参加する新しい方には、CoreOS はエコシステムにおける成熟したコンテナ・ランタイムとして、Kubernetes 環境をプロダクションで使うには、Docker Engine と比較して安定性があると CoreOS は評価されています。コンテナ・ランタイムの代替は Kubernetes 利用者に対して大きな意味のある改良ですが、私たちは上位プロジェクトの決定を支持し、私たちはプロジェクトに対して CoreOS Tectonic プラットフォームの選択肢をサポートし続けます。

さらに、Tectonic を利用する皆さんに対して。Kubernetes プラットフォームで避けられない内部変更があったとしても、導入およびアップグレードを独自に自動的に処理できるよう、Tectonic プラットフォーム全体が設計されています。Kubernetes エコシステムでは、将来の Kubernetes リリースに向けて、どのコンテナ・ランタイムを選択するのか評価が続きます。ですが、 皆さんに対しては、柔軟性を発揮するのにベストであり、最も安全な選択肢であるべく Tectonic の準備が整っているのを申しあげます。

エンタープライズへの準備が整った Kubernetes を皆さんの現在の環境で動かすために、Tectonic が最も簡単なのは何故なのか、皆さん自身で確かめたい場合は、 Tectonic をダウンロード できますし、10ノードまでのクラスタをデプロイするまでは無料でご利用いただけます。あるいは、皆さんのノート PC 上で Tectonic を触ってみたい場合は、 Tectonic Sandbox が独自の機能や実験用環境として使えるでしょう。こちらは皆さんのマシン上で動作するものであり、ハードウェアの追加やクラウド・アカウントは不要です。

原文

• Pluggable runtimes: containerd, CRI-O and their impact on Kubernetes users | CoreOS
  • https://coreos.com/blog/pluggable-oci-runtimes-and-their-impact-on-kubernetes-users

【参考訳】DockerCon EU 17 における Docker の Kubernetes サポート関連発表

概要

2017年10月17日、コペンハーゲン（デンマーク）で開催の DockerCon EU 基調講演で、Docker プラットフォームと moby プロジェクトで、 Kubernetes サポートの対応を開始する発表がありました。要点を纏めますと、

• Docker は Kubernetes に対応します(moby love Kubernetes）
• Docker for Mac/Winで Kubernetes 動きます（年内にベータ提供開始予定）
• Swarm も従来通り続けます

関連して ブログも更新 されたので、ご理解の参考程度にと共有します。

Docker プラットフォームと Moby プロジェクトに Kubernetes が加わる

今日私たちは、 Docker プラットフォームが Kubernetes との連携をサポートする発表を行いました。これにより、Docker の利用者と開発者の皆さんは、コンテナ処理のオーケストレートのため、Kubernetes と Swarm の両方を選べます。 ベータ・アクセスのご登録 と、どのように私たちが Kubernetes を使えるようにしているかを詳細を学ぶため、ブログの投稿をご覧ください。

• Docker Enterprise Edition（英語）
• Docker Community Edtion on the desktop with Docker for Mac and Windows（英語）
• The Moby Project（英語）

（各ブログの翻訳は、このページの後方にあります）

Docker はアプリケーションとインフラストラクチャ（システム基盤）に跨がるプラットフォームです。Docker 上でアプリケーションを構築すると、開発者や IT 運用者は自由と柔軟さを手に入れられます。 Docker はどこでも実行できますので、エンタープライズにおけるアプリケーションのデプロイを、オンプレミス上（IBMメインフレームだけでなく、エンタープライズ Linux と Windows も含みます）でもクラウドでも可能にします。アプリケーションをコンテナ対応（containerized）しておけば、再構築、再デプロイ、移動を簡単に行えます。それだけでなく、従来のオンプレミス環境とクラウド環境のどちらでも動作するようにセットアップできます。

Docker プラットフォームは多くのコンポーネントを４つのレイヤに構成します：

• 業界標準コンテナ・ランタイムである OCI 規格を実装する containerd
• ノード群を分散システムに変換する Swarm オーケストレーション
• Docker コミュニティ・エディションは、開発者に対してコンテナアプリケーションを開発・移動するワークフローを簡単にします。ワークフローとは、アプリケーションの構成や、イメージ構築・管理などです。
• Docker エンタープライズ・エディションは、プロダクションにおけるソフトウェアのサプライ・チェーン連携を安全に管理し、コンテナを実行します。

これら４つのレイヤは、オープンソースの Moby プロジェクトの一次コンポーネントで構成されます。

Docker の設計哲学とは、常に選択と柔軟性の提供であり、既存の IT システムと Docker を統合する利用者の皆さんにとって大切です。なぜならば、既にデプロイ済みのネットワーク、ログ記録、ストレージ、負荷分散、CI/CD システムと連携するように Docker が作られているからです。Docker が依存しているのは、業界標準プロトコルや論文、ドキュメント化されたインタフェースです。そして、これら全てにより、Docker エンタープライズ・エディションはデフォルトで実用的です。また、これら標準機能により、皆さんは既存のシステムや望ましいソリューションを利用するにあたり、認証済みのサードパーティ製のものへと置き換え可能なのです。

2016年、Docker はプラットフォームに SwarmKit プロジェクトから導入した オーケストレーションを追加 しました。そしてこれまでの１年、私たちは Swarm に対する多数の建設的なフィードバックをいただきました。セットアップが簡単で、スケーラブルであり、難しい設定を行わなくても安全です、と。

その一方で、Docker プラットフォームですべてをコンテナで管理する利用者の方からもフィードバックをいただきました。コンテナのスケジューリングのために Kubernetes のような他のオーケストレータを使いたいと。あるいは、既にサービスを Kubernetes 上で動作するように設計済みであったり、Kubernetes にこそ求めている機能がある場合にです。これこそが、私たちが Docker エンタープライズ・エディションと Docker for Mac と Windows におけるオーケストレーションのオプションに、（Swarm と並んで） Kubernetes 対応を追加した理由なのです。

さらに、Docker 利用者が Kubernetes オーケストレーションにネイティブ対応した、 Docker アプリケーションのデプロイが簡単になるように、革新的なコンポーネントに取り組んでいます。たとえば、 カスタム・リソース のような Kubernetes の拡張機構を使う場合や、API サーバとの連携レイヤについては、Docker が Kubernetes をサポートする将来のバージョンにより、 Docker Compose アプリケーションを Kubernetes ネイティブの Pod やサービスとしてでデプロイできるようになります。

次期バージョンの Docker プラットフォームでは、プロダクションが Kubernetes で動くようなアプリケーションを、開発者の皆さん自身ワークステーション上で構築・テスト可能となります。そして、運用担当は Docker エンタープライズ・エディションの全ての利点も得られるのです。安全なマルチ・テナンシー、イメージの検査、役割に応じたアクセス制御などを、プロダクションにおけるアプリ実行を Kubernetes あるいは Swarm でオーケストレートできるのです。

私たちが Docker との連携に取り組んでいる Kubernetes のバージョンは vanilla Kubernetes です。こちらは CNCF（訳者注；業界団体”クラウドネイティブ・コンピューティング・ファウンデーション”の略）が監督のもと、皆さんが扱いやすいものです。こちらからのフォークではなく、古いバージョンでもなく、包括および何らかを限定するものではありません。

Docker は昨年より Moby プロジェクトを通して、 Kubernetes の採用と貢献に取り組んできました。既にコンテナ・ランタイムとしての InfraKit 上にある containred と cri-containerd は、Kubernetes インストールにおける作成・管理とオーバレイ・ネットワーク機能用の libnetwork に対して取り組んでいます。サンプルおよび詳細については Moby プロジェクトのブログ投稿（英語） をご覧ください。

Docker と Kubernetes は系統を共有しています。いずれも同一のプログラミング言語であり、コンポーネントや貢献者やアイディアが重複しています。私たち Docker が期待しているのは、 Kubernetes サポートを私たちの製品に取り込み、また、オープンソース・プロジェクトにおいても取り組むことです。そして、私たちは Kubernetes コミュニティを待たずとも、コンテナやコンテナオーケストレーションをより協力かつ簡単に使えるようにします。

Kubernetes をサポートする Docker エンタープライズ（インフラをサポート）とコミュニティ・エディション（Mac と Windows 対応）のベータ版は、今年末に利用可能となります。 準備が整ったら通知を受けたい場合は、サインアップしてください 。

私たちは Docker におけるオーケストレーションのオプションとして Kubernetes に対応しますが、Swarm に対して取り組み（コミット）続けますし、お客さまや、スケールするプロダクションにおける、クリティカルなアプリケーションを実行する Swarm および Docker に依存している利用者の皆さんに対応し続けます。Docker がどのように Kubernetes を統合するのか詳細を知りたい場合は DockerCon EC の “What’s New in Docker” と “Gordon’s Secret Session” をご確認ください。

原文

• Docker Platform and Moby Project add Kubernetes - Docker Blog
  • https://blog.docker.com/2017/10/kubernetes-docker-platform-and-moby-project/

Kubernetes 対応 Docker for Mac および Windows

今日、Docker プラットフォームにおける Kubernetes サポートに対する取り組みの１つとして、Docker コミュニティ・エディションの Mac および Windows 版で Kubernetes オプションの追加を発表します。DockerCon でプレビューを実演しており（Docker ブースで足を止めてください！）、ベータプログラムを 2017 年末に準備します。ベータの準備が整ったら通知を受けるにはサインアップしてください。

Docker CE の Mac および Windows で Kubernetes をサポートすると、利用者の皆さんはソフトウエアとサービスを、開発ワークステーションにおけるテストや CI/CD を通し、オンプレミスまたはクラウド上のプロダクションに至るまで、コンテナで管理できるようになります。

Docker for Mac と Windows は Docker 開発環境の調整で最も人気のある手法であり、毎日何十万人もの開発者がコンテナ対応アプリケーションの開発、テスト、デバッグに使われています。Docker for Mac と Window が人気なのは、インストールがシンプルであり、更新は自動的に行われ、macOS や Windows とそれぞれ密接に統合しているからです。

Kubernetes コミュニティは開発ワークステーションで限定的な Kubernetes をセットアップする良い手法を Minikube など（こちら自身も一部は Docker for Mac と Windows の前身である、docker-machine プロジェクトを元にしています）として提供しています。これらソリューションは一般的ですが、docker build → run → test を頻繁に繰り返す設定をするにはトリッキーであり、古い Docker バージョンに依存しています。

Docker for Mac と Windows における Kubernetes サポートが見えてきたので、開発者は docker-compose と Swarm をベースとしたアプリケーションの両方を構築し、Kubernetes 上へデプロイ可能なアプリケーション設計が簡単になります。そのため、ノート PC やワークステーション上で使うには最良の選択肢となるでしょう。全てのコンテナ・タスク（biuld だけでなく run や push ）を、イメージ、ボリューム、コンテナが共通の同じ Docker インスタンス上で実行できます。そして、それらは最新かつ良い Docker プラットフォームのバージョンをベースとしているため、Kubernetes デスクトップ利用者に対して マルチステージ・ビルド のような拡張機能を扱えるようにします。

Docker に対する Kubernetes 取り組み成果の一部に、Kubernetes コンポーネントのカスタム・リソースを使う物や、API サーバ統合レイヤがあります。これらにより、Docker Compose アプリを Kubernetes ネイティブ Pot やサービスとしてシンプルにデプロイ可能となります。これらのコンポーネントは Docker EE と Docker CE for Mac と Windows でも提供していきます。

• Kubernetes in Docker for Mac (YouTube)

皆さんに Docker for Mac と Windows で Kubernetes が動いているのを早くお見せしたいです。DockerCon EU 17 の Docker ブースにお立ち寄りください。あるいは、ベータ版が利用可能になったときの通知の受け取りをお申し込みください。

原文

• Beta Docker for Mac and Windows with Kubernetes - Docker Blog
  • https://blog.docker.com/2017/10/docker-for-mac-and-windows-with-kubernetes-beta/

【参考訳】HashiCorp Vagrant 2.0

概要

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 の改善に取り組んでいます。

原文

• HashiCorp Vagrant 2.0
  • https://www.hashicorp.com/blog/hashicorp-vagrant-2-0/

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

概要

先日の 【参考訳】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=... フラグを使うかどうかの明確な決定を考慮すべきでしょう。

原文

• Upgrading to Terraform 0.10 - Terraform by HashiCorp
  • https://www.terraform.io/upgrade-guides/0-10.html

【参考訳】HashiCorp Terraform 0.10

“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 AWS Provider Changelog
• Terrform Google Compute 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 Terraform 0.10 | HashiCorp https://www.hashicorp.com/blog/hashicorp-terraform-0-10/ *

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

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 利用者の学習曲線と作業負担を軽減できうるでしょう。使いやすい主な機能は、次の通りです。

• バイナリ１つをデプロイするだけであり、外部の依存性が無い
• シンプルかつ双方向のデータ・モデル
• 宣言型のジョブ定義（declarative job specification）
• 高可用性のサポートと マルチ・データセンタ統合 を簡単にする

また、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 に対応しています。

原文

• Running Apache Spark on Nomad | HashiCorp
  • https://www.hashicorp.com/blog/running-apache-spark-on-nomad/

【参考訳】HashiCorp Nomad 0.6

“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/ をご覧ください。

原文

• HashiCorp Nomad 0.6 | HashiCorp
  • https://www.hashicorp.com/blog/hashicorp-nomad-0-6/

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

概要

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 までメールをお送りください。

原文

• Vagrant Cloud Migration Announcement | HashiCorp
  • https://www.hashicorp.com/blog/vagrant-cloud-migration-announcement/