Docker Registry HTTP API V2仕様が、コンテナ化業界を促進する標準を提供するLinux Foundation傘下の組織であるOpen Container Initiative(OCI)に採用されることを発表できることを嬉しく思います。 Dockerチームは、テクノロジースタックの別の側面が事実上の標準になることを誇りに思っています。 イメージ・フォーマットで行ったように、OCIコミュニティの一部としてコンテナ・エコシステムと正式に共有およびコラボレーションできることを嬉しく思います。 当社の流通プロトコルは、市場に出回っているすべてのコンテナレジストリの基盤であり、コンテナコンテンツが世界中に配布されるため、2週間ごとに10億回以上活用されるほど堅牢です。
このプロトコルは何をしますか?
プロトコルを視野に入れると、Dockerのコア機能の一部は、イメージをプッシュおよびプルする機能です。 最初の「こんにちは、世界」の瞬間から、この概念はすべてのユーザーに導入され、Dockerエクスペリエンスの大部分を占めています。 私たちは通常、肘掛け椅子に座ってこの魔法のような出来事に驚嘆しますが、その単純な機能に費やされた設計と配慮の量は簡単に見落とされる可能性があります。
Dockerが最初にリリースされたとき、チームは すぐにプロトコルとイメージレジストリ の実装をまとめ、魔法が本当に始まりました。 イメージ レジストリは 、マシン間でイメージを格納するための共通サービスを提供します。 これにより、あるマシンでイメージをビルドし、同じイメージをプルダウンして他のマシンで実行できます。ソフトウェアディストリビューション全体をプルダウンして、指先で実行できるようになりました。 この実装は Docker Hub を強化し、最終的には https://github.com/docker/docker-registry としてオープンソース化されました。 このプロトコルとその背後にある実装は 、最終的にV1プロトコルとして知られるようになりました。多くの画像がプッシュされたり引っ張られたりして、開発者は喜びました。
進化
イメージのプッシュとプルは時代を超えて続きましたが、ユーザーが他のレジストリでDockerを使用し始めると、V1プロトコルに問題が発生しました。 問題の中心的なテーマは、レジストリ間で共有される ID の概念と、Docker 実装との緊密な結合に関するものでした。 問題は、単一の Docker Engine が2つの別々のレジストリからイメージをプルする場合、どのイメージがどの識別子を持つかについて意見が一致しない可能性があることでした。 複数のレジストリを使用してもユーザーに問題が発生しないようにするために、何かを変更する必要がありました。
2014年の終わりに向けて、Dockerは最初のAPI構造を備えた 提案 の導入により、これらの問題への対処を開始しました。 この設計の鍵となったのは、レジストリがイメージの共通の識別子を持つことを可能にする コンテンツアドレス指定可能な イメージと、イメージ形式の内部の詳細をDockerエンジンから切り離して、独自に進化させることでした。コミュニティが集まり、その提案に関する140のコメントを作成し、仕様と実装に組み込まれました。 この取り組みの結果、2015 年春に Docker 1.6 で GA をサポートする Docker レジストリ 2.0 がリリースされました。 それ以来、Dockerコミュニティは、 ユーザーの高まるニーズを満たすために進化してきました。
今後の展開
Dockerの人気の結果として、このプロトコルは業界全体で広く採用されるようになりました。 さまざまな環境で戦闘テストされています。 このプロトコルは、 Docker Enterprise Edition で利用可能な署名や検証などの補完的なテクノロジとうまく統合されます。 この 仕様 をOCIに寄付することで、コンテナ・エクスペリエンスのこの重要な部分が公式のOCI標準になることを保証できます。 Open Container Initiative では、以前、コンテナー ランタイムで使用される ランタイム 仕様と イメージ仕様 が導入されました。配布仕様 の提案が受け入れられると、コンテナを使用する上で重要な部分であったプロトコルがOCIの一部として繁栄します。