<p>I'm in the process of containerizing our microservice architecture. Our microservice consists of 10 express.js apps, One frontend, and and nginx reverse proxy. Managing ports seems to be a nightmare and want to know the best practice - dynamic port mapping or using same ports for the Express service. Is it best to use same container port (80 or 3000) for the backend services or to use a dynamic port mapping and environment variables for ports and then use variables in the configuration/yaml files?</p>
<p>*We would want to scale to other orchestration systems (K8's)</p>
<p>Initially we have been assigning ports at Docker runtime in the docker file and in the compose/config files but it seems to be overkill and a hassle to manage. Have been seeing examples of using same port for container and exposing a different port to host</p>

Cortez Black
<p>In containerized systems it isn't a problem to just use the same port for every service as every container/pod gets a unique IP. The advantage of this is easy management while deploying the services. One problem with this approach is local development, because developers often want to run microservices outside of docker. This can be mitigated by local developer configuration, which specifies different ports for the services.</p>
<p>Another approach especially in a microservice architecture is service discovery with tools such as etcd, consul or zookeeper. Using this approach all ports are dynamically and discovered by the services and can be freely chosen by the microservice developers.</p>
<p>Usually ports are not directly exposed to the host, because you want to have a loadbalancer in front of services.</p>
