Libération de la machine s007 du cluster Swarm01¶

Maintenant que nous déployons les applications de nos clients sur leurs machines dédiées, nous avons de moins en moins d'applications sur les machines de Swarm01.

Nous voulons donc libérer une des machines afin de la rendre.

Je préfère ne pas rendre les 3 machines qui sont des managers et les 4 autres machines qui sont des workers ont toutes des applications avec des volumes stickés sur la machine.

La plus simple à libérer est s007 qui ne contient que notre Jenkins et celui de LurBerri.

Ce document décrit la procédure pour faire le déplacement des 2 Jenkins et sortir la machine du cluster.

Etat des lieux¶

En regardant les 3 autres machines s004, s005 et s008, je décide de déplacer les Jenkins vers s005. s004 contient le SFTP, a des disques HDD et est moins puissante. s008 contient les bases MySQL. s005 est moins occupée en terme de mémoire que s008.

Pour déplacer un Jenkins, la procédure doit être :

changer le tag de du volume de s007 vers s005
Docker Swarm doit alors créer un nouveau volume sur s005 et y déplacer les containers
Arrêter Jenkins (en demandant 0 container pour le service) et copier le contenu de l'ancien volume vers le nouveau
Redémarrer Jenkins (en demandant 1 container pour le service)

Déplacement du Jenkins de LurBerri¶

Problème avec l'authentification Keycloak¶

Je n'arrive plus à me connecter au Jenkins de LurBerri. Les certificats SAML de Jenkins ont dû expirer et keycloak n'a pas les nouveaux comme cela est déjà arrivé pour notre Jenkins en juin (voir cette note).

J'affiche les metadata du Jenkins LurBerri : https://jenkins.lurberri.computablefacts.com/securityRealm/metadata

Je récupère les 2 certificats SAML.

signing

encryption

Je vais dans la console admin de Keycloak, royaume de LurBerri, client Jenkins et l'onglets "Keys" : https://auth.computablefacts.com/admin/master/console/#/realms/lurberri/clients/3c0dd5d4-b45f-4c8d-9de0-6e3329e36462/saml/keys

J'importe les 2 certificats ci-dessus à la place de ceux déjà en place.

NOTA : à y regarder de plus près, les 2 certificats sont identiques. C'était le cas aussi pour les 2 certificats déjà présents dans Keycloak.

Je m'authentifie à nouveau sur le Jenkins de Lur Berri en passant par Keycloak.

Déplacement¶

Depuis le Portainer de swarm01, j'arrête le container Jenkins de LurBerri en mettant 0 container pour le service : https://portainer.swarm01.computablefacts.io/#!/1/docker/stacks/lurberri-jenkins?type=1&regular=false&external=true&orphaned=false

Je modifie le fichier ansible/03-swarm01-labels.yaml de cf-infra afin de déplacer le tag lurberri-jenkins.jenkins_home de s007 vers s005.

J'exécute la commande ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml afin de déplacer le tag.

Je vérifie dans Portainer et je constate que le tag a bien été déplacé (https://portainer.swarm01.computablefacts.io/#!/1/docker/swarm/visualizer).

Je démarre un container Jenkins de LurBerri depuis Portainer. Le volume lurberri-jenkins_jenkins-data est bien créé sur s005. Jenkins démarre mais, comme prévu, il est dans son état initial.

J'arrête le container Jenkins de LurBerri à nouveau et je copie le contenu du volume de s007 vers le nouveau volume de s005.

J'ai dû faire le transfert en plusieurs étape car je ne peux pas me connecter en ssh de s007 à s005 (il me demande un mot de passe que je n'ai pas) et je ne peux pas faire la synchro de s007 vers s005 (rsync n'accepte pas 2 machines distantes dans la même commande). J'ai également un problème de droit sur le dossier d'origine /var/lib/docker/volumes/lurberri-jenkins_jenkins-data qui n'est pas accessible directement par mon utilisateur ansible des 2 machines (j'utilise sudo).

Etape 1 : copie des fichiers sur s007

sudo rsync -avz --delete --progress /var/lib/docker/volumes/lurberri-jenkins_jenkins-data /tmp/

sudo chown ansible:ansible -R /tmp/lurberri-jenkins_jenkins-data

Etape 2 : transfert des fichiers de s007 vers mon PC

rsync -avz --delete --progress swarm01-s007:/tmp/lurberri-jenkins_jenkins-data/ /tmp/lurberri-jenkins_jenkins-data

Etape 3 : transfert des fichiers de mon PC vers s005

rsync -avz --delete --progress /tmp/lurberri-jenkins_jenkins-data swarm01-s005:/tmp/

Etape 4 : copie des fichiers sur s005

sudo rsync -avz --delete --progress /tmp/lurberri-jenkins_jenkins-data /var/lib/docker/volumes/

Je redémarre le container Jenkins de Lurberri depuis Portainer et j'arrive bien à me connecter au Jenkins en passant par Keycloak et je retrouve les jobs de LurBerri.

Déplacement de notre Jenkins¶

Je vais utiliser la même procédure que pour Lur Berri pour déplacer notre Jenkins.

Depuis le Portainer de swarm01, j'arrête le container Jenkins en mettant 0 container pour le service : https://portainer.swarm01.computablefacts.io/#!/1/docker/stacks/common-jenkins?type=1&regular=false&external=true&orphaned=false

Je modifie le fichier ansible/03-swarm01-labels.yaml de cf-infra afin de déplacer le tag common-jenkins.jenkins_home de s007 vers s005.

J'exécute la commande ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml afin de déplacer le tag.

Je vérifie dans Portainer et je constate que le tag a bien été déplacé (https://portainer.swarm01.computablefacts.io/#!/1/docker/swarm/visualizer).

Je démarre un container Jenkins depuis Portainer. Le volume common-jenkins_jenkins-data est bien créé sur s005. Jenkins démarre mais, comme prévu, il est dans son état initial.

J'arrête le container Jenkins à nouveau et je copie le contenu du volume de s007 vers le nouveau volume de s005.

Etape 1 : copie des fichiers sur s007

sudo rsync -avz --delete --progress /var/lib/docker/volumes/common-jenkins_jenkins-data /tmp/

sudo chown ansible:ansible -R /tmp/common-jenkins_jenkins-data

Etape 2 : transfert des fichiers de s007 vers mon PC

rsync -avz --delete --progress swarm01-s007:/tmp/common-jenkins_jenkins-data/ /tmp/common-jenkins_jenkins-data

Etape 3 : transfert des fichiers de mon PC vers s005

rsync -avz --delete --progress /tmp/common-jenkins_jenkins-data swarm01-s005:/tmp/

Etape 4 : copie des fichiers sur s005

sudo rsync -avz --delete --progress /tmp/common-jenkins_jenkins-data /var/lib/docker/volumes/

Je redémarre le container Jenkins depuis Portainer et j'arrive bien à me connecter au Jenkins en passant par Keycloak et je retrouve nos jobs.

Retirer `s007` du cluster swarm01¶

Je pourrais faire une commande sur la machine comme docker swarm leave --force mais je dois également mettre à jour mon inventaire ansible. Je vais donc tenter de retirer la machine avec une commande ansible.

Je modifie mon fichier d'inventaire (ansible/inventory.yml) pour déplacer s007 de swarm01_workers à swarm01_leave :

    swarm01_nodes:
      children:
        # Must be one of the Swarm managers hosts (only the first host is used)
        swarm_initiator:
          hosts:
            s001:
        # Hosts that will be Swarm manager (at least one)
        swarm01_managers:
          hosts:
            s001:
            s002:
            s003:
        # Hosts that will be Swarm worker. Must not be in Swarm managers list.
        swarm01_workers:
          hosts:
            s004:
            s005:
            s008:
        # Hosts that will be remove from Swarm
        swarm01_leave:
         hosts:
            s007:

Je regarde la composition du Swarm depuis s001 (un des managers) :

ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Reachable        24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active         Leader           24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active         Reachable        24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
mf52ayon7aolh16htm44mkd7m     s007       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Puis je fais la commande ansible pour retirer s007 :

ansible-playbook -i ansible/inventory.yml ansible/02-swarm.yaml --tags swarm-leave -e "infra=swarm01"

s007 est noté Down maintenant :

ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Reachable        24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active         Leader           24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active         Reachable        24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
mf52ayon7aolh16htm44mkd7m     s007       Down      Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Les containers sont déplacés sur d'autres machines mais je me rends compte qu'il reste 2 containers sur s007 :

ansible@s007:~$ sudo docker ps
CONTAINER ID   IMAGE         COMMAND                  CREATED         STATUS         PORTS     NAMES
ebf6121e5b3a   docker:dind   "dockerd-entrypoint.…"   16 months ago   Up 16 months             common-jenkins_dind
d5590ecfe1f7   docker:dind   "dockerd-entrypoint.…"   2 years ago     Up 16 months             lurberri-jenkins_dind

Ce sont les containers des 2 Jenkins qui permettent aux jobs d'exécuter des étapes dans un Docker. Ils sont créés par ansible pendant le déploiement d'un Jenkins et sont indépendants du Swarm d'où le fait qu'ils n'aient pas été déplacés.

Je vais relancer la commande ansible de déploiement du Jenkins de Lur Berri ce qui devrait créer ce container sur s005.

Dans le fichier ansible/client-common.yaml, je modifie la machine cible pour passer de s007 à s005 :

- name: Deploy jenkins stack
  # Must be the host where Jenkins will be created
  hosts: s005
  become: true
  tags: jenkins
  roles:
    - role: stack-jenkins
      swarm_manager: s001
      stack_name: common-jenkins
      stack_url: jenkins.common.computablefacts.com
      image_tag: 2.387.1
      jenkins_user: "{{ lookup('aws_ssm', '/swarm01/any/jenkins/ADMIN_USER') }}"
      jenkins_pass: "{{ lookup('aws_ssm', '/swarm01/any/jenkins/ADMIN_PASS') }}"
      memory_limits: 4G
      dind_memory_limits: 8G

Puis je fais la commande ansible-playbook -i ansible/inventory.yml ansible/client-common.yaml --tags jenkins.

Le container dind (Docker in Docker) pour common-jenkins a bien été créé sur s005 :

ansible@s005:~$ sudo docker ps | grep dind
61c4e888222d   docker:dind    "dockerd-entrypoint.…"   42 seconds ago      Up 40 seconds            2375-2376/tcp                  common-jenkins_dind
65ec79327ef7   docker:dind    "dockerd-entrypoint.…"   2 years ago         Up 16 months             2375-2376/tcp                  smacl-jenkins_dind

Je fais la même chose pour le Jenkins de Lur Berri. Je modifie le fichier ansible/client-lurberri.yaml pour mettre s005 à la place de s007 puis je fais la commande ansible-playbook -i ansible/inventory.yml ansible/client-lurberri.yaml --tags jenkins. Le container dind de lurberri-jenkins a bien été créé aussi sur s005.

Sur notre Jenkins, je lance le job "cf-ui ISTA" qui doit builder une image Docker et publier en PROD (mais c'est la PROD qui est sur swarm01 donc qui n'est plus utilisée). Le job s'exécute sans erreur donc je pense que le dind est bien déployé. Pour être bien sûr, j'ai supprimé le container dind et relancé le job qui a échoué puis j'ai remis le container dind avec la commande ansible, lancé le job à nouveau qui s'est terminé sans erreur.

Du coup, j'ai supprimé les 2 containers dind sur s007.

Enfin, depuis s001, je supprime le noeud s007 du cluster de façon définitive avec sudo docker node rm mf52ayon7aolh16htm44mkd7m.

Il n'est plus dans la liste du swarm :

ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Reachable        24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active         Leader           24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active         Reachable        24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Reste à rendre la machine à Scaleway.