I was starting from a point where my local development and remote production environments consisted of:

• Various Apache httpd webservers on laptop, desktop, RPi and EC2 instances.
• Each web server with tightly coupled LAMP stack modules such as PHP interpreter and MySQL Server.
• Each web server configured to serve multiple project sites.

Questions:

• How could migration to containerisation change my development workflows?
• What will my adoption path look like?
• Would I have to rewrite source code to adapt web applications to a new development and production environments?

My research learning process was roughly this:

1. Read a book.
2. Browse through some online docker docs documentation.
3. Watch some online videos.
4. Install Docker and do the practice exercises from the book.

The following is a brief discussion of one issue raised by that research learning process, regarding my migration to the Docker system of containerisation.

In my current development environment, each webserver has been configured with a Name-Based virtual host (vhost) for each site project. Apparently, one of the reasons the Apache webserver first became so popular on the web was this ability to host serveral isolated web sites on the same physical host, using the concept of virtual hosts.

Questions:

• Can this useful Name-Based virtual hosting practice be migrated to a containerised web server? Does it need to be?

I'll now briefly review how a development website hosted on my local network is accessed from any browser on the same network. The same would apply to a browser and webserver on the same physical host machine.

When I enter the URL of a site hosted on my local network into the browsers' address bar, there must be use some local DNS resolution of the hostname part. There are a stack of dns resolution options. Closest to the user and taking precedence are the translations defined in the /etc/hosts configuration file. If an entry here resolves what's been entered into the browser into a local IP address, then the network stack of that browser process has its' answer and can assign destination addresses to IP packets. The HTTP Host: header can also now be assigned that hostname value we entered. Let's assume that was successful.

Next, smoothing over the fine details, a request for the web page gets sent over the network (or down, then back up the localhost loopback interface) to the device that hosts the webserver, where an Apache daemon is always listening for such incoming requests on the one or more configured ports. These port are configured using the Listen directive, for example Listen 80.

Next, in my setups, with Name-Based virtual hosting, the hostname value assigned to the Host: header is used by the Apache webserver to decide to which virtual host to direct the request.

Without getting into the NAT-like interfaces involved, let's contrast that process with one in which those webservers are containerised. There are two principles of containerisation could prevent my hosts' /etc/hosts configuration file from participating in the process...

If I've understood it correctly, implementations of Containerisation must preserve:

• Isolation of container environments from host machine environment.
• Independence of container environments from any particular host set up, as containers should 'run anywhere', regardless of host configuration.

With those principles in mind, might I have a Docker containerisation migration/adoption issue?

Without /etc/hosts (or any other host configuration file) I'd be restricted to only entering either an IP address or the localhost value that gets preconfigured on all Linux-based systems. So using localhost would be fine, but with IP address only, my Apache webservers won't be able to route incoming packets to their correct Name-Based Virtual Host destinations.

Note also, that a port number specified in a localhost request gets packets to the correct running webserver container, but what then? It seems that when requests come from anywhere outside the container network, each containerised webserver can only possibly serve a single site.

As far as I can see at the moment, the Name-Based virtual hosting that I've used to serve multiple sites from each Apache webserver cannot be migrated over to a container-based environments. If so, I shouldn't waste time trying to craft images of Apache webservers configured with multiple virtually hosted sites. Phew!

Update: Ok, perhaps that conclusion is moot, since another key principle of Containerisation is that each container should provide a single service only.

Ahh... Ok. Never mind then. Nice chat anyway.