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.
[^] # 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.