We’re going to need a couple of domain names at this point in the book—​they can both be subdomains of a single domain. I’m going to use superlists.ottg.co.uk and staging.ottg.co.uk. If you don’t already own a domain, this is the time to register one! Again, this is something I really want you to actually do. If you’ve never registered a domain before, just pick any old registrar and buy a cheap one—​it should only cost you $5 or so, and you can even find free ones. I promise seeing your site on a "real" website will be a thrill.

We can separate out "deployment" into two tasks:

Ultimately, infrastructure-as-code tools can let you automate both of these, but for the purposes of this book, we can live with manual provisioning.

I should probably stress once more that deployment is something that varies a lot, and that as a result there are few universal best practices for how to do it. So, rather than trying to remember the specifics of what I’m doing here, you should be trying to understand the rationale, so that you can apply the same kind of thinking in the specific future circumstances you encounter.

We don’t want to be messing about with IP addresses all the time, so we should point our staging and live domains to the server. At my registrar, the control screens looked a bit like Domain setup.

In the DNS system, pointing a domain at a specific IP address is called an "A-Record". All registrars are slightly different, but a bit of clicking around should get you to the right screen in yours. You’ll need two A-records: one for the staging address and one for the live one. No need to worry about any other type of record.

DNS records take some time to "propagate" around the world (it’s controlled by a setting called "TTL", Time To Live), so once you’ve set up your A-record, you can check its progress on a "propagation checking" service like this one: https://www.whatsmydns.net/#A/staging.ottg.co.uk.

I’m planning to host my staging server at staging.ottg.co.uk

TODO:

https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

suggests pipx. could also install it in the local virtualenv? may need to add docker-sdk

Infrastructure-as-code tools, also called "configuration management" tools, come in lots of shapes and sizes. Chef and Puppet were two of the original ones, and you’ll probably come across Terraform, which is particularly strong on managing cloud services like AWS.

We’re going to use Ansible, because it’s relatively popular, because it can do everything we need it to, because I’m biased that it happens to be written in Python, and because it’s probably the one I’m personally most familiar with.

Another tool could probably have worked just as well! The main thing to remember is the concept, which is that, as much as possible we want to manage our server configuration declaratively, by expressing the desired state of the server in a particular config syntax, rather than specifying a procedural series of steps to be followed one by one.

Let’s dip our toes into ansible, and see if we can get it to run a simple "hello world" container on our server.

Here’s what’s called a "playbook" in ansible terminology. It’s in a format called YAML (Yet Another Markup Language), which, if you’ve never come across before, you will soon develop a love-hate^[2] relationship with.

Most ansible modules have pretty good documentation, check out the builtin.apt one for example. I often skip to the Examples section.

I don’t know about you, but whenever I make a terminal spew out a stream of output, I like to make little brrp brrp brrp noises, a bit like the computer Mother, in Alien. Ansible scripts are particularly satisfying in this regard.

Time to get into some good old-fashioned sysadmin! Let’s SSH in to our server and see if we can see any evidence that our container has run.

We use docker ps -a to view all containers, including old/stopped ones, and we can use docker logs to view the output from one of them:

SSHing in to check things worked is a key server debugging skill! It’s something we want to practice on our staging server, because ideally we’ll want to avoid doing it on production machines.

Typically, you can "push" and "pull" container images to a "container registry" — Docker offers a public one called DockerHub, and organisations will often run private ones, hosted by cloud providers like AWS.

So your process of getting an image onto a server is usually * Push the image from your machine to the registry * Pull the image from the registry onto the server. Usually this step is implicit, in that you just specifying the image name in the format registry-url/image-name:tag, and then docker run takes care of pulling down the image for you.

But I don’t want to ask you to create a DockerHub account, or implicitly endorse any particular provider, so we’re going to "simulate" this process by doing it manually.

It turns out you can "export" a container image to an archive format, manually copy that to the server, and then re-import it. In ansible config, it looks like this:

For completeness, let’s also add a step to explicitly build the image locally. This means we don’t have a dependency on having run docker build locally.

In any case, let’s see if it works!

Ah woops, we need to set those environment variables on the server too.

When we run our container manually locally, we can pass in environment variables with the -e flag. But we don’t want to hard-code secrets like SECRET_KEY into our ansible files and commit them to our repo!

Instead, we can use ansible to automate the creation of a secret key, and then save it to a file on the server, where it will be relatively secure (better than saving it to version contorl and pushing it to GitHub in any case!)

We can use a so-called "env file" to store environment variables, which are essentially a list of key-value pairs using shell syntax, a bit like you’d use with export.

One extra subtlety is that we want to vary the actual contents of the env file, depending on where we’re deploying to. Each server should get its own unique secret key, adn we want different config for staging and prod, for example.

So, just as we inject variables into our html templates in Django, we can use a templating language called "jinja2" to have variables in our env file. It’s a common tool in ansible scripts, and the syntax is very similar to Django’s.

Here’s what our template for the env file will looks like:

And here’s how we use it in the provisioning script:

Let’s run the latest version of our playbook and see how our tests get on:

Looks good! What do our tests think?

Taking a look at the logs from the server, we can see that the database is not initialised.

Here’s how

Hooray

One final bit of admin. In order to preserve a historical marker, we’ll use Git tags to mark the state of the codebase that reflects what’s currently live on the server:

Now it’s easy, at any time, to check what the difference is between our current codebase and what’s live on the servers. This will come in useful in a few chapters, when we look at database migrations. Have a look at the tag in the history:

Anyway, you now have a live website! Tell all your friends! Tell your mum, if no one else is interested! And, in the next chapter, it’s back to coding again.

There’s no such thing as the One True Way in deployment, and I’m no grizzled expert in any case. I’ve tried to set you off on a reasonably sane path, but there’s plenty of things you could do differently, and lots, lots more to learn besides.q Here are some resources I used for inspiration: