Docker Hub 上の公式リポジトリ¶

公式リポジトリを使うべきですか？¶

新しい Docker ユーザにとって、各プロジェクトの公式リポジトリは励みになります。これらのリポジトリには、明確なドキュメントがあり、ベスト・プラクティスを提供し、そして、一般的な利用例のために設計されています。高度なユーザにとっては公式リポジトリにある Dockerfile が学習プロセスにおいて役立つでしょう。

公式リポジトリからの分岐は、一般的にイメージ容量の最適化が求められます。例えば、多くのプログラミング言語か重ねられたイメージで、モジュールのインストールをサポートしているツールチェーンを構築するのは、コードの最適化に依存します。高度なユーザであれば、コンパイル済みの必要なライブラリのみのイメージを構築することで、容量を節約できます。

python と ruby のように、いくつかの言語スタックは -slim タグを持っており、これら最適化のために異なった形で設計されています。「slim」派生だけでは不十分なため、公式リポジトリをベースとした OS イメージからの継承を推奨します。これはメンテナンスの継続を重複して行うよりも効果的だからです。

私が改良できますか？¶

公式リポジトリには、ドキュメントには User Feedback （ユーザ・フィードバック）セクションがあり、対象のリポジトリに関する詳細を扱います。多くの場合、GitHub リポジトリには公式リポジトリの Dockerfile が含まれています。また、issue トラッカーも利用できます。一般的なフィードバックとサポートの質問は、Freenode IRC 上の #docker-library で直接行うべきです。

私が新しい公式リポジトリを作成できますか？¶

上位の手法としては、GitHub におけるプルリクエストの提案によって、公式リポジトリが動き出します。以下の GitHub リポジトリで詳細や提案に必要なものが確認できます。

• docker-library/official-images
• docker-library/docs

公式リポジトリ・チームは、コミュニティのコントリビュータの助けにより、作者に対して提案やフィードバックを公式に提供します。この初期レビュー・プロセスには、提案が承認されるまでに行ったり来たりすることがあります。

また、レビューのプロセス中では主観的な判断も含まれます。主観的な事項は、基本的な質問で煮詰めます「このイメージは一般的に使いやすいだろうか？」　たとえば python 公式リポジトリでは、大きな Python 開発コミュニティにとって「一般的に使いやすいか」です。これが先週 Python で書かれた無名のアドベンチャー・ゲームだとしてもです。

新しい提案が承認されると、作者はイメージの更新やユーザのフィードバック対応の継続に対する責任があります。公式リポジトリ・チームはイメージの配布と Docker Hub 上のドキュメントに対する責任があります。公式リポジトリの更新にあたり、複数のプルリクエストはレビューの少ないプロセスを辿ることもあるでしょう。公式リポジトリチームは、全ての変更に対して最終的に対応する門番です。公式リポジトリチームが、品質に対するリスクやセキュリティ問題が発生しないよう助力します。