Skip to content

Deprecated servers

Summary

Name CPU Memory Disks Description
Deprecated: ac-master-1 ??? ??? ??? No description
Deprecated: ac-slave-0 ??? ??? ??? No description
Deprecated: ac-slave-1 ??? ??? ??? No description
Deprecated: ac-slave-2 ??? ??? ??? No description
Deprecated: backstage-4g 3 4G 20 GB Machine pour tester Backstage
Deprecated: coreapi-1 ??? ??? ??? No description
Deprecated: coreapi-2 ??? ??? ??? No description
Deprecated: poc-docker 2 2G 10 GB Machine pour tester l'accès à Docker depuis YunoHost
Deprecated: s002 12 64G 2 x 1 To SSD Manager du cluster swarm01
Deprecated: s003 12 64G 2 x 1 To SSD Manager du cluster swarm01
Deprecated: s006 24 192G 2 x 1 To SSD Noeud du cluster swarm01
Deprecated: s007 24 192G 2 x 1 To SSD Noeud du cluster swarm01
Deprecated: scw-optimistic-brattain 4 12G 120 GB Machine pour entraîner les modèles de la SMACL
Deprecated: sentinel-api-1 8 64G ??? Manager du cluster infra2
Deprecated: sentinel-api-2 8 64G ??? Noeud du cluster infra2
Deprecated: sentinel-api-3 8 64G ??? Noeud du cluster infra2
Deprecated: zookeeper-1 ??? ??? ??? No description
Deprecated: zookeeper-2 ??? ??? ??? No description
Name IP v4 IP v6
Deprecated: ac-master-1 51.159.5.80 None
Deprecated: ac-slave-0 51.159.5.100 None
Deprecated: ac-slave-1 51.159.5.95 None
Deprecated: ac-slave-2 51.159.5.99 None
Deprecated: backstage-4g 51.15.204.122 2001:bc8:710:1646:dc00:ff:fe2d:7f67
Deprecated: coreapi-1 51.159.5.77 None
Deprecated: coreapi-2 51.159.5.78 None
Deprecated: poc-docker 51.159.156.219 2001:bc8:1210:4ac:dc00:ff:fe23:7fa9
Deprecated: s002 51.159.100.60 2001:bc8:1201:14:2e59:e5ff:fe42:88a0
Deprecated: s003 51.159.100.61 2001:bc8:1201:14:2e59:e5ff:fe42:47c4
Deprecated: s006 51.159.101.12 None
Deprecated: s007 51.159.101.13 2001:bc8:1201:25:2e59:e5ff:fe3a:caf8
Deprecated: scw-optimistic-brattain 51.15.244.96 2001:bc8:710:1647:dc00:ff:fe2d:7f7d
Deprecated: sentinel-api-1 51.159.17.217 None
Deprecated: sentinel-api-2 51.159.18.127 None
Deprecated: sentinel-api-3 51.159.18.50 None
Deprecated: zookeeper-1 51.159.4.208 None
Deprecated: zookeeper-2 51.159.4.209 None

Deprecated: ac-master-1

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.80 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: ac-slave-0

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.100 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: ac-slave-1

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.95 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: ac-slave-2

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.99 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: backstage-4g

[Système : None] [Lifecycle : deprecated]

Machine pour tester Backstage

CPU Memory Disks IP v4 IP v6
3 4G 20 GB 51.15.204.122 2001:bc8:710:1646:dc00:ff:fe2d:7f67

Détails

2023-12-29: suppression de cette instance Scaleway

Labels

  • supplier: scaleway

  • model: DEV1-M

  • dns_public: c07207d7-252c-4b5e-b269-328c98642891.pub.instances.scw.cloud

  • ssh_port: 22

  • ssh_user: root

Dependencies

Deprecated: coreapi-1

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.77 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: coreapi-2

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.5.78 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SATA

  • compute: dedibox

Deprecated: poc-docker

[Système : None] [Lifecycle : deprecated]

Machine pour tester l'accès à Docker depuis YunoHost

CPU Memory Disks IP v4 IP v6
2 2G 10 GB 51.159.156.219 2001:bc8:1210:4ac:dc00:ff:fe23:7fa9

TODOs

  • A supprimer ?

Labels

  • supplier: scaleway

  • model: DEV1-S

  • dns_public: ab565b5c-7ec9-4760-8cc3-e59cdf12df5b.pub.instances.scw.cloud

  • ssh_port: 22

  • ssh_user: root

Deprecated: s002

[Système : None] [Lifecycle : deprecated]

Manager du cluster swarm01

CPU Memory Disks IP v4 IP v6
12 64G 2 x 1 To SSD 51.159.100.60 2001:bc8:1201:14:2e59:e5ff:fe42:88a0

Events

2025-01-16 - 11:20 - Suppression des 2 machines Scaleway s002 et s003

Cela fait 6 jours que j'ai sorti ces 2 machines du cluster swarm01 et tout se passe bien. Je peux donc les "rendre" à Scaleway.

Je note ces 2 machines comme deprecated.

2025-01-10 - 18:20 - Suppression de 2 managers du cluster swarm01 (s002 et s003)

Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers.

Je choisi de garder s001 comme manager et de supprimer s002 et s003.

Je sauvegarde le répertoire /var/lib/docker/swarm sur s001.

Commande 
ansible@s001:~$ sudo tar -czvf var_lib_docker_swarm.20250110.tar.gz /var/lib/docker/swarm
tar: Removing leading `/' from member names
/var/lib/docker/swarm/
/var/lib/docker/swarm/worker/
/var/lib/docker/swarm/worker/tasks.db
/var/lib/docker/swarm/state.json
/var/lib/docker/swarm/docker-state.json
/var/lib/docker/swarm/raft/
/var/lib/docker/swarm/raft/wal-v3-encrypted/
/var/lib/docker/swarm/raft/wal-v3-encrypted/0000000000000282-0000000000fb5e32.wal
/var/lib/docker/swarm/raft/wal-v3-encrypted/0.tmp
/var/lib/docker/swarm/raft/snap-v3-encrypted/
/var/lib/docker/swarm/raft/snap-v3-encrypted/0000000000000184-0000000000fb7703.snap
/var/lib/docker/swarm/certificates/
/var/lib/docker/swarm/certificates/swarm-node.key
/var/lib/docker/swarm/certificates/swarm-root-ca.crt
/var/lib/docker/swarm/certificates/swarm-node.crt

Pour restaurer, faire (non testé) : 

sudo systemctl stop docker
sudo tar -xzvf swarm-backup.tar.gz -C /
sudo systemctl start docker

Le status des noeuds de mon 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

Je vais d'abord enlever le rôle de manager à s003. s002 devrait rester Leader. Puis je vais enlever le rôle de manager à s002 donc s001 sera le seul manager restant et devrait devenir Leader.

Commandes 
ansible@s001:~$ sudo docker node demote ljt3zkvuzii9f90k7o0g5jx6d
Manager ljt3zkvuzii9f90k7o0g5jx6d demoted in the 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                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4
ansible@s001:~$ sudo docker node demote 0u3khzcl9z51ht6mkm4faejxw
Manager 0u3khzcl9z51ht6mkm4faejxw demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Leader           24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active                          24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Je teste :

  • l'accès à l'admin de Keycloak fonctionne
  • l'accès au datalake de DEV puis de PROD ISTA, en passant par Keycloak fonctionne

Je dois maintenant retirer s002 et s003 du swarm. Je veux le faire avec ansible.

Je mets à jour mon inventaire : 

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:
    # 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:
        s002:
        s003:

Puis je fais la commande : ansible-playbook -i ansible/inventory.yml ansible/02-swarm.yaml --tags swarm-leave -e "infra=swarm01".

Elle est restée bloquée après avoir affichée Ok [s002]. J'ai donc fait aussi la commande sudo docker swarm leave directement sur s002 qui a réussi car elle a affiché : Node left the swarm..

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

Mais j'ai un problème car Portainer était stické sur s002.

Comment j'ai rétabli Portainer

J'ai d'abord mis le tag qui sticke Portainer sur s001 avec la commande sudo docker node update --label-add portainer.portainer-data=true k232lszqgaa76qas459m9v9c1.

Portainer a démarré mais comme si je venais de l'installer. Je dois donc transférer le contenu du volume de s002 vers s001.

J'ai commencé par arrêter le service de Portainer qui utilise le volume avec cette commande sur s001 : sudo docker service scale portainer_portainer=0.

Puis j'ai transféré depuis mon poste avec ces 3 commandes :

  • ssh swarm01-s002 "sudo tar czf - /var/lib/docker/volumes/portainer_portainer-data/_data" > portainer_portainer-data/portainer-data.tar.gz
  • scp portainer_portainer-data/portainer-data.tar.gz swarm01-s001:/home/ansible/portainer-data.tar.gz
  • ssh swarm01-s001 "sudo tar xzf /home/ansible/portainer-data.tar.gz -C /home/ansible/ && sudo mv /home/ansible/var/lib/docker/volumes/portainer_portainer-data/_data/* /var/lib/docker/volumes/portainer_portainer-data/_data && sudo rm -rf /var/lib/docker/volumes/portainer_portainer-data/var"

Je redémarre le service avec sudo docker service scale portainer_portainer=1. J'arrive à me connecter. Je vois le swarm et je vois qu'il a 49 stacks mais je n'arrive pas à lister les stacks ni les services. Par contre je vois la liste des containers. J'ai des messages d'erreur "Unable to retrieve stacks" ou "Unable to retreive services". Parfois les stacks se sont affichées mais les services jamais.

Je décide de publier à nouveau portainer sur s001 avec ansible et la commande : ansible-playbook -i ansible/inventory.yml ansible/04-swarm01-utility-stacks.yaml --tags portainer (j'ai changé hosts: s002 par hosts: s001 avant).

Les agents de chaque node redémarrent (comme je le pensais) et, maintenant, mon portainer fonctionne à nouveau comme avant.

Je vois toujours s002 avec la commande sudo docker node ls exécutée sur s001. Il a le statut down depuis que je l'ai retiré du swarm. Je fais la commande sudo docker node rm 0u3khzcl9z51ht6mkm4faejxw pour l'enlever définitivement de la liste.

Je passe à s003. Sur s003, je fais la commande sudo docker swarm leave qui réussie avec le retour Node left the swarm.. Comme s002, s003 reste présent avec le statut down dans la liste de sudo docker node ls. Je le supprime donc avec la commande sudo docker node rm s003. Ca fonctionne : je n'ai plus que 4 serveurs dans swarm01.

J'arrête là pour aujourd'hui. Je supprimerai les machines la semaine prochaine.

Labels

  • supplier: scaleway

  • model: EM-A410X-SSD

  • ssh_port: 22178

  • ssh_user: ansible

  • compute: elastic-metal

Dependencies

Deprecated: s003

[Système : None] [Lifecycle : deprecated]

Manager du cluster swarm01

CPU Memory Disks IP v4 IP v6
12 64G 2 x 1 To SSD 51.159.100.61 2001:bc8:1201:14:2e59:e5ff:fe42:47c4

Events

2025-01-16 - 11:20 - Suppression des 2 machines Scaleway s002 et s003

Cela fait 6 jours que j'ai sorti ces 2 machines du cluster swarm01 et tout se passe bien. Je peux donc les "rendre" à Scaleway.

Je note ces 2 machines comme deprecated.

2025-01-10 - 18:20 - Suppression de 2 managers du cluster swarm01 (s002 et s003)

Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers.

Je choisi de garder s001 comme manager et de supprimer s002 et s003.

Je sauvegarde le répertoire /var/lib/docker/swarm sur s001.

Commande 
ansible@s001:~$ sudo tar -czvf var_lib_docker_swarm.20250110.tar.gz /var/lib/docker/swarm
tar: Removing leading `/' from member names
/var/lib/docker/swarm/
/var/lib/docker/swarm/worker/
/var/lib/docker/swarm/worker/tasks.db
/var/lib/docker/swarm/state.json
/var/lib/docker/swarm/docker-state.json
/var/lib/docker/swarm/raft/
/var/lib/docker/swarm/raft/wal-v3-encrypted/
/var/lib/docker/swarm/raft/wal-v3-encrypted/0000000000000282-0000000000fb5e32.wal
/var/lib/docker/swarm/raft/wal-v3-encrypted/0.tmp
/var/lib/docker/swarm/raft/snap-v3-encrypted/
/var/lib/docker/swarm/raft/snap-v3-encrypted/0000000000000184-0000000000fb7703.snap
/var/lib/docker/swarm/certificates/
/var/lib/docker/swarm/certificates/swarm-node.key
/var/lib/docker/swarm/certificates/swarm-root-ca.crt
/var/lib/docker/swarm/certificates/swarm-node.crt

Pour restaurer, faire (non testé) : 

sudo systemctl stop docker
sudo tar -xzvf swarm-backup.tar.gz -C /
sudo systemctl start docker

Le status des noeuds de mon 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

Je vais d'abord enlever le rôle de manager à s003. s002 devrait rester Leader. Puis je vais enlever le rôle de manager à s002 donc s001 sera le seul manager restant et devrait devenir Leader.

Commandes 
ansible@s001:~$ sudo docker node demote ljt3zkvuzii9f90k7o0g5jx6d
Manager ljt3zkvuzii9f90k7o0g5jx6d demoted in the 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                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4
ansible@s001:~$ sudo docker node demote 0u3khzcl9z51ht6mkm4faejxw
Manager 0u3khzcl9z51ht6mkm4faejxw demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Leader           24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active                          24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Je teste :

  • l'accès à l'admin de Keycloak fonctionne
  • l'accès au datalake de DEV puis de PROD ISTA, en passant par Keycloak fonctionne

Je dois maintenant retirer s002 et s003 du swarm. Je veux le faire avec ansible.

Je mets à jour mon inventaire : 

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:
    # 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:
        s002:
        s003:

Puis je fais la commande : ansible-playbook -i ansible/inventory.yml ansible/02-swarm.yaml --tags swarm-leave -e "infra=swarm01".

Elle est restée bloquée après avoir affichée Ok [s002]. J'ai donc fait aussi la commande sudo docker swarm leave directement sur s002 qui a réussi car elle a affiché : Node left the swarm..

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

Mais j'ai un problème car Portainer était stické sur s002.

Comment j'ai rétabli Portainer

J'ai d'abord mis le tag qui sticke Portainer sur s001 avec la commande sudo docker node update --label-add portainer.portainer-data=true k232lszqgaa76qas459m9v9c1.

Portainer a démarré mais comme si je venais de l'installer. Je dois donc transférer le contenu du volume de s002 vers s001.

J'ai commencé par arrêter le service de Portainer qui utilise le volume avec cette commande sur s001 : sudo docker service scale portainer_portainer=0.

Puis j'ai transféré depuis mon poste avec ces 3 commandes :

  • ssh swarm01-s002 "sudo tar czf - /var/lib/docker/volumes/portainer_portainer-data/_data" > portainer_portainer-data/portainer-data.tar.gz
  • scp portainer_portainer-data/portainer-data.tar.gz swarm01-s001:/home/ansible/portainer-data.tar.gz
  • ssh swarm01-s001 "sudo tar xzf /home/ansible/portainer-data.tar.gz -C /home/ansible/ && sudo mv /home/ansible/var/lib/docker/volumes/portainer_portainer-data/_data/* /var/lib/docker/volumes/portainer_portainer-data/_data && sudo rm -rf /var/lib/docker/volumes/portainer_portainer-data/var"

Je redémarre le service avec sudo docker service scale portainer_portainer=1. J'arrive à me connecter. Je vois le swarm et je vois qu'il a 49 stacks mais je n'arrive pas à lister les stacks ni les services. Par contre je vois la liste des containers. J'ai des messages d'erreur "Unable to retrieve stacks" ou "Unable to retreive services". Parfois les stacks se sont affichées mais les services jamais.

Je décide de publier à nouveau portainer sur s001 avec ansible et la commande : ansible-playbook -i ansible/inventory.yml ansible/04-swarm01-utility-stacks.yaml --tags portainer (j'ai changé hosts: s002 par hosts: s001 avant).

Les agents de chaque node redémarrent (comme je le pensais) et, maintenant, mon portainer fonctionne à nouveau comme avant.

Je vois toujours s002 avec la commande sudo docker node ls exécutée sur s001. Il a le statut down depuis que je l'ai retiré du swarm. Je fais la commande sudo docker node rm 0u3khzcl9z51ht6mkm4faejxw pour l'enlever définitivement de la liste.

Je passe à s003. Sur s003, je fais la commande sudo docker swarm leave qui réussie avec le retour Node left the swarm.. Comme s002, s003 reste présent avec le statut down dans la liste de sudo docker node ls. Je le supprime donc avec la commande sudo docker node rm s003. Ca fonctionne : je n'ai plus que 4 serveurs dans swarm01.

J'arrête là pour aujourd'hui. Je supprimerai les machines la semaine prochaine.

Labels

  • supplier: scaleway

  • model: EM-A410X-SSD

  • ssh_port: 22178

  • ssh_user: ansible

  • compute: elastic-metal

Dependencies

Deprecated: s006

[Système : None] [Lifecycle : deprecated]

Noeud du cluster swarm01

CPU Memory Disks IP v4 IP v6
24 192G 2 x 1 To SSD 51.159.101.12 None

Labels

  • supplier: scaleway

  • model: EM-B112X-SSD

  • ssh_port: 22178

  • ssh_user: ansible

  • compute: elastic-metal

Dependencies

Deprecated: s007

[Système : None] [Lifecycle : deprecated]

Noeud du cluster swarm01

CPU Memory Disks IP v4 IP v6
24 192G 2 x 1 To SSD 51.159.101.13 2001:bc8:1201:25:2e59:e5ff:fe3a:caf8

Events

2024-11-19 - 21:54 - Décommissionnement de s007

Maintenant qu'aucune application n'est stickée sur s007 et que je l'ai sorti de swarm01, je peux le rendre à Scaleway.

Serveur Elastic Metal s007 supprimé depuis l'UI de Scaleway.

2024-11-19 - Déplacement de notre Jenkins et de celui de Lur Berri vers s005

Nous avons fait cela afin de ne plus avoir d'applications avec des volumes stickés sur s007. Cela nous a permis de rendre la machine s007 à Scaleway.

Voir ma note détaillée.

Labels

  • supplier: scaleway

  • model: EM-B112X-SSD

  • ssh_port: 22178

  • ssh_user: ansible

  • compute: elastic-metal

Dependencies

Deprecated: scw-optimistic-brattain

[Système : None] [Lifecycle : deprecated]

Machine pour entraîner les modèles de la SMACL

CPU Memory Disks IP v4 IP v6
4 12G 120 GB 51.15.244.96 2001:bc8:710:1647:dc00:ff:fe2d:7f7d

Events

2025-03-24 - Suppression de la machine scw-optimistic-brattain

La Smacl n'étant plus un client, pas la peine de garder cette machine qui servait a entraîner ses modèles.

Labels

  • supplier: scaleway

  • model: DEV1-XL

  • dns_public: fea21a67-9089-4369-848a-1361cfef01e2.pub.instances.scw.cloud

  • ssh_port: 22

  • ssh_user: root

Deprecated: sentinel-api-1

[Système : None] [Lifecycle : deprecated]

Manager du cluster infra2

CPU Memory Disks IP v4 IP v6
8 64G ??? 51.159.17.217 None

Events

2024-07-05 - 17:00 - Décommissionnement des 3 machines de Sentinel API donc du cluster infra2

J'ai planté les machines du cluster de Sentinel API en faisant une mise à jour apt-get update && apt-get upgrade pour tenter de corriger des erreurs.

Comme j'avais préparé la machine yunohost-sentinel-api avec la PROD, nous avons décidé de basculer sur l'API de cette nouvelle machine et, donc, de décommissionner les 3 machines de l'ancien cluster.

Labels

  • supplier: scaleway

  • model: Pro-6-S

  • compute: dedibox

Dependencies

Deprecated: sentinel-api-2

[Système : None] [Lifecycle : deprecated]

Noeud du cluster infra2

CPU Memory Disks IP v4 IP v6
8 64G ??? 51.159.18.127 None

Events

2024-07-05 - 17:00 - Décommissionnement des 3 machines de Sentinel API donc du cluster infra2

J'ai planté les machines du cluster de Sentinel API en faisant une mise à jour apt-get update && apt-get upgrade pour tenter de corriger des erreurs.

Comme j'avais préparé la machine yunohost-sentinel-api avec la PROD, nous avons décidé de basculer sur l'API de cette nouvelle machine et, donc, de décommissionner les 3 machines de l'ancien cluster.

Labels

  • supplier: scaleway

  • model: Pro-6-S

  • compute: dedibox

Dependencies

Deprecated: sentinel-api-3

[Système : None] [Lifecycle : deprecated]

Noeud du cluster infra2

CPU Memory Disks IP v4 IP v6
8 64G ??? 51.159.18.50 None

Events

2024-07-05 - 17:00 - Décommissionnement des 3 machines de Sentinel API donc du cluster infra2

J'ai planté les machines du cluster de Sentinel API en faisant une mise à jour apt-get update && apt-get upgrade pour tenter de corriger des erreurs.

Comme j'avais préparé la machine yunohost-sentinel-api avec la PROD, nous avons décidé de basculer sur l'API de cette nouvelle machine et, donc, de décommissionner les 3 machines de l'ancien cluster.

Labels

  • supplier: scaleway

  • model: Pro-6-S

  • compute: dedibox

Dependencies

Deprecated: zookeeper-1

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.4.208 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SSD

  • compute: dedibox

Deprecated: zookeeper-2

[Système : None] [Lifecycle : deprecated]

No description

CPU Memory Disks IP v4 IP v6
??? ??? ??? 51.159.4.209 None

Events

2025-07-15 - Résiliation de l'infrastructure CoreAPI

J'ai résilié les 8 machines suivantes :

2025-07-01 - Arrêt de l'infrastructure CoreAPI

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

Labels

  • supplier: scaleway

  • model: Start-2-M-SSD

  • compute: dedibox