I am not server admin and I often face server related issues with ports and ssh and such stuff. The problem that I am facing right now is with homestead and docker.
I have a laravel application running on homestead. But now I also need to run Process Maker too in homestead so that I can call their APIs from my application and use the data. So I found a docker image eltercera/docker-processmaker which runs well on my mac and tested the APIs and they are working fine.
I run the image with this command:
docker run -d -e "[email protected]" -p 80:80 --name some-pkm eltercera/docker-processmaker/
And it runs well. But now when I installed the docker-engine on my homestead machine and tried the same, I got the following error:
docker: Error response from daemon: driver failed programming external connectivity on endpoint some-pkm (dee715e3d7bf47d48f6fbb4a8ba1418009b1a811ef043e18fb232132ec3b6a2d): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use.
It says 0.0.0.0:80: bind: address is already in use. Now I am not sure what this means and how to resolve this and use the application inside my homestead machine. Is this somehow related to port forwarding? I can run the machine using -p as a 90:90 but I don't know how will access it then.
Can someone explain to me what I am missing here and what I need to learn before moving forward?
EDIT
I tried:
docker run -d -e "[email protected]" -p 90:80 -h processmaker.app --name some-pkm eltercera/docker-processmaker/
And edited my /etc/hosts file on mac and now I can do processmaker.app:90 in my browser and it works. But this was like hit and try. I still don't understand how I solved it.
You solved it by saying -p 90:80.
What this does is expose the internal port 80 of your Docker container (the one that your webserver listens on inside of the container) as port 90 on your host computer (so that you can go to http://processmaker.app:90 in your browser).
Because of this convenient feature (Docker-controller virtual network stacks), your application can use its default port and you can map that to any free port on the "real" network. You can do more complicated things as well, such as exposing ports only to other containers and not to the outside at all.
The reason -p 80:80 did not work is that the "real" port 80 was already in use.
The reason -p 90:90 did not work is that the container application listens on its virtual port 80, and exposing port 90 does not do anything useful (nothing connected to it inside the container).
You could make -p 90:90 work by re-configuring the containerized webserver to listen on port 90 instead of port 80. That is what you would do with a non-containerized application, but with Docker you can just run everything with default settings (ports, file system paths, etc) and wire things together outside of the application when you start the containers (fancy word for this: orchestration).