otsukare Thoughts after a day of work

Docker, some notes

We converted webcompat.com to Python 3, which included reconfiguring a couple of things on the server itself with nginx, uwsgi and so on. Let's say modernizing everything. As an aside, I would say that our unit tests made the code conversion to python 3 quite smooth. That was a good surprise. In the process, I started to wonder if it would make it easier for us to switch to Docker and containers. These are my notes trying to educate myself about the topic. They are probably naive for some of the readers but might be useful for others. They will also become handy for this 2019Q4 OKR.

πŸ’‘ Digital Ocean

Digital Ocean has everything we need for using Docker with multiple tutorials and examples on both docker and digitalOcean websites.

We are currently using:

  • Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-42-generic x86_64) on staging and production.
  • Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-98-virtual i686). we are not anymore. As we said, we modernized.

πŸ’‘ Learning about Docker

The Dockerfile is a set of instructions/commands which will explain to the Docker container what it should install to be ready. It configures it basically.

Docker images hold the snapshot of the Dockerfile, and the Docker container is a running implementation of a Docker image based on the instructions contained within that image. β€” Docker 101: Fundamentals & The Dockerfile

We could imagine we would have, before/after(?) deploying:

docker build -t staging/webcompat .
docker build -t prod/webcompat .

Translation: build (build) the image from the Dockerfile at the root level (.) and tag it -t as staging/webcompat.

Docker compose helps to orchestrate all services in one unique place.

is a recipe card β€” it’s a recipe of services that make up an application and the docker-compose.yml dictates how the services are mixed together. β€” Docker 102: Docker-Compose

And it could be practical if everything is under docker.

If you’re lucky enough to be able to use Docker containers in production, then a single docker-compose.yml file can deploy a complete system that runs exactly as it was tested in lower life cycle environments. β€” Docker 102: Docker-Compose

A nice example on how this can be done.

GitHub Actions

We probably also need to explore GitHub Actions. There's an article about Digital Ocean Kubernetes and GitHub actions.

Docker and Flask

Some examples of docker + nginx + uwsgi + flask

πŸ’‘ Docker Installation

  • Get started with Docker Desktop for Mac.
  • Debian buster 3.7.4 is the latest at the time of this writing for mimicking a production environment. ubuntu:20.04 > Debian Buster > ubuntu:18.04. We are currently running Ubuntu 18.04

πŸ’‘ Docker for dev environment

The reason number 1 is to speed up the setup process and then lower the bar to participation for coding. It’s a bit hard to start the webcompat project even with the docs. And there are a lot of things to configure just to fix one line of code. Time to time, for some people platforms differences created issues.

But they seem to refer to a couple of drawbacks with regards to time and dependencies in the project.

An argument discouraging using docker for the development environment.

When docker was introduced in our stack the first thing we noticed is that, while it simplified our initial setup and launch, it made our day to day development process much more complex. β€” Why using docker in your local dev environment is probably not a great idea

Easy setup. Dev process harder.

every command took almost twice as long to complete. β€” Why using docker in your local dev environment is probably not a great idea

All the literature seems to be consistent with regards to using docker for the dev environment. Probably better to stick to a solid and simple virtual environment, and then have a script which makes it possible for people to deploy this code locally on their docker container that we would have prepared.

So probably not something to recommend for now.

πŸ’‘ Docker for deployment testing

Probably Docker would be a very good thing to use for people deploying the project so they can test locally a couple of things before making the project live. The idea would be to reproduce the configuration of the DigitalOcean droplet.

So we could checkout a branch version into a local docker container and see if the house is on fire.

I could also see the possibility to have generic values for running functional and unit tests, which would be super stable across developers. To think.

πŸ’‘ Docker for production

This seems also to be a good choice with regards to what we want to do. It also kind of removes the stress of playing with the values in the live environment. Basically we can tweak the configuration in the container and then we think it’s ready deploy this specific instance.

In this article, the author gives an example of deploying a container to DigitalOcean using docker-machine.

$ docker-machine create --driver digitalocean --digitalocean-access-token xxxxx dash_app_droplet
$ eval $(docker-machine env dash_app_droplet)

Now, if you will run the $ docker-compose up --build -d it will deploy the app directly from the local host to the droplet.

πŸ’‘ Docker and images/data

We will need to handle the data at a different layer.

Probably I should try to create an image which is mimicking our server configuration, to better understand how to fit the development and deployment workflows process in the big picture.

Otsukare!