@ianjohnspain

You’d end up running two instances of NGINX – one running on the main Droplet and one running within the container.

The reason for this is because Docker doesn’t use public IP addresses, thus it doesn’t bind to your main Droplet IP (whether IPv4 or IPv6) – instead it uses local IP’s, similar to private networking IP’s.

You’d use the instance of NGINX that’s on the main Droplet to proxy incoming request on ports 80/443 to ports that you’ve opened on the container for the same purpose. You can bind to the same ports (many do), though you can also use alternative ports.

What you end up with is something such as this:

Incoming Request (Port 80) => Droplet (NGINX/Docker) => Container (LEMP Stack/WordPress)

The NGINX instance on the Droplet accepts the incoming request, proxies it to the container which is the full stack and WordPress installation, and then it functions as it normally would as if you were running it at just the hypervisor level (i.e. without Docker).

For something such as a simple WordPress site, you may actually be better of going without Docker unless you really plan on integrating Docker in to your entire work flow. There’s a good bit of detail and caution that’s needed with Docker.

For instance, without setting up volumes, if you bring the container down or destroy it, your data is gone with it. Generally once a container is setup, you run with it and when you need to update something such as NGINX, PHP, or MariaDB, you bring it down and then spin up a new container with the required software, then destroy the other.

If you don’t use volumes, the above is going to be a nightmare as you’ll end up losing data.