> - Pour les mises à jour de tes conteneurs ("aptitute update && etc"), tu as développé des scripts pour automatiser tout cela ?
"cron-apt", en personnalisant un peu les fichiers pour utiliser "aptitude" au lieu de "apt", et faire un petit "autoclean", pour éviter de surcharger le "/var" ; les paquets à mettre à jour sont donc automatiquement sur la machine virtuelle (bon, en même temps, pour l'instant, il n'y a qu'une machine physique OpenVZ, donc, même en direct, ça va de disque dur à disque dur, même si seul l'hôte en a "conscience" ; l'arbre partiel est monté sur lui, sur une partition dédiée, puis "bind-mounté" en "rw" dans le conteneur "approx") : plus qu'un "safe-upgrade" voire un "full-upgrade" à faire (ça, par contre, j'aime bien faire à la main ; quoique j'investigue pour faire ça via des triggers, manuels mais centralisés, dans Puppet, pour ne pas avoir à ouvrir 36000 shells via SSH - bon, à la limite, ce qui vient de security.debian.org, je pourrais le faire passer automatiquement via "cron-apt", mais même ça, je me méfie).
Il ne m'envoie pas encore de mail, puisque j'attends que le bug sur le noyau 2.6.26-8 dont je parle soit corrigé dans Lenny (par flemme de mettre celui qui est déjà dans Sid), pour m'occuper de leur gestion ; mais c'est prévu et a déjà été testé (probablement "exim-daemon-light" dans les conteneurs, ainsi qu'un "exim-daemon-heavy" et un "dovecot-imapd", centraux).
> Tu as des conteneurs qui font tourner des services très simples, comme par exemple NTPD. Quelle est la taille approximative sur le disque dur que cela prend ?
Pour le conteneur NTP (le "gros" "ntp", pas "openntpd"), par exemple :
$ du -h
...
270M /
après un debootstrap sans rien de particulier, soit seulement les paquets tagués "essential", soit ce que donne un "aptitude search ~prequired ~pimportant" (quelques uns, comme module-init-tools, sont superflus dans un conteneur), mais pas les "~pstandard" (de ceux-là, je ne fais pour l'instant venir que "openssh-client", "locales", "less" et "bash-completion" ; un petit "mutt" et un "exim4-daemon-light" ne seraient peut-être pas complètement idiots) ; et bien sûr ntp, ainsi que deux ou trois machins propres à mes habitudes d'administration (sudo, puppet, apt-show-version, ...).
C'est cela dit peu ou prou le minimum : le serveur chrooted-SFTP, qui doit vraiment être mon plus petit, hors "bind-mounts", fait 269Mio. Vu que je peux faire tourner une cinquantaine de machines de 48Mo de RAM (le minimum, arbitraire et empirique, bien que largement confortable, que je mette... bon, c'est une base : pour les trucs comme MLDonkey ou Tor, je n'hésite pas à mettre 240Mo ou 120Mo), avec mes 3Go de RAM (2,5Go dispatchés dans les "oomguardpages"), avec un "/var/lib/vz" d'environ 200Gio (4Gio par conteneur), niveau espace disque, je suis très-très-très large.
[^] # Re: Très bon retour d'experience
Posté par Aefron . En réponse au journal Debian, VServer & OpenVZ : les conteneurs. Évalué à 2.
"cron-apt", en personnalisant un peu les fichiers pour utiliser "aptitude" au lieu de "apt", et faire un petit "autoclean", pour éviter de surcharger le "/var" ; les paquets à mettre à jour sont donc automatiquement sur la machine virtuelle (bon, en même temps, pour l'instant, il n'y a qu'une machine physique OpenVZ, donc, même en direct, ça va de disque dur à disque dur, même si seul l'hôte en a "conscience" ; l'arbre partiel est monté sur lui, sur une partition dédiée, puis "bind-mounté" en "rw" dans le conteneur "approx") : plus qu'un "safe-upgrade" voire un "full-upgrade" à faire (ça, par contre, j'aime bien faire à la main ; quoique j'investigue pour faire ça via des triggers, manuels mais centralisés, dans Puppet, pour ne pas avoir à ouvrir 36000 shells via SSH - bon, à la limite, ce qui vient de security.debian.org, je pourrais le faire passer automatiquement via "cron-apt", mais même ça, je me méfie).
Il ne m'envoie pas encore de mail, puisque j'attends que le bug sur le noyau 2.6.26-8 dont je parle soit corrigé dans Lenny (par flemme de mettre celui qui est déjà dans Sid), pour m'occuper de leur gestion ; mais c'est prévu et a déjà été testé (probablement "exim-daemon-light" dans les conteneurs, ainsi qu'un "exim-daemon-heavy" et un "dovecot-imapd", centraux).
> Tu as des conteneurs qui font tourner des services très simples, comme par exemple NTPD. Quelle est la taille approximative sur le disque dur que cela prend ?
Pour le conteneur NTP (le "gros" "ntp", pas "openntpd"), par exemple :
$ du -h...
270M /
après un debootstrap sans rien de particulier, soit seulement les paquets tagués "essential", soit ce que donne un "aptitude search ~prequired ~pimportant" (quelques uns, comme module-init-tools, sont superflus dans un conteneur), mais pas les "~pstandard" (de ceux-là, je ne fais pour l'instant venir que "openssh-client", "locales", "less" et "bash-completion" ; un petit "mutt" et un "exim4-daemon-light" ne seraient peut-être pas complètement idiots) ; et bien sûr ntp, ainsi que deux ou trois machins propres à mes habitudes d'administration (sudo, puppet, apt-show-version, ...).
C'est cela dit peu ou prou le minimum : le serveur chrooted-SFTP, qui doit vraiment être mon plus petit, hors "bind-mounts", fait 269Mio. Vu que je peux faire tourner une cinquantaine de machines de 48Mo de RAM (le minimum, arbitraire et empirique, bien que largement confortable, que je mette... bon, c'est une base : pour les trucs comme MLDonkey ou Tor, je n'hésite pas à mettre 240Mo ou 120Mo), avec mes 3Go de RAM (2,5Go dispatchés dans les "oomguardpages"), avec un "/var/lib/vz" d'environ 200Gio (4Gio par conteneur), niveau espace disque, je suis très-très-très large.