Hello,
Chez le client chez qui je bosse et qui a eu le même besoin, tout a été fait comme décrit par Ruben il y a quelques années (dev interne pour à peu près tout ça). Depuis un an c'est HP CSA qui fait le taff en terme de GUI, sur la base de ce dev maison.
D'ici quelques mois, ce devrait être la mission de terraform piloté encore par HP CSA (ce dernier est gardé car il ne pilote pas que le provi des machines).
En terme d'usage provisionning - Linux (Bare Metal, VMWare, AWS EC2, Openstack) - Windows (VMWare, AWS EC2) - AIX (PowerVM)
Pour la gestion de conf, on a du puppet / Foreman avec le code dans du gitlab / jenkins et autres trucs à la mode.
Alors pourquoi pas de Foreman pour le provi ? Parce qu'il ne gère pas AIX (en tout cas, pas à ma connaissance) et surtout parce que la philosophie HP CSA a collé au dév interne, alors qu'il fallait tout réinventer avec Foreman.
Je suis pas vraiment au milieu du machin mais je peux aller à la pêche aux infos si besoin,
Bonne chance pour la suite,
Le mar. 18 avr. 2017 à 22:29, Ruben Alves gadept@gmail.com a écrit :
Salut,
Ayant eu exactement le même besoin il y a un peu plus d'un an, je me suis lancé dans l'aventure folle de coder un orchestrator complet en utilisant Python et deux couches techniques principales:
- pyvmomi -> pour tacler l'API VMWARE (creation des resources virtuelles,
cartes reseaux, disques venant des datastores etc...)
- Ansible -> pour tout ce qui est provisioning de la machine Linux ou
Windows (CentOS 6 et 7 / Windows 2008,2012)
Voila comment ca marche:
- declaration d'un nouveau serveur sur Infoblox (IPAM)
--> creation automatique du nom de serveur --> recuperation de l'adresse IP finale du serveur --> enregistrement du nom du serveur + IP dans l'IPAM 2) Creation de l'enveloppe de la VM (avec pyvmomi) --> selection du datastore --> creation des disques --> CPU, RAM etc... 3) Boot de la VM avec une {ISO Linux et un kickstart | ISO windows}" permettant l'install de l'OS automatiquement (avec pyvmomi) 4) modification de la VM, changement du network dans son VLAN de production (avec pyvmomi) 5) Taches de post-install (ssh, RDP, backup, users, password etc..) - le tout sous Ansible + powershell pour les serveurs windows 6) Deploy des applications (avec Ansible) ---> pour le monde Linux: Apache + PHP, nginx, MariaDB, SFTP over ssh, wordpress, docker, gnome etc... p ---> pour le monde windows: IIS / SQL Server etc...
C'etait un peu de taf de coding python, mais a la fin c'etait plutot pas mal, sexy, rapide et stable.
Effectivement il y a des solutions de provisioning (vRealize de VMARE, HP CSA etc...) seul soucis:
- manque de flexibilité
- le temps d'apprentissage et de maitrise des outils est souvent supérieur
au développement d'un "outil maison"
- prix a l'achat, integration + license par VM déployée
- dette technologique lié à l'investissement qui doit être rentabilisé sur
plusieurs années et jail technique (pour les outils HP, le résultat final est que tout reste très HP centric)
Seul bémol d'un outil fait maison:
- un outil comme ça doit être crée par une initiative globale de ta boite,
documenté et le tout sous GIT, sinon, il risque de mourir si tu te barres.
Voila mes 2 cents!
Bon courage
2017-04-18 21:45 GMT+02:00 Alexis Lameire alexis.lameire@gmail.com:
Hello, Sauf à faire faire des query dans ta CMDB/SI par tes scripts, tu as toujours un bout de variable, tu t’arrange pour qu'il soit le plus petit possible (c'est le but de l'automatisation, et ça permet d'assurer entre autre les conventions de nommage).
Le vrais besoin ici est d'un outils qui se pose autre le SI et l'infra, qui sont souvent gérer par deux entité différente.
@cyril : le but est bien en effet de sortir un bout de yaml avec le minimum de conf, ça se gâte juste quand tu dois faire écrire le bout de conf par des non technique ;)
Alexis
Le 18 avril 2017 à 20:50, Wallace wallace@morkitu.org a écrit :
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 FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/