Answers: <p>When you instantiate a new container it has its own networking, isolated from the host. So you can NOT access the container directly from its port.</p>
  
  <blockquote>
    <p>ports:
      - 8080:80</p>
  </blockquote>
  
  <p>this command will specify that you are fowarding your host port to the container port.
  In your local host in the port 8080 will call the port 80 of your container.</p>
  
  <p>There are some ways to do it, for example using traefik to execute the reverse proxy inside the containers, you can address all containers to a network, exposing only the port of traefik, so you can access all containers executing the router rule that u have specified.</p>
  
  <p>The simple answer is:</p>
  
  <p>'Cause it's the easiest way to access a service from a container.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-27T18:04:05.323Z
Answers: 2018-03-27T18:04:05.323Z
Answers: Lucas Fantacucci
Answers: <h2>TL;DR</h2>
  
  <p>There are a number of use cases for port mapping, but for DevOps at scale the primary reason is generally to enable mapping well-known service ports to available ports on the host. This matters when you're running large numbers of containers that use the same port by default, and you don't want to manually assign or track alternative port numbers.</p>
  
  <h2>A <em>Very</em> Short Port Primer</h2>
  
  <p>As a general rule, a port can only map to a single service or process on each host (multiplexing ports and multi-port services are something of an exception). Only 65,536 ports are available for services to bind, with the lowest 1,024 generally reserved for binding by the root user. Services also typically bind to well-known ports such as 22, 53, or 5432 to make the service easy to find. All of these issues matter, but it's often the last issue that typically concerns Docker hosts most.</p>
  
  <h2>Mapping Container Ports</h2>
  
  <p>Imagine that you have multiple PostgreSQL containers on a single host. By default, each wants to bind to port 5432 as its default. While you could certainly modify each container or run-command to bind the container's service to a unique host port, this quickly becomes a hassle at scale.</p>
  
  <p>Instead, Docker and other container managers make it easy to <em>map</em> ports between the host OS and the container. For example:</p>
  
  <pre><code># launch three PostgreSQL instances
  for i in {1..3}; do
      docker run --rm -d -P postgres:alpine
  done
  
  # show port mappings for each container
  docker container ls -q --filter="ancestor=postgres:alpine" |
      xargs -n1 docker port
  5432/tcp -&gt; 0.0.0.0:32773
  5432/tcp -&gt; 0.0.0.0:32772
  5432/tcp -&gt; 0.0.0.0:32771
  </code></pre>
  
  <p>This shows that you have three instances of PostgreSQL, all happily listening on the default port of 5432 <em>inside</em> their containers. However, each instance is listening on a different port (32771, 32772, and 32773) on the Docker host!</p>
  
  <p>At scale, you would typically use DNS, autodiscovery, linking, or container networking to help clients and applications find the right PostgreSQL instance to connect with. With just a few instances running, parsing <code>docker ps</code> may be sufficient for your needs. Your specific use case may vary.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-27T12:31:53.617Z
Answers: 2018-03-27T12:31:53.617Z
Answers: CodeGnome
Body: <p>I have been using docker for a few months and I am just a developer not a DevOps or a networking person. However, I came across a <code>docker-compose</code> which maps an external port to an internal port. Something like in this <a href="https://docs.docker.com/compose/compose-file/#endpoint_mode" rel="nofollow noreferrer">compose file</a>
  where it says:</p>
  
  <pre><code>ports:
    - 8080:80
  </code></pre>
  
  <p>My question is WHY? Why do we need to map an external port to internal port. Some of the explanation that I came across was that if you want to not expose a particular port to the user but use it internally. That also begs the same question: what would be a real life example of someone wanting to do this and why?</p>
  
Tags: <docker><docker-compose><networking>
Title: Why should you do port mapping for docker containers?
UserDisplayName: Lost
ThreadText: # Why should you do port mapping for docker containers?
  
  (Asked by: username_0 on 2018-03-27)
  
  I have been using docker for a few months and I am just a developer not a DevOps or a networking person. However, I came across a `docker-compose` which maps an external port to an internal port. Something like in this [compose file](https://docs.docker.com/compose/compose-file/#endpoint_mode)
  where it says:
  
  ```
  ports:
    - 8080:80
  
  ```
  
  My question is WHY? Why do we need to map an external port to internal port. Some of the explanation that I came across was that if you want to not expose a particular port to the user but use it internally. That also begs the same question: what would be a real life example of someone wanting to do this and why?
  
  **Tags:** docker, docker-compose, networking
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-03-27. Score: 9 | Accepted answer
  
  ## TL;DR
  
  There are a number of use cases for port mapping, but for DevOps at scale the primary reason is generally to enable mapping well-known service ports to available ports on the host. This matters when you're running large numbers of containers that use the same port by default, and you don't want to manually assign or track alternative port numbers.
  
  ## A *Very* Short Port Primer
  
  As a general rule, a port can only map to a single service or process on each host (multiplexing ports and multi-port services are something of an exception). Only 65,536 ports are available for services to bind, with the lowest 1,024 generally reserved for binding by the root user. Services also typically bind to well-known ports such as 22, 53, or 5432 to make the service easy to find. All of these issues matter, but it's often the last issue that typically concerns Docker hosts most.
  
  ## Mapping Container Ports
  
  Imagine that you have multiple PostgreSQL containers on a single host. By default, each wants to bind to port 5432 as its default. While you could certainly modify each container or run-command to bind the container's service to a unique host port, this quickly becomes a hassle at scale.
  
  Instead, Docker and other container managers make it easy to *map* ports between the host OS and the container. For example:
  
  ```
  # launch three PostgreSQL instances
  for i in {1..3}; do
      docker run --rm -d -P postgres:alpine
  done
  
  # show port mappings for each container
  docker container ls -q --filter="ancestor=postgres:alpine" |
      xargs -n1 docker port
  5432/tcp -> 0.0.0.0:32773
  5432/tcp -> 0.0.0.0:32772
  5432/tcp -> 0.0.0.0:32771
  
  ```
  
  This shows that you have three instances of PostgreSQL, all happily listening on the default port of 5432 *inside* their containers. However, each instance is listening on a different port (32771, 32772, and 32773) on the Docker host!
  
  At scale, you would typically use DNS, autodiscovery, linking, or container networking to help clients and applications find the right PostgreSQL instance to connect with. With just a few instances running, parsing `docker ps` may be sufficient for your needs. Your specific use case may vary.
  
  
  ---
  
  ### Answer by username_1 on 2018-03-27. Score: 3
  
  When you instantiate a new container it has its own networking, isolated from the host. So you can NOT access the container directly from its port.
  
  > ports:
  > - 8080:80
  
  this command will specify that you are fowarding your host port to the container port.
  In your local host in the port 8080 will call the port 80 of your container.
  
  There are some ways to do it, for example using traefik to execute the reverse proxy inside the containers, you can address all containers to a network, exposing only the port of traefik, so you can access all containers executing the router rule that u have specified.
  
  The simple answer is:
  
  'Cause it's the easiest way to access a service from a container.
  
  
  ---
  
  