Container on Zwindler's Reflection

QNAP débranche LXC sur les NAS ARM : comment contourner ?

Mon, 13 Jun 2022 08:00:00 +0200

Si vous le suivez sur Twitter ou Masto, vous m’avez très probablement lu râler contre la sortie ~~de QTS 5~~ Container Station v2.4.0.2316, l’été dernier.

Ou plus particulièrement, contre une décision prise lors de ce passage : enlever LXC pour l’administration des containers, au profit de LXD. LXD étant juste une couche d’administration, LXC est toujours présent et fonctionnel, juste caché.

Pourquoi je râle ?

J’ai un NAS QNAP TS431P2 depuis 2018 dont je suis pleinement satisfait, et qui m’a permis de passer moins de temps à administrer et ajouter des fonctionnalités à mon NAS ZFS maison, monté initialement en 2011 (merci Dworak_of_sky pour les souvenirs).

Sauf que mon QNAP est un NAS milieu de gamme, fonctionnant avec un processeur ARM et pas x86 ! Et ces charmantes personnes (grrrr) de chez QNAP n’ont pas porté LXD sur les NAS ARM (segmentation artificielle de l’offre ? Flemme ?).

Nous, propriétaires de NAS QNAP ARM, nous retrouvons donc sans solution puisque LXC est désactivé et LXD pas disponible.

Une fonction hyper pratique pour héberger de petits services à bas coût (autant en performance qu’en prix) disparaît. C’était un réel différenciant pour ce modèle et je me sens vraiment trahi (ou alors c’est ma faute, car je n’aurais pas dû leur faire confiance ?).

Je ne suis pas près de recommander QNAP comme j’ai pu le faire par le passé. #PasContent

Nuance

HEUREUSEMENT, les containers LXC ne se sont pas mis à ne plus marcher du jour au lendemain.

Enfin, encore heureux ! Je n’ose imaginer les dégâts en prod !

C’est d’autant plus vicelard que le message d’information pour expliquer qu’il n’y a plus LXC indique que c’est pas grave puisque vous avez LXD à la place. Aucune mention du fait qu’en fait, sous ARM, non…

Il est toujours possible (pour l’instant) de démarrer, arrêter, utiliser et supprimer les containers existants. Mais il n’est plus possible d’en créer de nouveaux.

Ça veut donc dire que tout est encore présent pour faire fonctionner la fonctionnalité, ce n’est “juste” plus disponible en UI.

En avoir le coeur net

En farfouillant, je me suis aussi rendu compte qu’il était toujours possible d’exporter des containers existants et d’importer les exports.

On peut donc contourner la limitation arbitraire de QNAP via des export / import. J’ai l’habitude de ce genre de bidouilles, puisque je faisais déjà ça il y a plus de 10 ans avec les hyperviseurs VMware en licence gratuite…

A l’usage, ça fonctionne mais c’est pas satisfaisant. D’abord parce que si on a pas, ou plus, de containers sur le NAS, on ne peut pas le faire trivialement.

Ensuite, parce que le processus et long (l’export et l’import) et pénible (plusieurs étapes).

Enfin, parce que les images LXC mises à disposition par QNAP étaient antédiluviennes !

Ubuntu 14.04 !!! Sauf si vous avez pris le temps de faire le processus d’upgrade complet de 14.04 à 20.04 ou 22.04 (et vous devriez), il est probable que vous n’ayez pas envie de repartir de ces vieux machins.

“Faites mieux”

Si vous êtes admin, vous avez probablement déjà activé SSH pour vous connecter directement à l’OS de votre NAS. (Et sinon vous pouvez aller ici pour l’activer)

Une fois connecté, on peut sortir du menu TUI et bidouiller l’OS comme on en a envie.

[~] # id
uid=0(admin) gid=0(administrators)

Je n’ai pas fait beaucoup d’administration LXC/LXD directement, car j’avais toujours une interface à ma disposition pour me “cacher” la façon dont ça fonctionne vraiment, que ce soit dans le cas de QNAP ou de Proxmox VE (que j’utilise beaucoup pour ça).

En lisant rapidement la doc sur ubuntu-fr, j’ai compris qu’il existait en fait chez Canonical un genre de dépôt d’images officielles de pleins d’OS, notamment compatible armhf.

Avec LXC, on peut accéder directement à ces images en ligne de commande avec lxc-download. Pas de bol, la commande n’est pas dispo sur QTS :

[~] # lxc-download
-sh: lxc-download: command not found

(En fait elle n’est juste pas dans le PATH, mais je ne le savais pas à ce moment-là)

Sauf qu’on peut aussi appeler directement la commande pour créer des containers lxc-create avec un flag “download”. Et ça tombe bien parce que lxc-create est disponible. Mais la joie sera de courte durée…

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf

/usr/local/container-station/lxc/share/lxc/templates/lxc-download: line 237: getopt: command not found

Hack…

Note : si vous trouviez que ce qu’on était en train de faire n’était déjà pas très propre, je tiens à vous prévenir, la suite est vraiment immonde… Pas merci QNAP de me forcer à faire ça !

Le script /usr/local/container-station/lxc/share/lxc/templates/lxc-download est moisi. Il manque la moitié des binaires dans la busybox.

Pire encore, la procédure que je donne ici semble être écrasée à chaque mise à jour de l’application Container Station. Mais, ça fonctionne…

La première chose qu’on va faire, c’est faire une sauvegarde du script lxc-download par sécurité.

cp /usr/local/container-station/lxc/share/lxc/templates/lxc-download{,.old}

Le premier message d’erreur qu’on a getopt: command not found indique juste que de nombreux binaires “classiques” ne sont pas disponibles directement dans le shell de QTS.

Sauf qu’en fait, ils sont là, ces binaires. Pas besoin de les télécharger ou de les compiler. Ils ne sont juste “pas visibles”.

QTS tourne, comme beaucoup de serveurs Linux minimalistes, avec l’aide de Busybox.

On peut donc “magiquement activer” les binaires qui nous manquent simplement avec des liens symboliques.

for binary in getopt xz seq; do
 ln -s /share/CACHEDEV1_DATA/.qpkg/container-station/bin/busybox /share/CACHEDEV1_DATA/.qpkg/container-station/bin/${binary}
done

getopt
getopt: missing optstring argument

… and slash!

C’est bon, mais pas suffisant.

La version du binaire mktemp de busybox n’est malheureusement PAS compatible avec le script lxc-download. On va devoir le modifier à la main…

Usage: mktemp [-dq] TEMPLATE

Le passage problématique se situe autour des lignes 320-325

320 if ! command -V mktemp >/dev/null 2>&1; then
321 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmp/lxc-download.$$"
322 else
323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)"
324 fi

En vrai, mktemp s’attend à avoir le path complet, accompagné d’un pattern à base de XXXXXX. mktemp remplace ensuite les caractères XXXXXX par un nombre aléatoire en s’assurant que le dossier n’existe pas déjà, puis le créé. Par exemple

mktemp /tmp/mydirXXXXX

Mode bourrin, j’ai remplacé la ligne par :

323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmpdir" && mkdir -p ${DOWNLOAD_TEMP}

De toute façon, il est supprimé à la fin de l’exécution du script, ce dossier (fonction cleanup dans le shell).

GPG

On progresse !

[~] # lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf
Setting up the GPG keyring
chmod: /var/lib/lxc/container_jammy/tmpdir/gpg: No such file or directory
Error creating container container_jammy

En creusant un peu, la vraie erreur est que je n’ai pas le binaire gpgkeys_curl à l’endroit attendu :

gpg: unable to execute program `/opt/cross-project/arm/linaro/arm-linux-gnueabihf/libc/libexec/gnupg/gpgkeys_curl': No such file or directory

Voilà un autre point que je n’ai pas réussi à corriger correctement.

Le plus simple est de simplement ignorer la validation avec --no-validate mais si vous avez une piste, je suis preneur.

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf --no-validate

Des dossiers qui disparaissent tout seul ???

Dernier mystère…

Downloading the image index
ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-system

L’erreur n’est pas du tout un problème d’accès à l’URL pour télécharger l’index des systèmes disponibles sur images.linuxcontainers.org (code 302, page redirigée sur uk.lxd.images.canonical.com).

En réalité, si active les messages d’erreurs lors du wget dans le script, l’erreur est que le dossier /var/lib/lxc/container_jammy/tmpdir/ n’existe pas !

Pourtant, ça devrait être corrigé, suite à la modif qu’on a faite ligne 323 (voir plus haut)… trop bizarre :/

J’en ai eu un peu marre de creuser et au bout d’un moment, j’ai juste fait :

export CONTAINER_NAME=jammy
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/tmpdir/
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/rootfs/
lxc-create -t download -n ${CONTAINER_NAME} -- -d ubuntu -r jammy -a armhf --no-validate

Et croyez-le ou non, mais ça marche ! Le container existe (il n’est juste pas visible dans la console pour l’instant)

[...]
You just created an Ubuntu jammy armhf (20220611_07:42) container.

On a plus qu’à redémarrer Container Station, il apparaît

Conclusion

Si jamais quelqu’un de chez QNAP lit ce blogpost… Arrêtez de vous fiche de nous et :

mettez nous LXD dans nos NAS ARM
OU si c’est trop de boulot (je peux l’entendre), remettre LXC en attendant.

Ce genre de hack est indigne et j’ai perdu plusieurs heures pour corriger votre m***e. J’ai payé pour un NAS compatible LXC, ce n’est pas pour que vous retiriez la fonctionnalité 1 an après.

Ce genre de pratiques est vraiment dégueulasse et je n’hésiterais pas à dire tout le mal que je pense de cette décision.

Sources

Kubernetes avec RancherOS et RKE – partie 1

Mon, 26 Oct 2020 07:45:00 +0000

RancherOS pour commencer

Pendant l’été, j’ai encore changé d’infra, avec un passage à un cluster Proxmox VE à 3 nœuds. Je reviendrais la dessus, mais la finalité c’est que j’ai eu (encore) l’envie de m’installer un petit cluster Kubernetes dans mes hyperviseurs.

Ceux qui me suivent depuis un moment savent que j’en ai déjà déployé des tonnes depuis le temps (k3s qui vient également de chez Rancher, mais aussi kubespray, kubeadm, aks, OVH, the hard way de kelsey hightower, …).

Du coup, plutôt que de gagner du temps et refaire quelque chose que je maîtrise déjà, je suis parti dans l’idée de tester quelque chose d’encore nouveau, deux produits de Rancher dont j’ai entendu parler : RancherOS + RKE !

L’idée dans cette première partie est de découvrir RancherOS, une des nombreuses solutions pour vos workload containerisés proposées par Rancher.

Mais c’est quoi RancherOS ?

RancherOS A lightweight, secure Linux distribution, built from containers to run containers well. RancherOS est donc un OS minimaliste contenant juste ce qu’il faut pour faire du Docker, configuré à l’aide de cloud-init et dans lequel la plupart des opérations de maintenances sont simplifiées. Quand je lis ça, je ne peux pas m’empêcher de repenser à CoreOS, qui faisait (fait) les mêmes promesses. N’ayant qu’installé et utilisé pendant peu de temps CoreOS, je ne serai pas capable de faire une comparaison des deux produits entre eux, mais la finalité est vraiment la même. Un point intéressant (je trouve) dans RancherOS est le fait que tous les services “techniques” nécessaires pour faire fonctionner correctement vos applications containerisés sont également des containers. RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as udev and syslog.

L’idée ici, c’est que tous ces services systèmes tournent dans un démon Docker séparé (pour plus de sécurité et éviter la suppression accidentelle).

Comment le déployer ?

Ça dépend. Et évidemment, ça dépend, ça dépasse.

Rancher a fait le choix (malin) de mettre le paquet pour faciliter le déploiement de leur RancherOS sur le plus de plateformes possibles.

Ainsi, vous retrouverez des processus de déploiement facilités pour la plupart des clouds providers public, mais aussi des images pour VMware, une image pour Rasberry Pi, Virtual Box ou Docker Machine. Il y a même de quoi booter en PXE pour ceux qui ont encore l’envie de faire ce genre de choses.

Dans mon cas, la seule solution à ma disposition pour KVM c’est d’utiliser l’ISO.

Première bonne nouvelle et première déconvenue

LA première bonne nouvelle, c’est qu’il existe un ISO tuné pour Proxmox VE, et ça c’est très cool.

Donc je DL l’ISO, créé une bête machine virtuelle sur mon cluster, dans lequel l’ISO est monté et roule ma poule ?

Ouais… presque !

You must boot with enough memory which you can refer to here.

Un point agaçant avec RancherOS est le minimum requirement en termes de mémoire. 1.25 Go pour un OS Linux soi-disant minimaliste (passé à 1 Go depuis la 1.5), la pilule a du mal à passer. Ok, je pinaille peut-être un peu, mais 1 Go c’est énorme quand on a prévu de lancer juste quelques petits containers comme des petits nginx ou des petits bouts de code python.

Il faut dire que Rancher nous a mal habitué avec k3s, leur Kubernetes modifié qui tourne avec quasiment pas de RAM au point de permettre de Kubernetes sur des RPi 1 ou en edge computing. Et là, avec 2 fois plus de RAM en requirement, j’ai que le démon Docker, même pas le kube qui va avec…

Du coup, le “RancherOS is the smallest, easiest way to run Docker in production”, bof…

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Rancher essaye de se raccrocher aux branches en vous linkant une doc permettant de construire soi-même une image custom nécessitant moins de RAM, mais bon… Le mal est fait, ils m’ont pas motivé à tester…

Déployer RancherOS sur Proxmox VE

Ok, assez discuté, maintenant on peut rentrer dans le vif du sujet. Sur notre hyperviseur préféré, on récupère l’ISO.

cd /var/lib/vz/template/iso
wget https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
--2020-08-10 15:00:26-- https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
Resolving releases.rancher.com (releases.rancher.com)... 104.26.12.240, 172.67.69.133, 104.26.13.240, ...
Connecting to releases.rancher.com (releases.rancher.com)|104.26.12.240|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 160432128 (153M) [application/x-iso9660-image]
Saving to: ‘rancheros.iso’
rancheros.iso 100%[===================>] 153.00M 42.3MB/s in 3.7s
2020-08-10 15:00:36 (40.9 MB/s) - ‘rancheros.iso’ saved [160432128/160432128]

La procédure d’installation officielle est disponible ici.

Grosso modo, on boot la VM, qui va configurer le serveur au minimum et permettre de se connecter avec l’utilisateur rancher sans mot de passe. L’idée est d’utiliser cet utilisateur pour finaliser l’installation avec ros install une fois la VM configurée.

The ros install` command orchestrates the installation from the rancher/os container. You will need to have already created a cloud-config file and found the target disk.

STOOOOOP

Si vous partez bille en tête comme moi et faites un ros install` sans lire la phrase en entier, vous vous retrouverez avec une VM sur laquelle vous ne pourrez pas vous loguer (voire sans réseau si vous n’avez pas de DHCP). C’est con.

The easiest way to log in is to pass a cloud-config.yml file containing your public SSH keys.

Cloud config

Ok, on va éviter de tous faire la même erreur. Voici maintenant le fameux prérequis, la documentation officielle qui parle de configuration/#cloud-config.

Si vous avez un doute sur certains paramètres, vous pouvez toujours utiliser la commande ros config` qui permet de récupérer les valeurs par défaut puis les setter.

On finalisera le tout en fusionnant la config actuelle avec un fichier YAML, ou alors on exportera la conf actuelle dans un autre fichier YAML.

Dans le cas d’un PoC, la plupart des valeurs qui vont nous intéresser sont simplement ce qui permet de setter l’IP et de configurer notre clé SSH pour pouvoir se connecter.

sudo ros config get rancher.network
dhcp_timeout: 0
dns:
nameservers: []
search: []
http_proxy: ""
https_proxy: ""
interfaces: {}
modem_networks: {}
no_proxy: ""
post_cmds: []
pre_cmds: []
wifi_networks: {}

Donc là, de base, bah ya rien.

Pourtant, si vous allez voir le fichier /var/lib/rancher/conf/cloud-config.yml, vous remarquerez qu’il y a pleeeeein de choses, plus ou moins utiles.

La page de doc qui nous intéressera donc dans ce cas est networking. Voici un exemple de commandes pour configurer une IP fixe (à remplacer par des valeurs qui ont du sens dans votre réseau, of course).

sudo ros config set rancher.network.interfaces.eth0.address 192.168.1.10/24
sudo ros config set rancher.network.interfaces.eth0.gateway 192.168.1.1
sudo ros config set rancher.network.interfaces.eth0.mtu 1500
sudo ros config set rancher.network.interfaces.eth0.dhcp false

A partir de ce moment là, vous avez accès au réseau depuis votre machine RancherOS, mais les modifications ne seront pas permanentes. On va donc exporter tout ça.

sudo ros config export
rancher:
environment:
EXTRA_CMDLINE: /init
network:
interfaces:
eth0:
address: 192.168.1.10/24
dhcp: false
gateway: 192.168.1.10
mtu: 1500
ssh_authorized_keys: []

Bon, et là vous voyez qu’il nous manque toujours la clé SSH.

Bonus clavier qwerty

Vous connaissez la différence entre un admin systèmes français débutant et un admin système français senior ?

If you call yourself a sysadmin and don’t know by heart the qwerty layout on an azerty keyboard, I just assume you are a junior.

(Pour ceux qui n’ont pas la blague, allez voir ce tweet de _oshell qui a bien backfired (lien mort) dans sa face)

Le senior, a force de bouffer des consoles à la con qui gèrent mal les différents layouts de claviers (parce que “hé, on s’en fout des gens qui ont pas de qwerty, on vient de la Silicon valley”), il connaît le qwerty par cœur.

Et ben là encore, ça n’a pas loupé. La console NoVNC de mon PVE, qui en plus n’avait le partage de presse-papier qui ne marchait pas.

Je veux bien être à l’aise en “blind qwerty sur azerty”, mais faut pas déconner, je suis pas senior au point d’être capable de copier une clé publique dans un YAML #trollface.

Donc pour ceux qui ne connaissent pas l’astuce, il est possible d’affecter temporairement un terminal série à votre VM de la façon suivante (voir doc Proxmox VE)

# qm set 100 -serial0 socket
update VM 100: -serial0 socket

A partir de là, vous devriez pouvoir accéder à un nouveau type de console dans Proxmox, qui devrait à la fois résoudre le problème de clavier qwerty ET le problème de presse-papier.

Cloud-config, suite

On récupère ce qu’on vient d’exporter et on ajoute notre clé comme nous le demande Rancher dans sa doc. Et avant de lancer l’install, on vérifie que notre cloud-config est valide

sudo ros config validate -i cloud-config.yml

Si la commande ne renvoie rien, c’est que c’est OK (pas super explicite mais bon why not). On passe donc à l’install :

sudo ros install -c cloud-config.yml -d /dev/sda
INFO[0000] No install type specified...defaulting to generic
Installing from rancher/os:v0.5.0
Continue [y/N]:
[...]
Continue with reboot [y/N]: y
INFO[0013] Rebooting

A partir de là, on peut (et on doit) se connecter en SSH sur la machine RancherOS (l’accès console n’est plus possible)

ssh -J proxmoxve rancher@192.168.1.10

Et si tout s’est bien passé, vous devriez pouvoir vous connecter !

Et maintenant, que vais-je fai-reuh ?

Ben déjà on peut regarder ce que RancherOS a activé comme “services” sur notre install Proxmox VE.

sudo ros service list
disabled amazon-ecs-agent
disabled container-cron
disabled open-iscsi
disabled zfs
disabled kernel-extras
disabled kernel-headers
disabled kernel-headers-system-docker
disabled open-vm-tools
disabled hyperv-vm-tools
enabled qemu-guest-agent
disabled rancher-server
disabled rancher-server-stable
disabled amazon-metadata
disabled volume-cifs
disabled volume-efs
disabled volume-nfs
disabled modem-manager
disabled waagent
disabled virtualbox-tools
disabled pingan-amc

Globalement, pas grand chose. La seule chose activée est le qemu-guest-agent, ce qui est utile puisque nous avons une effectivement une VM QEMU dans ce cas précis. Quant à vos containers Docker, vous pouvez vérifier qu’ils sont bien séparés des containers docker servant au fonctionnement de RancherOS avec les commandes suivantes :

Les containers “systèmes”

[rancher@rancher ~]$ sudo system-docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1e059e78c17e rancher/os-docker:19.03.11 "ros user-docker" 12 minutes ago Up 12 minutes docker
ba43a0648227 rancher/os-qemuguestagent:v2.8.1-2 "/usr/bin/ros entr..." 12 minutes ago Restarting (1) 34 seconds ago qemu-guest-agent
d9ad607221fa rancher/os-console:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes console
ad0197c79ff2 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes ntp
538ccf5eb624 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes network
f389c6b0b40e rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes udev
b51deb379bf2 rancher/container-crontab:v0.4.0 "container-crontab" 12 minutes ago Up 12 minutes system-cron
59441adcc016 rancher/os-syslog:v1.5.6 "/usr/bin/entrypoi..." 13 minutes ago Up 12 minutes syslog
120df7cc2492 rancher/os-acpid:v1.5.6 "/usr/bin/ros entr..." 13 minutes ago Up 12 minutes acpid

Vos containers :

[rancher@rancher ~]$ docker container ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Les containers “systèmes” sont bien distincts des containers docker “utilisateurs”. La promesse d’isolation Docker infra vs Docker appli est bien tenue.

Mon avis

A voir à l’usage, mais je ne suis pas hyper convaincu.

D’abord, en termes d’OS minimalistes, on a quand même vu mieux. Et d’ailleurs, les gens chez Rancher le savent puisqu’ils se sentent obligés de s’en justifier…

Plus grave, l’UX est quand même super bof. J’ai l’habitude d’installer des softs mais je me suis quand même pris la tête avec le cloud-config assez moyennement documenté, et en plus, à faire DANS une console (et la galère QWERTY/AZERTY associée).

“Et c’est pas fini”, comme dis la pub.

Je vous l’ai dis, mon objectif est d’avoir un cluster Kubernetes installé par RKE. Or, il n’est pas trivial d’utiliser RancherOS comme OS pour hoster un Kubernetes déployé avec RKE. Vous verrez dans la partie 2 que ça n’a pas été une partie de plaisir…

Un comble pour 2 produits de la même boite censé vous simplifier l’administration de Docker/Kube…

Et plus grave encore, c’est que j’ai du mal à voir pour qui ce genre de distribs apporte de la valeur. C’est d’ailleurs pour cette même raison pour laquelle je n’avais pas poussé l’expérimentation très loin avec CoreOS. En tant qu’admin, je suis forcément frustré par un OS où je n’ai pas/peu la main.

J’aime bien ce qu’ils font chez Rancher. Mais je ne sais pas répondre à la question Pourquoi RancherOS ? On pourrait se dire que pour une équipe de développeurs en mode startup qui doit sortir son MVP en peu de temps, ça peut être cool.

Mais même là, j’ai des doutes.

Si ces gens là veulent VRAIMENT s’abstraire d’Ops (voir mon avis sur la question dans Au secours, le métier d’Ops va disparaître !), ils partiront sur d’autres types de technos (Kubernetes managé, Serverless, No code ?).

Si vous voyez une raison que j’aurais loupé, n’hésitez pas à venir en parler en commentaire ou via les RS, car là je vois pas…

En attendant la partie sur RKE, have fun :)

Stockage distribué et répliqué avec DRBD

Mon, 11 May 2020 06:35:00 +0000

DRBD

En 2015, j’avais voulu essayer la solution de stockage distribué DRBD. Et oui, 2015. C’est mon plus vieux brouillon sur le blog que je sors enfin. Vous vous en doutez, j’ai du repasser dessus pour ne pas vous donner de versions antédiluvienne ;-)

DRBD (pour Distributed Replicated Block Device) est donc un logiciel disponible sous Linux et Windows qui permet de gérer des périphériques de stockages virtuels utilisables dans des infrastructures.

Ces périphériques ont la particularité de pouvoir être « distribués » sur plusieurs serveurs sur un réseau de façon synchrone ou asynchrone et disposant de plusieurs méthodes de resynchronisation en cas de perte de lien ou d’incohérences.

L’avantage de cette solution est qu’elle est robuste (fiabilité éprouvée) et qu’elle permet de répondre à des problématiques de haute disponibilité et de performance que n’offrent pas forcément toutes les solutions de stockage.

Si cette solution peut paraître de prime abord un peu datée à l’époque des containers et de Kubernetes, sachez que Linbit a fait un effort assez conséquent justement sur cette partie, en essayant de se positionner comme un des acteurs du stockage distribué pour les architectures containerisées et/ou “cloud native” (surtout trusté par Ceph/CephFS, voire Gluster).

Prérequis

Pour tester DRBD, vous l’aurez compris, il va nous falloir au minimum deux serveurs. Pour faire simple, je vais utiliser des machines virtuelles (mais évidemment ça fonctionnera mieux sur un serveur physique) sur lesquelles j’ai installé une image Ubuntu 18.04.

Dans mon cas, j’ai rajouté des disques virtuels de 16Go, pour simuler des disques physiques à synchroniser. De même, j’ai également rajouté des interfaces réseaux supplémentaires pour simuler un réseau dédié « stockage ».

Installation du logiciel

La société LINBIT qui distribue le logiciel DRBD propose des packages précompilés pour la plupart des distributions Linux classiques. L’ensemble des packages des différentes versions de DRBD sont disponibles sur le site de Linbit. Cependant, ces packages « officiels » précompilés nécessitent d’avoir payé le support.

Note : Si les packages officiels sont réservés aux personnes qui payent le support, les sources, elles, sont bien entendu disponibles sur le site.

Heureusement, il est possible d’utiliser tout simplement les packages précompilés de votre distribution.

A la base, quand j’avais écrit le tutoriel en 2015, j’avais des soucis de compatibilité entre la version du kernel et drbd de ma distribution CentOS (6.3 à l’époque…). Ma version, 2.6.32-279 alors que les versions 8.3 et 8.4 de DRBD nécessitent le kernel 2.6.32-431. Mais rien ne vous empêche d’installer le kernel demandé pour résoudre ce problème.

Pour ce tuto, voici les commandes que j’ai dû utiliser pour installer DRBD 9 (la dernière stable même si la 10 arrive bientôt) sur mes Ubuntu 18.04.

sudo apt update
sudo apt upgrade
sudo apt install software-properties-common
sudo add-apt-repository ppa:linbit/linbit-drbd9-stack
sudo apt-get update
sudo apt install drbd-utils python-drbdmanage drbd-dkms

Une fois que c’est installé, testez que tout fonctionne avec la commande suivante :

sudo modprobe drbd

Si tout se passe bien, elle ne devrait remonter aucune erreur. En revanche, si vous n’avez pas un kernel avec une version compatible, vous devriez avoir une erreur du type “file not found”. Dans ce cas-là, il faudra compiler DRBD à la main.

Préparation des machines

Les serveurs doivent évidemment pouvoir se joindre et se résoudre. Le mieux étant bien sûr un DNS correct, on pourra se rabattre dans le cadre d’un test sur a minima un fichier /etc/hosts contenant les informations nécessaires :

192.168.100.11 drbd1 drbd1.example.org
192.168.100.12 drbd2 drbd2.example.org

Ensuite, j’ai créé, sur chaque serveur, deux partitions de 8 Go chacun sur le disque de 16. La première sera de type Linux, la seconde sera de type LVM.

On oublie pas de créer les objets LVM pour pouvoir les utiliser plus tard.

pvcreate /dev/sdb2
vgcreate vg_drbd /dev/sdb2
lvcreate -n lv_drbd -l 2047 vg_drbd

Configuration

Le fichier de configuration global de DRBD est /etc/drbd.conf. Il définit les fichiers unitaires qui doivent être modifiés. Le fichier /etc/drbd.conf en lui-même ne doit donc pas être modifié directement ; sauf dans le cas où on souhaite changer les fichiers de configuration inclus de répertoire.

cat /etc/drbd.conf
# You can find an example in /usr/share/doc/drbd.../drbd.conf.example
include "drbd.d/global_common.conf";
include "drbd.d/*.res";

Le fichier suivant doit contenir les paramètres et les commandes qui sont globaux à toutes les ressources DRBD.

cat /etc/drbd.d/global_common.conf
# DRBD is the result of over a decade of development by LINBIT.
# In case you need professional services for DRBD or have
# feature requests visit http://www.linbit.com
global {
[...]

Template de ressource

Pour rendre la configuration lisible, on sépare les fichiers de configuration de manière à faire un fichier texte par ressource, nommé avec la convention r[nombre].res. Ici on prendra l’exemple le plus simple d’une synchronisation synchrone (protocole C, par défaut) dans un modèle actif/passif. Pour vous aider à créer vos premières ressources, DRBD met à disposition, dans /etc/drbd.d/drbdctrl.res_template un template dans lequel vous n’aurez qu’à modifier les valeurs.

resource .drbdctrl {
net {
cram-hmac-alg sha1;
shared-secret "<your-shared-secret>";
}
volume 0 {
device /dev/drbd0 minor 0;
disk /dev/mapper/<vgname>-.drbdctrl;
meta-disk internal;
}
on <node_1> {
node-id 0;
address <ipaddress>:<port>;
}
on <node_n> {
node-id <n>;
address <ipaddress>:<port>;
}
connection-mesh {
hosts <node_1> <node_2> ... <node_n>;
net {
protocol C;
}
}
}

Ressource pour un disque “simple”

Ici, c’est l’exemple le plus simple. On va indiquer que notre ressource est distribuée sur 2 serveurs sur un bête partition Linux. Les metadata, elles, sont stockées en local (ce qui n’est pas forcément le mieux, mais pour commencer ça suffira).

vi /etc/drbd.d/r0.res
resource r0 {
on drbd1 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.11:7789;
meta-disk internal;
}
on drbd2 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.12:7789;
meta-disk internal;
}
}

Note : si le protocole de synchronisation n’est pas spécifié, on est en synchronisation synchrone par défaut.

Attention : chaque ressource déclarée réserve le port TCP pour la communication de la ressource. Il faut donc incrémenter le numéro du device drbd ET incrémenter le numéro de port à chaque nouvelle ressource (et aussi s’assurer que le port est libre…).

Pour mes tests, j’ai également utilisé la possibilité offerte par DRBD d’utiliser des volumes LVM plutôt que des partitions brutes. La configuration est la même à ceci près qu’on pointe sur le LV plutôt que sur une partition.

vi /etc/drbd.d/r1.res
resource r1 {
on drbd1 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.11:7790;
meta-disk internal;
}
on drbd2 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.12:7790;
meta-disk internal;
}
}

Initialisation

Maintenant que tout est configuré, on va pouvoir déclencher l’étape d’initialisation des metadata et des ressources nouvellement créées. Lancez les commandes suivantes sur les deux nœuds :

drbdadm create-md r0
drbdadm create-md r1
drbdadm up r0
drbdadm up r1

Une fois que les commandes sont lancées, on peut afficher les informations sur l’initialisation des disques (état normal) avec drbdmon.

Actuellement, les nœuds sont Inconsistants et en Secondaire/Secondaire, car nous n’avons pas encore désigné le nœud principal. Nous allons “forcer” le sens dans lequel le disque doit être synchronisé.

Sélectionner un des nœuds, qu’on va désigner comme “serveur primaire” et exécuter les commandes suivantes (uniquement sur lui) :

root@drbd1:~# drbdadm primary --force r0
root@drbd2:~# drbdadm primary --force r1

ATTENTION : dans le cas d’un disque déjà créé, il faut bien ne pas se tromper de sens, au risque d’écraser le disque qui contiendrait les données.

Une fois la synchronisation terminée, on peut utiliser le disque /dev/drbdX.

C’est fini ?

En fait, pas tout à fait. On ne va pas pouvoir utiliser nos disques exactement comme des disques classiques. Si vous formattez ce disque en ext4/xfs/whatever et que vous essayez de le monter sur vos deux serveurs drbd1 et drbd2, vous allez avoir une drôle de surprise.

En effet, ces filesystems ne savent pas gérer les accès concurrents provenant de deux machines simultanées. On va donc devoir :

soit utiliser un filesystem capable de gérer les accès concurrents (page Wikipedia listant quelques clustered filesystems) comme OCFS2 ou GFS2. Si vous publiez les disques DRBD en iSCSI pour votre cluster VMware, vous n’aurez pas de problème non plus car le VMFS le gère très bien aussi.
soit s’assurer à tout moment que le disque n’est monté que sur un seul serveur à la fois.

Évidemment la 2ème option est à proscrire si vous êtes dans un contexte de production. Cependant, cela reste possible si vous montez un cluster Pacemaker ou RHCS par exemple, qui va s’assurer que les bascules de stockage se font de manière propre.

Enjoy !

Bonus : quelques commandes utiles

Pour une ressource donnée, afficher le rôle du serveur local

root@drbd1:~# drbdadm role r0
Primary
root@drbd1:~# drbdadm role r1
Secondary

Afficher de manière concise l’état d’une ressource sur les nœuds

root@drbd1:~# drbdadm dstate r0
UpToDate/UpToDate
root@drbd1:~# drbdadm dstate r1
Inconsistent/UpToDate

Afficher plus de détails sur une ressource avec drbdadmin pour un résultat simple ou drbdsetup pour avoir plus de détails :

drbdsetup status r1 --verbose --statistics
r1 node-id:1 role:Secondary suspended:no
write-ordering:flush
volume:0 minor:2 disk:Inconsistent quorum:yes
size:8384220 read:0 written:1972628 al-writes:0 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no blocked:no
drbd2 node-id:0 connection:Connected role:Primary congested:no ap-in-flight:0 rs-in-flight:0
volume:0 replication:SyncTarget peer-disk:UpToDate done:23.53 resync-suspended:no
received:1972628 sent:0 out-of-sync:6411740 pending:3 unacked:12 dbdt1:92.39 eta:68

En temps normal, toutes les ressources sont actives par défaut. Cependant, on peut les activer ou les désactiver à la main :

drbdadm up r0
drbdadm down r1
# utiliser le mot clé « all » pour désigner toutes les ressources

Si on modifie les fichiers de configuration global ou un fichier de ressource, il est nécessaire de mettre à jour la configuration sur les deux nœuds. Il est possible de reconfigurer les ressources même si elles sont opérationnelles grâce à la méthode suivante :

drdbadm adjust r0

Changer le statut du nœud courant (pour le passer en primary s’il est secondary par exemple)

drbdadm primary r1
drbdadm secondary r0

Sources

User Guide DRBD 9.0 (Anglais)

Exposer des applications containerisées Kubernetes (nginx Ingress Controller)

Tue, 06 Mar 2018 12:45:47 +0000

Ingress et Ingress Controller versus Baremetal

Autant le dire tout de suite, cet article s’adresse surtout aux admins qui font du Kubernetes (K8s pour les intimes) et en plus qui font tout eux même. Mais comme je suis sympa j’explique tout et j’ai mis des schémas si vous êtes curieux ;-).

Je vous plante le décors : vous avez suivi un de mes tutos sur Kubernetes et vous avez maintenant un cluster opérationnel en dehors des gros cloud providers (Amazon, Google, …) et de leurs solutions clés en main (sur vos propres VMs et/ou serveurs physiques). Vous êtes super contents et il y a de quoi.

Seulement voilà, maintenant que vous pouvez spawner des containers à tire larigot, vous voulez pouvoir y accéder depuis l’Internet.

Mais là, comment faire ?

Le premier problème que vous risquez d’avoir est que les applications que vous déployez dans Kubernetes ne sont de base accessibles que DANS Kubernetes.

On va être très très vite limité, niveau usecases.

Pour accéder à un container (ou faire discuter 2 containers comme un serveur web et une base de données), on passe par l’intermédiaire d’un objet appelé Service. C’est cet objet qui permet le service discovery, le scaling aisé de nos applications et la résolution de nom au sein du cluster.

Cependant, hors du cluster, pas de résolution de nom et/ou d’accès aux ressources par ce biais. Vous allez donc devoir passer par un DNS externe pour spécifier aux clients où sont vos applications et trouver un moyen de différencier quelle requête externe doit aboutir dans quelle container.

Accéder aux ressources

Le premier problème est donc de réussir à accéder à notre service. S’il est possible de créer des Services (les points d’entrées de nos containers) de type LoadBalancer sur AWS, Azure et GCP, qui ont l’avantage de permettre un accès direct au service depuis Internet (magie !), le mieux que l’on puisse faire par défaut sur un cluster Baremetal, c’est un Service de type NodePort.

Si vous n’êtes pas chez un cloud provider comme nous l’avons dit au départ, vous allez vite vous rendre compte qu’il n’est pas trivial de présenter un container sur HTTP:80 ou HTTPS:443. Car par défaut, les Services NodePort exposent nos container sur un port aléatoire compris entre 30000 et 3X000-je-sais-pas-combien (mate la précision) sur tous les nœuds du clusters.

Il y a deux choses importantes dans cette dernière phrase :

D’abord, on va se retrouver avec des URLs du type : http://@IP_node:32251 pour accéder à un serveur web depuis l’extérieur. Pas glop.
Ensuite, pour un Service de type NodePort donné, le port alloué l’est sur TOUS les membres du cluster, que le container tourne dessus ou pas. Ça veut dire que peu importe quel nœud Kubernetes on interroge, le 32251 répondra TOUJOURS sur le même container (les requêtes sont forwardé au bon nœud de manière transparente). Ça veut aussi dire qu’il n’y aura qu’un seul service qui aura le privilège d’utiliser le 32251 et aucun autre Service ne pourra le réserver.

Clairement, c’est tout sauf idéal. On se retrouve donc à différencier les applications simplement avec les numéros des ports qu’on accède.

Le DNS

Et c’est pas fini…

Si on prend un cas simple : un site web à exposer sur Internet, on va souvent vouloir relier une URL humainement compréhensible au container qui gère ce site. Cependant cette notion n’a pas vraiment de sens avec Kubernetes.

Vous ne savez pas a priori où va être instancié votre container dans le cluster (i.e. sur quelle machine et donc sur quelle IP). Ça sera un des nœuds du cluster, mais lequel ? D’autant que le Pod bouge d’un nœud à l’autre au gré de la vie de l’application (drain du node pour maintenance ou incident). Difficile donc de donner avec certitude un enregistrement DNS fiable dans le temps.

Alors bien sûr, vous pouvez toujours fixer en dur l’adresse IP d’un des nœuds Kubernetes dans un enregistrement DNS mais cette méthode trouve très vite sa limite : le moindre arrêt du serveur cause la perte de l’accès à l’application, qui pourtant a probablement été redémarrée sur un nœud du cluster.

Vous me pardonnerez ce « comic » en mode Draw.io. On s’amuse comme on peut ;-)

A quoi ça sert d’avoir un cluster dans ce cas là ?

Vous aurez peut être alors l’idée d’utiliser un moyen automatique (genre ce script qui utilise Dynhost, au hasard) pour mettre à jour le DNS dès que l’application change de nœud. Mais c’est clairement de la bidouille et on se retrouvera avec pleins d’utilisateurs dont les caches DNS ne sont pas à jour.

La méthode simple

On peut quand même bosser avec ce qu’on a et présenter à nos gentils utilisateurs des URLs user-friendly sans trop de difficultés, dans la majorité des cas.

La première chose qu’on peut faire c’est simplement mettre en face de notre cluster Kubernetes un bête reverse proxy et/ou répartiteur de charge. Après tout, c’est ni plus ni moins ce que font AWS et autre avec leur implémentation du Service de type Loadbalancer.

L’ensemble des requêtes HTTP(S) sont donc dirigées vers le reverse proxy, qui se charge de masquer la complexité de l’URL (l’aiguillage via des ports chelous et le maintiens à jour de l’ensemble des nœud du cluster qu’on arrive à contacter) à l’utilisateur final.

Personnellement, pour mes projets perso, ça m’ennuie d’avoir un composant externe au cluster K8s pour faire ça. J’ai déjà investi dans un cluster pour rendre mes applications hautement disponibles (ce qui est déjà overkill), je ne vais pas en plus :

soit ajouter un SPOF en ajoutant une seule machine pour faire mon reverse proxy
soit ajouter un cluster de machines rien que pour le reverse proxy

Et les Ingress dans tout ça ?

Donc on l’a vu, tout ça c’est pas super propre et on ajoute potentiellement un SPOF, mais ça « marche ». Mais on peut faire mieux :)

Si vous manipulez un peu Kubernetes, vous avez donc peut être vu qu’il existe un autre type d’objet qui s’appelle les Ingress et les Ingress Controllers.

Pour ceux qui n’ont pas eu le temps de potasser, un Ingress est une règle qui permet de relier une URL à un Service et un Ingress Controller est un composant qui permet de piloter un reverse-proxy pour implémenter cette règle. C’est LA méthode propre pour traduire une URL provenant d’un client en requête interne dans le cluster K8s pour atteindre le bon service.

L’Ingress Controller le plus utilisé est probablement celui pour nginx, mais il existe des Ingress Controllers pour traefik ou ha-proxy (ou autre) qui ont été développés et qui sont plus ou moins aboutis.

Helm

Helm c’est super. J’en ai parlé dans un autre article il n’y a pas longtemps, c’est un genre de gestionnaire d’application pour Kubernetes et ça simplifie grandement son utilisation. Mais il faut être honnête, ce n’est pas toujours une super idée…

Déjà, la documentation sur la page d’accueil du Chart est super light. Si vous ne trouvez pas d’infos sur comment le déployer, c’est normal, c’est parce qu’il faut aller dans le dossier « deploy » du dépôt pour trouver la doc d’installation.

Du coup, confiant, j’y suis allé avant d’avoir trouvé cette page, et je me suis pris ma première claque ;-)

helm install stable/nginx-ingress --name nginx-ingress
NAME: nginx-ingress
LAST DEPLOYED: Sun Feb 25 16:24:11 2018
NAMESPACE: default
STATUS: DEPLOYED
[...]
NOTES:
The nginx-ingress controller has been installed.

Oh cool, ça marché déjà ?

kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-7c6f79d45c-jwqkp 0/1 CrashLoopBackOff 14 47m
nginx-ingress-default-backend-6664bc64c9-2zpg4 1/1 Running 0 47m

Ah ben non en fait parce que je suis en RBAC (K8s > 1.7.0) ! Il faut créer des autorisations et un compte de service pour l’Ingress Controller.

kubectl logs nginx-ingress-controller-7c6f79d45c-jwqkp
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: 0.10.2
Build: git-fd7253a
Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
I0225 16:11:13.374547 7 flags.go:159] Watching for ingress class: nginx
I0225 16:11:13.376659 7 main.go:181] Creating API client for https://10.233.0.1:443
I0225 16:11:13.438774 7 main.go:193] Running in Kubernetes Cluster version v. (v1.9.0+coreos.0) - git (clean) commit 1b69a2a6c01194421b0aa17747a8c1a81738a8dd - platform linux/amd64
F0225 16:11:13.442654 7 main.go:80] &#x2716; It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller. Please check the configuration

Ok, pas grave… On supprime et on recommence !

helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
nginx-ingress 1 Sun Feb 25 16:24:11 2018 DEPLOYED nginx-ingress-0.9.1 default
helm delete nginx-ingress
release "nginx-ingress" deleted
helm install stable/nginx-ingress --name nginx-ingress --set rbac.create=true
[...]

Bon, ne vous fatiguez pas. Ça aura l’air de marcher mais en fait, le nginx-ingress-controller se base sur un Service de type… Loadbalancer ! Si vous n’êtes pas sur AWS, GCE ou Azure, votre Service restera indéfiniment à l’état Pending en attente d’une IP publique ;-)

kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-controller LoadBalancer 10.233.52.122 80:30215/TCP,443:31438/TCP 41m
nginx-ingress-default-backend ClusterIP 10.233.29.8 80/TCP 41m

Donc on laisse tomber Helm pour cette fois

En réalité, le mieux c’est de repartir sur le projet nginx Ingress Controller, qui donne (pour qui trouve la documentation) la bonne marche à suivre pour instancier rapidement son Ingress Controller.

github.com/kubernetes/ingress-nginx
github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md#bare-metal (lien mis à jour le 08/10/2018)

Partie à exécuter dans tous les cas

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/namespace.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/default-backend.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/tcp-services-configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/udp-services-configmap.yaml \
| kubectl apply -f -

Partie spécifique à ajouter pour déployer l’Ingress Controller dans un environnement de type RBAC (K8s >= 1.7)

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/rbac.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/with-rbac.yaml \
| kubectl apply -f -

Partie spécifique à ajouter en dernier, dans le cas où on est sur un cluster baremetal (i.e. en dehors des cloud providers).

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml \
| kubectl apply -f -

OK, on a quoi maintenant ?

Et bien, c’est pas encore fini malheureusement… En fait, tel quel, le dernier fichier YAML qu’on a créé nous créé un service de type NodePort…

Oui vous l’avez compris : retour à la case départ ! Nous avons un composant reverse proxy intégré à K8s, mais qui est en écoute sur un port 3XXXX au lieu du 80, et 3YYYY au lieu du 443. Là encore, on aurait pas du tout ce problème si on était chez AWS, car un service de type Loadbalancer (avec une IP publique) aurait été créé pour nous.

Rassurez vous, il y a des solutions, moyennant un peu de bidouille. J’en ai trouvé 2 dans notre cas.

Pour faire simple, la première nécessite juste de modifier unfichier de configuration de Kubernetes pour autoriser le composant NodePort à utiliser des ports en dessous de la limite arbitraire des 30000. Je ne suis pas fan du tout de cette solution mais elle « fonctionne » donc je vous laisse juger.

En revanche, je trouve la seconde bien plus élégante quoique peut être un peu moins flexible. On peut modifier le Service de l’Ingress Controller en y listant toutes les adresses IPs de tous vos serveurs K8s. Ce n’est pas super confortable dans le cas où ils changent souvent, mais ça à l’effet qu’on recherche, à savoir ouvrir les ports 80 et 443 et rediriger l’ensemble des requêtes HTTP vers les Ingress.

La modification à réaliser se situe au niveau du champ externalIPs :

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml -o ingress-nginx-service-nodeport.yaml
vi ingress-nginx-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx
namespace: ingress-nginx
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
- name: https
port: 443
targetPort: 443
protocol: TCP
externalIPs:
- 10.0.0.1
- 10.0.0.2
- 10.0.0.3
selector:
app: ingress-nginx
kubectl apply -f ingress-nginx-service-nodeport.yaml

Normalement après application de la modification vous devriez avoir la joie (oui oui, carrément) de voir apparaitre sur tous les serveurs (que vous aurez listés) les ports 80 et 443 en écoute !!

ss -lnt
LISTEN 0 128 8.8.8.8:80 *:*
LISTEN 0 128 8.8.8.8:443 *:*

Super, et maintenant c’est bon, mon container nginx est accessible ?

Ah ben non, toujours pas. On a configuré l’Ingress Controller, mais ça fait un moment qu’on parle plus des Ingress…

Comme je l’ai dis plus haut, les Ingress sont donc les règles de notre reverse proxy, permettant de mapper les URLs entrant dans le cluster sur les ports 80 et 443 (ou autre si on en définit d’autres) vers les Services définis dans le K8s.

Heureusement c’est partie est assez simple à configurer. Voici l’exemple minimaliste d’une application dont le Service toto-app-svc écoute sur le port 8080 à l’intérieur du cluster Kubernetes. Ce service est maintenant accessible pour toute requête HTTP aboutissant sur un des noeuds du cluster et accédé avec l’URL toto.zwindler.fr.

cat nginx-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: nginx-ingress
spec:
rules:
- host: toto.zwindler.fr
http:
paths:
- path: /
backend:
serviceName: toto-app-svc
servicePort: 8080

Point intéressant à noter, il n’est plus nécessaire de faire du NodePort maintenant, on peut se contenter des ClusterIP par défaut. En effet, l’Ingress Controller étant interne au cluster K8s, il sait résoudre les Services sans passer par un port crado en 30000. Autant ne plus les exposer donc et bannir les NodePorts à présent !

Bon vous avez vu ? Cette dernière étape n’est pas la plus dure qu’on ait fait !

Et maintenant, à vos Ingress !

[Tutoriel] XWiki, ma premier appli Statefull sur Kubernetes

Tue, 24 Oct 2017 11:30:52 +0000

Pourquoi déployer XWiki sur Kubernetes ?

Vous le savez surement maintenant vu le nombre d’article que j’ai écrit sur le sujet, j’aime bien XWiki. C’est un super projet mené par des gens passionnés, réactifs et surtout, c’est cet outil qui a permis à mon entreprise d’adopter ENFIN le wiki comme outil de documentation, que ce soit pour documenter les procédures, mais aussi documenter entièrement les concepts de l’outil que nous développons.

D’un outil quasi-confidentiel utilisés par quelques admins peu motivés (sous Mediawiki), nous sommes donc progressivement passés à un outil utilisé par toutes les équipes, du dev. au support en passant par les ergo. et les CPs, utilisés par plusieurs entités internes et même accepté comme document contractuel par nos prestataires. J’ai d’ailleurs documenté la migration sur cet article.

Mais j’aime aussi XWiki car c’est selon moi l’exemple parfait d’une appli 2 ou 3 tiers relativement simple pour explorer l’écosystème Docker (construction des images, les problématiques réseau et stockage, …). Je joue régulièrement avec ma propre image sur le Dockerhub pour explorer un peu plus cet écosystème riche (c’est rien de le dire).

Quelle meilleure application donc pour réellement tester mon tout nouveau cluster Kubernetes (je ne compte pas nginx ou helloworld) ?

Kubernetes ?

Pour ceux qui ont besoin d’un rappel sur Kubernetes ou des premiers concepts et/ou comment l’installer, je vous invite à lire/relire mon article précédent sur le sujet.

A noter également (j’ai pas mal communiqué là-dessus sur les réseaux sociaux), la Linux Foundation, qui gère également la Cloud Native Computing Foundation (et qui elle-même gère Kubernetes), a mis à disposition gratuitement un cour en ligne de type MOOC sur edX. Vous pouvez même vous « certifier » à la fin si vous réussissez le QCM, moyennant 100$.

A l’issue de ces lectures, vous devriez donc avoir :

la connaissance des différents concepts de Kubernetes
un cluster Kubernetes opérationnel (une ou plusieurs machines, ou simplement un minikube en local)

Ce sont les prérequis pour la suite de cet article, même si je vais essayer de détailler tout ce qui va suivre.

Plan de bataille

Je ne vais pas vous le cacher, si on veut tout faire soit même, ce n’est pas « trivial ». Mais en décomposant toutes les étapes, vous allez voir que c’est logique.

Pour faire tourner mon image Docker zwindler/xwiki-tomcat8, j’ai besoin, sur mon cluster Kubernetes, des choses suivantes :

un Deployment qui exécute la partie PostgreSQL. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne souhaite avoir qu’un seul Pod avec l’image postgresql officielle
- Un Service de type ClusterIP pour lui permettre de communiquer avec le XWiki mais pas avec le monde extérieur
- Un PersistantVolumeClaim et son PersistentVolume associé pour stocker les données de la base
- Des Secrets pour permet de configurer les mots de passes de postgres et de l’utilisateur XWiki
un Deployment qui exécute la partie XWiki. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne fait tourner qu’un seul Pod avec l’image zwindler/xwiki-tomcat8, car on n’utilise qu’un tomcat à la fois pour exécuter XWiki
- Un Service de type NodePort (ou mieux si vous avez des LoadBalancers ou des Ingress à dispo.) qui permettra d’exposer le port interne au cluster Kubernetes vers le monde extérieur
- Un PersistantVolumeClaim avec le PersistentVolume pour stocker les pièces jointes car mon image Docker utilise l’option filesystem_store pour éviter de surcharger la base pour les PJ
- et aussi le Secret défini précédemment pour accéder à la BDD.

OK.

Voir ça posé dans une liste comme ça, ça peut faire peur.

Alors vous allez me dire : « c’est plus facile de lancer ton DockerCompose » (car j’ai montré qu’avec DockerCompose on peut démarrer une instance XWiki en 2 ou 3 lignes de commandes). Mais au final, tout ce que j’ai écris ici peut être concaténé dans un seul et même fichier YAML et le résultat est aussi simple dans l’absolu.

Créer les Secrets

Clairement, c’est un des gros points forts par rapport à la solution plus simple avec juste Docker / DockerCompose : la gestion des Secrets (et des configurations, dans une moindre mesure).

Ici, plutôt que d’avoir un mot de passe en clair dans mon fichier compose, le mot de passe est renseigné à part, soit via un fichier, soit via l’API. Et ces mots de passes ne pourront plus être consultés via la CLI, mais pourront être utilisés.

Pour créer un secret dans Kubernetes en CLI, il existe plusieurs méthodes. Soit on utilise la CLI directement depuis le prompt ou depuis un fichier plat (qui va se charger d’encoder le secret en base64 et de générer le YAML pour nous), soit on décide de créer le YAML nous-même. Je vous met les deux méthodes :

echo -n "xwikidb" > ./POSTGRES_USER.txt
echo -n "xwikipwd" > ./POSTGRES_PASSWORD.txt
kubectl create secret generic postgresql-xwiki-user-password --from-file=POSTGRES_USER.txt --from-file=POSTGRES_PASSWORD.txt
secret "postgresql-xwiki-user-password" created
#ou
cat > postgresql_xwiki_user_password.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: postgresql-xwiki-user-password
type: Opaque
data:
username: $(cat POSTGRES_USER.txt| base64 -w 0)
password: $(cat POSTGRES_PASSWORD.txt| base64 -w 0)
EOF

Au final, pour un déploiement unitaire pour vous même, ça ne change pas grand-chose bien sûr. Vous avez renseigné en clair le mot de passe (ou en base64 mais c’est pareil) à un moment donné.

Cependant, dans le cadre d’un gros projet avec des développeurs qui poussent du code régulièrement d’un côté et des admins qui gèrent de l’autre les utilisateurs et les mots de passes, on peut permettre aux développeurs consommer les mots de passe sans jamais avoir à les connaitre (et laisser trainer sur Gitlab, ou pire, Github !).

kubectl describe secret postgresql-xwiki-user-password
Name: postgresql-xwiki-user-password
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 8 bytes
username: 7 bytes

Créer les Persistent Volumes

Dans mon infrastructure, j’ai déjà un cluster GlusterFS. GlusterFS étant un SDS, il est particulièrement indiqué comme stockage persistant dans le cadre d’un cluster Kubernetes (comme Ceph, Cinder, S3 ou autre). Ces types de méthodes de stockage peuvent facilement se piloter par API et sont hautement disponibles.

Création de l’endpoint GlusterFS

cat > gluster-endpoints.yaml <<EOF
apiVersion: v1
kind: Endpoints
metadata:
name: gluster-cluster
subsets:
- addresses:
- ip: 10.0.0.1
ports:
- port: 1
protocol: TCP
- addresses:
- ip: 10.0.0.2
ports:
- port: 1
protocol: TCP
EOF
kubectl apply -f gluster-endpoints.yaml
endpoints "gluster-cluster" created
kubectl get endpoints gluster-cluster
NAME ENDPOINTS AGE
gluster-cluster 10.0.0.1:1,10.0.0.2:1 39s
cat > gluster-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: gluster-cluster
spec:
ports:
- port: 1
EOF
kubectl apply -f gluster-service.yaml
service "gluster-cluster" created
kubectl get service gluster-cluster
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 1m

La partie GlusterFS a été configurée côté Kubernetes. On peut maintenant s’atteler à la création des PV et PVC associés. D’abord la base de données :

cat > gluster-pv-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-pg
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-pg-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-pg.yaml
persistentvolume "gluster-pv-xwiki-pg" created
cat > gluster-pvc-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-pg
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-pg.yaml
persistentvolumeclaim "gluster-pvc-xwiki-pg" created

Et maintenant l’application XWiki

cat > gluster-pv-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-app
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-app-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-app.yaml
persistentvolume "gluster-pv-xwiki-app" created
cat > gluster-pvc-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-app
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-app.yaml
persistentvolumeclaim "gluster-pvc-xwiki-app" created

Dans le cadre d’un test, vous pouvez vous contenter de faire simplement appel à un partage NFS ou même à du stockage local (si vous n’avez qu’un worker) mais sachez que vous n’aurez pas le même niveau de résilience ni les même facilités d’administration.

Si vous voulez un exemple de PersistentVolume utilisant NFS, je vous conseille cet article qui traite d’un sujet peu plus complexe mais qui donne les étapes de base pour mettre en place le PV et PVC : Créer un cluster PostgreSQL avec un seul et même Deployment en utilisant les StatefulSets.

Créer le Deployment postgreSQL

Voilà, on a tous les prérequis ! Il ne reste plus qu’à créer dans un premier temps notre base de données, puis notre XWiki. Comme indiqué au début, le Deployment contiendra tous les éléments qu’on a créé plus tôt, dont les Secrets et le Persistent Volume. Il manquera aussi un Service, que nous verrons plus tard.

cat > xwiki-pg.yaml << EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-pg
labels:
app: xwiki-pg
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-pg
application: xwiki
template:
metadata:
labels:
app: xwiki-pg
application: xwiki
name: xwiki-pg
spec:
containers:
- image: postgres:9.6
name: xwiki-pg
env:
- name: POSTGRES_DB
value: xwiki
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 5432
name: xwiki-pg
volumeMounts:
- name: xwiki-pg-storage
mountPath: /var/lib/postgresql/data/pgdata
volumes:
- name: xwiki-pg-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-pg
EOF
kubectl create -f xwiki-pg.yaml

Normalement, un Pod devrait se créer et monter le disque Gluster, puis s’initialiser avec les variables d’environnement qu’on lui a donné.

A partir de là, on ne peut cependant pas accéder à la base de données car on a pas encore créé le Service associé au Deployment. Par défaut, on ne donne pas de type, c’est donc un ClusterIP. Pour « savoir » vers quoi le Service doit rediriger, on a ajouté un Selector, qui pointe sur le tag « app » avec la valeur « xwiki-pg » définie plus haut.

cat > xwiki-pg-svc.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: xwiki-pg-svc
labels:
app: xwiki-pg
spec:
ports:
- port: 5432
protocol: TCP
selector:
app: xwiki-pg
EOF
kubectl create -f xwiki-pg-svc.yaml
service "xwiki-pg-svc" created

Créer le Deployment XWiki

Youhou ! Plus qu’un ! Ici pas de grosses différences, le principe est le même. On doit créer un Deployment puis un Service.

cat xwiki-tomcat.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-app
labels:
app: xwiki-app
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-app
application: xwiki
template:
metadata:
labels:
app: xwiki-app
application: xwiki
name: xwiki-app
spec:
containers:
- image: zwindler/xwiki-tomcat8
name: xwiki-app
env:
- name: POSTGRES_INSTANCE
value: xwiki-pg
- name: POSTGRES_DB
value: xwiki
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 8080
name: tomcat-port
volumeMounts:
- name: xwiki-app-storage
mountPath: /usr/local/tomcat/work/xwiki
volumes:
- name: xwiki-app-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-app
kubectl apply -f xwiki-tomcat.yaml
deployment "xwiki-app" created
cat xwiki-tomcat-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: xwiki-app-svc
labels:
apps: xwiki-app
spec:
type: NodePort
ports:
- port: 8080
targetPort: tomcat-port
protocol: TCP
selector:
app: xwiki-app
kubectl apply -f xwiki-tomcat-svc.yaml
service "xwiki-app-svc" created

Est-ce que ça marche ?

kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 4h
kubernetes 10.96.0.1 <none> 443/TCP 10d
xwiki-app-svc 10.103.218.140 <nodes> 8080:31484/TCP 4m
xwiki-pg-svc 10.108.219.88 <none> 5432/TCP 16m

Tout d’un coup

Chose promise chose due ! Je vous ai dit en début d’article que vous pouviez tout déployer en quelques lignes de commandes. Dans l’absolu, vous pourriez tout déployer via un seul fichier. Je préfère découpler la partie stockage (qui va dépendre du stockage que vous allez utiliser) et la partie secret du reste pour les raisons que j’ai énoncé plus haut. Voilà ce que ça donne :

On récupère les sources sur github

git clone https://github.com/zwindler/docker-xwiki

A adapter en fonction de votre contexte, à minima les adresses IP si vous avez du gluster, et carrément à réécrire si vous utilisez autre chose (NFS ou CEPH par exemple) :

kubectl apply -f docker-xwiki/kubernetes/gluster-endpoints-service.yaml
endpoints "gluster-cluster" created
service "gluster-cluster" created

On injecte ensuite les secrets. A vous de les changer comme on a vu plus haut.

kubectl apply -f docker-xwiki/kubernetes/postgresql_xwiki_user_password.yaml
secret "postgresql-xwiki-user-password" created

Et on fini par… tout le reste ! Là normalement il n’y a rien à changer à part éventuellement des ports, les seules « variables » dans ce déploiement étant le stockage et les mots de passes (qu’on vient de gérer).

kubectl apply -f docker-xwiki/kubernetes/xwiki-tomcat-pg-allinone.yaml
persistentvolume "gluster-pv-xwiki-pg" created
persistentvolume "gluster-pv-xwiki-app" created
deployment "xwiki-pg" created
persistentvolumeclaim "gluster-pvc-xwiki-pg" created
service "xwiki-pg-svc" created
deployment "xwiki-app" created
persistentvolumeclaim "gluster-pvc-xwiki-app" created
service "xwiki-app-svc" created

Le mot de la fin

Voilà, avec ce tutoriel vous avez maintenant une vue détaillée, étape par étape, de ce qu’il faut mettre en place pour gérer « proprement » le déploiement d’une application java + postgreSQL via Kubernetes.

Clairement, c’est bien plus complexe qu’un simple Docker compose comme j’ai pu le présenté dans l’article sur ce sujet. Pour autant, il faut comparer ce qui est comparable, les deux installations n’ont rien à voir !

D’un côté, vous avez une application déployée sur un nœud docker simple (éventuellement avec Swarm maintenant que les deux sont compatibles).

De l’autre, vous avez une application qui est déployée sur un cluster de machines :

Si l’une tombe en panne, la haute disponibilité est gérée : pas seulement sur le runtime, mais aussi sur le stockage !
Vous pouvez segmenter votre cluster en namespaces, et donner des droits à certains namespace à certains utilisateurs avec un gestion fine des autorisations (RBAC)
Vous disposez d’un dashboard et d’une API pour automatiser tous les déploiements (via Jenkins par exemple). Si vous voulez faire une mise à jour ou besoin de modifier un paramètre, c’est une simple commande ou un fichier de conf à appliquer à nouveau.
Vous avez la possibilité de faire du scaling up/down, voire de l’autoscaling.
…

La liste est longue ! En bref, vous passez d’une bidouille à la production.

Sources additionnelles

docs.openshift.org/latest/install_config/storage_examples/gluster_example.html (lien mort, pas dispo sur Internet Archive)
coderjourney.com/using-kubernetes-persistent-volumes/
www.xenonstack.com/blog/how-to-deploy-postgresql-on-kubernetes

Comment j’ai enfin trouvé une excuse pour installer Docker à la maison (Cozy Cloud)

Sat, 19 Sep 2015 10:30:30 +0000

Docker c’est « hype »

Ok, j’ai probablement 2 ans de retard sur le fait que Docker soit « hype » dans la communauté IT.

Les conteneurs sont donc à la mode.

Surtout chez ceux qui oublient que les conteneurs, c’est une techno archi-ancienne, remise au gout du jour avec « le cloud computing » (lui même un concept remis au gout du jour : comme tout ce qui est hype ;-)).

Mais ce n’est pas parce que c’est « à la mode » que je vais décider de ne pas tester. Car après tout, Docker a quand même de gros point forts.

Il me fallait juste que je me trouve une excuse et me convaincre d’allouer du temps pour tester Docker. Et je l’ai trouvée : Cozy Cloud (voir mon article précédent).

La simplicité

Enfonçons des portes ouvertes. La grande force des outils comme Docker aujourd’hui, c’est la simplicité de mise en place et d’utilisation. Sincèrement je ne m’attendais pas à ce que ce soit simple à ce point là.

Je suis parti de la machine que j’avais déjà utilisée pour installer ma première instance de Cozy Cloud, donc un Debian 8 from scratch ou quasiment.

La première chose à faire pour l’installer sur Debian 8 est d’activer dans les dépôts le « backports ». A priori Docker n’a pas été accepté dans Debian 8 pour des raisons de sécurités non résolues au moment de la sortie ? Vous aurez plus de détails dans la documentation officielle pour Debian : Docker Debian

sudo vi /etc/apt/sources.list #ajouter la ligne pour activer les backports
deb http://http.debian.net/debian jessie-backports main
sudo apt-get update
sudo apt-get install docker.io

Et c’est tout. Pas de configuration post installation : ça fonctionne. Si.

Pour s’en convaincre, on peut télécharger le conteneur hello-world, qui vous imprimera à l’écran un petit message de diagnostic et quelques pistes pour aller plus loin.

sudo docker run --rm hello-world

Application à Cozy

Cool, Docker fonctionne. Mais appliquons le maintenant à un cas d’usage utile.

Cozy, c’est aussi cool que Docker. Aux détails près que :

Une instance Cozy est mono utilisateur, impossible de l’utiliser pour une même famille par exemple.
Tout ce qui est stocké (notamment les fichiers et les photos) est stocké dans Cozy… impossible pour l’instant de pointer sur un espace partagé (type NFS/SMB) de votre NAS par exemple.

Les deux problèmes ont été remontés plusieurs fois et on peut régler le premier avec Docker ; voir ici (lien mort, j’utilise Internet Archive).

En regardant la documentation d’installation de Cozy Cloud via Docker, on se rend compte de la puissance de Docker en terme de simplification. Déployer Cozy Cloud, ce n’est guère plus compliqué qu’une ligne de commande.

sudo docker pull cozy/full

Voilà comment s’économiser les quelques lignes de l’installation classique, déjà relativement simple, pour installer une instance cozy dans un conteneur Docker. Reste à jouer un peu avec les arguments pour que nos instances écoutent sur des ports différents (voir la documentation officielle)

Mais ça ne résout pas encore totalement le problème du déploiement simplifié lorsqu’on a plusieurs utilisateurs pour une même machine.

C’est pourquoi un développeur de Cozy a mis en ligne un script qui automatise le déploiement multiple d’instances Cozy sur un même serveur Docker :

forum.cozy.io/t/cozy-deploy-a-tool-to-deploy-and-manage-multiple-cozy-instances/516 (lien mort, j’utilise Internet Archive)

Pour vous éviter une lecture de tout le post, le script en question est disponible sur Github à cette adresse.

Installation du script

wget -qO- https://raw.github.com/cozy-labs/cozy-deploy/master/install.sh | sudo bash #Installation

Si comme moi vous obtenez l’erreur suivant, c’est qu’il vous manque le package lsb-core. Installez le et relancez le script.

No LSB modules are available.
sudo apt-get install lsb-core
wget -qO- https://raw.github.com/cozy-labs/cozy-deploy/master/install.sh | sudo bash

Déploiement des instances et administration

cozy-deploy deploy cozy1.example.org #déploiement d'un premier conteneur
cozy-deploy deploy cozy2.example.org #et de deux !
cozy-deploy list #affichage de tous les conteneurs déployés
DOMAIN RUNNING PORT
cozy2.example.org true 49003
cozy1.example.org true 49002
cozy-deploy status
cozy2.example.org
postfix: up
couch: up
controller: up
data-system: up
home: up
proxy: up
index: up
cozy1.example.org
postfix: up
couch: up
controller: up
data-system: up
home: up
proxy: up
index: up

Vous disposez d’instances distinctes en écoute sur des ports distincts mais accessibles via leur nom complet à l’aide de nginx (qui sert ici uniquement de proxy pour rediriger les requêtes vers le bon port et donc le bon conteneur).

Le tout sans effort : Problem solved.

Il ne reste plus que cette histoire de stockage partagé (encore un petit effort, Cozy!).