Deploying a Wagtail site to Fly.io Part 3: Dockerising & Requirements
This post is part of a series:
- The Plan
- Configuration
- Dockerising & Requirements
- Static & Media Files
- Deploying
For Fly to know how to run our application, we need to package it up in a way that it understands. We need to tell it things like:
- How to acquire all our project’s dependencies
- What application server to use and how to configure it
- What files need to be made available to the platform
Fly currently supports 3 ways of doing this; Dockerfiles, Buildpacks and Nixpacks. The latter two are a great way to get started if you’re not familiar with Docker - they provide a pre-built way for the platform to build and run your application without the developer having to do much extra work.
Dockerfile’s are a bit more complicated but they are my preference because they offer complete flexibility over what we’re deploying. In our case, Wagtail’s starter project template already comes with a pretty decent Dockerfile, so we’ll focus on using that.
If you don’t have a Dockerfile, grab a copy of the Wagtail template file, place it in the root of your project and replace any occurrences of {{ project_name }} with the name of the folder your wsgi.py is found in.
You can skip the following changes if you’re using bakerydemo’s Dockerfile, as it is already in a fully usable state.
Looking at this Dockerfile, you’ll probably notice a big WARNING comment at the bottom, before the line that starts with CMD. This line is what Fly will execute when it starts running our application, and the warning is telling us that running migrate at this point is not best practice.
For most simple use cases, running migrate at this stage is unlikely to be a problem. Issues are likely to arise when running multiple simultaneous copies of the site (scaling out), as it is possible that they will each try to try run migrate at the same time potentially causing conflicts or errors.
Because Fly gives us a release phase in which we can run migrations (which we’ll come back to), we can simplify this line to:
CMD gunicorn myproject.wsgi:application
Now the only thing that Fly will do when your application launches is start the gunicorn application server.
Because we’ll be using PostgreSQL for our site, we need to make sure the package that Django uses to talk to PostgreSQL databases will be installed.
To do this, add psycopg2==2.9.3 to your requirements.txt file.