En informatique, ce qui prime plus que le code ce sont les données manipulées. C'est cela qui a de la valeur pour les usagers.
Je ne suis pas sûr que les algo sur les transactions faite par ma banque pour gérer mon compte soient très compliqués… Ce qui prime ici, c'est le droit (la confidentialité). Ce qui compte pour le profilage des utilisateurs, c'est pas le droit (il est donné par l'utilisateur) mais la c'est la donnée. En plus il y en a et plus le profilage est pertinent. Ce qui compte pour la compression (avec ou sens perte), c'est par le droit, ni même la donnée… C'est l'algo.
Bref, ce qui prime c'est le droit/confidentialité ou la donnée ou l'algo (en fonction du contexte).
Est-ce que le processus qui tourne dans le conteneur est le PID 1 ? Si oui, je suppose qu’il est possible de lancer systemd ?
L'objectif de Docker est justement de ne pas lancer init ou systemd mais on peut toujours le faire.
En fait ma question est plus : si on suppose que mon application est un service PHP/nginx/postgres, est-ce que je dois distribuer trois conteneurs (myapp-phpfpm, myapp-postgres, myapp-nginx) ou un seul myapp ?
Un seul conteneur ! Sauf si l'on veut donner de l'indépendance entre les services (Web/App/DB).
Docker est une couche de LXC, il est donc possible d'attribuer un nombre de CPU, de mémoire, d'I/O ou d'espace disque (tout ce que peut faire cgroup).
Une seule image permet de pouvoir le multiplier par la suite avec exactement les mêmes processus à l'intérieur.
Il manque une chose importante de la philosophie Docker : il n'y a pas d'interface réseau visible de l'extérieur mais uniquement des ports bindés explicitement depuis l'hôte. Ce qui est déroutant au début ;-)
Docker utilise son propre bridge réseau (que l'on peut lier sur plusieurs machines avec vSwitch) et dans lequel on peut attribuer des IP (statiquement ou par DHCP).
Est-ce que ce n’est pas un peu opposé à l’idée « déploiement en une commande » ?
C'est l'objectif que je vois dans Docker. Une commande pour une application. Le fait qu'elle soit « découper » (ce que je préconise) permet simplement de « bien » penser son système en délimitant chaque chose. La sauvegarde des données ne se fait pas de la même façon que la configuration (qui est dans un gestionnaire de version).
Cependant, il manque dans Docker un environnement de lancement des conteneurs (l'attribution de certains paramètres, des montages externes, des interdépences entre service…).
Pour le moment, cette partie est à gérer à la main (ou avec des outils d'orchestration…)
Pour reprendre sur PHP/nginx/postgres. Ce que l'on veut c'est configurer le conteneur pour avoir un site fonctionnelle « out of the box » avec les paramètres de NGinx, PHP et Postgres aux petits oignons. Ensuite l'exécution de ce container ce fait avec une base de données que j'hébergerai sur l'hôte (en lien des répertoires). Ainsi lorsqu'il y aura des mises à jour, on rejoue le Dockerfile, on copie la BD dans un autre répertoire (pour éviter les bêtises) et on lance ce nouveau container pour tester que tout marche bien.
Rapide et précis : « déploiement d'application » !
Pour faire très court (et pas très cours) :
Il y a des années, un programme (en stand-alone) se découpait en : binaire, données, configuration et log.
L'objectif de Docker est de mettre cette approche dans des services. Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs.
Les commandes exécutées dans le containers doivent tourner au premier plan, si l'application se termine alors le conteneur se terminé (il y a des moyens de lancer des applications en arrière plan avec Supervisord, par exemple). Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)
L'autre avantage de Docker est le versionnage des images disques : chaque commande effectuée dans un container crée une nouvelle image. La création d'un service est donc très rapide car on peut repartir d'une image dont la configuration était adéquate.
Il faut repenser le design de son services dans ce sens, sinon cela reste de la virtuallisation.
« Quand on a un marteau, on voit tout les problèmes comme des clous »
[^] # Re: La classique erreur de comparer matériel et immatériel...
Posté par CogitIO . En réponse au journal Est-ce que RMS raconte "des idioties basées sur des prémisses qui n'ont plus cours" ?. Évalué à 1.
Je ne suis pas sûr que les algo sur les transactions faite par ma banque pour gérer mon compte soient très compliqués… Ce qui prime ici, c'est le droit (la confidentialité). Ce qui compte pour le profilage des utilisateurs, c'est pas le droit (il est donné par l'utilisateur) mais la c'est la donnée. En plus il y en a et plus le profilage est pertinent. Ce qui compte pour la compression (avec ou sens perte), c'est par le droit, ni même la donnée… C'est l'algo.
Bref, ce qui prime c'est le droit/confidentialité ou la donnée ou l'algo (en fonction du contexte).
[^] # Re: Souligner APPLICATION et minimiser le mot virtualisation
Posté par CogitIO . En réponse à la dépêche Gérer les containers avec Docker. Évalué à 4.
L'objectif de Docker est justement de ne pas lancer init ou systemd mais on peut toujours le faire.
Un seul conteneur ! Sauf si l'on veut donner de l'indépendance entre les services (Web/App/DB).
Docker est une couche de LXC, il est donc possible d'attribuer un nombre de CPU, de mémoire, d'I/O ou d'espace disque (tout ce que peut faire cgroup).
Une seule image permet de pouvoir le multiplier par la suite avec exactement les mêmes processus à l'intérieur.
Il manque une chose importante de la philosophie Docker : il n'y a pas d'interface réseau visible de l'extérieur mais uniquement des ports bindés explicitement depuis l'hôte. Ce qui est déroutant au début ;-)
Docker utilise son propre bridge réseau (que l'on peut lier sur plusieurs machines avec vSwitch) et dans lequel on peut attribuer des IP (statiquement ou par DHCP).
C'est l'objectif que je vois dans Docker. Une commande pour une application. Le fait qu'elle soit « découper » (ce que je préconise) permet simplement de « bien » penser son système en délimitant chaque chose. La sauvegarde des données ne se fait pas de la même façon que la configuration (qui est dans un gestionnaire de version).
Cependant, il manque dans Docker un environnement de lancement des conteneurs (l'attribution de certains paramètres, des montages externes, des interdépences entre service…).
Pour le moment, cette partie est à gérer à la main (ou avec des outils d'orchestration…)
Pour reprendre sur PHP/nginx/postgres. Ce que l'on veut c'est configurer le conteneur pour avoir un site fonctionnelle « out of the box » avec les paramètres de NGinx, PHP et Postgres aux petits oignons. Ensuite l'exécution de ce container ce fait avec une base de données que j'hébergerai sur l'hôte (en lien des répertoires). Ainsi lorsqu'il y aura des mises à jour, on rejoue le Dockerfile, on copie la BD dans un autre répertoire (pour éviter les bêtises) et on lance ce nouveau container pour tester que tout marche bien.
# Souligner APPLICATION et minimiser le mot virtualisation
Posté par CogitIO . En réponse à la dépêche Gérer les containers avec Docker. Évalué à 10.
Rapide et précis : « déploiement d'application » !
Pour faire très court (et pas très cours) :
Il y a des années, un programme (en stand-alone) se découpait en : binaire, données, configuration et log.
L'objectif de Docker est de mettre cette approche dans des services. Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs.
Les commandes exécutées dans le containers doivent tourner au premier plan, si l'application se termine alors le conteneur se terminé (il y a des moyens de lancer des applications en arrière plan avec Supervisord, par exemple). Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)
L'autre avantage de Docker est le versionnage des images disques : chaque commande effectuée dans un container crée une nouvelle image. La création d'un service est donc très rapide car on peut repartir d'une image dont la configuration était adéquate.
Il faut repenser le design de son services dans ce sens, sinon cela reste de la virtuallisation.
« Quand on a un marteau, on voit tout les problèmes comme des clous »