Docker Hub入門：まずはここから押さえよう

By /

Docker Hub 完全入門：初心者から始めるコンテナイメージ管理のすべて

はじめに：なぜDocker Hubが重要なのか？

コンテナ技術、特にDockerは、現代のソフトウェア開発と運用において不可欠な存在となりました。アプリケーションとその依存関係をすべてパッケージ化し、どんな環境でも一貫して実行できるコンテナは、開発・テスト・デプロイのワークフローを劇的に効率化します。

しかし、コンテナを利用する上で避けて通れないのが、「コンテナイメージをどこから取得し、どこに保存し、どのように共有するのか」という課題です。この課題を解決する中心的な存在こそが、「Docker Hub」です。

Docker Hubは、Docker社が提供する、コンテナイメージのためのクラウドベースのレジストリサービスです。世界中の開発者が作成したコンテナイメージを公開・共有したり、自分自身が作成したイメージを保存・管理したりするためのハブ（拠点）として機能します。

例えるなら、Docker Hubは、GitHubがソースコードにとってのハブであるように、コンテナイメージにとってのハブなのです。オペレーティングシステム、ミドルウェア、プログラミング言語のランタイム、各種アプリケーションなど、さまざまなコンテナイメージがDocker Hubで公開されており、私たちはそれらを簡単に取得して利用できます。また、自分が開発したアプリケーションをコンテナ化し、そのイメージをDocker Hubにプッシュすることで、他の開発者や本番環境に簡単に配布することも可能です。

Docker Hubを使いこなすことは、Dockerを本格的に活用する上で避けては通れない道です。この記事では、Docker Hubの基本から応用的な機能まで、約5000語にわたって網羅的に解説します。Docker初心者の方でも理解できるよう、専門用語は丁寧に説明し、具体的な操作手順や例を豊富に盛り込みます。

この記事を読むことで、あなたは以下のことを習得できます。

  • Docker Hubの基本的な仕組み（リポジトリ、イメージ、タグ）
  • Docker Hubアカウントの作成とDocker CLIからの利用方法
  • 公開されているイメージの検索、取得（pull）、利用方法
  • 独自のコンテナイメージを作成し、Docker Hubに公開・共有（push）する方法
  • Official ImagesやVerified Publisherイメージの重要性
  • Docker Hubのその他の便利な機能（Organizations, Webhooksなど）
  • Docker Hubを利用する上でのベストプラクティスと注意点（セキュリティ、レート制限など）

さあ、Docker Hubの世界に足を踏み入れ、コンテナイメージ管理の基盤を固めましょう。

Docker Hubの基本概念：リポジトリ、イメージ、タグ

Docker Hubを理解するためには、いくつかの基本的な概念を抑える必要があります。それは「リポジトリ」「イメージ」「タグ」です。これらの概念は密接に関連しており、Docker Hubでのコンテナイメージ管理の根幹をなします。

リポジトリ (Repository)

リポジトリは、関連するコンテナイメージ群をまとめて管理するための単位です。ちょうど、GitHubでプロジェクトのソースコードを管理する単位がリポジトリであるのと似ています。

Docker Hubにおけるリポジトリは、通常、特定のアプリケーションやサービス、あるいはOSやミドルウェアの種類に対応します。例えば、UbuntuというOSのイメージ、MySQLというデータベースのイメージ、Node.jsというJavaScript実行環境のイメージなどは、それぞれ独立したリポジトリで管理されています。

リポジトリには、いくつかの種類があります。

  1. ユーザーリポジトリ (User Repository): 特定のDocker HubユーザーまたはOrganizationが所有するリポジトリです。例えば、ubuntu リポジトリはDocker社が、myuser/myapp リポジトリはmyuserというユーザーが所有します。ユーザー名（またはOrganization名）とリポジトリ名はスラッシュ（/）で区切られます。公式イメージや認証済みパブリッシャーのイメージでない限り、通常はこの形式です。
  2. トップレベルリポジトリ (Top-Level Repository): これは特別なリポジトリで、ユーザー名やOrganization名が含まれません。例えば、ubuntu, nginx, mysqlなどがこれにあたります。これらはDocker社によって管理される「公式イメージ (Official Images)」のリポジトリです。後述しますが、公式イメージは信頼性が高く、広く利用されています。

リポジトリには、「公開 (Public)」と「非公開 (Private)」の2つの状態があります。

  • Public リポジトリ: 誰でも自由に検索、表示、イメージの取得（プル）ができるリポジトリです。オープンソースプロジェクトのイメージや、広く利用される基盤イメージなどが公開されます。
  • Private リポジトリ: 特定のユーザーまたはOrganizationメンバーのみがアクセスできるリポジトリです。認証なしでは検索も表示もできません。企業内部で開発されるアプリケーションのイメージや、機密性の高い情報を含むイメージなどを保存するのに利用します。無料プランの場合、Privateリポジトリの数に制限がある場合があります（現在は通常1つ）。

イメージ (Image)

イメージは、コンテナを実行するために必要なファイルシステム、設定、依存関係などをすべて含んだ、読み取り専用のテンプレートです。イメージは、複数の読み取り専用の「レイヤー」が積み重ねられた構造をしています。このレイヤー構造により、イメージの共有や変更が効率的に行われます。

例えば、Ubuntuイメージの上にApacheをインストールし、さらにその上に特定のWebアプリケーションを配置したイメージを作成する場合、Ubuntuのレイヤー、Apacheのレイヤー、アプリケーションのレイヤーが積み重なります。もし別のアプリケーションが同じUbuntuやApacheのレイヤーを使用する場合、それらのレイヤーは共有されるため、ディスク容量を節約できます。

Docker Hubは、これらのイメージ本体を格納・管理する場所です。リポジトリは、このイメージ群を論理的にまとめる箱のようなものです。

タグ (Tag)

タグは、リポジトリ内の特定のイメージを識別するためのラベルです。同じリポジトリ内には、様々なバージョンやバリエーションのイメージが存在しえます。タグを使用することで、それらを区別し、目的のイメージを正確に指定できます。

例えば、ubuntu リポジトリには、22.04、20.04、latestといった様々なタグのイメージが存在します。

  • ubuntu:22.04: Ubuntu 22.04 LTS（Jammy Jellyfish）のイメージ
  • ubuntu:20.04: Ubuntu 20.04 LTS（Focal Fossa）のイメージ
  • ubuntu:latest: そのリポジトリ内で最新と見なされるイメージ（通常、最新の安定版を指しますが、保証されるものではありません。latestタグの使用には注意が必要です）

イメージを指定する際には、通常 リポジトリ名:タグ名 の形式を使用します。例: ubuntu:22.04。もしタグ名を省略した場合、デフォルトで :latest タグが指定されたものと見なされます。例: ubuntu は ubuntu:latest と同じ意味になります。

タグはバージョン番号だけでなく、alpine (軽量版)、fpm (PHP-FPM版)、debugなど、イメージのバリエーションを示すためにも使われます。

まとめ:

  • リポジトリ: 関連するイメージ群をまとめる箱。公開(Public)か非公開(Private)がある。ユーザー名/リポジトリ名またはリポジトリ名の形式。
  • イメージ: コンテナ実行のためのテンプレート。読み取り専用のレイヤー構造。リポジトリ内に複数存在する。
  • タグ: リポジトリ内の特定のイメージを識別するラベル。バージョンやバリエーションを示す。リポジトリ名:タグ名でイメージを特定。

これらの概念は、Docker Hubでの操作（検索、プル、プッシュ）において常に登場しますので、しっかりと理解しておきましょう。

Docker Hubを使ってみる：アカウント登録とCLI連携

Docker Hubの多くの機能を利用するには、アカウントが必要です。公開されているイメージの検索や取得（pull）だけであればアカウントは必須ではありませんが、後述するイメージの共有（push）やPrivateリポジトリの利用にはアカウント登録が必要です。

Docker Hub アカウントの作成

  1. Docker Hub ウェブサイトにアクセス: ブラウザを開き、https://hub.docker.com/ にアクセスします。
  2. サインアップ: ページ右上にある「Sign Up」ボタンをクリックします。
  3. 情報の入力:
    • Docker ID: あなたのユニークなユーザー名です。これがリポジトリ名の一部（your-docker-id/my-image）になります。後から変更できないので慎重に決めましょう。
    • Email: 有効なメールアドレスを入力します。
    • Password: 安全なパスワードを設定します。
  4. 利用規約とプライバシーポリシーへの同意: チェックボックスに同意します。
  5. サインアップ完了: 「Sign Up」ボタンをクリックします。おそらくメールアドレスの確認を求められるので、指示に従ってメールを確認し、アカウントを有効化します。
  6. プランの選択 (任意): 無料プラン（Docker Free）で始めることができます。必要に応じて有料プランへのアップグレードを検討してください。この記事の多くの内容は無料プランで利用可能です。

これでDocker Hubのアカウントが作成され、ウェブサイトからサインインできるようになります。ウェブサイトでは、リポジトリの作成、設定変更、イメージの確認、Organization管理などを行うことができます。

Docker CLIからのサインイン (Login)

Docker Hubの操作の大部分は、ローカル環境にインストールされたDockerコマンドラインインターフェース（CLI）から行います。イメージのプルやプッシュを行うには、CLIからDocker Hubにサインインする必要があります。

コマンドラインを開き、以下のコマンドを実行します。

bash
docker login

このコマンドを実行すると、対話形式でDocker IDとパスワードの入力を求められます。

Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: [あなたのDocker ID]
Password:

Docker IDとパスワードを入力してEnterキーを押します。パスワード入力時には画面に文字が表示されませんが、そのまま入力してEnterを押してください。

認証に成功すると、以下のようなメッセージが表示されます。

Login Succeeded

これで、あなたのDocker CLIはDocker Hubに認証された状態で接続されました。これにより、Privateリポジトリへのアクセスや、Public/Privateリポジトリへのイメージのプッシュが可能になります。

サインアウトする場合は、以下のコマンドを実行します。

bash
docker logout

Docker Hubの主要な機能を使ってみる

アカウントの準備ができたら、いよいよDocker Hubの主要な機能をCLIから使ってみましょう。

1. イメージの検索 (Searching Images)

Docker Hubで利用可能なイメージを探すには、ウェブサイトを利用する方法と、Docker CLIを利用する方法があります。

ウェブサイトでの検索:

https://hub.docker.com/search にアクセスし、検索バーに探したいイメージのキーワードを入力します。例えば、「nginx」と入力して検索すると、nginxに関連する様々なリポジトリが表示されます。

検索結果には、Official Images、Verified Publisher イメージ、およびコミュニティイメージが表示されます。信頼性の高いイメージを探す場合は、Official ImagesやVerified Publisherに絞り込むと良いでしょう。

Docker CLIでの検索:

ローカルのターミナルから docker search コマンドを使ってイメージを検索することもできます。

bash
docker search [キーワード]

例として、「ubuntu」イメージを検索してみましょう。

bash
docker search ubuntu

実行結果例：

NAME DESCRIPTION STARS OFFICIAL AUTOMATED
ubuntu Ubuntu is a Debian-based Linux operating s... 15288 [OK]
ubuntu-upstart Upstart is an event-based replacement for ... 121
rastasheep/ubuntu-sshd Dockerized SSH service using official Ubun... 305 [OK]
symplify/ubuntu-php Ubuntu with preinstalled PHP, Nginx and Post... 1
[...]

各列の意味は以下の通りです。

  • NAME: リポジトリ名です。ubuntuのようなトップレベルリポジトリ名、またはユーザー名/リポジトリ名の形式で表示されます。
  • DESCRIPTION: リポジトリの簡単な説明です。
  • STARS: そのリポジトリの人気度を示すスターの数です。
  • OFFICIAL: そのイメージが公式イメージであるか ([OK]) を示します。
  • AUTOMATED: かつてはGitHub/GitLabなどと連携して自動ビルドされていたイメージ ([OK]) を示しましたが、現在はAutomated Buildsの機能が変更されているため、この列の情報は参考程度になります。

検索結果を見て、目的のイメージのリポジトリ名を確認しましょう。通常、スターが多く、OFFICIAL または Verified Publisher (CLIでは表示されない) となっているイメージが信頼性も高く、よくメンテナンスされています。

2. イメージの取得 (Pulling Images)

Docker Hubからイメージを取得するには、docker pull コマンドを使用します。これにより、指定したイメージがDocker Hubからダウンロードされ、ローカルのDocker環境に保存されます。

bash
docker pull [リポジトリ名]:[タグ名]

タグ名を省略した場合、デフォルトで :latest タグが指定されます。

例：公式の最新版Ubuntuイメージを取得する

bash
docker pull ubuntu

これは docker pull ubuntu:latest と同じ意味です。

特定のバージョンのUbuntuイメージを取得する（例: 22.04）

bash
docker pull ubuntu:22.04

初めてイメージをプルする場合、DockerはDocker Hubに接続し、指定されたイメージ（とその構成レイヤー）をダウンロードします。

bash
Using default tag: latest
latest: Pulling from library/ubuntu
4f42f054cd65: Pull complete
Digest: sha256:a73e5361714b4ee6912a63f23d4cc2814d5c3c411520026798030158742768b3
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

Pull complete と表示されたレイヤーはダウンロードが完了したことを示します。複数のレイヤーがダウンロードされることがあります。Digest はイメージのハッシュ値で、イメージの整合性を確認するために使われます。

一度プルしたイメージはローカルにキャッシュされます。次に同じイメージをプルしようとした場合、もしローカルのイメージが最新であれば、ダウンロードはスキップされます。

プルしたイメージは docker images コマンドで確認できます。

bash
docker images

bash
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu latest a73e5361714b 2 weeks ago 77.8MB
ubuntu 22.04 a73e5361714b 2 weeks ago 77.8MB

同じ IMAGE ID を持つ行が複数ある場合、それは同じイメージに複数のタグが付いていることを意味します（この例では latest と 22.04 が同じイメージを指しています）。これは、docker pull ubuntu と docker pull ubuntu:22.04 を実行した場合に発生します。

イメージをプルしたら、それを使ってコンテナを実行できます。

bash
docker run -it ubuntu:22.04 /bin/bash

これにより、Ubuntu 22.04のコンテナが起動し、その中で /bin/bash シェルが実行されます。-it オプションは、インタラクティブモード (-i) と擬似ターミナル割り当て (-t) を有効にし、コンテナと対話できるようにします。

3. イメージの共有/公開 (Pushing Images)

自分で作成したコンテナイメージをDocker Hubにアップロードし、他のユーザーと共有したり、別の環境から利用したりするには、docker push コマンドを使用します。

イメージをプッシュするには、以下の準備が必要です。

  1. Docker Hub アカウントを持っていること。
  2. Docker CLIでログインしていること (docker login 済みであること)。
  3. プッシュしたいイメージがあること。
  4. プッシュしたいイメージに、あなたのDocker IDを名前空間とするタグが付いていること。

プッシュするイメージのタグ付け形式は重要です。Docker Hubにイメージをプッシュする場合、リポジトリ名は あなたのDocker ID/リポジトリ名 という形式である必要があります（Official Imagesとして公開する場合などを除く）。

自分で作成したローカルのイメージにタグを付けるには、docker tag コマンドを使用します。

bash
docker tag [元のイメージ名]:[元のタグ名] [あなたのDocker ID]/[新しいリポジトリ名]:[新しいタグ名]

例：ローカルに my-app:v1.0 というイメージがあり、それを myuser/my-app リポジトリの v1.0 タグとしてDocker Hubにプッシュしたい場合。

まず、ローカルのイメージに新しいタグを付けます。

bash
docker tag my-app:v1.0 myuser/my-app:v1.0

これで、ローカルに myuser/my-app:v1.0 というタグの付いたイメージが作成されます（元のイメージと同じものです）。docker images で確認できます。

次に、このタグを使ってDocker Hubにプッシュします。

bash
docker push myuser/my-app:v1.0

プッシュが始まります。Docker Hubは、ローカルイメージの各レイヤーを確認し、まだDocker Hubに存在しないレイヤーのみをアップロードします。

bash
The push refers to repository [docker.io/myuser/my-app]
a73e5361714b: Pushed
v1.0: digest: sha256:c0ffee... size: 1234

プッシュが完了したら、Docker Hubのウェブサイトにアクセスし、あなたのリポジトリ（例: myuser/my-app）を確認してみてください。新しいリポジトリが作成され、v1.0 というタグのイメージが登録されているはずです。

これで、他のユーザーは docker pull myuser/my-app:v1.0 コマンドを使って、あなたがプッシュしたイメージをダウンロードし、利用できるようになります。

Private リポジトリへのプッシュ:

Privateリポジトリを作成し、そこにイメージをプッシュする場合も手順は同じです。ただし、そのリポジトリはあなたのDocker Hubアカウント、または所属するOrganizationのメンバー以外には見えません。Privateリポジトリにアクセスするには、プルする側もDocker Hubにログインしている必要があります。

注意: 無料プランの場合、Privateリポジトリの数に制限があることが一般的です（現在は通常1つまで）。複数のPrivateリポジトリが必要な場合は、有料プランを検討する必要があります。

Docker Hubの便利な機能をもっと知る

Docker Hubは単なるイメージ置き場ではありません。チームでの利用を効率化したり、セキュリティを向上させたり、ワークフローを自動化するための様々な機能を提供しています。

公式イメージ (Official Images)

公式イメージは、Docker社によって公開され、レビューされ、メンテナンスされている高品質なイメージ群です。主要なOS（Ubuntu, Alpine, Debianなど）や、人気のあるミドルウェア/アプリケーション（Nginx, MySQL, PostgreSQL, Redis, Node.js, Python, Javaなど）の公式イメージが提供されています。

なぜ公式イメージを使うべきか？

  • 信頼性: Docker社およびそのコミュニティによってレビューされており、Dockerfileのベストプラクティスに従って構築されています。
  • セキュリティ: 脆弱性スキャンが定期的に行われ、セキュリティアップデートが迅速に適用されます。
  • 最新性: 最新の安定版が常に提供され、様々なバージョンやプラットフォームに対応しています。
  • ドキュメント: 豊富なドキュメントが提供されており、イメージの利用方法や設定方法が詳しく解説されています。

Official Imagesは、Docker Hubの検索結果で OFFICIAL 列に [OK] と表示されるか、リポジトリ名の隣に公式チェックマークが付いています。イメージを選択する際に、可能な限り公式イメージを選択することを強く推奨します。

Verified Publisher イメージ

Verified Publisher イメージは、Docker社がパートナー企業と提携して提供するイメージです。主要なソフトウェアベンダー（Microsoft, Oracle, VMWare, HashiCorpなど）が公式に提供し、メンテナンスしているイメージであり、高い信頼性があります。

Official Imagesと同様に、Verified Publisher イメージも品質、セキュリティ、ドキュメントにおいて高い基準を満たしています。エンタープライズレベルのアプリケーションやミドルウェアを利用する際に特に有用です。

Docker Hubのウェブサイトでは、リポジトリ名の隣に Verified Publisher のチェックマークが付いています。

Organizations & Teams

Docker Hubは、個人だけでなくチームや企業での利用にも対応しています。Organizationを作成することで、複数のユーザーをまとめて管理し、リポジトリへのアクセス権限をコントロールできます。

  • Organization: 会社名やプロジェクト名などで作成します。Organizationがリポジトリを所有します（例: mycompany/myapp）。
  • Teams: Organization内にチームを作成し、ユーザーをチームに所属させます。
  • アクセス権限: リポジトリごとに、Read (プルのみ), Write (プル、プッシュ), Admin (リポジトリの管理) といった権限をチームや個々のユーザーに付与できます。

これにより、例えば開発チームは特定のイメージをプッシュできるようにし、運用チームはそれをプルできるようにするなど、組織内での役割に応じたきめ細やかな権限管理が可能になります。これは、企業でDocker HubのPrivateリポジトリを利用する際に非常に重要な機能です。

Webhooks

Webhooksは、Docker Hubのリポジトリでイベント（例えば、イメージのプッシュ）が発生した際に、外部のURLにHTTP POSTリクエストを送信する機能です。

これを利用することで、CI/CDパイプラインを自動化できます。例えば：

  1. GitHubでコードが更新される。
  2. CIツール（Jenkins, GitLab CI, GitHub Actionsなど）がコードを取得し、新しいDockerイメージをビルドする。
  3. ビルドしたイメージをDocker Hubにプッシュする。
  4. Docker Hubがイメージプッシュイベントを検知し、設定されたWebhookをトリガーする。
  5. Webhookの送信先URL（例えば、CDツールやデプロイメントスクリプトのエンドポイント）がリクエストを受け取る。
  6. CDツールが新しいイメージを使ってアプリケーションをデプロイする。

これにより、コードのコミットからアプリケーションのデプロイまでを自動化するパイプラインを構築できます。

Automated Builds (Builds)

Automated Builds（現在は単に “Builds” と呼ばれることが多い）は、GitHub、GitLab、Bitbucketなどのソースコードリポジトリと連携し、リポジトリ内のDockerfileの変更を検知して、自動的にDockerイメージをビルドし、Docker Hubにプッシュする機能です。

かつてはDocker Hubの主要な機能の一つでしたが、無料プランでの利用が制限されるなど、その位置づけは変化しています。現在は、Docker Build Cloudという、より高度でスケーラブルなビルドサービスへの移行が進んでいます。

Buildsを設定しておくと、ソースコードを更新してGitリポジトリにプッシュするだけで、最新のコンテナイメージがDocker Hubで利用可能になるというメリットがあります。タグ付けルールなども柔軟に設定できます。

ただし、無料プランではAutomated Buildsの利用回数や同時実行数に厳しい制限があるため、本格的なCI/CDパイプラインでの利用には有料プランまたは代替のCIツールでのビルドを検討する必要があります。

Security Scanning (Docker Scout)

Docker Scout（旧Docker Scan）は、イメージに含まれるソフトウェアの脆弱性をスキャンする機能です。イメージ内のOSパッケージやライブラリなどを解析し、既知の脆弱性データベースと照合して、リスクの高い脆弱性をレポートします。

Docker Hubのウェブサイトで、リポジトリごとにスキャン結果を確認できます。これにより、公開または利用しようとしているイメージに潜在的なセキュリティリスクがないかを確認できます。

無料プランでも限定的なスキャン機能を利用できます。セキュリティはコンテナ利用において非常に重要ですので、積極的に活用したい機能です。

Docker Desktopとの連携

Docker Desktopは、WindowsやmacOS上でDockerを利用するための便利なツールです。Docker DesktopのGUIからもDocker Hubにサインインしたり、リポジトリを閲覧したり、イメージを管理したりすることができます。CLI操作に慣れていない初心者にとっては、GUIで視覚的に操作できるため理解しやすく、導入のハードルを下げてくれます。

実践編：カスタムイメージを作成してDocker HubにPushしてみよう

Docker Hubの使い方の基本として、自分で作成したカスタムイメージをDocker Hubにプッシュする手順を詳しく見ていきましょう。

ここでは、簡単なNode.jsアプリケーションをコンテナ化し、そのイメージをDocker Hubにプッシュする例を取り上げます。

準備:

  • Dockerがインストールされていること。
  • Docker Hubアカウントを作成済みであること。
  • Docker CLIで docker login 済みであること。

ステップ 1: シンプルなNode.jsアプリケーションの準備

まず、ごく簡単なNode.jsアプリケーションを作成します。適当なディレクトリ（例: my-nodejs-app）を作成し、その中に以下のファイルを作成します。

package.json:

json
{
"name": "my-simple-app",
"version": "1.0.0",
"description": "A simple node.js web app",
"main": "server.js",
"scripts": {
"start": "node server.js"
},
"dependencies": {
"express": "^4.17.1"
}
}

server.js:

“`javascript
const express = require(‘express’);
const app = express();
const port = 3000;

app.get(‘/’, (req, res) => {
res.send(‘Hello, Docker Hub!’);
});

app.listen(port, () => {
console.log(App listening at http://localhost:${port});
});
“`

これで、ポート3000で「Hello, Docker Hub!」と表示するだけのシンプルなExpressアプリケーションができました。

ステップ 2: Dockerfileの作成

次に、このアプリケーションをコンテナ化するためのDockerfileを作成します。アプリケーションと同じディレクトリに Dockerfile という名前でファイルを作成し、以下のように記述します。

“`dockerfile

ベースイメージとして公式のNode.jsイメージを使用します。

latestタグは避けて、具体的なバージョンタグ（例: 18-alpine）を指定することを推奨します。

FROM node:18-alpine

コンテナ内の作業ディレクトリを設定します。

WORKDIR /app

アプリケーションの依存関係ファイル（package.json, package-lock.jsonなど）をコンテナ内にコピーします。

これにより、依存関係のインストール時にDockerのキャッシュを活用しやすくなります。

COPY package*.json ./

アプリケーションの依存関係をインストールします。

RUN npm install

アプリケーションのソースコードをコンテナ内にコピーします。

COPY . .

アプリケーションが待ち受けるポートを指定します。これはドキュメント化のためです。

EXPOSE 3000

コンテナが起動したときに実行されるコマンドを指定します。

CMD [“npm”, “start”]
“`

このDockerfileは以下のことを定義しています：

  • FROM node:18-alpine: ベースとなるイメージとして、Node.js 18のAlpine Linuxバージョンを使用します。Alpine Linuxは非常に軽量なLinuxディストリビューションで、イメージサイズを小さくするのに役立ちます。
  • WORKDIR /app: コンテナ内で以降のコマンドを実行するディレクトリを /app に設定します。
  • COPY package*.json ./: ホストマシンの package.json と package-lock.json (もし存在すれば) をコンテナ内の /app ディレクトリにコピーします。
  • RUN npm install: コンテナ内で npm install を実行し、依存関係をインストールします。COPY package*.json ./ を先に行うことで、package.json が変更されない限りこのステップのキャッシュが利用され、ビルド時間を短縮できます。
  • COPY . .: ホストマシンのカレントディレクトリにあるすべてのファイル（server.js など）をコンテナ内の /app ディレクトリにコピーします。
  • EXPOSE 3000: このコンテナがポート3000で通信することを指定します。これは情報の提示であり、ポートマッピングを自動で行うわけではありません。
  • CMD ["npm", "start"]: このイメージからコンテナが起動したときに実行されるデフォルトのコマンドを指定します。

ステップ 3: イメージのビルド

Dockerfileが準備できたら、そのディレクトリでターミナルを開き、以下のコマンドでイメージをビルドします。

bash
docker build -t my-simple-app:v1.0 .

  • docker build: イメージをビルドするコマンドです。
  • -t my-simple-app:v1.0: ビルドするイメージにタグを付けます。my-simple-app がリポジトリ名、v1.0 がタグ名です。この時点ではまだローカルのリポジトリ名であり、Docker Hubの名前空間（あなたのDocker ID）は含めません。
  • .: Dockerfileが存在するディレクトリを指定します。. はカレントディレクトリを意味します。

ビルドプロセスが実行され、Dockerfileに記述された各ステップが順に実行されます。

bash
[+] Building 6.1s (8/8) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 377B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/node:18-alpine 0.0s
=> [1/4] FROM docker.io/library/node:18-alpine@sha256:... 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 327B 0.0s
=> [2/4] WORKDIR /app 0.0s
=> [3/4] COPY package*.json ./ 0.0s
=> [4/4] RUN npm install 4.9s
=> [5/4] COPY . . 0.0s
=> [6/4] EXPOSE 3000 0.0s
=> [7/4] CMD ["npm" "start"] 0.0s
=> [8/8] COMMIT my-simple-app:v1.0 0.0s

ビルドが成功したら、docker images コマンドでローカルにイメージが作成されたことを確認できます。

bash
docker images my-simple-app

bash
REPOSITORY TAG IMAGE ID CREATED SIZE
my-simple-app v1.0 abcdef123456 20 seconds ago 100MB

（IMAGE ID や SIZE は環境によって異なります。）

ステップ 4: Docker Hubの名前空間でイメージにタグを付ける

Docker Hubにこのイメージをプッシュするために、あなたのDocker IDを名前空間とするタグを付け直す必要があります。

bash
docker tag my-simple-app:v1.0 [あなたのDocker ID]/my-simple-app:v1.0

例：Docker IDが myuser の場合

bash
docker tag my-simple-app:v1.0 myuser/my-simple-app:v1.0

再び docker images で確認すると、新しいタグが追加されていることがわかります。

bash
docker images my-simple-app

bash
REPOSITORY TAG IMAGE ID CREATED SIZE
my-simple-app v1.0 abcdef123456 2 minutes ago 100MB
myuser/my-simple-app v1.0 abcdef123456 2 minutes ago 100MB

IMAGE ID が同じであることから、これらが同じイメージであることがわかります。

ステップ 5: Docker Hubにイメージをプッシュする

いよいよイメージをDocker Hubにプッシュします。ステップ4で付けたDocker IDを含むタグを指定します。

bash
docker push [あなたのDocker ID]/my-simple-app:v1.0

例：Docker IDが myuser の場合

bash
docker push myuser/my-simple-app:v1.0

Docker CLIがDocker Hubに接続し、イメージをアップロードします。プッシュ時には、イメージを構成する各レイヤーがアップロードされます。すでにDocker Hubに同じレイヤーが存在する場合は、そのレイヤーのアップロードはスキップされます。

bash
The push refers to repository [docker.io/myuser/my-simple-app]
abcdef123456: Pushed
v1.0: digest: sha256:fedcba987654... size: 4567

プッシュが完了しました！

ステップ 6: Docker Hubで確認する

ブラウザでDocker Hubのウェブサイト https://hub.docker.com/ にサインインし、あなたのプロフィールページやリポジトリ一覧を確認してください。

myuser/my-simple-app という新しいPublicリポジトリが作成され、その中に v1.0 というタグのイメージが登録されているはずです。

リポジトリページでは、タグ一覧、Dockerfile（Automated Buildを設定している場合）、脆弱性スキャン結果などを確認できます。

ステップ 7: プッシュしたイメージを別の環境でプルして実行する

これで、あなたがプッシュしたイメージはDocker Hubで公開（またはPrivateリポジトリに保存）されました。別のコンピューターやサーバーでDockerがインストールされていれば、以下のコマンドでこのイメージを取得し、実行できます。

まず、その環境でDocker Hubにログインします（Privateリポジトリの場合）。

bash
docker login

次に、イメージをプルします。

bash
docker pull [あなたのDocker ID]/my-simple-app:v1.0

そして、プルしたイメージでコンテナを実行します。ポート3000をホストのポート8080にマッピングして実行してみましょう。

bash
docker run -p 8080:3000 [あなたのDocker ID]/my-simple-app:v1.0

コンテナが起動したら、ホストマシンのブラウザで http://localhost:8080 にアクセスしてみてください。「Hello, Docker Hub!」と表示されるはずです。

これで、自分で作成したイメージをDocker Hubを介して共有し、利用する一連のワークフローを経験しました。

Docker Hubをより活用するために

Docker Hubを使いこなす上で、さらに理解しておきたい点や、より効果的に活用するためのヒントをご紹介します。

セキュリティのベストプラクティス

コンテナイメージはアプリケーションの配布単位として非常に便利ですが、セキュリティには十分な注意が必要です。

  • ベースイメージの選択: 信頼できる公式イメージやVerified Publisherイメージをベースとして使用しましょう。これらのイメージは定期的に更新され、既知の脆弱性が修正されています。
  • イメージサイズの最小化: 不要なツールやライブラリをイメージに含めないようにしましょう。イメージサイズが小さいほど、攻撃対象となりうる範囲が狭まります。Alpine Linuxのような軽量なベースイメージの利用や、マルチステージビルド（ビルドに必要なツールは最終イメージに含めない）が有効です。
  • ユーザーの利用: コンテナ内でrootユーザーとしてプロセスを実行しないようにしましょう。Dockerfileの USER 命令を使って、権限の少ないユーザーで実行するように設定します。
  • Secret情報の管理: APIキーやパスワードなどの機密情報は、決してDockerfile内やイメージレイヤーにハードコーディングしないでください。シークレット管理ツール（Docker Secrets, Kubernetes Secrets, HashiCorp Vaultなど）を利用しましょう。
  • 脆弱性スキャンの活用: Docker HubのSecurity Scanning（Docker Scout）を利用して、プッシュしたイメージの脆弱性を定期的にチェックしましょう。検出された脆弱性は速やかに修正（ベースイメージの更新、ライブラリのアップデートなど）してください。
  • 信頼できるソースからのプル: イメージをプルする際は、リポジトリ名だけでなく、公式イメージやVerified Publisherであるかを確認しましょう。素性の知れないイメージは安易に利用しないように注意が必要です。

CI/CDパイプラインへの組み込み

前述のWebhooksやAutomated Builds（または外部CIツールでのビルド＋Docker Hubへのプッシュ）を活用することで、開発ワークフローにDocker Hubをシームレスに組み込めます。

  • コードコミットトリガー: Gitリポジトリへのコミットをトリガーとして、CIツールがイメージをビルドし、Docker Hubにプッシュします。
  • プッシュトリガー: Docker Hubへのイメージプッシュをトリガーとして、CDツールがデプロイを実行します。

これにより、ソフトウェアの変更が迅速かつ自動的にテストされ、新しいコンテナイメージとして利用可能になり、本番環境へのデプロイまで自動化される理想的なDevOpsパイプラインが構築できます。

バージョン管理とタグ戦略

タグはイメージのバージョン管理に不可欠です。適切なタグ付け戦略を持つことで、イメージの管理が容易になり、どのイメージがどのバージョンのアプリケーションに対応しているかが明確になります。

  • セマンティックバージョニング: major.minor.patch のようなセマンティックバージョニングに従ってタグを付けるのが一般的です（例: 1.0.0, 1.1.0, 2.0.0）。
  • Gitコミットハッシュ: デバッグや再現性を重視する場合、Gitのコミットハッシュをタグに含めることもあります（例: v1.0.0-abcdef12）。
  • latest タグの注意: latest タグは便利ですが、どのバージョンを指しているか明確でないため、本番環境での利用は避けるべきです。デバッグや最新版の確認など、一時的な利用にとどめましょう。特定の安定版には必ず固定タグ (1.0.0, stable など) を使用します。
  • ブランチ名やビルド番号: 開発中のイメージには、ブランチ名やCI/CDのビルド番号などをタグとして利用することも考えられます。

代替となるコンテナレジストリ

Docker Hubは最も有名で広く利用されているコンテナレジストリですが、唯一の選択肢ではありません。特にエンタープライズ環境や特定のクラウド環境では、他のレジストリが利用されることもあります。

  • 主要クラウドプロバイダーのレジストリ:
    • Amazon Elastic Container Registry (ECR)
    • Google Container Registry (GCR) / Artifact Registry (AR)
    • Azure Container Registry (ACR)
      これらは、各クラウドプラットフォームとの連携が容易で、統合されたセキュリティ機能やIAMによるアクセス制御などを利用できるメリットがあります。
  • その他のレジストリ:
    • Quay.io (Red Hatが提供)
    • GitHub Container Registry (GHCR)
    • GitLab Container Registry
    • JFrog Artifactory など

これらのレジストリもDocker Hubと同様の機能を提供し、プライベートレジストリやCI/CD連携、セキュリティスキャンなどをサポートしています。利用する環境や要件に応じて、最適なレジストリを選択することが重要です。しかし、多くのレジストリはDocker Registry APIと互換性があるため、Docker CLIからの基本的な操作（pull, push）はDocker Hubとほぼ同じように行えます。

よくある質問 (FAQ)

Docker Hubを利用する上でよくある疑問とその回答をまとめました。

Q: Docker Hubは無料でどこまで使えますか？

A: Docker Freeプランでは、Publicリポジトリを無制限に作成できます。Privateリポジトリは通常1つまで作成できます。イメージのプルにはレート制限があります（後述）。Automated BuildsやSecurity Scanningなどの機能には制限がある場合があります。有料プランにすることで、Privateリポジトリ数の増加、レート制限の緩和、チーム機能の強化、高度なビルド/スキャン機能などが利用できるようになります。

Q: イメージの容量制限はありますか？

A: 個々のイメージサイズやリポジトリ全体の容量に対する明示的なハード制限は（無料プランで）あまり強調されていませんが、常識的な範囲での利用が推奨されます。非常に大きなイメージを多数プッシュすると、パフォーマンスの問題やストレージコスト（Docker社側の）に影響する可能性があります。イメージサイズを小さく保つためのDockerfileの最適化は、効率だけでなくコストやセキュリティの観点からも重要です。

Q: Docker Hubのセキュリティは大丈夫ですか？

A: Docker Hub自体は、基本的な認証・認可機能を提供しており、Public/Privateリポジトリの設定によってアクセスを制御できます。ただし、イメージのセキュリティについては、あくまでそのイメージを作成・公開したユーザーや組織に責任があります。信頼できるソース（Official Images, Verified Publisher）のイメージを選択すること、そして自分で作成したイメージは脆弱性スキャンを行うことが重要です。コンテナ実行時のセキュリティは、ホストOSの設定やDockerエンジンの設定、利用するオーケストレーションツール（Kubernetesなど）のセキュリティ対策も合わせて考慮する必要があります。

Q: Automated Buildsは今どうなっていますか？無料で使えますか？

A: Automated Buildsは引き続き利用可能ですが、無料プランでは利用できるBuild Minutes（ビルドにかけられる合計時間）に厳しい制限があります（月あたり極めて少量）。本格的なCI/CDパイプラインでAutomated Buildsを利用するには、実質的に有料プランが必要になります。Docker社はDocker Build Cloudという新しいビルドサービスへの移行を進めています。多くのユーザーは、GitHub ActionsやGitLab CIなどの外部CIツールでイメージをビルドし、その結果をDocker Hubにプッシュするというワークフローを採用しています。

Q: イメージのプル制限 (Rate Limits) にかかりました。どうすればいいですか？

A: Docker Hubでは、匿名ユーザーと認証済み（サインイン済み）ユーザーに対して、一定期間あたりのプル回数に制限を設けています。
* 匿名ユーザー: 6時間あたり最大100回まで
* 認証済み無料ユーザー: 6時間あたり最大200回まで
* 有料プランユーザー: より高い制限または無制限

制限にかかると、イメージのプルができなくなります。これを回避する最も簡単な方法は、Docker CLIや、コンテナを実行する環境（例えば、Kubernetesクラスターのノード）でDocker Hubに認証済みユーザーとしてログインすることです。組織で多数のプルが発生する場合は、有料プランを検討する必要があります。

Q: Privateリポジトリを増やしたいのですが？

A: 無料プランでは通常Privateリポジトリは1つまでです。Privateリポジトリの数を増やしたい場合は、Docker Pro, Team, Businessなどの有料プランにアップグレードする必要があります。

まとめ：Docker Hubをコンテナワークフローの中心に

この記事では、Docker Hubの基本的な概念から始まり、アカウント作成、主要な機能、そしてカスタムイメージの作成・プッシュといった実践的な手順までを詳しく解説しました。

Docker Hubは、コンテナイメージを管理し、共有するためのグローバルなプラットフォームとして、現代のコンテナエコシステムにおいて非常に重要な役割を担っています。

  • 世界中の開発者が公開した公式イメージやVerified Publisherイメージを利用することで、高品質で信頼性の高い基盤イメージを簡単に手に入れることができます。
  • 独自のコンテナイメージを作成し、Docker Hubにプッシュすることで、アプリケーションを簡単に配布・デプロイできるようになります。
  • OrganizationやTeam機能を活用すれば、チームや企業内でのイメージ管理と権限設定を効率的に行えます。
  • WebhooksやBuilds（Build Cloud）を利用することで、CI/CDパイプラインの一部としてイメージのビルドやプッシュを自動化できます。
  • Security Scanningは、イメージの安全性を確認し、リスクを低減するために不可欠な機能です。

Docker Hubを理解し、効果的に利用することは、Dockerを使った開発や運用を成功させるための鍵となります。まずはこの記事で紹介した基本的な操作（検索、プル、プッシュ）を実践し、慣れてきたらOrganizationやWebhooks、Security Scanningといった応用的な機能にも挑戦してみてください。

コンテナ技術の旅は始まったばかりです。Docker Hubをあなたのコンテナワークフローの中心に据え、より効率的で安全な開発・運用を目指しましょう。

さあ、今すぐ docker login して、あなたの最初のイメージをDocker Hubにプッシュしてみましょう！

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール