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

Posté par . Licence CC by-sa.
Tags :
19
27
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 (page perso) . É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.

    My father was a Brexit negotiator and his father before him

    • [^] # Re: the dockerbook est pas mal

      Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 3.

    Que fait Node.js là dedans?

    Incubez l'excellence sur https://linuxfr.org/board/

  • # Merci pour ta critique du livre

    Posté par . É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 . É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 . É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 . É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 (page perso) . É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 . Évalué à 2. Dernière modification le 30/10/18 à 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 . É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 . Évalué à -2. Dernière modification le 30/10/18 à 19:22.

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

Suivre le flux des commentaires

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