Panamax v0.2.3 brings some great changes to networking and port bindings that will make your time using Panamax even better. Panamax can now create a private network for you, and we've added support for automatic port mapping. Gone are the days of manually configuring your VM in order to peer into your Docker containers.
###The old way Prior to version 0.2.1, accessing your Panamax application on your local machine could be a bit of a hassle. We relied on the NAT adaptor and leveraged port forwarding to access CoresOS and the Panamax UI and API. This added some extra steps in order for you to access the applications running in Panamax.
In order to see your Docker container, you needed to add an additional port forwarding rule on the VM where Panamax runs, either by way of the VBoxManage command or via the VirtualBox GUI. You needed to port forward from your localhost to the host port on CoreOS, then to the port on the container.
Our own documentation for port forwarding demonstrates the complexity and time consumption to get this right.
###Using the Private Network Since version 0.2.1, the Panamax Installer now runs the CoreOS virtual machine with a Host-only Adaptor that uses a private network. By default, the CoreOS VM is accessible on port 10.0.0.200, with Panamax running on 10.0.0.200:3000.
NOTE: this only affects our desktop versions that leverage VirtualBox, not versions running Panamax directly on a cloud provider.
With our new method, you can access your Panamax applications simply using the assigned IP (10.0.0.200) and specifying the appropriate host port on CoreOS. For example, if you have the following host to container port binding: 8080 : 80 / TCP on your Wordpress web service, you can access your GUI using the private IP address: http://10.0.0.200:8080.
Even better, if you opted for Panamax to create an alias (panamax.local) for the private IP during installation or reinstallation, you just made your life even easier! You can now access that same application via that domain: http://panamax.local:8080.
By using this private network, along with the automatic port mappings outlined below, you only need to specify what container port you want available. Panamax and Docker will take care of exposing it, binding it to a port on your host, and then you'll be able to access it right from your browser -- without touching your VirtualBox at all.
Along with a private network, using automatic port mappings will help make your development with Panamax rather frictionless. When declaring a port binding rule, Docker will automatically assign a host port for you if you provide only a container port. In the UI, add a new port binding rule by clicking the 'Bind a Port' button. To allow Docker to auto-assign a host port, simply leave that field blank.
While the container is restarting, any mapped endpoint -- even those with static host ports -- will be unavailable.
Panamax continuously checks service status, and the page will auto-update as your container rebuilds. After your container enters running state, Docker will have provided a host port; that host port will be bound to the container port you have specified.
It is important to note that auto-assigned ports change each time the container restarts for any reason. Therefore, if your workflow depends on a known host port, you should declare it when setting the rule.
If your port mapping rule exposes a GUI, you can now click the link in the Port Mappings section to view the GUI in your browser, as described in the Private Networking section above.
With v0.2.3, you can see ports exposed by the container's base image right on the service details page. A port can be exposed to all other containers on the same host in two ways: the container's base image can including an EXPOSE rule in the Dockerfile, or you can expose a port via the Panamax UI, which uses the docker run flag --expose to expose the port at the time your container is run. Panamax previously displayed only ports exposed via docker run --expose.
Ports that have been exposed by the base image are noted as such with 'exposed by base image' appearing in lieu of a delete button. You can add a specific port mapping to a port exposed via the Dockerfile, but you may not delete the rule because it came from the base image.
In short, any port that has a port binding rule is exposed as well. When you declare a port binding rule using -p, docker will implicitly --expose that port as well; however, that --expose string is not included in the docker run command because it is redundant. Think of exposed ports as rectangles and bound ports as squares -- every bound port is exposed, but not every exposed port is bound. You need not first expose a port before defining a binding rule for it; Docker's got your back on that one.
Instead of saying: Local --> CoreOS --> Docker Container.
Use the image:
Consider a sub title : New and Improved
prior to the "With our new method, you can access" paragraph