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

Jetbrains 社の2020 年度開発動向調査 によると、現時点において 44 % の開発者が、何らかの形で Docker コンテナーを用いた継続的インテグレーション開発を行っています。 このような環境構築を採用する開発者の多くは、作業フローの一部としてコンテナー登録のため Docker Hub を利用しているものと思われます。 本ガイドではこれを行うベストプラクティス、そして手始めとして行うガイダンスを示します。

今までにうかがったフィードバックにおいて、以下のようなものもありました。 Docker が行った変更 として、ネットワーク出力に関すること、そして無償ユーザーが可能な最大プル数に関することがありました。 CI/CD ワークフローの一部として Docker Hub を利用するにあたって、それらの制限による影響を受けずに Docker Hub を利用する最良の方法はどういったものか、という質問でした。 本ガイドでは Docker Hub の経験を活かして適切に活用し、そういった制限に抵触するリスクを軽減させるベストプラクティスを提供します。 またユースケースによってはその制限を緩和するためのヒントにも触れます。

内部ループと外部ループ

Docker を利用していずれの CI/CD を構築する際にも重要になるのが、CI に対するテストをローカル環境においていつ実施すべきかを考えることです。 Docker を用いる際、内部ループ(inner loop)(コーディング、ビルド、実行、テスト)という観点、および外部ループ(outer loop)(変更のプッシュ、CI ビルド、CI テスト、デプロイ)という観点で、それぞれどのように開発者は作業を進めるのか、われわれは常にそのことを考慮しています。

CI/CD 内部ループと外部ループ

CI/CD の最適化を図る前にまず重要なのは、内部ループについて考えることであり、それが外部ループ(つまりは CI)とどのように関連させるかを考えることです。 たいていのユーザーは「CI を通じたデバッグ」を好まないのは承知しています。 したがって内部ループと外部ループは、できるだけ同じようなものにすることが望まれます。 そこでお勧めするのは、Dockerfile 内にターゲットを追加して、docker buildコマンドの一部としてユニットテストを実行することです。 こうしておけば、システムの変更とビルドはローカルで行ない、CI 上で実行するユニットテストは、同じものをローカル上で単純なコマンドを使って実施できることになります。

ブログ投稿「Go development with Docker」では、Docker プロジェクトにおいてテストをどのように行うか、そしてそれを CI 上でどのように再利用するかが、実によく示されています。 この例では、問題に対するフィードバックを短くして、CI の実行に必要となるプル操作やビルド処理の数を軽減しています。

CI/CD デプロイメントの最適化

実際の外部ループや Docker Hub への作業へ入ったら、CI を最大限に活用して Docker による最速の方法を実現させるための作業がいくつかあります。

何よりもまずはセキュアであることです。 CI を構築するにあたって Docker Hub に対しては、パスワードを用いるのでなく、アクセストークンを用いるようにします。

メモ

新たなアクセストークンは Docker Hub の Security ページにおいて生成します。

アクセストークンを生成して、プラットフォーム内の機密情報の保存場所に置いたら、次に考えるべきことは、CI/CD におけるシステム変更に対して、プッシュやプルをどのタイミングで行うのか、どこからそれを行うのかということです。

まずできることとして、ビルド時間や処理実行回数を軽減させるために、すでにプルを行ったレイヤーの再利用を図る ビルドキャッシュ を活用します。 これは多くのプラットフォーム上において buildX(buildkits)のキャッシュ機能を利用することで実現でき、プラットフォーム自体が提供するどのようなキャッシュであれ利用します。 たとえば「Optimizing the GitHub Actions workflow using build cache(ビルドキャッシュを利用した GitHub アクションの最適化)」を参照してください。

システム変更を行う際に、リリースイメージを単に Docker Hub に置きたいだけのときがあります。 そのような場合であれば、PR イメージを本番環境にまでリリースするのではなく、もっと身近にあるローカルな保存場所を利用して、すばやくプルやテストを行った上でその PR イメージをプッシュする段取りを築きさえすればよいということになります。

次のステップ

CI に対して Docker を利用するためのヒントやコツは、さらにあると考えられます。 そして最近の Docker Hub では ダウンロード率制限 があることを考えると、そういったものがテクニックの一部として重要になってきます。

メモ

認証を行った後にまだプル回数に対する制限にお悩みの場合は、Docker サブスクリプション にアップグレードすることを考えてみてください。

CI/CD と GitHub アクションの連携をどのように行うかについては GitHub アクションの設定 を参照してください。

CI/CD, GitHub Actions