Journal Revue de livre: Docker, prise en main et mise en pratique sur une architecture micro-services

Posté par dzecniv le 27 octobre 2018 à 17:02. Licence CC By‑SA.

Étiquettes :

oct.

2018

Salut journal,

Revue d'un bouquin technique, motivée par ma petite déception :/
Je voulais me lancer corps et bien dans Docker, adopter de bonnes pratiques et arrêter de lire de la doc et des articles de blog divers et variés sur écran. Je voulais acheter un bouquin en librairie, je n'ai donc pas eu masse de choix et j'ai acheté celui-ci: https://www.placedeslibraires.fr/livre/9782409009372-docker-deploiement-de-microservices-sous-linux-ou-windows-docker-swarm-docker-compose-docker-machine-jean-philippe-gouigo/ aux éditions Eni.

Je suis un développeur web "full-stack", avec des applis actuelles en Python-Django-Node.js, et je trouve que c'est trop une gageure à déployer. Ah, ces langages qui compilent en un exécutable portable… J'ai déjà utilisé Docker pour lancer des conteneurs simples, développé à partir d'un environnement Docker qu'on m'a donné, et écrit des Dockerfile plus ou moins fonctionnels. Je sentais que je perds trop de temps à re-compiler tout le machin au moindre changement de fichier, je n'ai pas de bonne pratique pour construire une image python&node.js, je n'ai pas utilisé Docker-compose, bref je voulais avoir une meilleure vision du tout et apprendre sur des bases saines. Malheureusement je trouve que ce livre n'est pas pour moi.

Le livre fait 450 pages. Le contenu intéressant commence à la 180e, "Notre premier Dockerfile", et encore ça reste simple.
On a une bonne intro pour remettre Docker en contexte.
Le chapitre 2, "premiers pas", est exaspérant car c'est pour les noObs, et on a des captures d'écran de comment chercher des images sur Microsoft Azure… oui, l'auteur est certifié Microsoft. On a sur une pleine page une capture d'écran de Putty, encore une capture d'un message qui demande à accepter la clef rsa… plus tard encore, on aura des captures d'écran de l'auteur qui tape un mot de passe, une capture de la page d'accueil du Docker store,…
À la page 130 on aura vu docker run -t -i et quelques commandes de base.

La 4e de couverture dit qu'on verra des "astuces de déploiement de conteneurs pour Java, .NET, Python et Node.js", mais évidemment les exemples sont triviaux. L'application Python est un simple fichier Flask, sans dépendances JS. Je pense qu'il me fallait mieux noter le sous-titre du livre: "sur une architecture micro-services", comme si le public était des admin sys qui doivent manipuler des images, mais pas des développeurs.
Notez que pour ces applications simples, on a droit au copier-coller et à l'explication sur une dizaine de pages du code Java, du code .NET, du code Angular.js, ce que je trouve inutile (surtout que les sources sont fournies sur un github).

Chapitre 4: 70 pages sur l'installation d'un registre privé et inscription sur le Docker Hub privé, avec moults captures d'écran (valider une "connexion non certifiée" sous Firefox…) et configuration Nginx. Ce n'est pas ce que je cherchais.

C'est dans l'avant-dernier chapitre qu'on parlera de persistance de données, de volumes, etc. J'appris des choses, mais vous savez ma frustration de ne pas avoir vu de cas d'usage plus réaliste pour un développeur web.

Si vous êtes sur Toulouse je peux vous le prêter, vous le vendre en € ou en monnaie-libre G1.

Vous me recommanderiez un autre livre ? Peut-il même exister un bon livre Docker, devant l'évolution rapide de l'écosystème ? Merci.

# the dockerbook est pas mal

Posté par palm123 (site web personnel) le 27 octobre 2018 à 17:52. Évalué à 8.

https://dockerbook.com/

avec des mises à jour régulières

mais ce projet évolue constamment

Un support docker auprès de "moustachus" serait peut-être plus adapté pour toi.

ウィズコロナ
- [^] # Re: the dockerbook est pas mal
  
  Posté par Philippe M (site web personnel) le 29 octobre 2018 à 09:48. Évalué à 1.
  
  Pas mal le ebook, manquerait plus qu'une traduction en français ;)
  
  Un moustachus littéraire dans l'assistance ? ;)
  
  Born to Kill EndUser !
- [^] # Re: the dockerbook est pas mal
  
  Posté par damaki le 29 octobre 2018 à 11:36. Évalué à 2.
  
  J'espère que leur "Updated for Docker 1.13." n'est qu'une erreur, parce qu'il s'est passé un gros paquet de trucs depuis cette version. Et les bonnes pratiques ont beaucoup changé (Dockerfile multi stage, par exemple).
# Taxe sur les GUI

Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 27 octobre 2018 à 18:13. Évalué à 10.

Quand on parle de gazole à 10€ le litre, est-ce que quelqu'un a pensé à une taxe écologique sur les logiciels sans interface en ligne de commande ? C'est fou le nombre de livres d'informatique où des pages entières de captures d'écrans sont désormais nécessaire là où quelques caractères suffisaient amplement autrefois.

Je sais on n'est plus vendredi…

« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: Taxe sur les GUI
  
  Posté par Michaël (site web personnel) le 28 octobre 2018 à 00:00. Évalué à 7.
  
  C'est fou le nombre de livres d'informatique où des pages entières de captures d'écrans sont désormais nécessaire là où quelques caractères suffisaient amplement autrefois.
  
  Dans mon ancienne entreprise mon chef s'éclatait à essayer des logiciels pour représenter “rôles” et ”ownerships” dans l'entreprise… vu qu'on était 25 employés et qu'ils n'ont recruté personne depuis un an et demi, ça aurait été torché en 14 minutes en faisant un dessin à la main.
# Python-Django-Node.js?

Posté par devnewton 🍺 (site web personnel) le 27 octobre 2018 à 19:49. Évalué à 3.

Que fait Node.js là dedans?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Python-Django-Node.js?
  
  Posté par Ludo le 27 octobre 2018 à 20:25. Évalué à 3.
  
  Peut-être pour des fonctionnalités que tu n'as pas de base dans Django ?
  Genre le WebSockets ou le SSR ?
# Merci pour ta critique du livre

Posté par Michaël (site web personnel) le 28 octobre 2018 à 00:32. Évalué à 8.
À la page 130 on aura vu docker run -t -i et quelques commandes de base.

C'est une prise en main bien tardive… ;)

C'est dans l'avant-dernier chapitre qu'on parlera de persistance de données, de volumes, etc. J'appris des choses, mais vous savez ma frustration de ne pas avoir vu de cas d'usage plus réaliste pour un développeur web.

Mon expérience pour ton cas est qu'il vaut largement mieux “se faire son expérience soi-même” car la plupart des sources que j'ai eues sous les yeux ne sont pas terribles.

Les problèmes récurrents que l'on repère dans les exemples facilement accessibles sont:
- Un mauvais usage du cache. – Cela produit des temps de compilation trop long.
- Un trop grand nombre de layers produits. – Cela ralentit les opérations push, pull et create.
- Une trop grande dépendance à des ressources en lignes. – Chaque source différente augmente le risque qu'on ne puisse déployer à un moment critique à cause d'une ressource indisponible.
Je sentais que je perds trop de temps à re-compiler tout le machin au moindre changement de fichier, je n'ai pas de bonne pratique pour construire une image python&node.js

C'est un problème assez difficile, j'ai à propos d'un autre problème rédigé quelques conseils pour améliorer ses Dockerfiles.

Dans le cas d'une application node.js ces conseils se résument en gros à dire que la fin du Dockerfile doit ressembler à:
```
ADD src/package.json /opt/my-project/var/src/my-package/package.json
RUN cd /opt/my-project/var/src/my-package\
 && yarn install
ADD src/. /opt/my-project/var/src/my-package/
RUN cd /opt/my-project/var/src/my-package\
 && yarn build
```
ou un truc du genre qui sépare bien l'installation des dépendances de la préparation du fichier JavaScript final.

Mais ceci dit il n'y a aucune bonne raison pour que l'environnement de développement utilise les mêmes images que l'environnement de test ou de production. C'est parfaitement légitime d'utiliser un environnement spécifiquement destiné au développement qui favorise une boucle de développement rapide quitte à prendre quelques raccourcis.

Un autre point très important est qu'il est absolument nécessaire d'écrire des petits scripts qui implémentent les “verbes” du développement. De bons candidats sont “reconstruire toutes les images” ou bien ”ouvrir un shell root dans un container pour voir ce qui s'y passe” etc.
# Suggestion

Posté par olivierrouge le 28 octobre 2018 à 10:35. Évalué à 3.

Salut,

Tu as regardé du côté de chez O'Reilly ?

Il y a une première édition "Docker: Up & Running" datant de 2015 et une deuxième édition du même nom sortie en septembre 2018.
- [^] # Re: Suggestion
  
  Posté par dzecniv le 29 octobre 2018 à 16:05. Évalué à 2.
  
  Justement non, j'avais pris le pari d'acheter un livre en librairie près de chez moi.
# L'enfer de la doc docker et des bonnes pratiques

Posté par damaki le 29 octobre 2018 à 11:47. Évalué à 7.

Etant en train de passer mes servers persos à Docker, et avec un objectif de faire ça proprement et sans Kubernetes (parce que c'est de l'overkill si t'es pas une entreprise), effectivement la doc et les tutos Docker, il y a un cercle de l'enfer pour ça.
La doc officielle est pas mal, mais elle est totalement insuffisante pour faire des déploiements dans la vraie vie, et elle suggère de vraies mauvaises pratiques (auto-restart, je te regarde). Je rêve d'une doc qui t'explique de façon centralisée :
- comment faire des Dockerfile en respectant les bonnes pratiques
- comment tester des Dockerfile en local sans avoir trop d'écart avec ta prod
- comment écrire des unit systemd pour démarrer les containers, avec gestion des dépendances entre containers sur une même machine
- comment scripter le déploiement et la mise à jour de containers sur un petit lot de serveurs, proprement
- bonnes et mauvaises pratiques d'administration système avec Docker sur une petite install (moins de 5 serveurs)
- comment bien utiliser les volumes dockers et les différents plugins dispos, ainsi que les contexes d'utilisation
- comment déployer un registry docker privé et pourquoi
- comment et pourquoi migrer d'une install serveur par serveur vers une install distribuée à la Kubernetes, Swarm, Nomad et compagnie.

Pratiquement toutes les docs que j'ai pu voir donnent l'impression d'être écrites par ou pour des devs et non pas des administrateurs système ce qui les rend difficiles à utiliser pour un vrai déploiement.
- [^] # Re: L'enfer de la doc docker et des bonnes pratiques
  
  Posté par CrEv (site web personnel) le 30 octobre 2018 à 14:20. Évalué à 5.
  La doc officielle est pas mal, mais elle est totalement insuffisante pour faire des déploiements dans la vraie vie
  
  C'est en partie parce que docker n'est que la partie conteneur, pas orchestration (si on oublie swarm). Donc forcément tu n'aura pas les infos sur tout.
  - comment faire des Dockerfile en respectant les bonnes pratiques
  Pour ça, j'utilise principalement deux techniques:
  - utiliser des linter sur Dockerfile (genre hadolint mais il y en a d'autres) : ça ne va pas te présenter les bonnes pratiques mais tu pourra au moins valider ce que tu écris (et tu peux aller voir tout la liste des règles)
  - lire les Dockerfile d'autres personnes, par exemple ceux de Jessie Frazelle mais il y en a plein d'autres
  - comment tester des Dockerfile en local sans avoir trop d'écart avec ta prod
  Tout dépend ce que tu veux tester vraiment.
  Pour ce qui est des images en elles-même, tu peux chercher du côté de Container Structure Test par exemple.
  Ensuite, je sais pas bien ce que c'est "tester des Dockerfile". Si ton conteneur contient toute ton app, ben tu testes en prod comme ailleurs. Si la question c'est comment tester une application composée de plusieurs services (sous forme de docker) s'en est une toute autre et la réponse peut être beaucoup plus complexe (docker ou non d'ailleurs).
  - comment écrire des unit systemd pour démarrer les containers, avec gestion des dépendances entre containers sur une même machine
  Ok, donc ça s'est purement systemd, que ce soit des containers ou non ne devrait pas changer grand chose. Je ne sais pas si on trouve de la doc dessus facilement. Je limite au max les units systemd que j'écris, et j'utilise un orchestrateur pour le reste. Et j'évite qu'il y ait des dépendances entre les conteneurs, que chaque service puisse démarrer sans que les autres soient disponible.
  - comment scripter le déploiement et la mise à jour de containers sur un petit lot de serveurs, proprement
  Je dirais, ne pas le faire.
  Les orchestrateurs sont là pour ça. Et nomad c'est bien.
  - bonnes et mauvaises pratiques d'administration système avec Docker sur une petite install (moins de 5 serveurs)
  On parle de docker ou d'orchestration de conteneurs ? (et donc k8s, nomad, mesos, swarm)
- [^] # Re: L'enfer de la doc docker et des bonnes pratiques
  
  Posté par Jarvis le 30 octobre 2018 à 18:13. Évalué à 2. Dernière modification le 30 octobre 2018 à 18:13.
  - comment scripter le déploiement et la mise à jour de containers sur un petit lot de serveurs, proprement
  Ansible, puppet, chef?
- [^] # Re: L'enfer de la doc docker et des bonnes pratiques
  
  Posté par Jarvis le 30 octobre 2018 à 18:19. Évalué à 2.
  - comment écrire des unit systemd pour démarrer les containers, avec gestion des dépendances entre containers sur une même machine
  Le Docker Compose gère les dépendances :
  https://docs.docker.com/compose/overview/
# Commentaire supprimé

Posté par carlos.duvrait le 30 octobre 2018 à 18:42. Évalué à -2. Dernière modification le 30 octobre 2018 à 19:22.

Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.