LEGO®製品をよく見ると、すべて同じビルディングブロックでできていることがわかります。ただし、これらのブロックの構成は、城を建設するのか宇宙船を建設するのかを区別する重要な要素です。 Podmanと、その兄弟プロジェクトであるBuildah、Skopeo、CRI-Oについてもほぼ同じです。ただし、再生プラスチックの代わりに、コンテナツールの構成要素はオープンソースコードで作られています。これらのビルディングブロックを共有することで、堅固なエンタープライズグレードのコンテナツールを提供できます。機能はより早く出荷され、バグはより早く修正され、コードはバトルテストされています。そして、まあ、プレイルームに喜びをもたらす代わりに、コンテナツールはデータセンターやワークステーションに喜びをもたらします。
コンテナツールの最も基本的な構成要素は、コンテナとコンテナイメージをローカルに保存および管理するコンテナ/ストレージライブラリです。 1つ上のレベルに進むと、コンテナ/イメージライブラリが見つかります。名前が示すように、このライブラリはコンテナイメージを処理し、非常に強力です。これにより、画像のプルとプッシュ、画像の操作（レイヤー圧縮の変更など）、構成とレイヤーとともに画像の検査、いわゆる画像トランスポート間での画像のコピーが可能になります。トランスポートは、ローカルコンテナストレージ、コンテナレジストリ、tarアーカイブなどを参照できます。 Dan Walshは、私が読むことを強くお勧めするさまざまなトランスポートに関するすばらしいブログ投稿を書きました。
イメージライブラリは、間違いなく repositorys.confであるいくつかの構成ファイルもサポートしています。 大多数のユーザーにとって最も重要なものです。このブログ投稿をregistries.confに捧げたい 構成ファイル、そのさまざまなオプションとノブ、およびそれらを本番環境で使用する方法を説明します。
registries.confを使用したコンテナレジストリの管理
repositorys.conf 画像をプッシュまたはプルするたびに構成が機能します。または、より一般的に言えば、コンテナレジストリに連絡するときはいつでも。これは簡単な経験則です。システム全体の場所は/etc/containers/registries.confです。 、ただし、1人のユーザーに対してこれを変更する場合は、 $ HOME / .config / container / registerries.confに新しいファイルを作成できます。 。
それでは、それに飛び込みましょう。次のセクションでは、 repositorys.confのさまざまな構成オプションを説明するいくつかの例を紹介します。 。例は実際のシナリオであり、個々のユースケースに取り組むためのインスピレーションの源となる可能性があります。
短い名前で引っ張る
人間は怠け者であり、私も例外ではありません。 podman pull ubi8を実行する方がはるかに便利です podmanpullregistry.access.redhat.com/ubi8:latestではなく 。どのイメージがどのレジストリにあるのかを忘れ続けています。そこにはたくさんのイメージとたくさんのレジストリがあります。 Docker HubとQuay.ioに加えて、Amazon、Microsoft、Google、Red Hat、およびその他の多くのLinuxディストリビューションのレジストリがあります。
Dockerは、常にDocker Hubに解決することで、私たちの怠惰に対処しました。 docker pull alpine docker.io / library / alpine：latestに解決されます 、および docker pull repo / image：tag docker.io / repo / image：tagに解決されます （指定されたリポジトリに注意してください）。 Podmanとその兄弟プロジェクトは、ユーザーが1つのレジストリのみを使用するようにロックすることを望まなかったため、短い名前はdocker.io以上に解決できます。ご想像のとおり、これは repositorys.conf> 次のように：
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
上記のスニペットは、 repositorys.confから直接取得したものです。 これは、短い名前のイメージをプルするときに指定された順序で接続されるレジストリのリストです。最初のレジストリでイメージが見つからない場合、Podmanは2番目のレジストリからプルしようとします。 BuildahとCRI-Oは同じロジックに従いますが、Skopeoは常にdocker.ioに正規化されることに注意してください。
[次のこともお勧めします：コンテナ化する予定の次のLinuxワークロードは何ですか？ ]
画像の検索
プルに関する前のセクションと同様に、画像は通常、名前で検索されます。 podman検索を実行する場合 、私は通常、特定のイメージがどのレジストリに存在するかを知らないか、単に忘れています。 Dockerを使用する場合、DockerHubでのみ検索できます。 Podmanはユーザーにより多くの自由を与え、任意のレジストリで画像を検索できるようにします。そして当然のことながら、 registerries.conf 解決策があります。
プルと同様に、 unqualified-search-registries podman searchで短い名前を使用する場合にも使用されます 。 podman search foo fooという名前の画像を検索します すべての非適格検索レジストリで。
大企業は通常、オンプレミスのコンテナレジストリを持っています。このようなレジストリをワークフローに統合するのは、修飾されていない検索レジストリのリストに追加するのと同じくらい簡単です。
短い名前のエイリアス
Podman、Buildah、およびCRI-Oの新しいバージョンには、主にエイリアスを使用して短い名前を解決する新しい方法が付属しています。エイリアスは単純なTOMLテーブル[aliases] "name" ="value"の形式で 、Bashエイリアスの動作と同様です。 github.com/containers/shortnames で、上流のコミュニティとともにエイリアスの中央リストを維持しています。 。画像を所有していてエイリアスが必要な場合は、プルリクエストを開くか、お気軽にお問い合わせください。
RHEL8などの一部のディストリビューションでは、ユーザーが誤って間違ったレジストリから画像を取得するのを防ぐために、独自の短い名前のリストを出荷する予定です。
短い名前のエイリアスがどのように機能するかを詳細に説明すると、このブログ投稿が大幅に拡張されるため、興味がある場合は、短い名前のエイリアスに関する以前のブログ投稿を参照してください。
ローカルコンテナレジストリの構成
ローカルコンテナレジストリの実行は非常に一般的です。私は常に1つを実行しているので、画像をキャッシュし、Podmanの自動更新などの新機能を開発およびテストできます。ホームオフィスの帯域幅は限られているので、高速プッシュとプルに感謝しています。すべてがローカルで実行されているため、レジストリのTLSの設定について心配する必要はありません。これは、HTTPSではなくHTTPを介してレジストリに接続することを意味します。 Podmanでは、-tls-verify =falseを指定することでこれを行うことができます コマンドラインで、TLS検証をスキップし、安全でない接続を許可します。
コマンドラインを介してTLS検証をスキップする別の方法は、 repositorys.confを使用することです。 。これは、特にコマンドラインフラグを手動で追加したくない自動スクリプトの場合に便利です。以下の設定スニペットを見てみましょう。
[[registry]]
location="localhost:5000"
insecure=true
registries.confの形式はTOMLです。 [[registry]]の二重中括弧 [registry] のリスト（またはテーブル）を指定できることを示します オブジェクト。この例では、場所（つまり、そのアドレス）が localhost：5000に設定されているレジストリは1つだけです。 。ここで、ローカルレジストリが一般的に実行されています。 container / image ライブラリはその場所のコンテナレジストリに接続し、その構成を検索してそれに応じて動作します。この場合、レジストリは安全でないように構成されており、TLS検証はスキップされます。 Podmanおよびその他のコンテナツールは、接続を拒否せずにローカルレジストリと通信できるようになりました。
レジストリ、名前空間、またはイメージをブロックする
ユーザーまたはツールが特定のレジストリからプルされないようにする場合は、次のようにすることができます。
[[registry]]
location="registry.example.org"
blocked=true
blocked =true このレジストリへの接続、または少なくともレジストリからのデータのプルをブロックするための接続を防止します。
ただし、驚くべきことに、レジストリ全体ではなく、特定の名前空間または個々のイメージのみをブロックすることがユーザー間で一般的です。ユーザーが名前空間registry.example.org/namespaceから画像をプルするのを阻止したいとします。 。 repositorys.conf これで次のようになります：
[[registry]]]
location="registry.example.org"
prefix="registry.example.org/example"
blocked=true
新しい設定ノブを導入しました： prefix 。プレフィックスは、特定のプレフィックスと一致するイメージをプルしようとしたときに、指定された構成のみを選択するように指示します。たとえば、 podman pull Registry.example.org/example/image:latestを実行する場合 、指定されたプレフィックスが一致し、Podmanが画像をプルするのをブロックされます。特定の画像をブロックする場合は、次の方法で設定できます。
prefix="registry.example.org/namespace/image"
プレフィックスの使用は、あらゆる種類のユースケースに対応するための非常に強力なツールです。 [registry]のすべてのノブと組み合わせることができます 。プレフィックスの使用はオプションであることに注意してください。何も指定されていない場合、プレフィックスはデフォルトで（必須の）場所になります。
レジストリのミラーリング
エアギャップ環境でワークロードを実行していると仮定しましょう。すべてのサーバーがインターネットから切断されています。それには多くの理由があります。エッジで実行している場合や、インターネットへの接続を禁止するセキュリティに敏感な環境で実行している場合があります。この場合、元のレジストリに接続することはできませんが、ローカルネットワークのコンテンツをミラーリングするレジストリを実行する必要があります。
レジストリミラーは、元のミラーからプルしようとする前に接続されるレジストリです。これは一般的なユースケースであり、コンテナエコシステムで最も古い機能リクエストの1つです。
[[registry]]
location="registry.access.redhat.com"
[[registry.mirror]]
location="internal.registry.mirror"
この構成では、 podman pull ubi8を介してユニバーサルベースイメージをプルする場合 、画像はRedHatのコンテナレジストリではなくミラーからプルされます。
指定された順序で接続される複数のミラーを指定できることに注意してください。それが何を意味するのかを簡単に見てみましょう：
[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"
[[registry.mirror]]
location="mirror-3.com"
画像をプルしようとしていると仮定しましょうregistry.example.com/myimage:latest 。ミラーは指定された順序（つまり、トップダウン）で接続されます。つまり、Podmanは最初に mirror-1.comからイメージをプルしようとします。 。画像が存在しない場合、または他の理由でプルが失敗した場合、Podmanは mirror-2.comに連絡します などなど。すべてのミラープルが失敗した場合、Podmanはメインの registerry.example.comに連絡します 。
ミラーはinsecureもサポートしていることに注意してください つまみ。特定のミラーのTLS検証をスキップする場合は、 insecure =trueを追加するだけです。 。
参照の再マッピング
上記で説明したように、 prefix 特定の[registry]を選択するために使用されます registerries.confにあります 。プレフィックスは、特定の名前空間または特定のイメージがプルされるのをブロックする強力な手段ですが、イメージ全体を再マップするためにも使用できます。ミラーと同様に、プレフィックスを使用して、別のレジストリと別の名前空間からプルできます。
再マッピングの意味を説明するため 、エアギャップ環境で実行していると考えてみましょう。インターネットから切断されているため、コンテナレジストリにアクセスできません。私たちのワークロードは、Quay.io、Docker Hub、およびRedHatのコンテナーレジストリからのイメージを使用しています。レジストリごとに1つのネットワークローカルミラーを使用できますが、次の構成で1つだけ使用することもできます。
[[registry]]
prefix="quay.io"
location="internal.registry.mirror/quay"
[[registry]]
prefix="docker.io"
location="internal.registry.mirror/docker"
[[registry]]
prefix="registry.access.redhat.com"
location="internal.registry.mirror/redhat"
podman pull quay.io/buildah/stable:latest 代わりにinternal.registry.mirror/quay/buildah/stable:latestをプルします 。ただし、プルされたイメージは quady.io/buildah/stable:latestのままになります 再マッピングとミラーリングはPodmanやその他のコンテナツールに対して透過的に行われるためです。
上記のスニペットでわかるように、 internal.registry.mirror は、Quay.io、Docker Hub、およびRedHatのコンテナレジストリに代わってイメージをプルするために使用しているネットワークローカルミラーです。各レジストリのイメージは、レジストリの個別の名前空間（つまり、「quay」、「docker」、「redhat」）に存在します。これは、プル時にイメージを再マップするためのシンプルで強力なトリックです。 3つのレジストリからの画像を内部ミラーに事前入力する方法を自問してみてください。手動で行うことはお勧めしませんが、 skopeo syncを使用することをお勧めします 代わりは。 skopeo syncを使用 、システム管理者は、すべてのイメージをUSBドライブに簡単にロードし、それをエアギャップクラスターに取り込み、ミラーをプリロードできます。
このような再マッピングが役立つ可能性のあるユースケースは無数にあります。たとえば、テスト中に別のレジストリを使用する場合、本番環境よりも別の（テストまたはステージング）レジストリから透過的にプルする方が便利な場合があります。コードを変更する必要はありません。
TomSweeneyとEdSantiagoは、再マッピングを使用して、DockerHubのレート制限に対処するためのクリエイティブなソリューションを開発しました。 2020年11月下旬に、DockerHubは特定の時間枠でのユーザーあたりのプル数の制限を開始しました。最初は、テストシステムの大部分と継続的インテグレーションでDockerHubイメージが使用されていたために懸念がありました。しかし、 repositorys.confに簡単な変更を加えるだけです 私たちのシステムでは、トムとエドは素晴らしい解決策を見つけました。これにより、テストでdocker.ioを参照するすべての画像を変更するという手作業で面倒な作業から解放されました。
ドロップオン構成ファイルによる高度な構成管理
構成の管理は困難です。当社のシステムは常に更新されており、更新に伴い構成が変更される場合があります。新しいレジストリを追加したり、新しいミラーを構成したり、以前の設定を修正したり、Fedoraのデフォルト構成を拡張したりすることができます。多くの動機があり、特定の repositorys.conf いわゆるドロップイン構成ファイルを介してサポートします。
構成をロードするとき、 container / image ライブラリは最初に/etc/containers/registries.confにあるメイン設定ファイルをロードします 次に、 /etc/containers/registries.conf.d内のすべてのファイル アルファベット順のディレクトリ。
このようなドロップインregistries.confを使用する ファイルは簡単です。 .confを配置するだけです ディレクトリ内のファイル、およびPodmanは更新された構成を取得します。構成内のテーブルはマージされ、単純なノブはオーバーライドされることに注意してください。これは、実際には、 [[registry]] テーブルは、新しいレジストリで簡単に拡張できます。同じプレフィックスを持つレジストリがすでに存在する場合、レジストリ設定は上書きされます。同じことが[aliases]にも当てはまります テーブル。 unqualified-search-registriesなどの単純な構成ノブは常にオーバーライドされます。
[コンテナを使い始めますか？この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ：技術的な概要。 ]
結論
repositorys.conf は、コンテナツールのコアビルディングブロックです。コンテナレジストリと通信するときに、あらゆる種類のプロパティを構成できます。構成をより詳細に調査することに興味がある場合は、 man container-registries.confを実行できます。 Linuxマシンのマニュアルページを読むか、アップストリームのドキュメントにアクセスしてください。