[和訳] containerd、BuildKitとDocker Engineの永続的な価値についての考察 #docker #kubernetes #k8s
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本稿は Containerd, BuildKit and a Reflection about the Enduring Value of Docker Engine (2018/6/29) の和訳です。
2週間前に4年間で8回目のDockerConを開催いたしました。コミュニティのコントリビューター、開発者、ITユーザー、企業、およびエコシステムパートナーは、Docker社創業者Solomon Hykesによる「ソフトウェアコンテナの利用を民主化する」という単純な前提に基づいて、数百万人に急激に増加しました。発足当初から今日に至るまで、Docker社はシンプルなツールを開発し、コンテナ内にすべてのアプリケーションの依存関係を束ねるユニバーサルなパッケージングを行うというアプローチを取ってきました。Docker Engineによって、アプリケーションを任意のインフラストラクチャ上のどこでも一貫して実行できるようになり、開発者や運用チームの「依存地獄」を解決し、「自分のラップトップでは動いたのに!」という問題を排除できるようになりました。
過去2年間でDocker Engineのコードベースは、再利用可能な複数のコンポーネントへとリファクタリングしました。それらのコンポーネントの例として、コアコンテナランタイムである最も重要なcontainerd、そしてイメージをビルドするためのDocker Engineの一部だったBuildKitがあります。DockerConのコントリビュートとコラボレーションのトラックでは、Michael CrosbyとTonis Tiigliがこれらの2つのプロジェクトのアップデートを発表しました(ビデオ、スライド)。
Docker Engineのコアコンテナランタイムであるcontainerdは、数百万人のユーザーが活用しており、数万の組織が本番環境で運用しています。18か月前、Docker社はDocker Engineからcontainerdを取り出し、Cloud Native Computing Foundation (CNCF)に寄贈しました。そしてKubernetes、gRPC、Prometheusとの強力な連携により、トップレベルプロジェクトとなりました。Docker社は、Alibaba、AWS、Google、IBM、Microsofの5大クラウドプロバイダと協力して、オンプレミス、すべてのクラウド上や、Linux、Window、メインフレームを横断して動作するソリューションを提供するという目標を掲げて、containerdの寄贈を行いました。
Docker社の寄贈の目的の1つは、他のコンテナシステムベンダーとKubernetesやDC/OSのようなオーケストレーションプロジェクトが活用できるコアコンテナランタイムを提供することにより、コンテナのエコシステムにおけるさらなるイノベーションを促進することでした。containerdの重要な設計方針は、排他的な縛りなしに、Kubernetesのために第一級のサポートを提供することです。なぜなら、コアコンテナランタイムをKubernetes用に固定してしまうと、その使用事例がKubernetesに限定し、コンテナによる多くのユースケース、たとえば開発者のデスクトップ、CI/CD、シングルノードデプロイメント、最先端事例およびIoTが置き去りになってしまうおそれがあったからです。
4月に発表したcontainerd 1.1は、Kubernetes Container Runtime Interface（CRI）を実装しているため、KubernetesとDocker Engineから直接使用できます。異なるコンテナシステム(Docker EngineやDC/OSなど)のクライアントで、論理的に分離しているひとつのシステム上で単一のcontainerdインスタンスを活用できるように、ネームスペースを実装しています。このリリースでは、Kataコンテナ、gVisorなどのOCI準拠のランタイムを組み込むことができます。Pod起動時のレイテンシやCRIプラグインのCPU/メモリ使用量の大幅な改善など、多くのパフォーマンスを改善しています。さらなるパフォーマンス向上のために、GraphDriverをより効率的なスナップショット取得機能で置き換えました。BuildKitはより高速なビルドのためにこれを活用します。CRIに取り組んでいるKubernetesコミュニティメンバーは、5月下旬にKubernetesのcontainerd 1.1を一般公開しました。
Michaelの講演では、containerd 1.1のスマートクライアント機能の概要を説明しました。クライアント側からのI/Oリダイレクト、複数のクライアント（Kubernetes、Docker Engine、その他のシステム）から論理的に分離した単一のランタイムインスタンスを活用するためのcontainerdネームスペース、（Brendan Burn氏のMetaparticleプロジェクトからインスピレーションを受けた)containerd Goクライアントライブラリを使用している場合のGolang形式でのコンテナなどです。
Tonisの講演では、BuildKitによるすべてのパフォーマンスの改善と、モジュラーアーキテクチャのために公開した機能について説明しました。新しいビルドシステムを作成するオープンソース開発者は、BuildKitを直接使用して新しいフロントエンド（Dockerfilesを超えて）とバックエンド（Dockerイメージを超えて）を作成できます。
BuildKitは実験的機能として、Docker 18.06に組み込む予定です。この新しい実験的機能は、Dockerfileの拡張性をもたらします。開発者は新しい#syntaxディレクティブを使用してDockerfileをパースする独自拡張を作成できます。例: #syntax = registry/user/repo:tag
彼らが提供するコンテナイメージは、Dockerfileの新しい構文をどのように解釈するかを知っています。Tonisが紹介したひとつの例は、RUN -mountを理解し、ビルド時にMavenリポジトリキャッシュなどのボリュームをマウントできる拡張機能です。ビルドに最大33倍のパフォーマンス向上をもたらします。これは、Dockerビルドに対する最も人気の機能リクエストのひとつでした。
containerdとBuildKitは両方とも、実行時とビルド時の、コンテナで可能なことを一括りにして後押ししています。Docker Engineに組み込むという事実は、開発者はワークフローを変更することなく、このコンポーネントプロジェクトの新機能を利用できるようになることを示しています。Docker Desktopのラップトップ、本番環境のKubernetesクラスタ、コンテナで従来のアプリケーションをモダナイズしたメインフレーム、IoT シナリオ用のRaspberry Piデバイス等、いずれの場合においてでもです。開発者と運用者は、どのシステムを使用しているかに関係なく、Docker Engineが提供する アプリケーションワークフローの移植性 を活用し、あらゆる場所で同一の信頼できるコードベースを使用してコンテナの構築および実行ができます。
もちろん、これらの2つの分野では、特定のニッチな分野に対応したコンテナの構築や運用に関する多くのオープンソースプロジェクトがあります。例えば、コンテナのVM型分離を提供するKataのようなランタイム、KubernetesのOCIコンテナを実行するCRIO、とくにRHELのOpenShift、KubernetesのイメージをビルドするKanikoのようなビルダー、Javaアプリケーションのイメージをビルドするためのjib、またはbuildahなどです。しかし、Docker Engineに組み込んだcontainerdとBuildKitを使用すれば、開発者と運用者がよく知っているポータブルアプリケーションのワークフローに統合し、あらゆるタイプのユースケース（単一のサーバー、統合されたランタイム、CI/CD、 IoTなど）で使用できる、より優れたパフォーマンスと構成性を備えた次世代のランタイムとビルダーコンポーネントを手に入れることができます。
要約すると、すべてのオーケストレータ（Kubernetes、Swarm、AWS ECSなど）、Linuxディストリビューション、Windowsおよびメインフレーム、オンプレミス、x86、ARM、GPU上で動作する任意のクラウドで動作するたったひとつのコアコンテナランタイムが必要な場合の唯一のソリューションは、containerdです。さらに、containerd用に最適化したイメージビルドソリューションのさらなる価値を得たいなら、Docker Engineに組み込んだBuildKitが最適なソリューションです。
DockerCon San Francisco 2018で閲覧可能なオンデマンドセッションを利用してDockerとの繋がりを維持してください:
もっと知りたい方は:
