Use Docker in production

[dfabulich]

We're using the version of MariaDB, Apache, and PHP provided by Debian. We set up the machine with a manual unreproducible setup process.

We should probably use Docker in production instead. This will allow us to choose our preferred version of PHP #468 and MariaDB, and will give us the freedom to upgrade Debian whenever we want, without breaking production.

[dfabulich]

@dougvalenta and I were discussing this on Slack earlier today.

Here are some of the example questions I had that had no clear answers

1. Looking at https://github.com/iftechfoundation/ifdb (the public source repository), we have a Dockerfile for the Apache/PHP (“web“) server, and a docker-compose.yml that installs a standard mariadb:10 machine, phpmyadmin, and the web server.

   I assume I can’t use that exact docker-compose.yml file in production, because it’s designed to launch with an empty database. I want the dev environment to wipe/recreate its DB from scratch on launch, but I certainly don’t want prod to do that. So, how does that work?

   You would want to mount your existing data directory into the db container

2. Secret management. Currently I ssh in and put secrets in /var/www/html/local-credentials.php. How would that work when Dockerizing production?

   Mount that file (or one like it) into the container, or pass those as environment variables (in which case they're stored in a service unit or similar)

3. Composer. We don’t currently use Composer, but I think we’re supposed to start doing so. (Not sure how familiar you are with PHP and its ecosystem; Composer is equivalent to NPM for JS, PIP for Python, Maven for Java, etc.

   I’m confused as to how that’s supposed to work, even in a dev environment. Are all the devs supposed to download the dependencies on their own machine, every time it runs? Or are we supposed to download the dependencies and check them in? How and when would production update itself?

   I have written Dockerfiles that use composer in the past for running Wordpress in docker, I can dig that up as an example

4. Cron. Currently, the production machine runs a bunch of cron jobs, manually set up. How would that work?

5. Actually deploying. Currently I ssh in to production and I run a script that checks out a branch in git, then I rsync files from git into /var/www/html. I presume that's not gonna work with Docker. How is it supposed to work? (How would I do the deploy with zero-ish downtime?)

6. Kubernetes. Am I supposed to use that? (Even for a deploy that runs all on one machine?)

7. Docker Hub. Am I supposed to build Docker images and deploy them to Docker Hub? That's what the Docker guide at https://docs.docker.com/guides/php/ seems to want me to do (but it feels like overkill; we've never needed/used Docker Hub for our dev environment, and it's hard to see how we'd benefit from it or use it in production).

8. Staging vs. prod. We have a staging server at dev.ifdb.org, with different secrets, different cron settings, (especially different certbot certificates). How would that work?

[dougvalenta]

4. Can cron file go in your git repo, and get deployed to the machine? The cron job itself can run your docker image (or exec into a running container)
5. Depends a lot on answers to other questions, let's meet about this :)
6. No
7. Probably not. If you want to build images on one machine and run them on another, you will need a registry where you can stash them. There are a lot of options here, but it's also possible with PHP that you don't need to build an image at all. You can probably keep all the PHP files (checked out from git) on the host machine's file system, and then your Docker container is running Apache and PHP and reading the files from the host machine. (In fact, start here and only build a custom image if you really need it)
8. Getting those two systems into alignment (along with local dev) is I assume one of the big motivators for this project. If they're running the same Git commit and the same images, that's a big step in the right direction