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

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

Pluggability(プラガビリティ ※1)とは Kubernetes のサクセス・ストーリー(成功談)の一部です。そして、Kubernetes ユーザ体験(user experience)を変えることなく、ストレージ、ネットワーク、スケジューラといった多くのレイヤを置換可能かつ改良可能なのを、コミュニティの皆さんにお約束するものです。今年の初め、 Kubernetes 上でのコンテナ実行をプラガブルにする手法として、Kubernetes プロジェクトはコンテナ・ランタイム・インターフェース(CRI; Container Runtime Interface)と呼ぶ API を作成しました。今週、Kubernetes CRI API を実装する2つのプロジェクトが成熟に向かいつつあります。 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) とは、アプリケーションに対する依存関係全てを、1つの名前のアセット(asset;もの、存在)にパッケージしたものです。これにより、多くのマシン間にコピーできます。これはサーバ上におけるモバイルアプリの考え方と同じです。つまり、アプリの中に全てが入っており、簡単にインストールできます。
  • コンテナ・ランタイム(Container runtimes) とは、Kubernetes エコシステムにおいて Kubernetes システムの内部コンポーネントです。このシステムは、コンテナ・イメージにパッケージ化されたアプリケーションをダウンロードし、実行します。コンテナ・ランタイムの例には containerd、CRI-O、Docker Engine、frakti、rkt があります。
  • オープン・コンテナ・イニシアティブ(OCI)ランタイム仕様(Runtime Specification) とは、コンテナ・ランタイムのスキーマ(仕様)を明確に定義したものです。具体的には userid、bind mount、カーネル名前空間(kernel namespaces)、コントロール・グループ(cgroups)であり、これらはコンテナ・イメージの実行時に作成されます。この仕様はコンテナ・ランタイムの相互運用性を保証するために重要ですが、インフラ管理者が日々で扱う領域ではありません。

ここ数年、コンテナは広範囲かつ急速に広まり、開発者とインフラ管理者らに有名になりました。そして、皆さんが必要としたのは長期にわたるフォーマット(仕様)の安定性と、内部ツールの互換性です。私たちは 2014年に提供を始めた appc から、コンテナ相互運用に関して業界との対話に努めてきました。以降、コンテナ業界の他社とオープン・コンテナ・イニシアティブ(OCI)を組織し、2年の取り組みの後、最近 イメージおよびランタイム仕様 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)として定義しました。2つの要素がゴールです。テストとしてこのインターフェースをモックとして使える API を導入すること。それと、 Docker Engine や CRI-O、rkt、containerd のようなコンテナ・ランタイムを Kubernetes において置き換え可能とすることです。

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

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

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

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

CRI の働きにより、Kubernetes 内部のコンテナ・ランタイムの入れ替えが簡単になりました。そして、エンド・トウ・エンドのテストも通過しています。これまでの3年、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 が独自の機能や実験用環境として使えるでしょう。こちらは皆さんのマシン上で動作するものであり、ハードウェアの追加やクラウド・アカウントは不要です。

原文



概要

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

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

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

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

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

2016年、Docker はプラットフォームに SwarmKit プロジェクトから導入した オーケストレーションを追加 しました。そしてこれまでの1年、私たちは 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” をご確認ください。

原文

Kubernetes 対応 Docker for Mac および Windows

今日、Docker プラットフォームにおける Kubernetes サポートに対する取り組みの1つとして、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 でも提供していきます。

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

原文



概要

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を実行可能なシステムおよびネットワーク基盤)の自動デプロイに対して、瞬く間に頼りになるツールとなりました。プロダクション(本番環境)の鏡となる開発インフラの構築を、1つのワークフローで作成することが 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 は、これら両者のプロセスを1つのコマンドで行えるように変えたのです。

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

コミュニティとチーム

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

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

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

原文



概要

先日の 【参考訳】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.examplemodule.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” 概要

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

HashiCorp Terraform 0.10

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

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

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

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

Terraform コア(Core)と Terraform プロバイダを分割

terraform 0.10 では、プロジェクトを2つの論理コンポーネントに分割しました。それが 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 の2つのプロバイダを使う設定を考えましょう。

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

provider fastly {
  api_key = "exampleapikey"
}

こちらには2つのプロバイダ・ブロックを宣言し、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 (状態)ファイルに名前空間を使うことで、1つのフォルダ内で複数の明確なインフラ・リソースを管理する設定が可能にしました。初リリース以降、コミュニティからは用語が混乱を招くとの指摘を受けました。 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 をダウンロード して、試してみましょう!

原文



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 ConsulHashiCorp 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.02.1.1 に対応しています。

原文



“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;更新方針)のうち1つを指定します。また、ジョブの詳細として、 update 区間で注釈を追加することもできます。以下の例は Nomad でジョブを更新する例です。時間と条件を2つ割り当ててており、ロールアウト(ジョブの展開)をする前に、少なくとも 30 秒は正常(healthy)である条件を指定しています。

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

  update {
    # 同時に2つを並列更新
    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 はローリング・アップデートを行います。ローリング・アップデートとは、新しい2つの api-server:0.2 の割り当て(allocation)にあたり、1つが 30 秒は正常(healthy)になるまで待った後、新しく割り当てるものです。このヘルスチェックによる割り当てに失敗しますと、Nomad はデプロイが失敗したと印を付け(マークし)ます。 auto_revert (自動修復)がセットされていれば、全てのジョブが正常に割り当てられるまで、直近のジョブにロールバックします。

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

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

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

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

$ nomad job promote api-server

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

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

動的な環境変数(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 の 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 には2つのポスト・プロセッサ(post-processor)、つまり atlasvagrant-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 までメールをお送りください。

原文



概要

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

  • swarm モードで Compose ファイルのサポート(新しい docker stack deploy コマンド )、Compose v3 フォーマット追加
  • docker コマンドラインの後方互換性に対応
  • docker system df の容量表示と、 docker system prune による不要なデータ削除コマンド
  • CLI の再編成(今のコマンドは維持するものの、 docker container xxxdocker image history の利用が可能に)
  • docker service logs でサービス全てのログを取得、Prometheus スタイルのエンドポイント
  • 構築時に --squash オプションを指定すると1つのレイヤを作成(オーバヘッドとなる可能性あり)、圧縮オプションのサポート
  • 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 は2つの便利なコマンドを導入しています。Docker がどれだけディスク容量を使用しているのか調べるものと、使っていないデータを削除するために役立つものです。

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

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

CLI の再開発(restructured)

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

Docker 1.13 では論理的な目的の下に全てのコマンドがおさまるようにコマンドを再編成しました。たとえばコンテナの list (一覧)と start (起動)は新しいサブコマンド docker container で利用可能となり、 historydocker 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 は構築時に作成した全てのファイルシステム・レイヤを取得し、それを1つの新しいレイヤに押し込み(スカッシュし)ます。これにより最小のコンテナ・イメージ作成に関わる手間を簡単にします。一方、イメージが移り変わる場合は(スカッシュされたレイヤはイメージ間で共有されなくなるため)、極めて大きなオーバヘッドとなる可能性があります。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 MacWindows で始めましょう。

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

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

原文



概要

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

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

利用とリソース

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

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

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

原文

関連