Aller au contenu

Contrôler vos VM sous FlatCar avec Nabraska

logo ansible

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 :

Terminal window
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.

Terminal window
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.

nebraska flatcat

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 :

Terminal window
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 :

Terminal window
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 :

Terminal window
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 :

Terminal window
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).

nebraska flatcat

Le téléchargement est bien en cours.

Retour sur la console de l’instance.

Terminal window
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].

nebraska flatcat

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 :

Terminal window
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.

Terminal window
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.