Lets start off by deploying a single MySQL DB instance. For this, we’re going to use the default mysql image from docker hub. In order to deploy anything to CoreOS, you need to first create a service file. Here’s one for the MySQL that we’re going to deploy.

Save that file as
wpdb.service. Lets examine that file. As you can see, the file is split into three distinct sections.
Unit,
Service and
X-Fleet. The Unit section tells CoreOS, or more specifically
fleet, what this service is about and what it is for. Since this one is quite simple, we only have a
Description here.

The second section is Service. This basically defines the mysql service. We’ve got four lines. The first three cover
ExecStartPre section where we define commands that it needs to run before starting our service. In this case, we are stopping and removing any existing containers named
wpdb (as that’s what we’re calling our database instance). We’re also pulling in the latest mysql image from dockerhub so that we can be prepared when the service is started.

Next we’re defining what happens when the service is started by defining the
ExecStart property. Here, we’re running a simple docker run command. Since the mysql image needs a password to be defined in the environment, we’re passing one here. We’re also naming our database to be
wpdb. Note that we are not binding any ports as we don’t want access to the mysql locally on any machine. Later on, we’ll let our wordpress docker container talk directly to the mysql container by using docker
link.

Now load up the
wpdb.service using
fleetctl command:

1

fleetctl load wpdb.service

Once loaded, you can start it by running the
start command:

1

fleetctl start wpdb.service

Now that our database container is deployed, lets deploy our wordpress container. To do that, we need another service file.

Save that file as
www-manthanhd.service. As you can see, this file is very similar to the
wpdb.service file that we created earlier. However, there are a few changes.

Since we want to make sure that our database container is running before we run our wordpress container, we have to make sure that we have
After and
Requires properties defined accordingly. In this case, we’re instructing fleet to run our wordpress container that we require the
wpdb.service and to run this container after the
wpdb.service.

Another notable change is in the
X-Fleet section. Here we’re defining an extra property called
MachineOf where we’re telling fleet to deploy this wordpress container on the same machine as the
wpdb.service container. This is to ensure minimum latency between wordpress and the database.

We do have a slight change in the
ExecStart where we’re now linking the
wpdb container to the wordpress container by using docker link as well as binding port
80.

Once done, load up the wordpress container service using
fleetctl:

1

fleetctl load www-manthanhd.service

And then start it:

1

fleetctl start www-manthanhd.service

Lets check if the database and the wordpress containers are actually running. To do that, run:

1

fleetctl list-units

You should see output similar to this:

fleetctl list-units

1

2

3

UNIT MACHINE ACTIVE SUB

wpdb.service7528fd75.../172.17.8.101active running

www-manthanhd.service7528fd75.../172.17.8.101active running

That’s telling us that
wpdb.service and
www-manthanhd.service are both running on the same machine –
172.17.8.101 and are actually running!

Cool! Lets try to see if we can access wordpress. You can do this by navigating to port
80 of
172.17.8.101 or whatever ip address is shown above for
www-manthanhd.service above for you.