本ページはプロモーションが含まれています

Docker

Dockerポート設定の「なぜ？」を解決

トム

・都内自社開発IT企業勤務／javaのバックエンドエンジニア
／java歴10年以上 ・首都圏在住30代
・資格：基本情報技術者／応用情報技術者／Java Silver／Python3エンジニア認定基礎

こんにちは、Dockerと日々格闘している現役インフラエンジニアです。

私自身、Dockerを学び始めたころ、この「ポート」の仕組みに何度もつまずきました。「docker runしたのにlocalhostで表示されない」「ポートが競合しているとエラーが出る」など、丸1日悩んだ経験も少なくありません。

しかし、Dockerのポートは「コンテナという仮想的な箱と、PC（ホスト）をつなぐ窓口」という基本さえ押さえれば、決して難解なものではありません。

この記事は、過去の私のように「Dockerのポートがよくわからない」「設定方法を調べても、いまいち仕組みが理解できない」と悩んでいる方に向けて書きました。

この記事を読めば、以下の悩みが解決できます。

  • Dockerでなぜポート設定が必要なのかがわかる
  • 「-p」オプションや「EXPOSE」の正しい使い分けが理解できる
  • よくあるポート関連のトラブルに、自分で対処できるようになる
  • Docker Composeや本番環境での、より実践的なポート設計が学べる

Dockerのポート設定をマスターして、開発効率を格段に上げましょう。

Dockerのポートとは？基本の仕組みをわかりやすく解説

Dockerのポートを理解するには、まずDockerコンテナが「隔離された環境」であると知る必要があります。コンテナは、それ自体が独立した小さなコンピュータのように動作します。

Dockerでポート設定が必要な理由

Dockerコンテナは、デフォルトでは外部（あなたのPCや他のサーバー）から隔離されています。コンテナ内部でWebサーバー（例えばApacheやNginx）を起動しても、そのままではあなたのPCのブラウザからアクセスできません。

なぜなら、コンテナは独自のネットワーク空間を持っているからです。

ポート設定が必要な理由は、この隔離されたコンテナの「特定の窓口（ポート）」を、私たちのPCの「特定の窓口（ポート）」に、意図的につなげるためです。

この「つなげる」作業を「ポートフォワーディング」や「ポートマッピング」と呼びます。

例えば、コンテナ内のポート80を、ホストPCのポート8080につなげる設定をします。

これにより、私たちがPCのブラウザで http://localhost:8080 にアクセスすると、その通信がホストの8080番ポートを経由し、コンテナの80番ポートに自動的に転送されます。結果として、コンテナ内のWebサーバーにアクセスできるわけです。

コンテナ内とホスト側のポートの違い

ここで重要なのが、「ホスト側のポート」と「コンテナ側のポート」は別物であると認識する点です。

ホストポート

  • あなたのPCが持つポート番号です。
  • ブラウザからのアクセスなど、外部からの通信を最初に受け取る窓口となります。
  • localhost:8080 の 8080 がこれにあたります。
  • このポートは、ホストPC上でユニークでなければなりません。他のプロセスが既に使用しているポートは使えません。

コンテナポート

  • Dockerコンテナが内部で持つポート番号です。
  • コンテナ内のアプリケーションが待ち受けているポートです。
  • コンテナ内のポート80（http）やポート443（httpsK）がこれにあたります。
  • このポート番号は、コンテナのイメージ（設計図）によって決まっていることが多いです。

ポート設定とは、この2つの異なるポートを「ホスト:コンテナ」という形で紐付ける作業なのです。

「EXPOSE」「-p」「–publish」の関係を整理

Dockerのポート設定でよく混乱するのが、「EXPOSE」「-p」「–publish」の3つのキーワードです。これらは似ているようで、役割が明確に異なります。

EXPOSE (Dockerfile内の命令)

  • EXPOSE は、Dockerfile内に記述される命令です。
  • 「このコンテナは、このポート番号（例：EXPOSE 80）で通信する予定です」という意思表示のようなものです。
  • EXPOSE を書いただけでは、ホストPCからそのポートにアクセスできるようにはなりません。ポートマッピングは実行されないのです。
  • これは、コンテナを操作する人（や、Docker Composeなどの他のツール）に対して、「このポートを使うと良いですよ」と伝えるためのヒントとして機能します。

-p (docker run のオプション)

  • docker run コマンド実行時に使用するオプションです。
  • これが、実際にホストポートとコンテナポートをマッピングするための、最も重要な命令です。
  • 例えば、docker run -p 8080:80 nginx と実行すると、ホストの8080番ポートへのアクセスが、コンテナの80番ポートへ転送されます。
  • EXPOSE がDockerfileに書かれていなくても、-p オプションを使えば強制的にポートマッピングが可能です。

–publish (docker run のオプション)

  • --publish は、-p の正式名称（ロングフォーマット）です。
  • 機能は -p とまったく同じです。
  • -p は --publish の短縮形（ショートカット）にすぎません。
  • シェルスクリプトなどで可読性を高めたい場合に --publish が使われることもありますが、日常的な操作では短い -p を使うことが圧倒的に多いです。

コンテナを外部に公開したい場合は、必ず -p (または --publish) オプションを使う必要があります。 EXPOSE は、あくまで設計上の目安を示すものだと覚えておきましょう。

docker runの-pオプションの使い方

Dockerでポートを公開する基本は、docker run コマンドの -p オプションです。この使い方をマスターすることが、Dockerポート理解の第一歩となります。

「-p ホスト:コンテナ」形式の意味

-p オプションの最も基本的な書式は 「-p <ホストポート>:<コンテナポート>」 です。

この書式は、「ホスト（PC）の <ホストポート> へのアクセスを、コンテナの <コンテナポート> へ転送する」という意味を持ちます。

具体例 (Nginxを起動する):

docker run -d -p 8080:80 nginx

このコマンドの意味を分解してみましょう。

  1. docker run: コンテナを起動します。
  2. -d: コンテナをバックグラウンドで実行します（デタッチドモード）。
  3. -p 8080:80:
    • 8080（左側）: ホストポートです。あなたのPCの localhost:8080 を指します。
    • 80（右側）: コンテナポートです。Nginxコンテナが内部で待ち受けているポート（デフォルトのHTTPポート）です。
  4. nginx: 起動するイメージの名前です。

このコマンド実行後、ブラウザで http://localhost:8080 にアクセスすると、Nginxコンテナが応答し、おなじみの「Welcome to nginx!」ページが表示されるはずです。

もし -p 3000:80 と指定すれば、http://localhost:3000 でアクセスできるようになります。ホストポート（左側）は、ホストPC上で空いている番号であれば、基本的には何でも構いません。

ポート番号を省略したときの挙動

-p オプションでは、ポート番号の一部を省略する書き方があります。この挙動は少しトリッキーなので、注意が必要です。

ホストポートを省略した場合 (-p <コンテナポート>)

  • 書式: docker run -p 80 nginx
  • これは、Dockerfileの EXPOSE で指定されたポート（この場合、Nginxイメージは80をEXPOSEしている）を公開対象とすることを意味します。
  • しかし、この書き方は非推奨です。現在は -P (大文字) オプションがこの役割を担います。
  • -p 80 のようにコンテナポートだけを指定した場合、Dockerはこれを「ホストポート」として解釈しようとし、コンテナポートが指定されていないとみなすため、多くの場合エラーになるか、意図しない動作をします。

ホストポートを省略 (Dockerにおまかせ) (-p :<コンテナポート> または -P)

  • 書式1: docker run -p :80 nginx (ホスト側を空にする)
  • 書式2: docker run -P nginx (大文字P)
  • これが「ホストポートをDockerに自動で割り当ててもらう」方法です。
  • Dockerは、ホストPCの空いているポート（通常 32,768 以上の高い番号）をランダムに選び、指定されたコンテナポート（この例では80）にマッピングします。
  • どのポートが割り当てられたかは、docker ps コマンドで確認する必要があります。
$ docker ps
CONTAINER ID   IMAGE   ...   PORTS
a1b2c3d4e5f6   nginx   ...   0.0.0.0:32768->80/tcp

上記の場合、ホストの 32768 番ポートがコンテナの 80 番に割り当てられたことがわかります。

この方法は、複数のコンテナを同時に起動するテストなどで、ポート競合を自動的に避けたい場合に便利です。

ホストIPを指定する場合 (-p <IP>:<ホストポート>:<コンテナポート>)

  • docker run -p 127.0.0.1:8080:80 nginx
  • このように、ホストポートの前にIPアドレスを指定することも可能です。
  • 127.0.0.1 は localhost (自分自身) を意味します。
  • この設定は、「ホストPCの 127.0.0.1 (つまり localhost) の 8080 番ポート」だけをコンテナにつなげます。
  • もしホストPCが複数のIPアドレス（例: Wi-Fi用と有線LAN用）を持っている場合、特定のIPアドレスからのアクセスのみを許可したい場合に利用します。
  • IPを省略すると、デフォルトで 0.0.0.0（ホストのすべてのIPアドレス）が指定されたことになり、外部ネットワークからもアクセス可能になるため、セキュリティ上はこちらが望ましい場合もあります。

複数ポートを指定する場合の注意点

1つのコンテナが複数のポートを公開する必要がある場合（例: Webサーバーの80番と、管理画面の8081番）、-p オプションを複数回指定するだけです。

書式:

docker run -p <ホストポート1>:<コンテナポート1> -p <ホストポート2>:<コンテナポート2> [イメージ名]

具体例:

docker run -d \
  -p 8080:80 \
  -p 8443:443 \
  my-web-server

この例では、以下の2つのマッピングを同時に設定しています。

  1. ホストの 8080 番を、コンテナの 80 番（HTTP）につなぐ
  2. ホストの 8443 番を、コンテナの 443 番（HTTPS）につなぐ

注意点として、当然ながら、指定するホストポート（左側）は、すべて異なる番号で、かつホストPC上で空いている必要があります。

もし 8080 番ポートをすでに別のコンテナやプロセスが使用している場合、docker run コマンドは「port is already allocated（ポートはすでに割り当て済みです）」というエラーを出して失敗します。

よくあるDockerポートトラブルと解決策

Dockerを使い始めた人が必ず遭遇するのがポート関連のトラブルです。「設定したはずなのに、なぜか繋がらない」という状況は、非常によくあります。しかし、原因の多くは基本的な確認漏れです。

localhostにアクセスできない原因

docker run -p 8080:80 ... と実行したのに、ブラウザで http://localhost:8080 を開いても「このサイトにアクセスできません」と表示される。これは最も多いトラブルです。

原因はいくつか考えられます。

コンテナ内のアプリケーションが起動していない

  • ポートマッピングは正常でも、肝心のコンテナ内部でWebサーバーが起動に失敗しているケースです。
  • 解決策: docker logs <コンテナIDまたは名前> コマンドを実行し、コンテナのログを確認します。
  • ログに「Error」や「Failed」などの文字がないか、設定ファイル（Nginxの nginx.conf など）のミスで起動できていないかを確認します。

コンテナ内のアプリケーションが「127.0.0.1」で待ち受けている

  • コンテナ内のアプリが、コンテナ自身の localhost (つまり 127.0.0.1) だけで待ち受けている場合があります。
  • ポートフォワーディングは、コンテナの「外」から「中」への通信です。アプリが 127.0.0.1 (コンテナ内) でしか待っていないと、外からの通信を拒否してしまいます。
  • 解決策: アプリケーションの設定を見直し、0.0.0.0（すべてのIPアドレス）で待ち受けるように変更します。
  • 例えば、PythonのFlaskなら app.run(host='0.0.0.0')、Node.jsなら server.listen(PORT, '0.0.0.0') のように設定します。

Docker for Mac / Windows の仮想化の問題 (古いバージョン)

  • (最近は稀ですが) 以前のDocker Desktopでは、localhost ではなく、Dockerが内部で持つ特定のIP (docker-machine ip など) を使う必要がありました。
  • 解決策: Docker Desktopを最新版にアップデートします。現在のバージョンでは、localhost でのアクセスが標準です。

ファイアウォール

  • ホストPCのファイアウォール（Windows Defenderや、サードパーティ製のセキュリティソフト）が、指定したホストポート（例: 8080）へのアクセスをブロックしている場合があります。
  • 解決策: 一時的にファイアウォールを無効にしてアクセスできるか試します。もしアクセスできたら、ファイアウォールに「ポート8080を許可する」ルールを追加します。

ポートがすでに使われているときの対処法

docker run を実行した際に、以下のようなエラーが出ることがあります。

docker: Error response from daemon: driver failed programming external connectivity ...
Bind for 0.0.0.0:8080 failed: port is already allocated.

これは「ホストポートの8080番は、すでに他の誰か（プロセス）が使っています」という明確なエラーです。

解決策1: 使用中のプロセスを特定して停止する

  • まず、どのプロセスがそのポートを使っているか特定します。
  • macOS / Linux:sudo lsof -i :8080
  • Windows (コマンドプロンプト):netstat -aon | findstr ":8080" (表示されたPIDをタスクマネージャーで確認します)
  • もし、そのプロセスが不要なもの（例えば、以前起動したまま停止し忘れていた別のDockerコンテナや、開発サーバー）であれば、そのプロセスを停止 (kill) します。
  • docker ps を実行し、停止すべきコンテナが残っていないかも確認しましょう。

解決策2: 別のホストポートを使う

  • もし使用中のプロセスを停止できない場合、docker run で指定するホストポート（左側）を変更します。
  • エラーが出たコマンド: docker run -p 8080:80 nginx
  • 変更後のコマンド: docker run -p 8081:80 nginx
  • このように、空いている別のポート（例: 8081）を指定すれば、競合を避けられます。この場合、ブラウザからは http://localhost:8081 でアクセスすることになります。

ポートフォワーディングが反映されないときに確認すべき設定

-p オプションを変更したのに、古い設定のまま動いているように見える（または繋がらなくなる）場合があります。

コンテナの再起動ではなく「再作成」が必要

  • docker run の -p オプションで指定したポートマッピングは、コンテナの作成時に決定されます。
  • docker stop して docker start で再起動しただけでは、ポート設定は変更されません。
  • 解決策: ポート設定を変更したい場合は、古いコンテナを docker rm <コンテナID> で削除 (rm) してから、新しいポート設定で docker run し直す（再作成する）必要があります。
  • docker run は、常に新しいコンテナを作成するコマンドだと意識することが重要です。

Docker Desktop (Windows/Mac) の再起動

  • 稀に、Docker Desktop自体のネットワーク設定に不具合が生じているケースがあります。
  • 解決策: PCやDocker Desktopを再起動すると、ネットワーク設定がリセットされ、正常に反映されることがあります。

docker ps で現状の確認

  • 思い込みは禁物です。必ず docker ps コマンドを実行し、PORTS の欄を確認します。
  • 0.0.0.0:8080->80/tcp となっていれば、ホストの8080がコンテナの80にマッピングされています。
  • もしここが 80/tcp (ホスト側のマッピングがない) や、意図しないポート番号になっていれば、run コマンドが間違っているか、コンテナの再作成ができていません。

Docker Composeでポートを設定する方法

複数のコンテナ（例: Webサーバーとデータベース）を連携させる場合、docker run コマンドを何度も打つのは非効率です。そこで docker-compose.yml という設定ファイルで管理する Docker Compose を使います。

docker-compose.ymlのportsセクションの書き方

Docker Composeでポートマッピングを行うには、docker-compose.yml ファイル内の、各サービス定義（services:）の下に ports: セクションを追加します。

書き方は docker run -p とほぼ同じですが、YAMLのリスト形式（ハイフン -）で記述します。

書式 (YAML):

services:
  web:
    image: nginx
    ports:
      - "8080:80"  # ホストポート 8080 を コンテナポート 80 にマッピング

docker run -p 8080:80 nginx と実質的に同じ意味になります。

複数のポートを指定する場合:

services:
  myapp:
    image: my-app-image
    ports:
      - "3000:3000" # アプリケーション用
      - "9229:9229" # デバッグ用

このように、リスト形式で必要なだけマッピングを追加できます。

ホストIPを指定する場合 (localhostのみ):

    ports:
      - "127.0.0.1:8080:80" # ホストのlocalhost:8080のみ

環境ごとにポート番号を切り替える方法

開発環境（localhost）では 8080 番を使いたいが、ステージング環境では 9000 番を使いたい、といったニーズはよくあります。

docker-compose.yml では、環境変数を使ってポート番号を動的に変更するのが一般的です。

.env ファイルの用意

プロジェクトのルートに .env というファイルを作成し、そこで変数を定義します。

WEB_HOST_PORT=8080

docker-compose.yml で変数を参照

ports: セクションで、${変数名} という書式で参照します。

docker-compose.yml:

services:
  web:
    image: nginx
    ports:
      - "${WEB_HOST_PORT}:80"

使い方:

  • docker-compose up を実行すると、Composeは自動的に .env ファイルを読み込みます。
  • WEB_HOST_PORT に 8080 がセットされ、結果的に ports: ["8080:80"] として解釈されます。

もし、ステージング環境でポートを変えたい場合は、その環境の .env ファイル（または環境変数）で WEB_HOST_PORT=9000 と設定するだけで、docker-compose.yml 本体を修正する必要がありません。

Composeで「EXPOSE」と「ports」の違い

docker-compose.yml にも expose: というセクションがあり、Dockerfileの EXPOSE と似た役割を持ちます。

ports: (ポートマッピング)

  • ホストPCとコンテナを接続します。
  • ホストPCのポート（例: 8080）を占有します。
  • ホストPCからアクセス可能になります。

expose: (Compose内部のポート公開)

  • ホストPCには接続しません。ホストのポートも占有しません。
  • コンテナポート（例: 3306）を、Docker Composeで管理されている他のコンテナ（同じネットワーク内）に対してのみ公開します。
  • 例えば、web コンテナと db (MySQL) コンテナがあるとします。
  • db サービスに expose: ["3306"] と設定します（ports: は設定しません）。
  • これにより、web コンテナは db コンテナの 3306 番ポートに db:3306 という名前でアクセスできます。
  • しかし、ホストPCから db の 3306 番ポートには直接アクセスできません。

使い分け:

  • ports:: ブラウザなど、ホストPCからアクセスさせたい場合。
  • expose:: コンテナ同士の通信にしか使わないポートの場合。

セキュリティの観点から、データベースのポートなどを不必要にホストPCに公開しないために、expose: を適切に使うことが推奨されます。

本番環境でのDockerポート設計の考え方

開発環境では localhost:8080 のような設定で問題ありませんが、本番環境では、セキュリティや拡張性を考慮したポート設計が不可欠です。

セキュリティ上の注意点（不要なポートを開けない）

本番環境における最大の原則は「不要なポートは開けない（公開しない）」です。

開発中にデバッグ用に使っていたポート（例: 9229）や、データベースのポート（例: 3306, 5432）、キャッシュサーバーのポート（例: 6379）などを、ports: を使って本番サーバーのグローバルIPに公開してはいけません。

これらは攻撃者にとって格好の標的となります。

対策:

  • ports: は必要最小限に: ユーザーにWebページを見せるためのポート（HTTPの80番、HTTPSの443番）以外は、原則として ports: でホストにマッピングしません。
  • expose: と内部ネットワークの活用: データベースやキャッシュサーバーは、expose: を使い、Dockerの内部ネットワーク（docker-compose が自動で作成するネットワーク）内でのみ通信させます。
  • ホストIPの指定: もし万が一、特定のポート（例: SSH管理用ポート）をホストにマッピングする必要がある場合でも、0.0.0.0（全開放）ではなく、127.0.0.1（サーバー内部からのみ）や、特定の管理用IPアドレスからのみアクセスできるように ports: ["127.0.0.1:2222:22"] のようにIPをバインドします。

Nginxなどリバースプロキシを使う場合のポート設計

本番環境では、アプリケーションコンテナ（Node.js, Python, Rubyなど）を直接インターネットに公開することは稀です。

通常、手前に Nginx や Apache などのWebサーバーを「リバースプロキシ」として配置します。

リバースプロキシの役割:

  1. 外部からのHTTP(80) / HTTPS(443) のアクセスをすべて受け取る。
  2. SSL/TLS（暗号化）の処理を一手に引き受ける。
  3. 静的ファイル（画像、CSS、JS）を高速に配信する。
  4. 必要に応じて、アプリケーションコンテナ（例: localhost:3000 で待機）にリクエストをプロキシする。

この構成でのポート設計:

  1. リバースプロキシ (Nginx) コンテナ:
    • ports: を使い、ホストの 80 番と 443 番をコンテナにマッピングします。これがインターネットへの唯一の窓口です。
    • ports: ["80:80", "443:443"]
  2. アプリケーション (App) コンテナ:
    • ports: は使いません。ホストPCにポートを公開する必要はありません。
    • expose: を使い、コンテナが待ち受けるポート（例: 3000）を内部ネットワークに公開します。
    • expose: ["3000"]
  3. Nginxの設定:
    • Nginxの設定ファイル ( nginx.conf ) で、リクエストが来たら http://app:3000 （app はDocker Composeでのサービス名）にプロキシするように設定します。

この設計により、アプリケーションコンテナは外部ネットワークから完全に隠蔽されます。すべての通信はNginxコンテナを経由するため、セキュリティが向上し、負荷分散やSSL管理もNginxコンテナに集約できます。

ポート競合を防ぐ命名・管理のコツ

1台のホストマシンで複数のプロジェクト（複数の docker-compose.yml）を動かすと、ホストポートの競合が頻発します。「Aプロジェクトを起動したら、BプロジェクトのWebサーバーが使う8080番と競合した」といった問題です。

対策1: .env によるポート管理の徹底

  • 前述の通り、ホストポートは docker-compose.yml に 8080 のように直書きするのをやめます。
  • 必ず ${WEB_PORT} のように環境変数経由で指定し、プロジェクトごとに .env ファイルで管理します。
  • Aプロジェクト/.env: WEB_PORT=8080
  • Bプロジェクト/.env: WEB_PORT=8081
  • これにより、設定ファイル本体（yml）を変更することなく、ポート番号を簡単に切り替えられます。

対策2: プロジェクトごとの命名規則（プレフィックス）

  • ポート番号に、プロジェクトを識別するためのプレフィックスをつけるルールも有効です。
  • 例えば、「プロジェクトAは 10000番台」「プロジェクトBは 11000番台」のように決めます。
  • プロジェクトA (Web): 10080
  • プロジェクトA (DB): 10306
  • プロジェクトB (Web): 11080
  • これなら、ポート番号を見ただけでどのプロジェクトか判断でき、競合も防げます。

対策3: ホストポートを使わずリバースプロキシに集約

  • 最もクリーンな方法は、開発環境であっても、すべてのプロジェクトの前に「全体を管理するリバースプロキシ」を1つだけ立てることです。
  • ホストPCの80番ポートは、その管理用Nginxだけが使います。
  • 各プロジェクト（A, B）は、ホストポートを一切公開しません（expose: のみ）。
  • 管理用Nginxが、a.localhost へのアクセスはAプロジェクトのコンテナへ、b.localhost へのアクセスはBプロジェクトのコンテナへ、といった具合に、ドメイン名（ホスト名）ベースで通信を振り分けます。
  • docker run -p 8080... のようなポート指定が不要になり、ポート競合は根本的になくなります。これは本番環境に非常に近い、理想的な開発環境と言えます。

まとめ：Dockerのポート設定は“仕組みの理解”が近道

Dockerのポート設定は、最初は難しく感じるかもしれません。しかし、基本は「隔離されたコンテナの窓口」と「ホストPCの窓口」を、-p オプションや ports: 設定で「紐付ける」だけです。

トラブルの9割は「ポートの対応関係」で起きている

私が経験してきたDockerのポートトラブルの9割は、以下の3つのどれかに当てはまりました。

  1. ホストとコンテナを逆に指定している (-p 80:8080 とすべきところを -p 8080:80 にしている)
  2. ホストポートがすでに使われている (別のコンテナやプロセスと競合している)
  3. コンテナ内のアプリが 0.0.0.0 で待機していない (localhost でしか待っておらず、外からの通信を受け付けない)

「繋がらない」と焦ったときは、まず docker ps を実行し、PORTS 欄が自分の意図したマッピング（例: 0.0.0.0:8080->80/tcp）になっているかを確認する癖をつけましょう。

覚えておきたいコマンドとチェック手順

最後に、ポートトラブル時に確認すべきコマンドと手順をまとめます。

1. docker ps (コンテナのポートマッピング確認)

  • PORTS 欄を確認します。0.0.0.0:XXXX->YYYY/tcp となっているか？

2. docker logs <コンテナ名> (コンテナ内部のログ確認)

  • コンテナ内のアプリケーションが正常に起動しているか？ Error はないか？
  • 「Listening on http://localhost:3000」となっていないか？ (→ 0.0.0.0 にすべき)

3. lsof -i :<ホストポート> (Mac/Linux) または netstat -aon | findstr ":<ホストポート>" (Windows)

  • ホストポートを他のプロセスが使っていないか？
  • 競合しているなら、そのプロセスを止めるか、ホストポートの番号を変えます。

4. docker rm <コンテナ名> → docker run ... (再作成)

  • ポート設定を変更したら、docker startではなく、必ず docker rm してから docker run します。

Dockerのポート設定は、コンテナを外部の世界とつなげるための重要な架け橋です。仕組みを理解し、正しく設定することで、Dockerはあなたの開発を強力にサポートしてくれるでしょう。

  • この記事を書いた人
  • 最新記事

トム

・都内自社開発IT企業勤務／javaのバックエンドエンジニア
／java歴10年以上 ・首都圏在住30代
・資格：基本情報技術者／応用情報技術者／Java Silver／Python3エンジニア認定基礎

-Docker