i cannot understand one thing -
when we run docker on our computers, we have to specify "port mapping" e.g. docker run my-image -p 4000:3000
now we can access it on localhost:4000 (3000 is the docker container's port, 4000 host port)
so why do we need to process.env.PORT on our nodejs app ?
all we need to do is have node listen on any port (lets say 3000), then specify "port mapping" -p $PORT:3000 ($PORT is the port which heroku provides)
The objective of having the PORT environment variable in your node application is that you can specify a dynamic port to run your app and that is the best way to make sure that your container and your app are using the same port to communicate with each other. We usually run the docker application through a docker-compose.yaml file, or maybe your application can be managed by an orchestrator which will for sure require a dynamic environment variable to define the ports.
In conclusion, basically having a port defined via an environment variable provides a unified way to declare which port your app should be running.
what if i wanted to run all 3 containers on the same app?
in my local development mode, all 3 containers run on their own port 3000.
i tied my host port 3000 to the reverse proxy container's port 3000
so now from my host, only reverse proxy is accessible, and i only needed one port to run 3 containers.
but in heroku, if i tie one container to the $PORT, what about the other 2 containers?
so i didnt want to run all the containers on the $PORT provided by heroku.
I don't think Heroku is an effective microservices orchestration tool. You might want to try something like Okteto or Fly.io. (A lot of people like Heroku because it's a free VPS; the ones I mentioned are too.) I've got a working example of the reverse proxy in docker code up on Okteto. Fly works sometimes and other times it's tricky. I didn't bother trying to get it to work there. But here's a link to a recent poast and it also has the git repo and the example. Have a good one.
i cannot understand one thing -
when we run docker on our computers, we have to specify "port mapping" e.g. docker run my-image -p 4000:3000
now we can access it on localhost:4000 (3000 is the docker container's port, 4000 host port)
so why do we need to process.env.PORT on our nodejs app ?
all we need to do is have node listen on any port (lets say 3000), then specify "port mapping" -p $PORT:3000 ($PORT is the port which heroku provides)
am i missing something?
The objective of having the
PORTenvironment variable in your node application is that you can specify a dynamic port to run your app and that is the best way to make sure that your container and your app are using the same port to communicate with each other. We usually run the docker application through adocker-compose.yamlfile, or maybe your application can be managed by an orchestrator which will for sure require a dynamic environment variable to define the ports.In conclusion, basically having a port defined via an environment variable provides a unified way to declare which port your app should be running.
to make sure that your container and your app are using the same port to communicate with each other.actually, i wanted to run 3 containers on the same app -
i ultimately went on to make 3 separate heroku apps, one for each container, which works absolutely fine.
what if i wanted to run all 3 containers on the same app?
but in heroku, if i tie one container to the $PORT, what about the other 2 containers?
so i didnt want to run all the containers on the $PORT provided by heroku.
Do you have a git repo with your code for the containerized reverse proxy?
github.com/shameekagarwal/gql
three different heroku apps frontend (in react, served via nginx), backend (in expressjs), and a reverse proxy (nginx)
I don't think Heroku is an effective microservices orchestration tool. You might want to try something like Okteto or Fly.io. (A lot of people like Heroku because it's a free VPS; the ones I mentioned are too.) I've got a working example of the reverse proxy in docker code up on Okteto. Fly works sometimes and other times it's tricky. I didn't bother trying to get it to work there. But here's a link to a recent poast and it also has the git repo and the example. Have a good one.
dev.to/bronifty/nginx-reverse-prox...
thanks!!
my example does work..but heroku isnt for container orchestration..just deploy containers..