Déployer un docker-compose.yml sur un serveur

Rôle Ansible pour déployer un docker-compose.yml dans un répertoire personnel, à utiliser de préférence avec bigsudo.

Ce README décrit les fonctionnalités, voir TUTORIAL.md pour un tutoriel avec des modèles orientés pour atteindre l'eXtreme DevOps.

Exemple

Ce rôle se teste lui-même et vous pouvez commencer à copier :

• Dockerfile : fonctionnera par défaut pour un projet CRUDLFA+, offre un service de fichiers statiques compressés et mis en cache ainsi qu'un spooler.
• .gitlab-ci.yml : construit et pousse l'image docker vers le registre d'images GitLab, fournit un modèle YAML pour les tâches de déploiement (macro), ainsi que 3 configurations d'exemple pour différents cas d'utilisation de déploiement.
• docker-compose.yml : pour des déploiements locaux et éphémères.
• docker-compose.traefik.yml : pour le support youlabs.traefik.
• docker-compose.persist.yml : addon à utiliser pour des déploiements persistants, c'est-à-dire spécifiés dans .gitlab-ci.yml, nécessite docker-compose.traefik.yml.

Vous devez modifier :

• .gitlab-ci.yml : il y a quelques commentaires # UNCOMMENT ABOVE AND REMOVE BELOW, suivez les instructions pour utiliser yourlabs/ansible.
• ci.yourlabs.io avec votre serveur dans .gitlab-ci.yml.
• Variable GitLab CI à définir : $CI_SSH_KEY, elle doit contenir une clé privée ed25519, vous pouvez en créer une avec : ssh-keygen -t ed25519 -a 100.
• Dockerfile : changez l'argument de commande --module=wsgi:application avec le chemin approprié vers votre application wsgi, supprimez la configuration bigsudo si vous le souhaitez et décommentez ce que vous voulez.

Ensuite, vous pouvez personnaliser tout ce que vous voulez !

D'autres commandes bigsudo que vous pouvez utiliser :

• activer un timer de sauvegarde systemd avec : bigsudo yourlabs.compose backup home=/home/$CI_PROJECT_NAME-$CI_ENVIRONMENT_NAME.
• sur le serveur de déploiement CI de révision, pour supprimer les images, volumes et réseaux inutilisés : bigsudo yourlabs.docker prunecron @ci.your.host, cela empêche les déploiements de révision de remplir l'espace disque.

Vous pouvez également obtenir une description plus générale et conceptuelle dans l'article de blog sur l'eXtreme DevOps.

Documentation des fonctionnalités

L'objectif de ce rôle est d'automatiser le déploiement d'une fusion de fichiers docker-compose.yml dans un répertoire sur un hôte, et d'automatiser tout ce qui entoure cela.

Depuis un répertoire avec un fichier docker-compose.yml, vous pouvez le déployer dans $host:/home/staging avec la commande suivante :

bigsudo yourlabs.compose home=/home/staging $user@$host

Si $user@$host n'est pas défini, alors il s'exécutera sur localhost.

Vous pouvez passer plusieurs fichiers compose et les variables d'environnement seront transmises lors de la génération du fichier final :

FOO=bar bigsudo yourlabs.compose \
    home=/home/staging \
    compose_django_image=$YOUR_IMAGE \
    compose=docker-compose.yml,docker-compose.staging.yml

Génération de répertoires

Ce rôle peut également pré-créer des répertoires avec un uid, gid et mode donnés, avec le label io.yourlabs.compose.mkdir comme suit :

volumes:
- "./log/admin:/app/log"
labels:
- "io.yourlabs.compose.mkdir=./app/log:1000:1000:0750"

Cela entraînera la création du répertoire {{ home }}/log/admin avec le propriétaire 1000 et le groupe 1000 et le mode 0750.

Génération d'environnement

Une autre fonctionnalité intéressante est l'approvisionnement automatique de l'environnement avec chaque variable déclarée dans l'environnement du service qui est définie à l'exécution. Par exemple, avec ceci dans docker-compose.yml :

environment:
- FOO

Puis en exécutant le rôle yourlabs.compose avec la variable FOO définie comme suit :

FOO=bar bigsudo yourlabs.compose home=/home/test

Cela résultera dans l'environnement suivant :

environment:
- FOO=bar

Remplacements YAML en ligne de commande

Vous pouvez également ajouter ou remplacer des valeurs de services avec la variable compose_servicename_keyname. Exemple de remplacement de la valeur compose[services][django][image] à la volée :

bigsudo yourlabs.compose home=/home/test compose_django_image=yourimage

Vous pouvez vider des valeurs à la volée si vous le souhaitez, il suffit de passer des valeurs vides, c'est-à-dire pour rendre compose[services][django][build] vide, passez compose_django_build= sans valeur. Dans le cas où vous ne clonez pas votre dépôt dans le répertoire personnel, docker-compose se plaignera s'il ne trouve pas le chemin vers le Dockerfile, cela contourne cette limitation :

bigsudo yourlabs.compose home=/home/test compose_django_build=

Automatisation des réseaux

Les réseaux peuvent également être un peu délicats à gérer avec docker-compose, par exemple nous avons généralement un réseau web avec un équilibreur de charge tel que traefik. Cela ajoute le réseau web au service django, et il se joindra automatiquement au réseau s'il est présent en déclarant le réseau web comme externe dans le fichier docker-compose.yml qu'il déploie :

bigsudo yourlabs.compose home=/home/test compose_django_networks=web

Si vous utilisez le docker-compose.yml de votre équilibreur de charge, alors vous avez le problème opposé : le docker-compose.yml déclare un réseau web comme externe, mais docker-compose up ne le créera pas et échouera comme suit :

ERREUR : Réseau web déclaré comme externe, mais introuvable. Veuillez créer le réseau manuellement en utilisant `docker network create lol` et réessayer.

Ce rôle évite ce problème en analysant le docker-compose.yml pour les réseaux externes et en utilisant le module ansible docker_network pour le pré-créer sur l'hôte si nécessaire.

En tant que rôle ansible

Enfin, vous pouvez utiliser ce rôle comme n'importe quel autre rôle ansible, si vous souhaitez l'encapsuler dans d'autres tâches dans votre dépôt :

- name: S'assurer que docker est configuré une fois sur cet hôte
  include_role: name=yourlabs.compose
  vars:
    home: /home/yourthing
    compose_django_image: foobar
    compose_django_build:
    compose_django_networks:
    - web

Sauvegardes

Les sauvegardes automatisées sont activées pour les déploiements avec un argument home. Il configurera 3 scripts dans /home :

• ./backup.sh : crée une sauvegarde locale et une sauvegarde dans restic.
• ./restore.sh : liste les instantanés restic, exécutez-le avec un hachage d'instantané restic comme argument pour restaurer l'instantané.
• ./prune.sh : supprime les anciennes sauvegardes.

Il créera 1 service systemd et un timer systemd :

• backup-PROJECTNAME.service
• backup-PROJECTNAME.timer

Hacking

Pour développer ce rôle en local :

# construire l'image
docker build -t test .

# exécuter bigsudo comme suit :
bigsudo . home=/tmp/test compose_django_build= compose_django_image=test compose=docker-compose.yml,docker-compose.persist.yml

Notez qu'il essaiera toujours d'exécuter le script de sauvegarde avant de le mettre à jour. Si vous le modifiez, vous devez supprimer backup.sh avant de réexécuter yourlabs.compose afin qu'il mette à jour backup.sh.