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 上のドキュメントに対する責任があります。公式レポジトリの更新にあたり、複数のプルリクエストはレビューの少ないプロセスを辿ることもあるでしょう。公式レポジトリチームは、全ての変更に対して最終的に対応する門番です。公式レポジトリチームが、品質に対するリスクやセキュリティ問題が発生しないよう助力します。