Immutable WordPress Example

One of my goals to improve security and availability is to containerize my applications and use a Microservices architecture.  I’ve separated MySQL and WordPress and placed them in their own containers.

By creating immutable instances of an application that is highly mutable, I’m able to destroy/recreate on the fly should something happen to my WordPress applications.

I’ll explain how these two containers are created.

MySQL docker-compose.yaml

I’ve made a universal docker-compose.yaml that takes advantage of an external MySQL DB container: To visit, click the following button.

I’ve noted the following areas in the configuration and why I chose to implement them this way:

Config	Description
image	mysql:5.6 This is the MySQL version I’m using. WordPress supports MySQL and MariaDB (latest versions)
network_mode	network_mode: bridge If you’re running standalone containers that need to communicate with each other, use bridge mode.
volumes	volumes: – db_data:/var/lib/mysql I’ve created a persistent volume. When bringing down the container and restoring it, the contents of MySQL is kept.
ports	I’ve opened these two ports to communicate with it directly with a client.  Turn this off to close the ports entirely from the outside world.
expose	Exposing 3306 within Docker will help other containers communicate with it.  In fact, you need this exposed.
restart	restart: always As the name suggests, always restart the container should something happen to it (system restart, container restart, container crashes, etc).
container_name	container_name: db-mysql-main I’ve explicitly gave my container a name.  Not the best practice if you’re looking at scaling.  Feel free to omit this unless you want to use a single container throughout its lifecycle.
environment	The official MySQL container has several environmental variables you can take advantage to interact directly with the management of the service.  See the official MySQL Docker for more information.

WordPress docker-compose.yaml

Creating a MySQL container is pretty straight explanatory.  The hardest part of these two configurations is putting together a docker-compose.yaml file for a WordPress container.  To view the example configuration, click the following link:

Config	Description
image	image: wordpress:4.9.8-php5.6-apache Official WordPress image.  You should probably use a PHP7 version.
network_mode	network_mode: bridge If you’re running standalone containers that need to communicate with each other, use bridge mode.
volumes	The following volumes need to be mapped to the contents remain consistent: – /wp-content/themes – /wp-content/plugins -/wp-content/uploads -/.htaccess Add a custom .htaccess. A very good feature for this is to map assets to the live version of your website if this is a sandbox version.  See this section on how that .htaccess would look like.
ports	ports: – “8080:80” I used port 8080 to serve my HTTP page.  Feel free to change that to whatever you want.  The internal port is your standard port 80.
restart	restart: always As the name suggests, always restart the container should something happen to it (system restart, container restart, container crashes, etc).
container_name	container_name: wp-test I’ve explicitly gave my container a name.  Not the best practice if you’re looking at scaling.  Feel free to omit this unless you want to use a single container throughout its lifecycle.
environment	Environmental variables go here.  I’ve used the standard variables that you’ll need to get WordPress running.  Visit this page to know other variables you may need to use if needed. Most notably, you can add additional configurations outside your standard configurations using WORDPRESS_CONFIG_EXTRA

Launching Containers

Launch the following configurations in this exact order:

• MySQL docker-config.yaml
• WordPress docker-config.yaml

I have these configurations in their own folder.  In each folder, execute the containers by executing the following:

docker-compose up -d