Bonjour à tous,

Effectivement la discussion part dans toutes les directions qui devraient converger mais qui ne le font pas.

Reprenons dans l'ordre. Pour commencer à connaître l'état de machines il faut connaître les machines. Je n'ai pas encore trouvé d'outil simple d'inventaire dynamique qui me permette de connaître les machines et de pondre un inventory ansible en fonction de mes besoins.
Collins semble faire le job mais c'est un outil Java qui consomme 800M de Ram à vide, ce qui est inacceptable pour un outil d'inventaire qui ne devrait pas, pour 1000 machines, gérer plus de 2 ou 3M de données texte.

Ensuite les mises à jour. J'ai testé Landscape et c'est à peu près exactement ce qu'il faudrait sans le crap marketing Canonical. Un contournement pourrait être :
- Mes serveurs n'ont qu'une seule entrée sources.list (ou équivalent yum/...) vers un repo que j'héberge.
- Une MAJ est détectée, je spawne mes environnements de prod en test, je MAJ, je run tous mes tests unitaires, fonctionnels, ... Si ça passe, je met à jour mon repo de prod.
- En cron ou manuellement, tous mes serveurs de prod peuvent upgrade car c'est testé.
Ainsi si c'est bien fait, j'enlève même l'intervention humaine des mises à jour de mon parc de prod :)

Pour le pilotage des serveurs, rundeck m'a vendu du rêve. Faire du libre-service de scripts est une très bonne idée. Je peux écrire des scripts et en donner accès aux devs, qui les exécutent en un clic sur leurs envs. Enfin sur le papier, car j'utilise Ansible et c'est pas encore très sec, il faut wrapper ansible dans des scripts shell et utiliser l'inventaire issu de Collins. Rundeck est en Java et consomme quasiment 1G de ram à vide. Encore une fois inacceptable.

Le sujet du déploiement d'une stack from scratch est intéressant. Je connais des admins par exemple qui utilisent ansible pour installer et conf puppet-agent sur leurs machines fraîches :)
J'utilise Vagrant pour mes VM de test et de plus en plus de prod (Digital ocean, AWS). Il n'a pas de plugin pour déployer en Bare Metal, mais peut-être qu'en passant par un intermédiaire qui fasse du PXE/... unifié derrière une API ça marcherait (je vais tester MAAS de Canonical qui, encore une fois sur le papier, vend du rêve :) )

Très interessé par vos réponses !

++

2015-08-21 15:06 GMT+02:00 Alexis Lameire <alexis.lameire@gmail.com>:
En pratique, c'est pas quelque chose qui me choque.

J'ai pu en discuter sur #frsag hier, mais on tourne ici sur le sujet des accords de confidentialités et du devoir de réserve. Il est bien souvent difficile d'avoir une vision de ce que tu peut et ce que tu ne peut pas dire sur ton boulot. Au moins avec ce genre de structure tu sait clairement où t’arrêter que ça soit niveau comm verbale ou utilisation des services numérique de ta boite.

C'est une protection pour l'employeur et le salarié à mon sens. Dans un autre domaine je ne saurais que trop vous rappeler l'affaire Alten

Alexis
PS : on est pas mal en train de dévier du sujet initial, peut  être devrions nous changer le titre du topic

Le 21 août 2015 15:01, Simon Morvan <garphy@zone84.net> a écrit :
On 21/08/2015 13:40, Xavier Beaudouin wrote:
>> On 21/08/2015 12:17, Xavier Beaudouin wrote:
>>> >> Il y avais même^H^H^H^Htroll sur le net vis a vis de la position de Octave vis a
>>> >> vis de ses employés et github...
>> > Vis-à-vis de tout ce qui n'est pas hosté en interne, notamment les
>> > emails corporate.
> Enfin faut quand même avoir pas confiance en ses équipes infra si on est hébergeur de mail (entre autres) et qu'on utilise pas l'infra vendue pour les mails corpo (ou tout du moins une partie de l'infra)...
C'était plutôt dans le sens : si tu forwardes tes mails pro vers ton
Gmail perso, tu perds des doigts...

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/


_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/




--
// Damien Michaudet
# Libre systems engineer @ inovia.fr | 42.mg
// +33 (0)6 76 74 46 50