Cher lecteur/lectrice,
je me permets de porter à ta connaissance le relâchement de Ansible Tower par Redhat en tant que projet OpenSource, portant l'acronyme AWX.
Ici l'annonce de Redhat :
Ici la FAQ relative au projet AWX :
https://www.ansible.com/awx-project-faq
Comme entre la Fedora et RHEL, le mode de fonctionnement retenu entre AWX et Ansible Tower semble être le même :
Q: What’s the difference between AWX and Ansible Tower?
AWX is designed to be a frequently released, fast-moving project where all new development happens.
Ansible Tower is produced by taking selected releases of AWX, hardening them for long-term supportability, and making them available to customers as the Ansible Tower offering.
This is a tested and trusted method of software development for Red Hat, which follows a similar model to Fedora and Red Hat Enterprise Linux.
Je me demande si ce modèle est tenable avec un produit comme Tower.
En effet, en comparaison, un OS et ses composants connexes, tout changement peut avoir pas mal d'effets de bord.
Il est donc normal de procéder à beaucoup de tests pour produire une version stable.
Mais un produit comme Tower bouge beaucoup plus.
Si vous me permettez une petite digression, c'est pour moi comparable à un produit comme Redhat Satellite.
Et il n'y a qu'à voir la fréquence des mises à jour de redhat satellite (v6) pour se rendre compte que c'est pas simple.
https://access.redhat.com/articles/1365633
On remarque par exemple que la version de the foreman embarquée est la 1.11.0.83-1 tandis que le projet amont en est beaucoup plus loin : release 1.15 et 1.14
Bref, ça bouge très vite et ça rame derrière pour pouvoir suivre et produire une version stable.
Mais, vous me direz, rien de nouveau sous le soleil, debian is dying etc etc..
En outre, une version stable n'a jamais empêché les bugs.
Je vous ferai grâce des bugs que j'ai remonté au support sur satellite mais qui sont restés lettre morte pour le moment.
Dernière parenthèse sur Redhat Satellite, c'est l'arrivée d'Ansible Tower dans sa version 6.3
Si comme moi, vous avez travaillé sur la version 6.2, et avez commencé à capitaliser sur Puppet, arrêtez tout !
Bien que la version 6.3 intégrera Puppet 4, la version 6.4 amorcera une rupture :
- Ansible core automation as default for provisioning and configuration management
- Puppet support remains, inside or connected
Je vous invite à prendre connaissance du slide ci-dessous pour voir la trajectoire du produit redhat satellite :
On s'en doutait que le rachat d'Ansible remettrait en cause pas mal de chose, mais jusqu'à présent le support de Tower et d'Ansible dans Satellite n'était qu'additionnel.
Maintenant les masques sont tombés.
# puppet
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 08 septembre 2017 à 11:29.
Chez nous on travaille avec foreman, katello open source et puppet open source. Ça se passe bien. J'ai travaillé par le passé avec satellite et puppet enterprise, je ne souffre pas vraiment de manque. Je ne vois pas pourquoi ce serait différent avec Ansible/AWX.
Du reste je ne suis pas d'accord avec ta conclusion. Si tu lis l'annonce puppet restera supporté. Ansible Tower est une option supplémentaire à côté de puppet+puppetdb (ou puppet enterprise). C'est ce que veux dire :
Puppet support remains, inside or connected
Redhat est juste en voie de compléter l'intégration ansible/sattelite. Mais ils savent pertinemment que puppet reste un des gros acteurs du monde de la gestion de configuration et que son ecosystem est énorme.
Après redhat n'a jamais été hyper investi dans puppet, rien de nouveau sous le soleil. Ça ne va pas changer grand chose.
[^] # Re: puppet
Posté par Dabowl_75 . Évalué à 2.
Donc pour toi le message n'est pas assez clair ?
Bien entendu que puppet restera pris en charge un certain temps.
Redhat ne peut pas le balayer d'un revers de main, y a des clients derrière ses produits.
C'est le commerce mon bon monsieur.
La transition se fera en douceur.
Mais la trajectoire me semble claire.
Les clients peuvent toutefois se manifester en faveur de puppet.
Mais vu l'investissement de Redhat sur Ansible, nul doute que beaucoup de décideurs vont orienter leurs équipes vers Ansible…
[^] # Re: puppet
Posté par Psychofox (Mastodon) . Évalué à 4.
ou pas.
Là on parle d'un ecocsytème stallite-centric. Je connais pleins de boites qui ont du redhat et vivent très bien sans satellite.
[^] # Re: puppet
Posté par LeSeb (site web personnel) . Évalué à 1.
Mais même pour celles qui vivent avec: quand tu as des milliers de systèmes à gérer sur des dizaines de sites, tu apprécies le fait que les capsules Satellite embarquent leur propre serveur Puppet et pourront donc gérer la charge associée.
De mon côté, même si j'ai étudié la possibilité d'utiliser Ansible plutôt que Puppet dans mon infra Satellite, j'en suis venu à la conclusion - après avoir réalisé quelques tests - qu'on allait sagement utiliser Puppet en attendant que Red Hat sorte une version de Satellite offrant les mêmes possibilités de décentralisation pour Ansible.
[^] # Re: puppet
Posté par Dabowl_75 . Évalué à 1.
tout en sachant que ce n'est pas dans la philosophie initiale d'Ansible que de travailler en mode décentralisé ou en mode pull.
Ansible n'est pas non plus fait pour du maintien de conf à la base, contrairement à puppet.
C'est en cela que Tower vient combler ce manque, par le scheduling notamment.
Nul doute que Redhat va quand même essayer de rafler la mise.
C'est le jeu de la concurrence libre et non faussée.
# C'est quoi?
Posté par ʭ ☯ . Évalué à 8.
Et sinon, une description courte de AWX, c'est possible? Parce que pour l'instant, ce journal est réservé aux utilisateurs de toutes ces solutions…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: C'est quoi?
Posté par claudex . Évalué à 7.
C'est la partie serveur de Ansible. Ansible, c'est de la configuration automatique. Tu lui donne une liste de chose à faire (par exemple installer postgresql, apache, mod-wsgi et python, avec un fichier configuration (utilisant un template) et il va le mettre sur toutes les machines dont tu as besoin. Ça t'évite de devoir faire le tour de tes machines à chaque mise à jour d'un bout de conf.
Alors, ansible se lance en ligne de commande. Le problème, quand tu commence à avoir un parc un peu conséquent, c'est d'automatiser le lancement en ligne de commande, de faire le rapport des machines sur lesquels il y a eu des problème, etc. Ansible Tower fait ce boulot plutôt que de scripter un cron et parser le résultat.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# et je te réponds
Posté par GG (site web personnel) . Évalué à -10.
à cause de systemd.
Vu la complexité sur les trucs simples que systemd à apporté…
Bref, pour faire des scripts d'init, systemd est pas mal. Mais il faut distinguer ceux qui ont besoin de faire des scripts d'init, et les autres… et comme systemd est imposé, bref, c'est pénible pour tout le reste.
Heureusement qu'il n'y a pas systemd sur OpenBSD. Et je suis déjà en train de commencer à me faire la main dessus. OpenBSD c'est très bien, le réseau y est très bien géré. Après, chacun y trouvera des trucs dessus… et alors, tant qu'on a le choix.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: et je te réponds
Posté par kebree . Évalué à 7.
J'étais franchement dubitatif sur systemd avant de l'utiliser.
Mais maintenant… quel bonheur. Le limiter à des scripts de démarrage est franchement réducteur.
# Très déçu par tower
Posté par Sébastien Rohaut . Évalué à 6.
Toute la stack d'automatisation de la plateforme que je gère est codée via des recettes ansible depuis 2013. Ça va du provisioning de serveur jusqu'au build et déploiement de containers docker, en passant par la configuration de nos load balancers haproxy.
Quand awx/tower est sorti, nous avons dû faire partie de 30 pèlerins à m'avoir acheté. Nous n'avons pas renouvelé la licence tant c'était un produit inutile et cher pour ce qu'il proposait, en 2014.
Finalement nous avons remplacé tower par jenkins et les plugins qui vont bien. Ça suffit largement.
[^] # Re: Très déçu par tower
Posté par pizaninja . Évalué à 4. Dernière modification le 10 septembre 2017 à 07:14.
J'ai aussi utilisé Jenkins pour automatiser les install d'un parc hétérogène avec packer, vagrant, ansible, docker, tunnels ssh, etc…
Ceci dit, j'ose imaginer qu'ansible tower permet aussi de monitorer ses installs et aider à l'organisation de ses configs ansible, non ?
Un RetEx de ton utilisation de Jenkins pour du provisioning avec ansible est le bienvenu. Quels plugins ? Quel résultat obtenu sous Jenkins? Un journal sur le sujet ?
[^] # Re: Très déçu par tower
Posté par Re_ . Évalué à 2.
Bonjour,
je suis également intéressé par un retour d'utilisation Jenkins + Ansible !
Merci
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.