Dockerhub on Zwindler's Reflection

Sortie de XWiki 9.5 et mise à jour Docker

Fri, 30 Jun 2017 10:30:12 +0000

Adieu à 8.4, bonjour XWiki 9.5 (.1)

J’évite de faire un article à chaque fois qu’une nouvelle version de XWiki sort, surtout les versions mineures. Le projet XWiki est assez dynamique : les versions (et les fonctionnalités supplémentaires qui vont avec) s’enchaînent assez vite. Effectivement, depuis mon dernier article sur comment mettre à jour en 8.4 votre XWiki si vous utilisez mon image Docker de XWiki date d’à peine plus de 6 mois !

Mais j’ai deux occasions pour faire ce petit article.
D’abord parce que je continue à maintenir mon image zwindler/xwiki-tomcat8 qui fonctionne avec postgresql. Et je viens de déployer la dernière version sur le dockerhub.
Et ensuite parce qu’au delà des nombreuses améliorations et modifications de l’interface (j’en fais la liste dessous), la gestion des pages par défaut du XWiki (Flavor) a été découplée du Distribution Wizard pour permettre à la communauté de créer son propre « set » de pages par défaut.

Une bonne nouvelle car personnellement la première chose que je fais quand je déploie un XWiki, c’est supprimer la Sandbox et le Blog. J’attend donc les premiers Flavors avec impatience :).

Pourquoi maintenir une version non officielle ?

Depuis mon dernier post, les gens de chez XWiki (surtout Vincent Massol) ont sorti leur propre version de XWiki sous Docker.

100k pulls dépassés, respect !

Vincent est même allé assez loin dans le travail, avec la promotion de son image en tant qu’image « officielle » (titre réservé aux éditeurs, et si j’ai bien compris gagner ce titre n’a pas été une mince affaire), ainsi que la création d’un build automatisé multiple pour plusieurs version de XWiki et le support de plusieurs bases de données :

De nombreuses versions disponibles, comme les plus grands

Alors dans ces conditions, à quoi bon maintenir ma propre image ?

Eh bien déjà parce que XWiki a été ma première expérience avec Docker et que construire cette image m’a permis de mettre le pied à l’étrier. Aujourd’hui encore, quand je teste une techno ou un outil dans l’écosystème Docker, une installation simple XWiki + postgresql me sert de base de comparaison.

Du coup j’utilise XWiki avec ma propre image, et la mettre à jour lorsque je veux profiter des dernières version. Accessoirement, ça me permet aussi de faire la course avec Vincent et de parfois mettre à jour ma version de XWiki containerisé avant l’image officielle (je plaisante ;-) ).

(Elle est aussi plus légère car je n’embarque pas le serveur Open Office que je n’utilise pas, mais ce n’est probablement pas un argument en ma faveur).

Quoi de neuf docteur ?

J’aurais bien fais la blague « quoi de neuf, Docker » mais j’ai découvert récemment que c’est une chaine Youtube qui existe déjà…

Pour ceux qui n’ont pas le temps de lire l’ensemble des releases notes depuis la 8.4, voici la liste des fonctionnalités et des changements les plus notables qui ont été ajoutées depuis (de 9.0 à 9.5) :

La 9.0 a surtout servi à marquer le changement de branche et n’ajoute que quelques ajustements sur la taille max des pièces jointes et de la corbeille
Depuis la 9.1, ajout d’une protection contre la suppression accidentelles de page du système

Depuis la 9.1, l’export HTML prend mieux en compte les nested pages (pages filles) ! Un grand soulagement pour ceux qui font des exports pour avoir des versions figées comme moi !
Depuis la 9.2, les options en terme de notification (pour les utilisateurs en cas d’abonnement, etc) a été enrichi. Et depuis la 9.4, on peut s’abonner aux commentaires d’une page, une fonctionnalité qui m’a déjà été demandé et qui manquait, effectivement ! Des filtres ont également été ajoutés pour plus de finesse dans les notifications.

Depuis la 9.2, et à la suite d’un sondage parmi les utilisateurs de XWiki, les ergonomes de chez XWiki on réorganisé la page d’administration pour améliorer l’expérience utilisateur. Certains changements sont subtils mais bienvenus (notamment l’ordre des menus).

Depuis la 9.4, pour répondre de nombreuses remarques venant de novices et suite à une consultation sur la dev-list, les menus pour interagir avec une page ont été refondus et des labels (pour modifier et créer) ont été ajoutés pour être plus explicites. Ce n’est pas forcément vrai pour tout le monde, mais c’est vrai que dans certain cas, trouver comment faire une action sur une page (renommer pour déplacer) n’était pas toujours intuitif.

l’éditeur CKEditor a été amélioré à plusieurs reprise pour une meilleure intégration avec XWiki et notamment ses macros, …
l’API REST a été améliorée et permet maintenant (entre autre) de déployer des XWiki de manière non interactive et d’interagir avec les différents éléments du XWiki (dont la corbeille). Personnellement je sous-utilise énormément l’API et c’est une erreur car je pense que nous pourrions gagner beaucoup de temps…
Diverses améliorations graphiques dans les diff entre révisions d’une page/extension, sur les calendriers, des preview sur les images en attachement, …

Bon et donc la 9.5, on fait comment pour l’avoir ?

Rien ne vous empêche d’installer la 9.5 vous même, ou bien d’attendre que la version XWiki Docker officielle ne sorte, mais si vous utilisez mon image, elle est disponible :-p.

Pour rappel, les sources sont disponibles sur Github et l’image est elle accessible sur Dockerhub ou encore via une simple commande du type :

docker network create -d bridge xwiki-nw
docker run --net=xwiki-nw -itd --name xwiki-postgres -e POSTGRES_DB=xwiki -e POSTGRES_USER=xwiki -e POSTGRES_PASSWORD=xwiki postgres
docker run --net=xwiki-nw -itd --name xwiki-tomcat -p 8080:8080 -e POSTGRES_INSTANCE=xwiki-postgres zwindler/xwiki-tomcat8

Si vous voulez un tutoriel plus complet sur ma version, je vous conseille cet article ou tout simplement de suivre les instructions sur Dockerhub.

Have fun !

[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 ».

Automatiser la création d’une image Dockerhub

Tue, 24 Jan 2017 13:00:53 +0000

Créer un automated build sur le Dockerhub

Ça fait quelques semaines maintenant que j’ai mis à disposition sur le Dockerhub ma première image Docker. Sans aller jusqu’à dire qu’elle a déplacé les foules, je suis assez content de voir que je ne suis pas le seul à l’utiliser avec une 100aine de « pull », même si sur le segment des images préconfigurées pour XWiki, les builds de Hellyna et Lavadiablo sont bien plus souvent téléchargées. Et c’était sans compter sur l’image Docker officielle de XWiki qui est sortie juste avant que je ne publie cet article !

Mais aussi auto-satisfait que je suis, je suis forcé de le reconnaître, cette image Docker pêche d’un défaut de jeunesse : la mise à disposition d’une nouvelle version nécessite :

Que je modifie (et éventuellement que je le push sur Github) mon code sur mon repository git
Que je la build moi même à partir du code

docker build -t zwindler/xwiki-tomcat8:latest .

Et une fois l’image sur mon Docker registry local, que je lance la commande

docker push zwindler/xwiki-tomcat

Mais, vous l’aurez deviné, il y a mieux ;-)

Une fonctionnalité de Dockerhub vous permet de créer une image que vous poussez manuellement ou une image dont la création est automatique. On peut distinguer ces deux types d’images par la mention automated build sous le nom de celle ci.

Comment en profiter ?

Tout commence d’abord par renseigner quelques informations dans votre profil. Dans les propriétés de votre compte, il y a un menu « Linked Accounts & Services ».

Ce menu vous permet de lier le Dockerhub avec un ou plusieurs comptes Github/Bitbucket via une autorisation de type OAuth.

Au delà de simplement lier les deux comptes, Dockerhub paramètre vos dépôts git et y ajoute des services (webhooks préconfigurés) permettant de prévenir automatiquement Dockerhub de la présence de code mise à jour sur GitHub.

On autorise l’accès en lecture/écriture sur le compte. On peut le mettre en lecture seule mais il faudra paramétrer les webhooks à la main !

Présence du service dans les paramètres du projet Github

Créer son premier automated build

Maintenant que les permissions sont bien passées entre Github et Dockerhub, on peut créer son image automatique.

Ici j’ai sélectionné mon compte Github, puis le projet qui contient mon projet xwiki-tomcat.

La suite de la création de l’image est similaire à la création d’une image « non automatique ». On donne un nom à l’image ainsi qu’une petite description et on valide en cliquant sur create.

Dans mon cas, ça n’a pas fonctionné du premier coup et le build a échoué car par défaut l’image cherchait le Dockerfile à la racine du projet Github. Sur mon dépôt git, le Dockerfile est situé dans un sous dossier, la racine contenant le README et un fichier docker-compose.

Dans ce cas précis, il faut donc aller dans le build settings et renseigner la variable « Dockerfile location ».

A noter : pour plus de clarté dans mes images, j’ai indiqué que la branche Master dans git correspondait au tag « latest » et ait ajouté une seconde ligne avec la branche Master taguée avec le numéro de version (actuellement 8.4.4).

Ainsi, les utilisateurs pourront soit récupérer la dernière version, soit spécifier la version 8.4.4 manuellement.

Et cerise sur le gâteau, j’ai également ajouté une branche 7.4.5-lts dans Github qui me permet de proposer de manière optionnelle une image préconfigurées avec la version LTS actuelle de XWiki.

Conclusion

Il est très simple de créer un automated build dans Dockerhub et vous avez donc tout intérêt à arrêter de pusher manuellement vos images si vous déposer votre code Github.com.

Seul bémol, le manque d’intégration avec Git ou même Gitlab qui sera un vrai point noir si vous avez votre propre dépôt personnel ou d’entreprise en dehors des deux services en lignes proposés par Dockerhub.

Sources

docs.docker.com/docker-hub/builds/