Aller au contenu principal

Contrôler vos VM sous FlatCar avec Nabraska

· 6 minutes de lecture
Stéphane ROBERT
Stéphane ROBERT
Consultant DevOps

Dans un précédent billet, je vous ai présenté FlatCar Linux, un os immutable. Par manque de temps, j'avais laissé le sujet de côté. Suite à une discussion, j'ai découvert Nebraska le serveur de mise à jour d'instances FlatCar.

Nebraska​

Par défaut les instances Flatcar Linux utilisent les serveurs publics pour obtenir les mises à jour de l'OS. Pour gérer finement ces mises à jour, il faut mettre en place un serveur qui prend en charge le protocole Ohama. C'est là qu'entre en jeux Nebraska.

Installation de Nebraska​

Pour le moment, il n'existe pas de package permettant d'installer facilement Nebraska, c'est pourquoi je vais utiliser la stack docker-compose du projet pour monter mon POC. Pour info, dans la documentation, on trouve aussi comment l'installer dans un cadre d'entreprise sur un serveur Kubernetes en le couplant avec le système d'authentification OpenID.

Installation du projet​

Bon, on clone le projet :

git clone https://github.com/kinvolk/nebraska.git
cd nebraska/backend

Pour permettre de récupérer les dernières versions des images à partir des serveurs publiques, il faut éditer le fichier docker-compose.test.yaml présent dans ce dossier :

version: "3.9"

services:
  postgres:
    image: postgres:12.9
    ports:
      - "8001:5432"
    environment:
      POSTGRES_PASSWORD: nebraska
      POSTGRES_DB: nebraska_tests
      POSTGRES_USER: postgres
      TZ: UTC
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  server:
    build:
      context: ../
      dockerfile: Dockerfile
      network: host
    ports:
      - "8002:8000"
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - NEBRASKA_DB_URL=postgres://postgres:nebraska@postgres:5432/nebraska_tests?sslmode=disable&connect_timeout=10
    command: sh -c "/nebraska/nebraska --auth-mode=noop -enable-syncer=true --http-static-dir=/nebraska/static --api-endpoint-suffix=/"

Modifier simplement la dernière ligne de fichier pour ajouter l'option -enable-syncer=true comme indiqué dans la documentation.

Reste plus qu'à démarrer le tout.

docker-compose -f docker-compose.test.yaml up -d

Connexion au frontend de Nebraska​

Normalement au bout de quelques minutes le serveur devrait être disponible. Il suffit suivre le lien suivant http://localhost:8002.

Tout est prêt pour enregistrer notre premier client.

Rattachement de notre premier client​

Reprenons notre exemple de notre précédent article. Nous allons simplement ajouter un fichier /etc/flatcar/update.conf :

---
passwd:
  users:
    - name: core
      ssh_authorized_keys: ${ssh_keys}
storage:
  files:
    - path: /home/core/works
      filesystem: root
      mode: 0755
      contents:
        inline: |
          #!/bin/bash
          set -euo pipefail
          hostname="$(hostname)"
          echo My name is ${name} and the hostname is $${hostname}
    - path: /etc/flatcar/update.conf
      filesystem: root
      mode: 0644
      contents:
        inline: |
          GROUP=stable
          SERVER=http://192.168.122.1:8002/v1/update/
systemd:
  units:
    - name: nginx.service
      enabled: true
      contents: |
        [Unit]
        Description=NGINX example
        After=docker.service
        Requires=docker.service
        [Service]
        TimeoutStartSec=0
        ExecStartPre=-/usr/bin/docker rm --force nginx1
        ExecStart=/usr/bin/docker run --name nginx1 --pull always --net host docker.io/nginx:1
        ExecStop=/usr/bin/docker stop nginx1
        Restart=always
        RestartSec=5s
        [Install]
        WantedBy=multi-user.target

Il faut remplacer dans la chaine SERVER=http://192.168.122.1:8002/v1/update/ l'IP par celle de votre machine.

Avant de démarrer notre instance, nous allons télécharger une ancienne version de l'image flatcar :

wget  https://stable.release.flatcar-linux.net/amd64-usr/3139.2.3/flatcar_production_qemu_image.img.bz2
bunzip2 flatcar_production_qemu_image.img.bz2

Maintenant, relançons l'instance :

terraform apply --auto-approve
...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

ip-addresses = {
  "mycluster-mynode" = tolist([
    "192.168.122.46",
  ])
}

On se connecte à notre instance :

ssh -i ~/.ssh/id_ed25519 core@192.168.122.46
Last login: Fri Nov 18 11:57:55 UTC 2022 from 192.168.122.1 on pts/0
Flatcar Container Linux by Kinvolk stable 3402.1.0 for QEMU
core@mycluster-mynode ~ $

On lance manuellement le client :

update_engine_client --update

I1118 15:27:24.636034  1172 update_engine_client.cc:251] Initiating update check and install.
I1118 15:27:24.645364  1172 update_engine_client.cc:256] Waiting for update to complete.

update_engine_client -update
I1118 16:20:34.466879  1275 update_engine_client.cc:251] Initiating update check and install.
I1118 16:20:34.473798  1275 update_engine_client.cc:256] Waiting for update to complete.
LAST_CHECKED_TIME=1668788434
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATE_AVAILABLE
NEW_VERSION=3374.2.0
NEW_SIZE=360141900
LAST_CHECKED_TIME=1668788434
PROGRESS=0.050088

I1118 15:27:44.661505  1172 update_engine_client.cc:194] No update available

Si vous retournez sur le frontend de Nebraska, vous devriez retrouver votre instance dans le groupe Stable (Défini dans la conf de l'instance).

Le téléchargement est bien en cours.

Retour sur la console de l'instance.

LAST_CHECKED_TIME=1668788434
PROGRESS=0.000000
CURRENT_OP=UPDATE_STATUS_UPDATED_NEED_REBOOT
NEW_VERSION=3374.2.0
NEW_SIZE=360141900
I1118 16:22:19.810748  1275 update_engine_client.cc:198] Update succeeded -- reboot needed.

La mise à jour est prête à être installé. Manque juste le reboot. Normalement cela se fait tout seul, car la stratégie par défaut est de faire le reboot dans un délai de 5 minutes. Pour changer de stratégie il faut se rendre dans la documentation de flatcar.

Changer de release de votre group​

Il faut se rendre dans la section [Flatcar Container Linux] et dans le Channel de votre instance de cliquer sur les ... et choisir l'action [Edit]. Choissisez votre Package et Cliquer sur [SELECT], puis [SAVE].

Une fois modifié. Vous pouvez attendre que votre instance se mette à jour toute seule ou faire comme précédemment.

Pour vérifier le processus, vous pouvez sur votre instance afficher le status du service d'update :

mycluster-mynode ~ # systemctl status  update-engine.service
● update-engine.service - Update Engine
     Loaded: loaded (/usr/lib/systemd/system/update-engine.service; disabled; vendor preset: disabled)
     Active: active (running) since Fri 2022-11-18 16:28:29 UTC; 7min ago
   Main PID: 721 (update_engine)
      Tasks: 2 (limit: 7368)
     Memory: 9.2M
        CPU: 71ms
     CGroup: /system.slice/update-engine.service
             └─721 /usr/sbin/update_engine -foreground -logtostderr

Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192747   721 omaha_request_action.cc:619] Omaha request response: <?xml versio>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: <response protocol="3.0" server="nebraska"><daystart elapsed_seconds="0"></daystart><app appi>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192929   721 omaha_request_action.cc:409] No update.
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192948   721 action_processor.cc:82] ActionProcessor::ActionComplete: finished>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192957   721 omaha_response_handler_action.cc:36] There are no updates. Aborti>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192965   721 action_processor.cc:68] ActionProcessor::ActionComplete: OmahaRes>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192971   721 action_processor.cc:73] ActionProcessor::ActionComplete: finished>
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192979   721 update_attempter.cc:302] Processing Done.
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.192997   721 update_attempter.cc:338] No update.
Nov 18 16:30:35 mycluster-mynode update_engine[721]: I1118 16:30:35.193012   721 update_check_scheduler.cc:74] Next update check in 41m1s

Le prochain update aura lieu dans 41m....

Tout cela est contrôlable via la configuration de ce service.

Comment faire un rollback sur notre instance​

Nous allons faire un rollback de notre instance à une ancienne version de flatcar.

flatcar-update --to-version 3402.1.0

Plus loin avec Nebraska​

Bon notre POC est validé. Reste à le déployer dans un cluster Kubernetes.

PS: Merci à Jérôme HARDY et Thomas Delacotte de Claranet France pour cette découverte ! Il l'utilise pour ne plus gérer le patch management des nodes de leurs clusters Kubernetes OnPrem.