Docker 17.06およびKubernetes 1.7：主要な革新

先週、コンテナのオープンソースの世界から2つの「おいしい」リリースが提供されました。Docker（バージョン17.06）とKubernetes（バージョン1.7）はほぼ同時に更新されました。 彼らはどのような機会をもたらしましたか？ この記事では、これらのリリースの発表およびリリースノートからの情報を、主要な変更点の一部について少し説明しながら提供します。

Docker CE 17.06

6月28日に、 Docker CE（Community Edition）が6月17日に発表され、Mobyプロジェクトで構築されたコンテナシステムの最初のリリースが4月に発表されました。 Mobyについてはすでに説明しました 。

いくつかの段階での組み立て

このリリースの主な機能は、Docker 05.17.0で初めて導入されたマルチステージビルド（マルチステージビルド）のサポートの公式な安定化でした。 その本質は、1つのDockerfileでイメージアセンブリのいくつかの段階を記述できるため、不要な中間データが最終イメージに含まれないようにすることにあります。 Dockerで明らかな例：Java開発者は通常、アプリケーションをコンパイルするためにApache Mavenを使用しますが、これらのアプリケーションを実行するための最終コンテナー（イメージ）にはMavenは必要ありません。 これで、Maven自体が中間イメージ（アセンブリ用）で使用され、最終（起動用）にならないようにDockerfileを配置できます。

以下に、 単純な Java Spring Boot アプリケーションの DockerfileオプションをDockerfileます。

FROM node:latest AS storefront
WORKDIR /usr/src/atsea/app/react-app
COPY react-app/package.json .
RUN npm install
COPY . /usr/src/atsea/app
RUN npm run build

FROM maven:latest AS appserver
WORKDIR /usr/src/atsea
COPY pom.xml .
RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
COPY . .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests

FROM java:8-jdk-alpine
WORKDIR /static
COPY --from=storefront /usr/src/atsea/app/react-app/build/ .
WORKDIR /app
COPY --from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .
ENTRYPOINT ["java", "-jar", "/app/AtSea-0.0.1-SNAPSHOT.jar"]
CMD ["--spring.profiles.active=postgres"]

ご覧のとおり、ここの2つの準備段階ではNode.jsとApache Mavenを使用してアプリケーションをビルドしていますが、結果のイメージはコンパクトで、Node.jsもMavenもありません。

注 ：これまで、当社では、これらの目的のために、独自のオープンソースユーティリティdappでアーティファクトと呼ばれる機能を使用していました （ 概要はこちらをご覧ください ）。

ログとメトリック

プラグインでDockerメトリックを使用できるようになりました。 デモンストレーションのために、使用可能なメトリックのリクエストをプロキシするプラグインの例を示します。

 $ docker plugin install --grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest $ curl http://127.0.0.1:19393/metrics 

しかし、これは単なるデモンストレーションであり、このイノベーションの本当の目的は、プラグインの助けを借りて収集されたメトリックを外部サービスに送信するか、別のサービス（たとえば、Prometheus）によるアセンブリに利用できるようにすることです。

プラグインはログにも使用できるようになり（つまり、ロギングドライバーの実装）、すべてのロギングドライバーのリストがdocker info追加されました。 さらに、Docker docker service logs実装（前回のリリース05.17からも）個別のタスクログ（ /task/{id}/logs RESTの/task/{id}/logs ）も表示できますが、EdgeブランチからStableに移動され、一般的なログを簡単に取得できるようになりましたSwarmで実行されているすべてのサービス。

ネットワーク

ノード（ノードローカル）内のネットワークにサービスをバインドすることが可能になりました：ホスト、Macvlan、IPVlan、ブリッジ、ローカルスコープ。 Macvlanが提供する例は、作業ノードでホスト固有のネットワーク構成を作成し、それらを使用する管理ノードでネットワークを作成することです。

 [Wrk-node1]$ docker network create --config-only --subnet=10.1.0.0/16 local-config [Wrk-node2]$ docker network create --config-only --subnet=10.2.0.0/16 local-config [Mgr-node2]$ docker network create --scope=swarm --config-from=local-config -d macvlan mynet [Mgr-node2]$ docker service create --network=mynet my_new_service 

同じ変更の一環として、 DOCKER-USERチェーンがiptablesに追加されました。これは最初にFORWARD挿入され、リセットされません（この追加についてはertaquoに感謝します ） 。

さらに、操作のロジックを改善するために、サービスディスカバリの内部アルゴリズムに変更が加えられました。

群れ

いくつかのイノベーションがSwarmモードを受け取りました。特に：

• 構成オブジェクト（構成オブジェクト）を使用すると、構成情報を安全に送信できるようになります。
  
  

   $ echo "This is a config" | docker config create test_config - $ docker service create --name=my-srv --config=test_config … $ docker exec -it 37d7cfdff6d5 cat test_config This is a config 

  
  
• コンテナオーケストレーションシステムの安全な展開に使用される公開キー基盤（PKI）システムのCA証明書ローテーション機能（ docker swarm ca --rotate ）;
• サービス、ノード、ネットワーク、シークレットのリアルタイムデータを受信するためのイベントサポート（以前はSwarmの外部で利用可能）。
• 新しいフラグ--datapath-addr docker swarm init --datapath-addrは、アプリケーションデータ（データトラフィック）から制御トラフィックタスクを分離するためのネットワークインターフェイスを示します-入出力の負荷が大きいアプリケーションの場合に役立ちます。
• コンテナ内のシークレットの場所を指定する機能（従来の/var/run代わりに）。

Docker 17.06での変更のより詳細なログとコミットへのリンクは、 Docker CEリリースノートに記載されています 。 また、ファンが視聴できるように、 8分間のビデオでストーリーと主な革新のデモンストレーションを紹介しています。

Kubernetes 1.7

6月29日にKubernetes 1.7が発表されました。その主な革新は、セキュリティの改善、ステートフルアプリケーションのサポート、プラットフォームの拡張性と呼ばれています。 この背後には何がありますか？

安全性

• 安定したネットワークポリシーAPIを宣言し、ポッド間の相互作用を定義（および制限）するルールを構成できます。
• Node authorizer 。これにより、kubelet APIリクエストを（ノードのシークレット、送信、その他のオブジェクトに）制限できます。
• etcdに保存されている秘密およびその他のリソースの暗号化のアルファ版。
• kubelet TLSブートストラップでのクライアントおよびサーバー証明書のローテーションのサポートが追加されました。
• APIサーバーによって保存される監査ログは、イベントとWebブックのフィルタリングのサポートにより、システムの監査用により多くのデータを提供することで、よりカスタマイズ可能で拡張可能になりました。

ステートフルアプリケーションのサポート

• ステートフルアプリケーションの展開に使用されるStatefulSet 自動更新機能のベータ版。 更新戦略はspec.updateStrategyフィールドによって定義され、現在はOnDeleteとRollingUpdate 2つの値をサポートしています。
• StatefulSetsでのサポートにより、厳密な順序付けを必要としないアプリケーションの迅速なスケーリングと起動が可能になりました。現在はPod Management Policyで構成されています。 このようなアプリケーションは、特定のステータス（実行中、準備完了）を待たずに並行して実行できるようになりました。
• ローカルストレージのアルファバージョン： StatefulSets内のStorageClasses StatefulSets 、標準のPVC / PVインターフェイスを介してローカルストレージにアクセスできるようになりました。
• DaemonSets更新によるスマートロールバック （および改訂履歴）。
• （ローカルまたはストレージノードに接続された）クラスター全体で永続的な高可用性ストレージボリュームを実装する新しいStorageOSボリュームプラグイン。

拡張性

• API集約により、ネイティブAPIを使用してKubernetes機能を拡張できます。 集約レイヤーはkube-apiserverと連携し、API拡張を登録するためのリソースが登録されるまで何もしません。 API登録は、Kubernetesクラスターで実行されている炉内のextension-apiserverを介して実装されるAPIServiceオブジェクトを介して実行されます。
• コンテナーメトリックを取得するために、新しいRPC呼び出しがContainer Runtime Interface（CRI）に追加されました。 囲炉裏とイメージ管理の基本的なライフサイクルをサポートするcontainerdとの統合のアルファ版が追加されました。

その他

• 外部Dynamic Admission Controllerのアルファバージョンのサポートにより、オブジェクトを変更するときにビジネスロジックをAPIサーバーに追加できます。
• ポリシーベースのフェデレーションリソース配置のアルファバージョン。これにより、フェデレーションリソースに関するポリシーベースの決定を定義できます（たとえば、価格やパフォーマンスの要件に基づいて外部ポリシーエンジンを使用）。
• サードパーティリソース（TPR）は、カスタムリソース定義（CRD）に置き換えられました。CRDは、「より明確なAPI」を提供し、TPRベータ中に修正された多くの問題を解決します。 Kubernetes 1.8では完全なTPRが削除されます（ 移行ガイドが利用可能）。