DockerFile: WordPress

Let’s take a look at Docker‘izing WordPress.

 

The Docker pull command is:

docker pull wordpress

pull: pulls an image or a repository from a registry. It doesn’t run it. It just means you have the image locally.

https://docs.docker.com/engine/reference/commandline/pull/

 

You can actually run the image using:

docker run --name some-wordpress --link some-mysql:mysql -d wordpress

some-wordpress is going to be the name of the container.

--link is a bit old school. It connects one container to another. i.e. MySQL to WordPress. Nowadays we use user-defined networks – e.g. overlays. https://docs.docker.com/network/links/

WordPress Docker Repo: https://hub.docker.com/_/wordpress/

 

However, before you can run it you’ll need MySQL. So:

docker pull mysql:5.7.24

(Aside: why not use mysql or mysql:latest? ‘cos MySQL 8 changed the password authentication method. See below.)

and then run it with:

docker run --name test-mysql -e MYSQL_ROOT_PASSWORD=test -d mysql:latest

--name is the name you’re giving to the container,

MYSQL_ROOT_PASSWORDis an environment variable that you set which is read in the container. Note: with MySQL this is done programmatically via docker-entrypoint.sh – https://github.com/docker-library/mysql/blob/696fc899126ae00771b5d87bdadae836e704ae7d/8.0/docker-entrypoint.sh . For more on ARG, Environment variables: https://stackoverflow.com/questions/53592879/dockerfile-and-environment-variable/53593826#53593826

and -d means detach.

To specify a tagged version just add it after the image using a colon. E.g. mysql:5.7.24.

 

Once you’ve run it you can exec in with

docker exec -it test-mysql bash

or check logs with:

docker logs test-mysql

E.g.

2018-12-03T14:24:57.091306Z 0 [Note] mysqld: ready for connections.
Version: '5.7.24' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

 

Or even mysql in via another MySQL container using:

docker run -it --link test-mysql:mysql --rm mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'

https://hub.docker.com/_/mysql/

 

So, getting back to WordPress let’s run it now with:

docker run --name test-wordpress --link test-mysql:mysql -d wordpress

and check the logs with:

You should then be able to access your WordPress site on http://localhost:8080

 

Errors

Conflict. The container name “/test-wordpress” is already in use by container

You run

docker run --name test-wordpress --link test-mysql:mysql -d wordpress

and get:

docker: Error response from daemon: Conflict. The container name "/test-wordpress" is already in use by container "0ea70abdaf306d896eb71f3ab585961359f27af23a243b81370bf407d3dd846d". You have to remove (or rename) that container to be able to reuse that name.

You’ve already got a container with that name.

Remove it with: docker rm test-wordpress

https://stackoverflow.com/questions/31676155/docker-error-response-from-daemon-conflict-already-in-use-by-container

This might happen if the container exited and you try and relaunch it.

 

Site can’t be reached

You plug http://localhost:8080 into the web browser but get:

Checking the WordPress logs with docker logs test-wordpress I can see:

however this is a secondary problem. Why are we getting this?

‘cos MySQL 8 introduced a different type of authentication – https://github.com/docker-library/wordpress/issues/313

If you are getting this then you need to use: docker pull mysql:5.7.24 or use a different auth method.

 

Back to the problem at hand – we should still be able to see a (non-functioning) WordPress site on that port. i.e. Apache should be running.

Let’s just do a sanity check:

This 0.0.0.0:8080->80/tcp means the docker host port 8080 is mapped to the container port 80.

https://stackoverflow.com/questions/41798284/understanding-docker-port-mappings

so http://localhost:8080 is correct.

 

It seems the problem really was the lack of MySQL. Using 5.7.24 and looking at the WordPress logs showed (for a successful installation):

 

Installing MySQL and WordPress in under a minute:

https://asciinema.org/a/nW3l0A1hi6wzMde4RUQ1QVPsc?speed=3

 

 

 

 

 

How Does DRBD work?

How Does DRBD work?

Each device (DRBD provides more than one of these devices) has a state, which can be ‘primary’ or ‘secondary’. On the node with the primary device the application is supposed to run and to access the device (/dev/drbdX). Every write is sent to the local ‘lower level block device’ and to the node with the device in ‘secondary’ state. The secondary device simply writes the data to its lower level block device. Reads are always carried out locally.

UCARP

What is UCARP

UCARP allows a couple of hosts to share common virtual IP addresses in order to provide automatic failover. It is a portable userland implementation of the secure and patent-free Common Address Redundancy Protocol (CARP, OpenBSD’s alternative to the patents-bloated VRRP).

Strong points of the CARP protocol are: very low overhead, cryptographically signed messages, interoperability between different operating systems and no need for any dedicated extra network link between redundant hosts.

How Does DRBD work?

How does it work ?

 

Each device (DRBD provides more than one of these devices) has a state, which can be ‘primary’ or ‘secondary’. On the node with the primary device the application is supposed to run and to access the device (/dev/drbdX). Every write is sent to the local ‘lower level block device’ and to the node with the device in ‘secondary’ state. The secondary device simply writes the data to its lower level block device. Reads are always carried out locally.

 

If the primary node fails, heartbeat is switching the secondary device into primary state and starts the application there. (If you are using it with a non-journaling FS this involves running fsck)

 

If the failed node comes up again, it is a new secondary node and has to synchronise its content to the primary. This, of course, will happen whithout interruption of service in the background.

 

And, of course, we only will resynchronize those parts of the device that actually have been changed. DRBD has always done intelligent resynchronization when possible. Starting with the DBRD-0.7 series, you can define an “active set” of a certain size. This makes it possible to have a total resync time of 1–3 min, regardless of device size (currently up to 4TB), even after a hard crash of an active node.

What is DRBD

What is DRBD

 

DRBD is a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1.

 

DRBD is copyright by Philipp Reisner, Lars Ellenberg and LinBit.

 

What is the scope of drbd, what else do I need to build a HA cluster?

 

DRBD takes over the data, writes it to the local disk and sends it to the other host. On the other host, it takes it to the disk there.

 

The other components needed are a cluster membership service, which is supposed to be heartbeat, and some kind of application that works on top of a block device.

 

Examples:

A filesystem & fsck.

A journaling FS.

A database with recovery capabilities.

 

http://www.drbd.org/