À 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.
# Merci pour ta critique du livre
Posté par Michaël (site web personnel) . En réponse au journal Revue de livre: Docker, prise en main et mise en pratique sur une architecture micro-services. Évalué à 8.
C'est une prise en main bien tardive... ;)
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.
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 à:
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.