Registry on Zwindler's Reflection

Harbor : la registry Docker open source de VMware – part 2

Tue, 26 Jun 2018 11:45:04 +0000

Harbor, la registry Docker de VMware

Il y a quelques mois, j’avais écris un article à propos d’une bonne surprise de la part de VMware : Harbor. Pour ceux qui n’ont pas lu mon article sur le sujet, j’ai développé dans la première partie ce qu’était Harbor et ce que cette solution apporte par rapport aux autres outils du marché, puis j’ai expliqué pas à pas comment l’installer et la configurer (vous pouvez vous rattraper ici).

Rapidement, Harbor est un des produits open sourcé par VMware. C’est un serveur permettant de stocker « on premise » ou dans le cloud des images Docker, au même titre que le produit historiquement appelé Docker Registry (maintenant Docker Distribution), mais avec des fonctionnalités supplémentaires, notamment :

Gestion de la sécurités, des comptes, rôles, habilitation (RBAC)
Réplication des images entre plusieurs instances de Harbor
Portail web
Logging de toutes les opérations à des fins d’audit
API RESTful
Scan de vulnérabilité intégré
Nettoyage automatique des images inutiles (garbage collection)
Intégration native avec Notary pour la signature des images

Dans cette deuxième partie, j’ai voulu explorer un peu plus l’utilisation et l’administration de la plateforme que nous venons d’installer.

Administration de base

Dans l’article précédent, on a installé Harbor à l’aide d’un Docker Compose et d’Ansible pour faciliter la récupération de certains prérequis et la configuration des différents composants.

Démarrer/arrêter Harbor

Du coup, comme tout est configuré avec docker compose, l’arrêt et le redémarrage de la plateforme se limite à un simple docker-compose up ou down.

docker-compose up
[...]
docker-compose down
Stopping nginx ... done
Stopping harbor-jobservice ... done
Stopping harbor-ui ... done
Stopping harbor-db ... done
Stopping registry ... done
Stopping harbor-adminserver ... done
Stopping harbor-log ... done
WARNING: Found orphan containers (notary-server, notary-signer, notary-db) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Removing nginx ... done
Removing harbor-jobservice ... done
Removing harbor-ui ... done
Removing harbor-db ... done
Removing registry ... done
Removing harbor-adminserver ... done
Removing harbor-log ... done
Removing network harbor_harbor

Supprimer / Réinstaller Harbor

Contrairement à ce qu’on pourrait penser naïvement, un simple docker-compose down ne suffit pas. Si les containers sont bien supprimé (cf. le « Removing… » pour chaque composants plus haut), il reste encore les fichiers de configurations et les données des différents containers, toujours présents sur disques et persistés à l’aide de volumes Docker.

Il est nécessaire de supprimer ces fichiers créés par l’installation précédente, notamment le contenu de common/config et le fichier secretkey. Par défaut, l’emplacement de ces fichiers est configuré par le playbook Ansible que je vous ai proposé. common/config est par défaut dans /usr/local/harbor, et la secretkey dans dans /data (configurable dans le fichier /usr/local/harhor/harbor.cfg).

cd /usr/local/harbor
ll common/config/
total 0
drwxr-xr-x 2 root root 16 20 oct. 11:38 adminserver
drwxr-xr-x 2 root root 16 20 oct. 11:38 db
drwxr-xr-x 2 root root 31 20 oct. 11:38 jobservice
drwxr-xr-x 9 root root 139 20 oct. 11:38 nginx
drwxr-xr-x 3 root root 27 20 oct. 11:38 notary
drwxr-xr-x 2 root root 38 20 oct. 11:38 registry
drwxr-xr-x 2 root root 53 20 oct. 11:38 ui
cat harbor.cfg
[...]
secretkey_path /data
[...]

Voilà donc la bonne méthode pour tout supprimer (maintenant qu’on a vérifié que les chemins configurés correspondent).

docker-compose down
rm -rf /usr/local/harbor/common/config/
rm -rf /data/secretkey

Pousser (push) une image depuis un client configuré vers la Registry

Pour vous permettre d’organiser un peu vos images et donner des droits plus fins aux utilisateurs, les accès aux images sont découpés via des « projet » dans Harbor.

Du coup, avant de pousser un image sur la registry, il est nécessaire de « taguer » l’image avec le nom du serveur registry ET son projet associé, au lieu de simplement taguer un nom d’image comme on l’aurait fait normalement avec la Docker Registry.

REGISTRY=[hostname_de_la_registry]
DOCKER_IMAGE=[your-docker-image]
HARBOR_PROJET=library
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded
docker tag $DOCKER_IMAGE $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE
docker push $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE
The push refers to a repository [xxx/library/xwiki-tomcat8]
ac33aaa78bac: Pushed
[...]
fe40aaa9465f: Pushed
cf4aaa492384: Pushed
latest: digest: sha256:81b3a60d6936a07e9zzzzzzccb29ead8a1d1035fa5042297ac54f71a6c1e95bb size: 4504

L’image apparaît sur la console :

Tirer (pull) une image depuis un client configuré

Même principe que pour le push, il faut être authentifié et sélectionner le projet dans lequel est située l’image

REGISTRY=[hostname_de_la_registry]
DOCKER_IMAGE=[your-docker-image]
HARBOR_PROJET=library
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded
docker pull $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE

Tout simplement !

Interface web : Projects

La vue Projects a vocation a permettre la segmentation de la plateforme en plusieurs projets distincts.

Chaque projet peut être privé ou public, disposer d’habilitations et règles de réplications qui lui sont propres.

Interface web : Logs

La vue Logs permet aux administrateurs d’avoir une vue d’ensemble des logs (pull, push, etc) de TOUS les projets de manière centralisée.

Chaque projet peut également voir ses propres logs dans la vue du projet.

Clairement, ce n’est pas transcendant en terme de logging (à des fins d’audit par exemple) mais c’est mieux que rien (Docker Registry…) et relativement intuitif.

Interface web, partie Administration

Le sous-menu Users permet d’avoir une liste des utilisateurs et de les administrer.

Le sous-menu Replication permet de gérer les endpoints de réplication et la réplication des projets (Replication Rule) de manière globale.

Le sous-menu Configuration permet de visualiser et modifier une partie des paramètres généraux de la plateforme. Une partie des ces paramètres proviennent de la configuration harbor.cfg renseignée lors de l’instanciation (via Ansible dans notre cas). Certains ne peuvent pas être changés depuis l’interface (comme la méthode d’authentification par exemple, mais je ne le testerai pas si j’étais vous…).

Par défaut, la création de projets est permis pour tout le monte et l’enregistrement d’utilisateurs est possible. Pour des raisons de sécurité, il est préférable de le désactiver si ce n’est pas nécessaire.

Erreurs rencontrées

Dans l’ensemble, Harbor est un produit sympa et plutôt bien fini, qui étend avec des fonctionnalités vitales en entreprise la bête Docker Registry.

Pour autant, le produit étant récent, il n’était pas exempt de quelques bugs à sa sortie (en grande partie corrigés depuis). Voilà ceux que j’ai rencontré au moment où j’ai rédigé le premier article (il y a quelques mois maintenant)

Modification du secretkey_path

Si on modifie le paramètre secretkey_path, le container harbor-adminserver part en crash loop. Le problème est référencé sur ce ticket

github.com/vmware/harbor/issues/2208

docker ps
[...]
7dcd18a310bc vmware/harbor-adminserver:v1.2.0 "/harbor/harbor_ad..." 19 seconds ago Restarting (1) 3 seconds ago harbor-adminserver
docker-compose up
[...]
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] initializing system configurations...
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] the path of json configuration storage: /etc/adminserver/config/config.json
harbor-adminserver | 2017-10-20T09:56:16Z [DEBUG] [driver_json.go:46: path of configuration file: /etc/adminserver/config/config.json]
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] the path of key used by key provider: /etc/adminserver/key
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] configurations read from storage driver are null, will load them from environment variables
harbor-adminserver | 2017-10-20T09:56:16Z [FATAL] [main.go:46: failed to initialize the system: read /etc/adminserver/key: is a directory]

A priori il n’y a pas encore de correctif, la seule solution est de remttre le paramètre secretkey_path à la valeur par défaut

secretkey_path /data

Crash loop sur nginx lorsqu’on utilise Notary

En cas d’installation avec Notary, le container frontend nginx (reverse proxy) part en crashloop

nginx | 2017/10/20 10:05:40 [emerg] 1#0: host not found in upstream "notary-server:4443" in /etc/nginx/conf.d/notary.upstream.conf:3
nginx | nginx: [emerg] host not found in upstream "notary-server:4443" in /etc/nginx/conf.d/notary.upstream.conf:3
nginx exited with code 1

A priori, il s’agit d’un problème d’ordonnancement du démarrage des containers dans le Docker Compose (notary n’est pas accessible au moment du démarrage du nginx). Un redémarrage du container nginx (uniquement )après le « docker compose up » règle la plupart du temps le problème.

Harbor : la docker registry d’entreprise open source de VMware – part 1

Tue, 27 Feb 2018 12:45:35 +0000

Harbor ?

Rien à voir avec l’île dans le Pacifique ou l’accord entre les Etats Unis et l’Union Européenne dans les années 90. Le Harbor dont je vais vous parler, c’est la registry Docker d’entreprise et Open Source de VMware !

Harbor est un des produits open sourcé par VMware. C’est un serveur permettant de stocker « on premise » ou dans le cloud des images Docker, au même titre que le produit historiquement appelé Docker Registry (maintenant Docker Distribution), mais avec des fonctionnalités supplémentaires, notamment :

Gestion de la sécurités, des comptes, rôles, habilitation (RBAC)
Réplication des images entre plusieurs instances de Harbor
Portail web
Logging de toutes les opérations à des fins d’audit
API RESTful
Scan de vulnérabilité intégré
Nettoyage automatique des images inutiles (garbage collection)
Intégration native avec Notary pour la signature des images

Rien que ça ;)

Pour ceux que ça intéressent et qui ne savaient pas (comme moi) que VMware met à disposition des logiciels open source, les autres sont disponibles sur la page Github de VMware.

Petite étude du marché

Je ne vais pas vous faire une analyse poussée du marché de la registry privée, mais si jamais vous cherchez des produits similaires, vous pouvez aller jeter un œil aux produits suivants qui ont attirés mon attention :

Docker Trusted Registry (version entreprise de Docker Distribution)
Gitlab Container Registry, fortement intégré à Gitlab CI
Artifactory supporte maintenant les containers
Quay de CoreOS, Inc. (maintenant racheté par Redhat)

Et je vous met aussi quelques articles sympas qui parlent de ces différentes solutions :

Méthode choisie

Ok ! Maintenant qu’on connaît un peu l’écosystème, on peut s’attaquer à la bête. Il existe plusieurs méthodes pour installer Harbor sur une infrastructure « on premise » :

Installer Harbor sur un serveur Docker via
- l’installeur « online » (qui télécharge les images nécessaires sur Dockerhub)
- l’installeur « offline » (qui dispose déjà des images nécessaires)
Déployer une VM VMware via un OVA VIC (VMware vSphere Integated Containers) qui contient entre autre un serveur Harbor préinstallé et préconfiguré
Déployer Harbor directement sur un cluster Kubernetes via YAML (option communautaire)

Les releases sont disponibles depuis la page « release » sur le dépôt Github. L’OVA est lui disponible sur myvmware (lien mort, comme tout chez VMware, j’utilise Internet Archive), le site de téléchargement habituel de VMware.

Dans le cadre de cette article, la méthode d’installation que j’ai choisie est l’installation via les sources en mode « offline » car il m’arrive souvent dans les datacenters de ne pas avoir accès à Internet facilement (pour des raisons de sécurité).

Récupération des sources

Depuis un poste qui a accès à Internet, on va donc télécharger l’ensemble des fichiers dont nous aurons besoins : le fichier d’installation ainsi que sa signature md5.

curl -L https://github.com/vmware/harbor/releases/download/v1.2.0/harbor-offline-installer-v1.2.0.md5.txt -o harbor-offline-installer-v1.2.0.md5.txt
curl -L https://github.com/vmware/harbor/releases/download/v1.2.0/harbor-offline-installer-v1.2.0.tgz -o harbor-offline-installer-v1.2.0.tgz

C’est super d’avoir mis un fichier MD5… mais la comparaison avec la signature ne peut pas être faite telle quelle car un fichier de signature MD5 « valide » doit avoir le nom du fichier indiqué APRÈS la signature en elle même. Ce n’est pas le cas dans le fichier mis à disposition par VMware.

cat harbor-offline-installer-v1.2.0.md5.txt
235fcfb9fe00ad61f6cbc2de4920b477
#Un fichier MD5 valide doit contenir "235fcfb9fe00ad61f6cbc2de4920b477 harbor-offline-installer-v1.2.0.tgz"

Pour pouvoir le comparer sous Linux avec md5sum, on doit recréer un fichier correct avec la commande suivante :

file="harbor-offline-installer-v1.2.0"
md5sum -c <(echo $(<${file}.md5.txt) ${file}.tgz)
harbor-offline-installer-v1.2.0.tgz: Réussi

Source : Most practical way to compare MD5 checksums sur StackExchange

Installation des prérequis

La documentation d’installation officielle nous indique les dépendances suivantes :

python 2.7+
docker 1.10+
docker-compose 1.6+

Depuis un serveur qui a accès à Internet, on va donc récupérer les sources de Docker compose

curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

Vous ne trouvez pas que ça commence à être un peu relou toutes ces étapes ?

Vous le voyez venir ? Quoi donc ?

Et bien le playbook Ansible pardi !! Pour faciliter cette installation, j’ai écris des rôles Ansible pour automatiser ça ;-)

Pourquoi ? Parce que je kiffe Ansible.

Ansible à la rescousse

Tout est sur mon Github, sauf docker compose et l’installeur d’Harbor évidemment (que vous aurez récupéré lors des étapes précédentes)

cd /etc/ansible
git clone https://github.com/zwindler/ansible-deploy-harbor
cp /usr/local/bin/docker-compose /etc/ansible/roles/prereqs_harbor/files
cp harbor-offline-installer-v1.2.0.tgz /etc/ansible/roles/install_harbor/files

Et si vous voulez un coup d’œil rapide au fichier principal qui appelle les rôles, voici ce qu’il contient (et les variables qu’il convient de renseigner) :

cat deploy_harbor.yml
---
# Playbook pour installer Harbor
- name: "Install harbor prerequisites"
hosts: zwindler_linux
vars_prompt:
- name: "db_password"
prompt: "Harbor Database Password"
default: "HarborPassword"
- name: "clair_db_password"
promt: "ClairDB password"
default: "HarborPassword"
- name: "harbor_admin_password"
promt: "Harbor Admin password"
default: "HarborPassword"
vars:
- add_notary: false
- use_https : true
- generate_ssl: true
- harbor_install_path : "/usr/local/"
roles:
- prereqs_harbor
- install_harbor

Dans le cas où l’on ne souhaite pas utiliser Notary, la configuration d’Harbor est plus simple et la configuration se fait en HTTP simple. Il est nécessaire de modifier la variable add_notary à False dans le playbook dans ce cas particulier.

Dans le cas où l’on souhaite utiliser Notary, il est obligatoire de passer en HTTPS et d’avoir un certificat. Si tel est le cas, vous l’avez compris, il faut laisser le paramètre add_notary à True ce qui permettra de gérer ce cas particulier. Pour être honnête, je n’ai pas testé la partie Notary, je ne peux donc pas certifier à 100% que cette partie fonctionne convenablement.

Enfin, le script Ansible peut générer un certificat autosigné en laissant la variable generate_ssl à True. Il est aussi possible d’en générer un à la main en suivant la documentation sur le site de Harbor. Auquel cas il ne faudra pas oublier de passer le paramètre generate_ssl à False.

Configuration

Le playbook déploie Harbor avec une authentification login/mdp stockés dans une base de données interne. Pour tester, c’est pas mal mais évidemment, dans un second temps, il sera opportun de déporter cette authentification à une source de type LDAP ou Active Directory par exemple.

La première connexion se fait donc avec le login admin et le mot de passe tel que défini lors du déploiement du playbook.

Une fois connecté, le portail permet d’explorer les projets et de réaliser les configurations complémentaires, telle que la création d’utilisateurs (si on est en mode de stockage « base de données »), la gestion des habilitations, ou la réplication des registries entre elles.

Configurer un client

Comme le playbook est très bien fait (enfin normalement, hahaha), tout s’est bien passé et on peut maintenant configurer son poste client pour qu’il s’authentifie sur la Registry et commence à pousser/tirer des images Docker.

Si vous êtes en HTTPS, vous aurez besoin sur le poste client du CA autosigné généré lors du déploiement d’Harbor, car la registry est du coup sécurisée. Il devrait être disponible dans /etc/ssl/ca/ et dans /etc/docker/certs.d/[hostname_de_la_registry]/ et doit être déposé dans /etc/docker/certs.d/ du client depuis lequel on souhaite se connecter :

scp /etc/docker/certs.d/ca.crt [machine_cliente]:/etc/docker/certs.d/[hostname_de_la_registry]/

Une fois fait, on peut tenter de se connecter sur la registry avec la commande suivante :

REGISTRY=[hostname_de_la_registry]
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded

Tadam !

Et la suite ?

Et ben c’est déjà pas mal pour un premier article sur Harbor, non ? Vous venez, sans effort, de déployer une registry privée d’entreprise pour vos images Docker ;-)

Mais comme vous l’avez sûrement vu dans le titre, ce n’est que la partie 1. J’ai encore plein de choses à vous raconter sur Harbor. La suite au prochain épisode !

[Tutoriel] Premiers pas avec Swarm (FR)

Tue, 31 Jan 2017 13:00:42 +0000

Pourquoi Docker Swarm ?

Docker Swarm est une fonctionnalité d’orchestration de clusters Docker initialement développée à part et finalement intégrée à la version 1.12 du moteur Docker. Il est donc nécessaire d’avoir a minima cette version pour pouvoir utiliser Swarm tel que je le présente dans cet article. En effet, dans les versions précédentes, l’installation était beaucoup plus complexe.

Swarm un orchestrateur de containers Docker relativement « simple ». On va donc pouvoir disposer d’un cluster de machines sur lesquelles seront répartis automatiquement les containers.
A noter cependant, la gestion de la persistance entre nœuds n’est pas inclus dans la fonctionnalité Swarm elle même, qui doit être implémenté à part (via des volumes distribués).

Swarm convient parfaitement aux contextes stateless, c’est à dire sans données stockées par le container, mais est moins adapté dans les contextes où la personnalisation des services et la gestion de la persistance (base de données) est importante. Si vous voulez un retour un peu plus argumenté que le mien sur la question, voilà notamment l’avis de l’équipe MySQL sur la question (lien mort, j’utilise Internet Archive).

Cet article a été rédigé en suivant le tutoriel officiel disponible ici et adapté pour aller un peu plus loin (notamment en ajoutant un registry local pour permettre aux machines coupées d’Internet de fonctionner).

Prérequis

Serveurs

Dans ce tutoriel, je pars du principe que vous disposez de deux nœuds Docker sur lesquels vous avec installé l’OS RHEL 7.2 (ou CentOS). Je me référerai à ces deux nœuds sous les noms suivants :

pocdocker01
pocdocker02

J’ai également ajouté un serveur de configuration management (Ansible dans mon cas) avec un repository RPM local et sur lequel nous ajouterons le registry Docker. Ce serveur n’est pas obligatoire à proprement parler mais je l’avais sous la main et c’est la seule machine qui a accès à Internet. Cette machine aura pour nom « infra01 ».

Préparation des machines

Depuis infra01, je récupère le dépôt RPM du projet Docker car par défaut RHEL 7.2 embarque une version antérieure de Docker (la 1.10 je crois).

cd /etc/yum.repos.d/
tee /etc/yum.repos.d/docker.repo <<-'EOF'
> [dockerrepo]
> name=Docker Repository
> baseurl=https://yum.dockerproject.org/repo/main/centos/7/
> enabled=1
> gpgcheck=1
> gpgkey=https://yum.dockerproject.org/gpg
> EOF
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg

Je met ensuite à jour mon dépôt local de RPM (zwindlerrepo)

cd /share/zwindlerrepo
yumdownloader docker-engine
createrepo --update .

Si vous ne savez pas utiliser createrepo et yumdownloader, je vous invite à aller sur le site des Howtos de CentOS qui résume plutôt bien le concept.

Depuis infra01, je me connecte sur les deux serveurs pocdocker01 et 02 pour déposer la clé de mon serveur de configuration management, puis j’éxecute 2 playbooks (un pour configurer les dépôts locaux, l’autre pour installer Docker).

ssh-copy-id root@pocdocker01 #idem pour le 02
#Configuration par défaut repositories, ntp, supervision, firewall, SELinux
ansible-playbook -l pocdocker* /etc/ansible/zwindler_rhel.yml
ansible-playbook -l pocdocker* /etc/ansible/zwindler_docker_linux.yml
cat zwindler_docker_linux.yml
---
# Playbook pour noeud Docker sous RHEL
- name: "Docker RHEL node"
hosts: docker_rhel_nodes
roles:
- docker_linux
cat roles/docker_linux/tasks/main.yml
---
- name: insecure registry - temporary mesure until registry is TLS secured
lineinfile:
state: present
create: yes
dest: /etc/docker/daemon.json
line: '{ "insecure-registries":["infra01.zwindler.fr:5000"] }'
- name: install docker engine
yum: name={{ item }} state=latest
with_items:
- docker-engine
- name: start and enable docker engine
systemd: name=docker state=started enabled=yes

Création d’un registry Docker sur infra01

Les nœuds pocdocker01 et 02 n’ayant pas accès à Internet, on utilisera le registry sur infra01. Pour cela, le plus simple est de récupérer l’image officielle sur le Dockerhub.

docker run -d -p 5000:5000 --restart=always --name registry registry:2

Pour les besoins du tutoriel, je récupère l’image alpine par défaut, puis la « push » sur mon registry interne.

docker pull alpine
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry 2 182810e6ba8c 15 hours ago 37.6 MB
alpine latest 0766572b4bac 18 hours ago 4.799 MB
zwindler/xwiki-tomcat 8.4.1 d4a1b1df7349 4 weeks ago 661.2 MB
tomcat 8-jre8 b3e4bba2bff8 5 weeks ago 334.9 MB
docker tag 0766572b4bac infra01.zwindler.fr:5000/alpine
docker push infra01.zwindler.fr:5000/alpine

A partir de là, nous avons donc tous nos prérequis pour créer et utiliser notre cluster Docker Swarm (coupé d’Internet).

Mise en place du cluster

Création du cluster

Dans la topology Swarm, il existe des nœuds managers et des workers. A noter, les commandes liées à Swarm ne peuvent être effectuées que sur les nœuds managers.

Depuis pocdocker01 (manager), on créé le cluster en une simple commande :

docker swarm init --advertise-addr 10.0.0.10
Swarm initialized: current node (6zzehbr4ulsld8ofxe09h3djz) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join \
--token SWMTKN-1-aaaaaaaaaeaxirr7ldxr3ucv4z0q1soddszao7b46ywz9q90-8ofnnub6kl7r39zmophu6qqq7 \
10.0.0.10:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Intégration du 2ème noeud

Depuis pocdocker02 (worker), on rejoint le cluster en copiant collant le résultat de la commande précédente réalisée sur le manager.

docker swarm join --token SWMTKN-1-5nufexjdjh6eaxirr7ldxr3ucv4z0q1soddszao7b46ywz9q90-8ofnnub6kl7r39zmophu6qqq7 10.0.0.10:2377
This node joined a swarm as a worker.

Vérification de l’état du cluster

Depuis pocdocker01 (manager), on peut vérifier l’état du cluster avec les commandes suivantes :

docker info
[…]
Swarm: active
NodeID: 6zzehbr4ulslaaaaae09h3djz
Is Manager: true
ClusterID: 7a4lauts8xaaaaaa190tu4jf
Managers: 1
Nodes: 2
[…]
docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
6zzehbr4ulsld8ofxe09h3djz * pocdocker01.zwindler.fr Ready Active Leader
a7demo2k14obqp66gbxfsm7er pocdocker02.zwindler.fr Ready Active

Création d’un service orchestré par Docker

Dans un cluster Swarm, la notion de « service » a été ajoutée. Ce nom englobe un peu plus que le simple container, puisque nous avons également des notions de scaling, …

Toutes les commandes relative à la création de services sont donc débutée par l’instruction « docker service … », et je le rappelle, lancées depuis le manager, qui est le seul à pouvoir avoir les gérer.

Création d’un service

Dans cet exemple simple, on va créer un « service » qui ne contente de récupérer notre container alpine disponible sur le registry interne et pinguer indéfiniment docker.com. Puis ensuite, on vérifiera que tout s’est bien passé avec la commande « docker service ls », l’équivalent du « docker ps » pour les services.

docker service create --replicas 1 --name helloworld infra01.zwindler.fr:5000/alpine ping docker.com
docker service ls
ID NAME REPLICAS IMAGE COMMAND
26krds5pwpqs helloworld 1/1 infra01.zwindler.fr:5000/alpine ping docker.com

On peut également avoir un peu plus de précision sur le service en cours avec la commande « docker service inspect ».

docker service inspect --pretty helloworld
ID: 21e1ync4fjafudd4e7kzrurag
Name: helloworld
Mode: Replicated
Replicas: 1
Placement:
UpdateConfig:
Parallelism: 1
On failure: pause
ContainerSpec:
Image: alpine
Args: ping docker.com
Resources:

Scaling de l’application

Admettons que vous souhaitiez faire plus de pings simultanés sur le site de docker pour une raison ou pour une autre (ce qui je le concède volontiers n’est que modérément utile), vous pouvez très simplement faire un « up-scaling » de vos containers avec la commande « docker service scale ».

docker service scale helloworld=5
helloworld scaled to 5
docker service ps helloworld
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
dn46s9z7zcet9iol79ej7e3h3 helloworld.1 alpine pocdocker01.zwindler.fr Running Running 2 minutes ago
1gme311su7osbz7m92hsv5vc3 helloworld.2 alpine pocdocker02.zwindler.fr Running Preparing 21 seconds ago
ew7o5gsszm6585moxf672inlb helloworld.3 alpine pocdocker02.zwindler.fr Running Preparing 21 seconds ago
cwifuygmvlw44pit740n7z50q helloworld.4 alpine pocdocker01.zwindler.fr Running Running 19 seconds ago
bidm8wth2tuxo25z261h87yy4 helloworld.5 alpine pocdocker01.zwindler.fr Running Running 19 seconds ago

Simplissime !

Désactivation des capacités du noeud 2

Pour vérifier que notre cluster fonctionne bien ou tout simplement réaliser une maintenance sur un des noeuds en fonctionnement nominal, il est possible de peut passer un noeud hors ligne.

Les répliquas du services sont alors démarrés sur les nœuds encore disponibles.

docker node update --availability drain pocdocker02.zwindler.fr
docker service ps helloworld
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
92c4tbremj6iq7h65brs8u42l helloworld.1 infra01.zwindler.fr:5000/alpine pocdocker01.zwindler.fr Running Running about a minute ago
18lwc3j7r1t3uqeij0g0qm701 helloworld.2 infra01.zwindler.fr:5000/alpine pocdocker01.zwindler.fr Running Running 17 seconds ago
9iozodo4q7be4klmib5znh9e0 \_ helloworld.2 infra01.zwindler.fr:5000/alpine pocdocker02.zwindler.fr Shutdown Shutdown 18 seconds ago
6dad19g5m6zd9b7wd9sczs10c helloworld.3 infra01.zwindler.fr:5000/alpine pocdocker01.zwindler.fr Running Running 17 seconds ago
3autcjlnqfe4v6x2gsoov5853 \_ helloworld.3 infra01.zwindler.fr:5000/alpine pocdocker02.zwindler.fr Shutdown Shutdown 18 seconds ago
033idvu5mbo89q05p32nytpg9 helloworld.4 infra01.zwindler.fr:5000/alpine pocdocker01.zwindler.fr Running Running about a minute ago
53x5kbx0su09w2b639hnpcj8v helloworld.5 infra01.zwindler.fr:5000/alpine pocdocker01.zwindler.fr Running Running about a minute ago

Réactivation des capacités du nœud 2

Et on peut bien entendu revenir en arrière :

docker node update --availability active pocdocker02.zwindler.fr

Suppression du service

Et comme je suis sympa, je vous donne la commande pour nettoyer tout ça car je ne pense pas que Docker.com ait besoin que vous le pinguier ad vitam æternam.

docker service rm helloworld

Conclusion

Dans cet article, j’ai essayer de vous montrer à quel point il est simple d’utiliser la fonctionnalité d’orchestration de containers Swarm. Et ça n’a pas toujours été au si simple comme le reconnaissent eux même les gens de Docker :

On peut ainsi gérer sur plusieurs machines un ensemble de containers sans se demander où les déposer. Les communications inter-hôtes sont également simplifiée avec l’ajout d’overlay-network qui monte des tunnels VPN entre réseaux virtuels de vos containers. Et enfin, vous pouvez simplement ajouter de nouvelles instances à votre service à la hausse ou à la baisse d’une simple commande.

Et c’est là un des avantages majeurs de l’orchestration de containers. Au delà de la simple création d’un cluster, on peut adapter en fonction du besoin le nombre de processus en frontend/backend d’une application, pour peut que ce processus soit :

capable de traiter de manière distribuée les requêtes
n’ait pas besoin d’être différencié car tous les containers d’un même service sont strictement identiques

C’est probablement la difficulté pour les applications « classiques ».
A date, il existe encore beaucoup de workloads qui ne sont pas parallélisables et/ou qui nécessitent d’être différenciés. Je pense notamment aux bases de données ou aux applications web qui stockent des fichiers ou des informations de session en interne, qui auront besoin de composants externes supplémentaires pour fonctionner correctement sur ce type d’architectures pour pourvoir être « up-scalés ».