SUSE Manager 5.0 a été délivrée cet été, le 16 juillet, suivie d'une version 5.0.1 en août.
J'en ai entendu parler la première fois à la SUSECon de Munich il y a deux ans, dans une conférence abordant le challenge que les équipes de SUSE rencontraient pour réaliser la transformation d'un logiciel monolithique vers du micro-service.
Il s'agit en effet de la nouveauté majeure de cette version : la conteneurisation.
Conteneurs
Une solution comme SUSE Manager est composée d'un certain nombre de composants : le frontend sous Tomcat + Apache, une API XMLRPC, une base de données PostgreSQL, un gestionnaire de tâches, un Salt Master, Cobbler...
D'autres composants sont externes au serveur SUSE Manager central, comme par exemple le proxy.
Le passage aux conteneurs a plusieurs objectifs :
- Séparer le cycle de mise à jour des composants et de l'hôte, encore lié à SUSE Linux Enterprise Server 15 SP4 avant la mise à jour 5.x.
- Séparer le cycle de mise à jour de chaque composant, de façon à simplifier leur upgrade indépendamment les uns des autres, et ainsi accélérer le rythme d'évolution générale de la solution.
- Apporter de la robustesse dans les déploiements et dans la mise à jour de la solution : La mise à jour d'un conteneur consistant simplement à remplacer l'image par une nouvelle.
- À terme, pouvoir déployer la solution sur un cluster Kubernetes et bénéficier des capacités de haute disponibilité, scaling horizontal et automatisation de la solution (imaginez si vous pouviez déployer vos activation keys avec une CRD ?).
Il y a plusieurs approches pour arriver à ce résultat et la première étape est de déplacer toute l'application dans un simple conteneur unique. C'est l'option retenue par SUSE.
En pratique
Le système d'exploitation traditionnel SLES 15 est abandonné au profit de de SLE Micro 5.5, la distribution ultra-légère et transactionnel de SUSE.
Les services SUSE Manager ne tournent plus sur l'hôte mais dans un conteneur sur Podman, ce qui implique certains ajustements dans l'exploitation de la solution.
SLE Micro 5.5
Il s'agit d'une version allégée de SLE, dont les composants facultatifs ont été retiré.
L'objectif est de fournir un socle optimal pour héberger des workloads conteneurisés ou virtualisés. Il s'agit par exemple de la distribution utilisée pour Harvester HCI.
L'OS est dit "Immutable" (transactionnel), ce qui assure qu'aucune modification ne peut y être apportée pendant son exécution.
À l'usage, cela signifie que toute modification réalisée sur le système est perdue au redémarrage. Chaque modification permanente doit être réalisée lors d'un update transactionnel qui se charge alors de commiter les modifications sur le disque, puis d'un redémarrage.
Les gains sont multiples :
- Conformité : FIPS 140-2, DISA SRG/STIG, et conforme CIS.
- Sécurité : Le système est minimal, réduisant drastiquement le nombre de vulnérabilités.
- Stabilité : Les applications tournent dans leur conteneur et n'impacte pas l'hôte qui reste immuable.
Il s'agit également d'une distribution idéale pour des environnements Edge.
Il reste toutefois possible de déployer une SLE Micro et d'y installer SUSE Manager, ce qui est utile si vous êtes dans un environnement où vous ne pouvez pas déployer l'image de SUSE (GCE ne propose pas encore à ce jour SUMA 5 par exemple).
Par exemple, la mise à jour du système SLE Micro est réalisée par une commande :
transactional-updateIl ne reste ensuite qu'à redémarrer pour que les modifications soient pris en compte définitivement.
La gestion étant sensiblement différente, SUSE a implémenté des wrappers comme mgradm, mgr-storage-server et mgrctl
mgradm permet d'installer, mettre à jour et gérer SUSE Manager mais également de lancer la mise à jour de votre ancien environnement en 4.3.
mgr-storage-server permet de configurer le stockage nécessaire (PGSQL + Spacewalk).
mgrctl permet d'interagir avec le conteneur et de lancer les opérations connues que l'on trouve sur la version 4.3. Par exemple, mgrctl term ouvre un terminal dans le conteneur dans lequel on retrouve toutes les commandes standard.
Podman

Le container runtime retenu, podman, n'est pas basé sur Kubernetes mais s'y approche philosophiquement.
Pour faire simple, il s'agit d'une solution à mi-chemin entre Docker et Kubernetes, en stand-alone, gérant des pods plutôt que des conteneurs, et permettant de déployer des manifestes Kubernetes.
L'ensemble des composants de SUSE Manager a été intégré dans un conteneur unique utilisant des images :
suma:~ # podman image list
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/suse/manager/5.0/x86_64/server 5.0.1 2d88e5efd7c4 3 weeks ago 2.18 GB
localhost/suse/manager/5.0/x86_64/server-attestation 5.0.1 4d2bd5270189 4 weeks ago 361 MB
localhost/suse/manager/5.0/x86_64/server-hub-xmlrpc-api 5.0.1 44869c8331e4 4 weeks ago 178 MB
localhost/suse/manager/5.0/x86_64/server 5.0.0 0edb647be48d 2 months ago 2.22 GB
localhost/suse/manager/5.0/x86_64/server-migration-14-16 5.0.0 e242aa0fedb1 3 months ago 631 MBListing des images locales, on y voit les images en 5.0.1, plus récentes, et celles en 5.0.0.
suma:~ # podman ps
...
2c78627c566c localhost/suse/manager/5.0/x86_64/server:5.0.1 /usr/lib/systemd/... 18 minutes ago Up 18 minutes (healthy) 0.0.0.0:69->69/udp, 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:4505-4506->4505-4506/tcp, 0.0.0.0:5432->5432/tcp, 0.0.0.0:5556-5557->5556-5557/tcp, 0.0.0.0:9100->9100/tcp, 0.0.0.0:9187->9187/tcp, 0.0.0.0:9800->9800/tcp, 0.0.0.0:25151->25151/tcp uyuni-serverL'image de SUSE Manager en cours de fonctionnement.
La gestion du conteneur est réalisée automatiquement par l'intermédiaire de mgradm.
Par exemple, pour mettre à jour SUSE Manager, on lancera la commande mgradm upgrade podman qui se chargera de remplacer l'image en cours d'exécution par la dernière disponible, téléchargée lors de la dernière mise à jour réalisée avec un transactional-update.
suma:~ # mgradm upgrade podman
2:30PM INF Welcome to mgradm
2:30PM INF Executing command: podman
2:30PM INF Computed image name is registry.suse.com/suse/manager/5.0/x86_64/server:5.0.1
2:30PM INF Ensure image registry.suse.com/suse/manager/5.0/x86_64/server:5.0.1 is available
2:31PM INF Using the localhost/suse/manager/5.0/x86_64/server:5.0.1 image loaded from the RPM instead of its online version
...
Running smdba system-check autotuning...
INFO: No changes required.
System check finished
Starting Postgresql...
...
Planning to run schema upgrade with dir '/var/log/spacewalk/reportdb-schema-upgrade/schema-from-20241010-123137'
Executing spacewalk-sql, the log is in [/var/log/spacewalk/reportdb-schema-upgrade/schema-from-20241010-123137-to-uyuni-reportdb-schema-5.0.6.log].
(2/2) apply upgrade [schema-from-20241010-123137/99_9999-upgrade-end.sql]
The database schema was upgraded to version [uyuni-reportdb-schema-5.0.6-150600.1.6].
Schedule a system list update task...
INSERT 0 0
Stopping Postgresql...
...
DONE
WARN[0000] Path "/etc/SUSEConnect" from "/etc/containers/mountsMise à jour de SUMA 5.0 vers la version 5.0.1
Mais tout cela a d'autres implications :
- Le Salt Master se retrouve dans un conteneur... ainsi que toutes les commandes Salt. Il est alors nécessaire de lancer un terminal avec mgrctl term pour lancer des jobs Salt.
Selon vos usages, cela peut avoir un impact. Quelques exemples :- Si vous utilisiez des scripts faisant directement appel aux commandes Salt, ils devront être réadapté pour utiliser mgrctl.
- Si vous aviez configurer votre Salt Master pour utiliser les ACLs Salt, le terminal du conteneur ne vous permettra pas de les exploiter.
- Les commandes Spacewalk se retrouvent également dans un conteneur.
- Le stockage standard, généralement dans des points de montages figés, est remplacé par des volumes podman.
Bien heureusement, le conteneur a été conçu de manière à réduire au maximum les frictions et on retrouve rapidement ses petits, surtout si l'on a quelques connaissances Docker / Podman.
Il est possible d'analyser sa conception avec la commande : podman generate kube <containerid>
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2024-10-10T13:10:37Z"
labels:
app: uyuni-server-pod
name: uyuni-server-pod
spec:
containers:
- env:
- name: TZ
value: UTC
- name: HOSTNAME
value: uyuni-server.mgr.internal
image: localhost/suse/manager/5.0/x86_64/server:5.0.1
name: uyuni-server
...La première section déclare un pod uyuni-server-pod utilisant l'image de SUSE Manager
...
- containerPort: 69
hostPort: 69
protocol: UDP
- containerPort: 80
hostPort: 80
- containerPort: 443
hostPort: 443
- containerPort: 4505
hostPort: 4505
...Le bloc suivant bind tous les ports de SUSE Manager à ceux de son hôte
...
volumeMounts:
- mountPath: /run
name: tmp-0
- mountPath: /srv/salt
name: srv-salt-pvc
- mountPath: /root
name: root-pvc
- mountPath: /etc/apache2
name: etc-apache2-pvc
- mountPath: /var/spacewalk
name: var-spacewalk-pvc
- mountPath: /var/lib/pgsql
name: var-pgsql-pvc
- mountPath: /etc/salt
name: etc-salt-pvc
- mountPath: /etc/systemd/system/multi-user.target.wants
name: etc-systemd-multi-pvc
...
volumes:
- emptyDir:
medium: Memory
name: tmp-0
- name: srv-salt-pvc
persistentVolumeClaim:
claimName: srv-salt
- name: root-pvc
persistentVolumeClaim:
claimName: root
- name: etc-apache2-pvc
persistentVolumeClaim:
claimName: etc-apache2
- name: var-spacewalk-pvc
persistentVolumeClaim:
claimName: var-spacewalk
- name: var-pgsql-pvc
persistentVolumeClaim:
claimName: var-pgsql
La section volumeMounts monte l'ensemble des volumes déclarés dans le conteneurs. Les volumes sont déclarés dans la section volumes. Tous les volumes sont des volumes podmans.
Les volumes podmans peuvent être listés avec la commande podman volume ls, mais on les retrouve également sur le filesystem :
suma:/var/lib/containers/storage/volumes # ls -l
total 0
drwx------. 3 root root 19 Sep 16 17:28 ca-cert
drwx------. 3 root root 19 Sep 16 17:28 cgroup
drwx------. 3 root root 19 Sep 16 17:28 etc-apache2
drwx------. 3 root root 19 Sep 16 17:28 etc-cobbler
drwx------. 3 root root 19 Sep 16 17:28 etc-postfix
drwx------. 3 root root 19 Sep 16 17:28 etc-rhn
drwx------. 3 root root 19 Sep 16 17:28 etc-salt
drwx------. 3 root root 19 Sep 16 17:28 etc-sssd
drwx------. 3 root root 19 Sep 16 17:28 etc-sysconfig
drwx------. 3 root root 19 Sep 16 17:28 etc-systemd-multi
drwx------. 3 root root 19 Sep 16 17:28 etc-systemd-sockets
drwx------. 3 root root 19 Sep 16 17:28 etc-tls
drwx------. 3 root root 19 Sep 16 17:28 etc-tomcat
drwx------. 3 root root 19 Sep 16 17:28 root
drwx------. 3 root root 19 Sep 16 17:28 srv-formulametadata
drwx------. 3 root root 19 Sep 16 17:28 srv-pillar
drwx------. 3 root root 19 Sep 16 17:28 srv-salt
drwx------. 3 root root 19 Sep 16 17:28 srv-spacewalk
drwx------. 3 root root 19 Sep 16 17:28 srv-susemanager
drwx------. 3 root root 19 Sep 16 17:28 srv-tftpboot
drwx------. 3 root root 19 Sep 16 17:28 srv-www
drwx------. 3 root root 19 Sep 16 17:28 tls-key
drwx------. 3 root root 19 Sep 16 17:28 var-cache
drwx------. 3 root root 19 Sep 16 17:28 var-cobbler
drwx------. 3 root root 19 Sep 16 17:28 var-log
drwx------. 3 root root 19 Sep 16 17:28 var-pgsql
drwx------. 3 root root 19 Sep 16 17:28 var-salt
drwx------. 3 root root 19 Sep 16 17:28 var-spacewalkOn les retrouve également dans le répertoire /var/lib/containers/storage/volumes
Features
Cette mise à jour se concentre sur la modification d'architecture de la solution.
Quelques fonctionnalités viennent toutefois s'ajouter à la plateforme.
Des mises à jours de composants et de clients supportés :
- Des mises à jours de composants :
- PostgreSQL passe de la version 14 à 16.
- Nouvelle version LTS de Java en v17.
- Prometheus node_exporter v1.7.0, Grafana 9.5.18
- De nouveaux clients :
- Support des SLE 15 SP6.
- SLE Micro 6.0
- Leap 15.6
De nouvelles fonctionnalités et des améliorations :
- Une meilleure gestion des AppStreams Red Hat, permettant aux administrateurs d'activer des modules pour les clients. Il devient également possible de les associer à des clés d'activations.
- Un state récurrent nommé update-salt facilite la mise à jour des clients.
Plusieurs fonctionnalités ont été supprimé :
- Le client traditionnel, déjà deprecated en 4.3
- La découverture des environnements Bare Metal et leur provisionnement.
- La fonction de visualisation disponible dans la liste des systèmes.
D'autres sont deprecated :
- La gestion de la virtualisation avec libvirt permettant de gérer des environnements KVM.
- ISSv1 est deprecated au profit de ISSv2. Pour rappel, il s'agit d'un service de synchronisation inter-serveur pour SUSE Manager.
Comme toujours, SUSE maintient une release note complète des nouvelles fonctionnalités.
Pour quelques instructions concernant les mises à jours, l'article est en cours de rédaction, mais cela se passera ici.