CI/CD に Docker Hub を使用するためのベスト プラクティス

2020年のJetbrains開発者調査 によると、開発者の44%が現在、Docker Containersとの何らかの形の継続的インテグレーションとデプロイを使用しています。多くの開発者がワークフローの一部として Docker Hub をコンテナー レジストリとして使用してこの設定を行っていることがわかっているため、これを行うためのベスト プラクティスを掘り下げ、開始方法に関するガイダンスを提供することにしました。 これをサポートするために、今後数週間にわたって一連のブログ投稿を公開し、トップCIプロバイダーによく寄せられる質問に答える予定です。

また、Docker がネットワーク エグレスと無料ユーザー向けのプル数に関して導入した変更を考えると、これらの制限に達することなく CI/CD ワークフローの一部として Docker Hub を使用する最善の方法について質問があるというフィードバックも寄せられています。 このブログ投稿では、エクスペリエンスを向上させるベストプラクティスについて説明し、これらの制限に達するリスクを軽減するDocker Hubの賢明な消費と、ユースケースに応じて制限を引き上げる方法について説明します。 

開始するには、Dockerと実際にCI / CDを使用するときに最も重要なことの1つは、CIでテストする必要がある場合、またはこれをローカルで実行できる場合を解決することです。 Dockerでは、開発者が内部ループ(コード、ビルド、実行、テスト)と外部ループ(プッシュ変更、CIビルド、CIテスト、デプロイ)の観点からどのように作業するかを考えています 

CI/CD の最適化を検討する前に、内側のループと、それが外側のループ (CI) とどのように関連しているかについて考えることが常に重要です。 ほとんどの人は「CIを介したデバッグ」のファンではないことがわかっているので、内側のループと外側のループができるだけ似ている方が常に良いです。 このためには、Dockerfile に単体テストのターゲットを追加して、Docker ビルド コマンドの一部として単体テストを実行することをお勧めします。 そうすれば、変更を加えてローカルで再構築するときに、簡単なコマンドでローカルマシンのCIで実行するのと同じ単体テストを実行できます。 Chris は 今年の初めに Docker を使った Go 開発に関するブログ記事を書いていますが、これは Docker プロジェクトでテストを使用し、CI で再利用する方法を示す良い例です。 これにより、問題に関するフィードバックループが短くなり、CIが行う必要のあるプルとビルドの量が減ります。

実際の外部ループと Docker Hub に入ったら、CI を最大限に活用し、最速の Docker エクスペリエンスを提供するためにできることがいくつかあります。 

何よりもまず、安全を確保してください! CI を設定するときは、パスワードではなく Docker Hub アクセス トークンを使用していることを確認し、 Docker Hub のセキュリティ ページから新しいアクセス トークンを作成できます。 

これを入手し、プラットフォームで利用可能なシークレットストアに追加したら、CI / CDをプッシュおよびプルすることを決定するタイミングと、行っている変更に応じてどこからかを確認する必要があります。 ビルド時間を短縮し、呼び出しの数を減らすためにここで最初にできることは、ビルドキャッシュを使用して、すでにプルしたレイヤーを再利用することです。 これは、 buildX (ビルドキット)キャッシュ機能とプラットフォームが提供するキャッシュを使用して、多くのプラットフォームで実行できます。

あなたがしたいと思うかもしれない他の変更はあなたのリリースイメージをDockerHubに行くだけです、これはあなたのPRイメージをよりローカルなイメージストアにプッシュする機能を設定して、それらを本番環境まで宣伝するのではなく、迅速にプルしてテストすることを意味します。

CIでDockerを使用するためのヒントやコツは他にもたくさんあることはわかっていますが、最近のハブレートの変更を中心にこれを行う方法を実際に見ると、これらが実行できる最大のことだと思います。

それでもプル制限に問題がある場合は、認証された後も、 Proアカウントまたはチームアカウントへのアップグレードを検討できます。 これにより、24時間で50,000回のプルと無制限の画像保持が可能になります。 近い将来、これには、新しいイメージをDocker Hubにプッシュする際の画像スキャン(Snykを搭載)も含まれます。

Githubアクションでこれらのプラクティスのいくつかを実施する方法についてのシリーズの次のブログ投稿を探して、Twitter@Dockerにメッセージをドロップして、私たちがカバーしてほしいCIプロバイダーのアイデアを自由に提供してください。