What are you using in production?

[robertoassuncaofilho]

When you develop a new project using django cookiecutter, what do you use for production deployments?
Currently (after my first project developed using django cookiecutter), I am using docker-compose on a Linux-based VM at DigitalOcean (a droplet), but I realized that it is a bad idea (on every new release, it takes about 3 to 5 minutes of downtime at my server).
I believe that Kubernetes would be a better option, but honestly, I need to study it.
I would appreciate it if you can share your experience and any tip about production environments for cookiecutter projects. 

[foarsitter]

Can you describe your release proces? I do the same once a while and in my situation it does not take 3 to 5 minutes to deploy a new version. There is some downtime but not more than 60 seconds I think.

The actual update command I use is docker-compose -f production.yml up -d django celeryworker. Before I run that command I pull the new images from a registry and run the migrations with the new image. Before I was using an online registry I was building the images on the server which caused a lot of trouble.

Nowadays I make use of a single VPS (4cpu, 8gb ram) to host a docker-swarm instance for multiple sites and apps. There is an excellent tutorial about this on https://dockerswarm.rocks/. In swarm mode you can use the restart_policy definition with an healthcheck command as shown below. This enables you to perform rolling updates with the command docker service update <service_name> --image <image_name>.

services:
  django:
    <<: *default-opts    
    command: /start

    healthcheck:
      test: /bin/bash -c "timeout 1 bash -c '</dev/tcp/localhost/5000' 2>/dev/null"
      start_period: 20s
      interval: 30s
      timeout: 30s
      retries: 5
    deploy:
      restart_policy:
        condition: any
        delay: 5s
        max_attempts: 24
      rollback_config:
        parallelism: 0
        order: stop-first
      update_config:
         order: start-first
         failure_action: rollback
         delay: 10s 

[robertoassuncaofilho]

Currently my release process is like your previous one (building the images on the server), and it is really causing some problems. In my case, I am using docker-compose -f production.yml build and then docker-compose -f production.yml up --build.
Thanks for the suggestion about docker-swarm. Looks like it will help a lot.

[foarsitter]

Do you use gitlab? This project has an gitlab pipeline script for building images and gitlab provides a free container registry. This solves your 'build-on-server' issue.

[robertoassuncaofilho]

Not yet, but I could migrate to gitlab or use another container registry and github actions, but I believe that the downtime issue will only be solved when I start using docker-swarm.

[foarsitter]

One step a time is my advise. Things are complicated enough. There are some hacks to do rolling deployments with docker compose as described here but I tink a downtime of 30 seconds wont bother in most use cases.

[robertoassuncaofilho]

That's true. 30 seconds would be great for now. I will try the hacks for docker compose as described in the link you sent. Thanks!

[Manjit2003]

I have made my custom github-actions workflow to push the code to my server automatically. Basically, it logins via ssh and performs docker-compose commands. With this method, I hardly get downtime of ~10sec or even less!!

[tasiotas]

I build images (frontend and backend) on GitHub via actions, from there push to Image Repo on GitLab ( 5GB free ). Once push is done, GH actions continues and SSH into VM and execute few commands, that boil down to docker-compose pull, docker-compose down and docker-compose up. So downtime is really just few sec between down and up.