DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

プルとプッシュを使用したDockerイメージ管理のベストプラクティス

`docker pull` および `docker push` を使用したDockerイメージ管理のベストプラクティスを学びます。このガイドでは、レジストリからのイメージの取得、タグ付け、アップロードの効率的なワークフロー、イメージサイズの最適化、特定のタグを使用した再現性の確保、CI/CDパイプラインとの統合について説明します。よりスムーズな開発とデプロイのために、Dockerイメージ管理戦略を強化しましょう。

Dockerイメージのプルとプッシュを管理するためのベストプラクティス

DockerイメージはアプリケーションをラップトップからCI、そして本番環境へと移動させますが、ずさんなプルとプッシュの習慣はデプロイを予測不可能にします。フローティングタグに依存したり、レジストリ認証チェックをスキップしたり、命名計画なしでイメージをプッシュしたりすると、すべてのコマンドが成功しても間違ったビルドをデプロイする可能性があります。

docker pullとdocker pushを使用してDockerイメージを管理するためのこれらのベストプラクティスは、再現可能なタグ、安全なレジストリワークフロー、そしてスクリプトやCI/CDパイプラインで使用できるシンプルなコマンドに焦点を当てています。

docker pullについて

docker pullコマンドは、レジストリで利用可能な事前構築済みDockerイメージの広大なエコシステムにアクセスするためのゲートウェイです。レジストリからイメージまたは特定のタグをローカルのDockerデーモンにダウンロードします。これは、既存のイメージを独自のアプリケーションのベースとして使用する必要がある場合や、特定のコンテナイメージに依存するサービスを実行する場合の最初のステップです。

基本的な使い方

docker pullの最も簡単な使い方は、イメージ名を指定し、オプションでタグを続けることです：

docker pull <イメージ名>[:<タグ>]

例：

  • Ubuntuのlatestタグをプルする：

    docker pull ubuntu

    これにより、タグが指定されていない場合のデフォルトであるlatestとしてタグ付けされたイメージがダウンロードされます。これは便利なタグとして扱い、本番環境の固定としては使用しないでください。

  • Alpine Linuxの特定のバージョンをプルする：

    docker pull alpine:3.18

    これにより、再現可能なビルド環境が確保されます。

  • 特定のレジストリからイメージをプルする：

    docker pull registry.example.com/my-app:v1.2

    プライベートレジストリやDocker Hub以外のレジストリを使用している場合は、レジストリのホスト名を含める必要があります。

docker pullのベストプラクティス

  • 常にタグを指定する： latestに依存すると、レジストリ所有者がいつでもそのタグを移動できるため、予期しない動作が発生する可能性があります。alpine:3.18やnginx:1.25-alpineなどの明示的なタグを使用すると、ビルドの再現が容易になります。
  • 本番環境では不変の参照を使用する： タグは人間にとってわかりやすいですが、上書きされる可能性があります。厳格な本番環境のロールアウトでは、テスト済みのタグとイメージダイジェストを組み合わせてデプロイします。例：nginx:1.25-alpine@sha256:<ダイジェスト>。
  • 未使用のイメージをクリーンアップする： docker image pruneを使用してローカルイメージキャッシュを定期的に整理し、ディスク容量を解放します。プルしたイメージはかなりのストレージを消費する可能性があります。
  • イメージレイヤーを理解する： Dockerイメージはレイヤーで構成されています。イメージをプルするとき、これらのレイヤーをダウンロードしています。Dockerはこれらのレイヤーをローカルにインテリジェントにキャッシュするため、既に持っているレイヤーと共有するイメージをプルする場合、新しいレイヤーのみがダウンロードされ、後続のプルが高速になります。

docker pushについて

docker pushコマンドは、ローカルでビルドまたは変更したDockerイメージをコンテナレジストリにアップロードするために使用されます。これは、イメージを共同作業者と共有したり、クラウドプラットフォームにデプロイしたり、バックアップとして保存したりするために不可欠です。

基本的な使い方

イメージをプッシュするには、レジストリのホスト名、ユーザー名（または組織名）、イメージ名、およびタグを適切にタグ付けする必要があります。

docker push <イメージ名>[:<タグ>]

前提条件：

  1. docker loginを使用して、プッシュ先のレジストリにログインしている必要があります。
  2. イメージはターゲットレジストリに対して正しくタグ付けされている必要があります。

プッシュのためのタグ付け

イメージをプッシュする前に、レジストリ内の宛先リポジトリへの完全なパスでタグ付けする必要があります。標準的な形式は次のとおりです：

<レジストリホスト名>/<ユーザー名または組織>/<イメージ名>:<タグ>

Docker Hubにプッシュする場合、レジストリホスト名は通常省略され、形式は<ユーザー名>/<イメージ名>:<タグ>になります。

ワークフローの例：

my-appという名前のイメージをビルドし、タグv1.0でDocker Hubアカウント（myusername）にプッシュするとします。

  1. イメージをビルドします（まだの場合）：

    docker build -t my-app .

  2. Docker Hub用にイメージをタグ付けします：

    docker tag my-app:latest myusername/my-app:v1.0

    注：my-appのlatestビルドを特定のレジストリパスmyusername/my-app:v1.0にタグ付けしています。

  3. Docker Hubにログインします：

    docker login

自動化にアカウントパスワードを入力する代わりに、Docker Hubアクセストークンまたはレジストリの推奨トークンフローを使用してください。

  1. タグ付けされたイメージをプッシュします：
    docker push myusername/my-app:v1.0

docker pushのベストプラクティス

  • 意味のあるタグを付ける： latestだけではなく、説明的なタグ（例：バージョン番号、リリース名、staging、production）を使用します。これにより、イメージの特定のバージョンを識別および管理しやすくなります。
  • 役立つ場合は複数のタグを使用する： リリースイメージには1.4.2とgit-3f2a9c1の両方のタグを付けることができます。バージョンは人間にとって役立ち、コミットSHAはソースを指し示します。
  • 脆弱性についてイメージをスキャンする： 特にパブリックリポジトリや機密性の高い環境にプッシュする前に、Docker Scoutやサードパーティのスキャナーなどのツールを使用して、既知の脆弱性についてイメージをスキャンすることを検討してください。
  • イメージサイズを最小化する： 小さいイメージはプッシュおよびプルが高速です。Dockerfileを最適化してイメージサイズを削減します（例：マルチステージビルドの使用、中間ファイルのクリーンアップ、Alpineのような最小限のベースイメージの使用）。
  • 機密データにはプライベートレジストリを使用する： プロプライエタリなコードや機密設定については、常にプライベートレジストリを使用し、アクセス制御を適切に管理します。
  • タグ付けとプッシュを自動化する： 自動ビルドとデプロイのために、イメージのタグ付けとプッシュをCI/CDパイプラインに統合します。

高度なシナリオとヒント

複数のタグのプルとプッシュ

デフォルトでは、docker pullとdocker pushは1つのイメージ参照に対して動作します。同じイメージIDに複数回タグ付けし、各タグをプッシュできます。一部のDockerバージョンでは、リポジトリのすべてのローカルタグを意図的にプッシュしたい場合に、docker image push --all-tags <リポジトリ>もサポートしています。

例：複数のタグでイメージをプッシュする

# 同じイメージIDを指す'latest'タグを追加
 docker tag myusername/my-app:v1.0 myusername/my-app:latest

# 新しい'latest'タグをプッシュ
 docker push myusername/my-app:latest

プライベートレジストリの認証

プライベートレジストリ（AWS ECR、Google GCR、Azure ACR、またはセルフホスト型レジストリなど）の場合、プルまたはプッシュする前に認証する必要があります。

# Docker Hubの例
 docker login

# AWS ECRの例（多くの場合、ヘルパーコマンドを使用）
 aws ecr get-login-password --region <リージョン> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<リージョン>.amazonaws.com

正しい認証方法については、必ず特定のレジストリのドキュメントを参照してください。

イメージレイヤーとキャッシュ

Dockerのレイヤーファイルシステムにより、プルが効率的に保たれます。イメージをプルするとき、Dockerはローカルコンテンツストアで既存のレイヤーをチェックし、まだ持っていないレイヤーのみをダウンロードします。docker build中、BuildKitは、Dockerfileの命令と入力が変更されていない場合、以前のビルドのキャッシュされたレイヤーを再利用することもできます。

イメージを最新の状態に保つ

セキュリティパッチとアップデートを組み込むために、ベースイメージを定期的にプルし、アプリケーションイメージを再ビルドします。

# 最新のベースイメージをプル
 docker pull python:3.11-slim

# 更新されたベースを使用してアプリケーションイメージを再ビルド
 docker build -t myusername/my-app:v1.1 .

# 新しいバージョンをプッシュ
 docker push myusername/my-app:v1.1

実践的なポイント

日常業務では、ワークフローを単純に保ちます：明示的なベースイメージタグをプルし、バージョンとコミットタグでビルドし、結果をスキャンし、トークンでログインし、デプロイする予定の参照のみをプッシュします。本番環境では、テストに合格したダイジェストを記録しておき、変更可能なタグが変更されても後で同じイメージをプルできるようにします。