Bonjour,

Il n'y a pas de miracle, les automatismes font ce que tu leur demande, si tu ajoutes une notion variable en amont il faut un traitement en amont pour gérer cela.

Pour parler d'Ansible que je recommande vivement pour plein de très bonne raisons, tu as Ansible Tower et son fork libre qui permet de donner la main à des équipes pour déployer une plateforme iso prod sur en dev ou testing très facilement par exemple.

Pour les cas complexe, soit faut faire à la main soit faut coder ce qu'il manque. Je préfère standardiser le nom des serveurs (le client n'a pas à décider du nom du serveur si c'est toi qui le gère), installer les proxy ou autre éléments de la même façon tout en laissant du côté du code la possibilité de faire tous les cas concrets possibles.

L'avantage c'est standardisé, n'importe quel ingé qui passe sur un serveur sait où se trouve les éléments qu'il cherche, c'est fluide pour le client, gain de temps pour les équipes. Mais surtout si tu dois ajouter du hardening, changer une configuration en prévision d'une mise à jour, tu peux l'appliquer à toutes tes instances au même endroit.

Donc de mon point de vue, si on structure en automatisation on structure forcément en archi, la brique au dessus qui me parait normale c'est ton propre SI avec API et là forcément c'est à faire sur mesure en fonction de vos choix.

Chez nous, le nom du serveur est codifié en partie par son nom d'entreprise, après une partie variable que les ingénieurs fixent en fonction du rôle du serveur, ça donne un fqdn unique qu'on entre dans une base et de là tout en découle par des automatismes codés en interne (supervision, déploiement vm / dédié, ansible qui fait les configurations, ...). Il nous reste à faire la partie plus bas niveau, créer tel compte avec ces contraintes et stocker les mots de passe générés dans une banque de mot de passe. Cela pour libérer plus de temps bas niveau inutile car sans valeur ajoutée pour le client et se concentrer sur l'accompagnement et la capacité à rapidement changer un même paramètre chez tous nos clients en 10 sec si y a une faiblesse découverte par exemple.

Le 18/04/2017 à 20:18, Alexis Lameire a écrit :

Bonjour,

Dans nos infra qu'il s'agisse de système ou de réseau l'automatisation s'imisse de plus en plus. Aujourd’hui nous avons une quantité d'outils non négligeable pour automatisé les infras : Puppet, chef et ansible sont je pense les 3 outils les plus utilisé pour arrivé à son but.

Je ne cherche pas une réponse absolue ici sur lequel de ces outils est le meilleur, par ce qu'à mon sens cela dépend beaucoup de l'entreprise, de l'interlocuteur et du besoin final ; néanmoins un besoin reste : une fois l'automatisation réalisé, comment transférer l’outil aux équipes de productions ?

Prenons un cas simple pour l'illustration, je veux fournir à un client un hébergement web dédier sur une VM. Les outils de gestion de conf vont me permettre :

* de déployer la VM

* de configurer le système avec les politique de sécurité

* d'installer le serveur web, ftp, ... et de les maintenir à jour

* d'appliquer la configuration réseau

* de mettre en place les scripts de supervision sur l'host

Mais il reste un certains nombre de questions, en particulier quand on est en phase de transition vers un SI qui prend en charge la configuration :

* quel nom à la VM je donne => c'est une informations dépendante du client

* quel est son ip publique ?

* il y a t'il du reverse proxy ? combien ? sur quel domaine ?

* quel login pour les FTP/DB/THTTP ?

dès lors on a besoin :

- dans un premier temps d'une solution permettant la saisie facile dans des formulaire sans gros développement qui font appel aux outils backend (puppet/ansible/checf)

- dans un second temps, la possibilité de requêter les outils facilement par des api pour l'intégration avec un SI grandissant

Dès lors, quel outils permet de répondre à ce besoin ?

Cordialement

Alexis Lameire

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