Sommaire
J'ai appris récemment Kickstart et Ansible et je voulais écrire un petit retour d'expérience.
Ces deux outils permettent d'automatiser des tâches d'administration système. Un gros avantage est d'avoir une description dans des fichiers texte (sous forme de fichier de config ou de code) de comment installer et configurer une machine ou un ensemble de machines.
Il suffit alors d'utiliser un gestionnaire de versions comme git pour garder un historique de ces fichiers texte, pouvoir créer des branches etc. Bref, c'est le « infrastructure as code », les sysadmins sont de plus en plus apparentés à des programmeurs.
Kickstart
Kickstart est spécifique à la famille de distributions Red Hat : Fedora, RHEL, CentOS, … Ça permet d'automatiser une installation de l'OS. Au lieu de démarrer sur un live USB/DVD et de répondre manuellement aux questions, on écrit un fichier de config Kickstart qui peut automatiser toute l'installation.
Je m'y connais moins en Debian, mais je suppose qu'il existe un équivalent pour la famille de distributions Debian (ou toute autre distro). Si vous pouvez éclairer ma lanterne dans les commentaires… ;-)
Il m'a fallu plusieurs essais avant d'arriver à réussir ma première installation Kickstart. J'aurais eu le temps de faire l'équivalent de peut-être 15 installations manuelles en série… Mais bon l'essentiel c'est que maintenant ce soit automatisé, j'ai trouvé une méthode qui marche bien pour CentOS.
Comme tout outil, l'effort initial d'apprentissage est plus important, mais c'est bénéfique à plus long terme.
Les pros choisiront de créer une serveur PXE et de faire démarrer les machines à installer par le réseau. Pour ma part je suis un amateur (et je n'ai pas beaucoup de machines à installer), donc je mets le fichier kickstart sur une clé USB dans une partition nommée OEMDRV, je branche cette clé USB ainsi que le live USB/DVD de CentOS, je démarre la machine et c'est parti, je peux aller boire un café.
Ansible
Une fois que l'OS est installé, il peut y avoir plein de tâches d'administration système à faire en plus : configurer un serveur web, serveur git, base de données etc etc. Ça demande d'installer des paquets en plus, éditer certains fichiers de config, activer certains services, …
Ce que je faisais avant d'apprendre Ansible était de décrire dans un fichier de log toutes les étapes que j'ai fait, en écrivant pour certaines tâches un script shell. Si je devais réinstaller mon serveur de cette façon-là, ça me prendrait certainement une journée complète…
Avec Ansible – une fois qu'on a écrit le code nécessaire – tout est automatisé ! Ansible se connecte en ssh sur la ou les machines distantes (on peut exécuter Ansible en local aussi) et exécute les tâches demandées. Il n'y a même pas besoin d'installer Ansible sur les ordinateurs distants, c'est une architecture agentless, en mode push. C'est comme si on se connectait manuellement en ssh sur une machine et qu'on exécutait certaines commandes, sauf que c'est Ansible qui le fait à notre place.
On écrit ce qu'on appelle un playbook, dans des fichiers YAML. Un playbook est composé de plays, qui est lui-même composé de tâches. Une tâche est un appel à un module Ansible. Il faut aussi un inventaire d'hôtes. Un play définit sur quel(s) hôtes exécuter les tâches.
Il y a plein de modules. Il y a par exemple le module package pour s'assurer que certains paquets soient installés ou désinstallés. Le module service pour dire si un service doit être démarré et/ou activé au démarrage, ou pour redémarrer un service après avoir édité un fichier de config. Le module lineinfile pour s'assurer qu'une ligne est bien présente dans un certain fichier. Et bien sûr un module shell pour exécuter une commande shell s'il n'y a pas d'autre module plus approprié.
Et ce qui est génial, c'est qu'on peut écrire du code réutilisable, sous forme de rôles. Si on doit faire une nouvelle installation similaire mais avec quelques différences, il suffit d'écrire un nouveau playbook; si on a bien fait son travail il y a des rôles existants qu'on peut réutiliser tels quels.
- Site web d'Ansible
- Whitepaper (le document qui m'a convaincu)
Conclusion
Je n'ai pas encore terminé de décrire mon serveur entièrement avec Ansible, mais une fois que ce sera fait, là où il fallait peut-être une journée complète pour tout réinstaller, avec Kickstart et Ansible ce sera fait en certainement moins d'une heure (incluant peut-être entre 5 et 10 min d'intervention humaine).
Il y a plusieurs années je me demandais aussi comment gérer une salle informatique (par exemple une trentaine d'ordinateurs pour des étudiants). Maintenant je sais qu'avec un serveur PXE, Kickstart et Ansible, on sait gérer facilement un tel parc informatique. Faire les mises à jour sur toutes les machines, installer certains programmes, etc.
Bref, je ne me vois plus administrer des ordinateurs sans ce genre d'outil.
Petit bonus pour la fin : Vagrant est un outil pratique pour apprendre Ansible : au lieu de tester Ansible sur une machine distante on teste sur une machine virtuelle.
# Quelques infos en plus
Posté par Sébastien Wilmet . Évalué à 5.
Le journal étant déjà assez long, je n'ai pas expliqué tout ce que je voulais initialement.
[^] # Re: Quelques infos en plus
Posté par BAud (site web personnel) . Évalué à 4.
oui, je l'ai utilisé en 2005, avec les 3 jours de formation offerts^Wfournis pour la modique somme de 15 k€ avec le satellite server installé, nous étions opérationnels pour gérer les environnements applicatifs (pas la bureautique :/) de dév et ceux d'intégration/préprod'/prod' (bon on y a passé une dizaine de jours ensuite pour tuner au mieux ce dont nous avions besoins (pas les mêmes outils pour les dévs que pour la prod'… YMMV)
il y a aussi chef dans le paysage.
En complément, tu pourrais t'installer :
oui, ansible est un bon produit, couplé à de bonnes pratiques : en partageant entre équipes, il permet de limiter la doc' d'install' à une page voire 1 ligne : « lancer le job ansible tartempion ». Ça prend du temps à la 1ère mise en place, mais c'est du tout bénéf' lors des relivraisons, ou lors d'un changement de TMA ou d'exploitant (c'est « auto-documenté » dans les fichiers de conf'… pour ceux sachant les lire, on va dire).
bon, après, faut accepter que d'accéder à l'utilisateur deploy soit quasi-équivalent à être root sur tout le parc…
[^] # Re: Quelques infos en plus
Posté par Psychofox (Mastodon) . Évalué à 3.
il y'a aussi salt, cfengine et quelques autres encore je crois dans le monde du libre.
# Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 3.
Bienvenue dans le monde magique des devops :)
[^] # Re: Devops
Posté par Sébastien Wilmet . Évalué à 3.
Merci. À la base je ne suis pas du tout sysadmin, je suis développeur. Mais je gère un petit serveur web, git, et quelques autres petits trucs. Et je fais de temps en temps une installation d'un desktop pour un PC de labo (mais pas une salle informatique complète).
Avant ça j'étais étudiant, sans serveur, avec mon seul laptop à administrer, donc je n'avais jamais appris Kickstart, Ansible etc. Mais maintenant que je connais Ansible, je vais essayer d'automatiser les tâches de post-installation pour mon PC perso aussi.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2.
Pour ma part, j'ai gardé un shellscript simple pour la post-installation de mon PC.
… pour deux raisons toutes simples :
À titre pro, je gère quelques dizaines de serveurs et tout ça est géré avec SaltStack.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 15 mai 2017 à 17:02.
C'est une remarque que j'aurais pu comprendre pour son concurrent puppet mais dans le cas d'Ansible il n'y a justement même pas de client à installer. Il faut juste avoir ssh et pousser une clé.
Du reste on parle d'installer des serveurs avec kickstart. Du coup même avec puppet c'est un non-problème. Dans mon environnement pro on installe justement notre client puppet dans le postinstall du kickstart du coup tout est prêt dès la fin de l'installation de base.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Gné ? Quand je viens d'installer mon PC, il n'y a pas de serveur SSH, pas de clé à pousser et aucun moyen d'accéder à un serveur Ansible à partir duquel je déploierais la conf de mon PC, vu que j'utilise mon PC pour ces choses-là… J'ai besoin de pouvoir le post-installer où que je sois.
Non, là c'est une sous-discussion qui parle de nos postes de travail.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne peux pas parler pour Ansible ne l'utilisant pas mais dans le cas de puppet c'est utilisable en local sans avoir à mettre en place une infra client/serveur.
Du coup ça peut être aussi simple qu'un
apt install puppet && puppet apply monfichierinit.ppDu coup je ne vois pas vraiment le rationnel pour tout garder dans un script ou t'auras tendance à être obligé de faire usine à gaz pour assurer la gestion des erreurs/conflits/dépendances au lieu d'utiliser un truc bien plus déclaratif. La "recette" puppet peut très bien être self contained si elle n'utilise pas de module particulier, ça tombe bien par défaut il y'a tout ce qu'il faut pour déclarer des ressources packages, user, fichiers, templates pour faire tout ce que tu as besoin. Les modules accessibles depuis la forge sont très bien mais pas essentiels pour qui ne gère pas un nombre élevé de machines / configs différentes.
[^] # Re: Devops
Posté par barmic . Évalué à 5.
C'est ce qui me paraît donner le plus de valeur ajoutée les templates.
Sinon oui ansible marche très bien localement, mais pour configurer ma machine moi c'est :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 3.
./postinstall.shPas besoin de templates, pas de problème de dépendances, et s'il y a la moindre erreur ça plante, c'est fait pour. :)
Il y a du
apt-get install, dumv, dudconf write, duxdg-mimeet quelques autres machins… Tout ça passe très bien dans un script (pour lequel je peux réexécuter n'importe quelle partie quand j'en ai besoin).J'ai pas vraiment envie de transformer mon script de 900 lignes qui marche très bien et que je maintiens depuis plusieurs années en playbook ansible (ou autre projet concurrent) juste pour la beauté du geste…
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 18 mai 2017 à 07:54.
Personne ne te demande de réécrire quoique ce soit ni de passer à ansible ou puppet. On t'explique juste que l'argument ça tient dans un script n'est pas valable.
On explique juste qu'à choisir si tu commençais maintenant tu aurais meilleur temps de partir sur un outil de gestion de conf qui te prendra peut-être un dixième de tes 900 lignes parce que toute la mécanique qui assure la gestion des erreurs, mais surtout d'idempotence, etc sont inclus dedans et partagés et testés par des millions de gens. Et que la lecture d'un playbook salt ou d'une recette puppet ou chief est bien plus lisible et compréhensible (et donc maintenable) que de naviguer dans un trilliards de fonctions, de structures de controles if/else et compagnie, etc.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
PsychoFox, il faudrait que tu penses à être cohérent :)
D'abord tu me dis qu'il n'y a pas besoin de client et qu'il suffit d'avoir SSH et pousser une clé (donc avoir un Ansible ailleurs), ensuite tu me dis d'installer Ansible (ou Puppet, ou autre, je m'en fous de la techno) pour lire le playbook (ou l'équivalent) localement.
Alors là, carrément pas. Ce que j'ai appelé "helpers" dans mon script, donc l'équivalent des ça prend 175 lignes (tout compris). Tout le reste c'est relatif aux actions d'installation/configuration. Et les appels aux fonctions que j'ai créées sont moins verbeux que la façon de faire avec Ansible (ou n'importe quel autre équivalent). À vue de nez, un playbook Ansible équivalent ferait 150% à 200% de la taille de mon script.
Par exemple :
(qui appelle un script très simple que j'ai écrit une seule fois il y a longtemps)
devient, avec Ansible :
ou avec Salt :
Par ailleurs, je ne vois pas du tout comment, avec Ansible et en un seul fichier, je peux demander de déployer "tout ce qui concerne vim" (c'est à dire installer vim, vim-gnome, puis copier mon ancienne conf, puis mettre gvim comme éditeur par défaut par le biais de xdg-mime).
Ensuite, Ansible tout court ne suffit pas. Notamment, comme indiqué, j'appelle dconf pour paramétrer mon système. J'utilise xdg-mime pour les associations de fichiers. Pour dconf, il faut installer l'un des modules ansible-dconf avant d'exécuter le playbook. Pareil pour xdg, il faut installer ansible-xdg. Donc "installer ansible et jouer le playbook" ne suffit pas : il faut aussi installer des modules ansible ou alors reprendre manuellement la configuration précédente.
Là où je te rejoins, c'est que le fait que ce soit utilisé par des milliers de personnes rend ces solutions plus solides. Mais ce n'est pas crucial pour cet usage.
Le mieux serait que je générise mon script pour le partager publiquement, tu pourrais te faire un avis par toi-même :)
[^] # Re: Devops
Posté par barmic . Évalué à 3.
ou :
Tes fichiers sont bien quelque part il peut aller les chercher en https, ftp, git,… C'est des documents en ligne ? Ansible sait faire aussi. Tu as des choses à modifier dedans ? Tu fais un template.
Mais voyons le autrement. Tu as tes machines qui sont bien installé et finalement, tu veux changer quelque chose :
Ansible est plus compliqué à installer c'est un fait, mais :
n'est probablement pas un frein à quelqu'un qui maîtrise le shell tel que toi. Tu utilise du coup git pour versionner et mettre à jour ton ensemble autant que tu le souhaite, tu peux découper tes fichiers autant que tu veux pour les gérer comme tu sens ça ne changera pas ton déploiement, tu accède à des options de haut niveau (les templates, la gestion des comptes utilisateurs, etc). Tu peux aussi spécialisé ton environnement en fonction de la machine et te servir des même scripts pour ta machine de bureau, ton dédié OVH et ton rPi (sauf que tu aura vim-gnome, sur certain et vim-nox sur d'autres, même le même
.vimrc). Tu ne peux pas avoir d'injection dans ansible.Bref tu fais bien ce que tu veux (moi même j'utilise dpkg pour le moment), mais ansible t'offre beaucoup de choses en plus pour une marche qui n'est pas bien plus grande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
On s'est mal compris, je ne parlais pas des fichiers ou quoi que ce soit d'autre, je parlais d'exécuter plusieurs actions en même temps, tirées d'un même fichier.
En l'occurrence, pour Vim, j'ai une fonction :
Je peux alors lancer
./postinstall.sh vimpour exécuter ces 7 actions. Je ne connais pas de manière, avec Ansible, pour appeler 7 plays en une seule commande aussi simple, sauf à faire un playbook pour chaque programme, puis utiliser les rôles, etc etc. Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers…Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.
Comme je l'ai dit plus haut, je parle du déploiement de ma postinstallation sur mon poste de travail. Une seule machine, sans aucun autre outil à côté. Si j'ai plusieurs machines à gérer, j'utilise un outil dédié. Ansible, SaltStack ou autre.
Pour répondre à ta question, mon script repasse sur lui-même sans (trop de) problème. Je ne suis pas allé jusqu'à vérifier que je gère l'idempotence à 100%, mais ça ne doit pas en être très loin.
ce script de postinstallation, je l'utilise une fois tous les 6 mois quand j'installe la version suivante d'Ubuntu.
En cas d'erreur dans le script, je le corrige et je le relance. La plupart du temps, c'est lié à des changements entre deux versions d'Ubuntu, par exemple récemment ça a été le passage de gsettings à dconf pour pas mal d'applis…
Ensuite je le lance occasionnellement (et partiellement, comme dans l'exemple de vim ci-dessus) pour rétablir des conf que j'ai un peu trop tripatouillées à la main.
Et vu que je ne me rappellerais jamais de cette commande en entier, utilisée une fois tous les 6 mois sur une machine vierge, il faudrait la mettre dans un script :)
Comme tu le dis, chacun fait comme il veut. Pour ma part et pour cet usage, je ne vois pas d'intérêt à utiliser Ansible : un script shell est bien plus flexible et facile à utiliser in fine pour cet usage à mon sens.
[^] # Re: Devops
Posté par wismerhill . Évalué à 4.
Juste pour répondre à cette remarque, et sans impliquer que tu devrais changer ta façon de faire.
Ce genre de chose se fait typiquement avec des tags.
Tu fais un playbook avec toutes les actions à appliquer, et tu applique des tags sur les différentes actions selon, ce à quoi elles s'appliquent. Si une action particulière est toujours nécessaire (par exemple parce qu'elle récupère des informations qui sont utilisées à plusieurs endroits), plutôt que de devoir lui appliquer tous les tags, il y a un tag spécial always pour toujours l'exécuter.
Ensuite, tu peux exécuter ansible-playbook avec l'option -t (--tags) pour n'exécuter que les actions qui correspondent à ce(s) tag(s). Il y a aussi une option --skip-tags pour exclure selon d'autres tags.
Note que ça peut aussi fonctionner de façon hybride, la commande de base ansible permet d'exécuter une unique action, elle peut donc être utilisée dans un script (et appliquée à localhost) pour profiter des fonctionnalités de certains modules complexes, et scripter d'autres choses qui seraient de toute façon compliquées à faire dans ansible.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2.
Intéressant, en effet ça répond à une des problématiques.
[^] # Re: Devops
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Tu peux toujours planter un clou avec un tournevis en version Ansible :
Avec les mêmes défauts d'ailleurs : aucune vérification des codes de retour, possibilité d'échouer en plein milieu sans retour arrière, pas de contrôle fin sur le sudo, pas de notion de ok/changed/failed, etc.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Ouais, on va éviter cette approche hein :D
[^] # Re: Devops
Posté par barmic . Évalué à 3.
C'est quoi cet intérêt pour n'avoir qu'un seul fichier ? Il n'y a aucune raison de n'avoir qu'un seul fichier. Je ne dis pas que ce n'est pas grave d'avoir plusieurs fichiers, je dis que c'est bénéfiques. Il n'y a pas l'ombre d'un problème à utiliser une arborescence de fichiers.
Ça n'est pas comme ça que fonctionne ansible (et les logiciels du genre). Dans ansible tu défini des rôles qui peuvent avoir des fichiers, des templates, un playbook, des variables,… et tu va agréger et paramétrer ces rôles pour chaque cible ou groupe de machines. Donc tu aura un rôle vim que tu applique à ta machine. Comme tout est idempotent, tu ne devrais pas lancer ansible par rôle mais par machine, si tu fais une modification tu ré-applique tout. Les tags peuvent servir, mais je ne les utilise pas pour ça.
On à tous pleins de machines. Celle(s) de chez toi, celle du travail,…
C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.
C'est de la mauvaise fois… Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?
Je sais parfaitement écrire des scripts shells/bash/zsh, mais justement parce que je sais ce qu'il en retourne la piètre qualité des scripts généralement (mauvaise gestion des inputs par exemple) et, même en zsh, la quantité de code que ça prends de faire les choses bien, je préférerais toujours partir sur une solution, qui ne me fais pas réinventer là roue (fabric par exemple peut faire l'affaire pour ça, mais il n'est pas idempotent).
Regarde tes confs fichiers tout statiques : Les écrire en jinja (c'est le moteur de templates d'ansible) te permet de les rendre plus courts.
L'utilisation d'outils de plus haut niveau te retire le plaisir d'utiliser ce que tu connais parfaitement et te sors de ta zone de confort, mais :
Le tout pour un coût faible ;) (ne me dis pas que cloner un dépôt, trouver une commande ou le wrapper dans un script, etc sont hors de ta portée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Plus facile à transporter.
J'ai un seul poste de travail, depuis plus de 5 ans.
Tout le reste, ce sont des serveurs, que je gérerai certainement un jour avec Ansible quand j'en prendrai le temps…
Je n'ai pas de dépôt git pour ça. Ce script est dans $HOME.
Je n'ai aucun fichier de conf templaté, je ne veux que mettre en place certains points de config et surtout pas mettre en place une config complète, vu que je veux profiter des éventuelles dernières évolutions des logiciels…
Ce n'est pas hors de ma portée, mais c'est chiant dans le contexte.
J'installe la dernière version d'Ubuntu, j'arrive dans une session vierge, je n'ai pas envie de m'embêter. Ma seule action est :
À la limite je pourrais faire un script qui installe Ansible etc etc, mais je n'en vois pas vraiment l'intérêt, ce script marche très bien depuis plusieurs années…
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 2.
En 2017 l'argument du "transport de fichier" est irrecevable. À moins que tu copies à la main ton fichier depuis une clé usb ou que tu n'as aucun stockage externe/backup (mais là t'as bien d'autres problèmes que gérer un script).
Encore une fois, à vrai dire on s'en fout que tu utilises un script, que tu aies la flemme ou pas l'envie de passer à autre chose. C'est ton choix. Par contre prétendre que ta solution est meilleure parce que tu n'as rien à installer avant (alors que ton script va installer des trucs de toute manière, et que globalement c'est moins facilement maintenable) et que ça tienne en 1 seul fichier copié/collable, ce n'est pas convainquant comme raisons.
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2. Dernière modification le 22 mai 2017 à 19:54.
Je déplace à la main ce fichier depuis mon ancien $HOME. Il est constamment dans mon $HOME.
Clé USB, stockage externe, tout ça représente déjà une étape de trop dans mon process de réinstallation…
Je n'ai pas dit une seule fois que c'est "la meilleure".
J'ai juste dit que ça répond parfaitement à mon besoin…
C'est précisément ça le besoin : de n'avoir aucun truc à installer manuellement pour pouvoir l'utiliser, afin qu'il fasse lui-même toutes les installations des trucs dont j'ai besoin.
Nope, je le maintiens très facilement…
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 2.
Pourquoi voudrais-tu séparer les actions liées à vims des autres ? Si tu utilises un outil comme ansible, puppet, salt ou chief qui gèrent l'idempotence tu n'as pas besoin de faire ça justement.
Tu t'inventes des problèmes en utilisant justement une technique du paléolithique pour gérer ta bécane.
Que tu gère 1 ou 10 machine la complexité ne change pas.
Pourquoi aurais-tu besoin de faire ça ? Ta machine explose à chaque maj d'ubuntu ?
En gros tu sais pas ce que tu fais ! Pourquoi ne versionnes-tu pas tes fichiers de conf ?
Nan mais la c'est de la mauvaise foi crasse. Et quand bien-même tu mettrais cette ligne dans un .sh où est le problème ?
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 2.
Je suis cohérent mais tu mélanges 2 posts qui ne répondent pas aux même questions.
Ansible ne nécessite pas de client si tu l'utilises en mode serveur/client.
Si tu l'utilises en standalone tu as forcément besoin d'avoir quelque part un ansible qui va appliquer le playbook.
Peut-être que Ansible n'est pas le bon example (je ne le connais pas assez) mais je n'y crois pas du tout. Exemple dans puppet que j'utilise tu as la directive de base qui tiens dans une ligne.
Exemple dans puppet :
package { 'vim' }
Par contre tu as effectivement pleins de trucs optionnels qui peuvent t'être utiles mais qui ne sont pas indispensables:
package { 'resource title':
name => # (namevar) The package name. This is the name that the...
provider => # (namevar) The specific backend to use for this `package...
ensure => # What state the package should be in. On...
adminfile => # A file containing package defaults for...
allow_virtual => # Specifies if virtual package names are allowed...
allowcdrom => # Tells apt to allow cdrom sources in the...
category => # A read-only parameter set by the...
configfiles => # Whether to keep or replace modified config files
description => # A read-only parameter set by the...
flavor => # OpenBSD supports 'flavors', which are further...
install_options => # An array of additional options to pass when...
instance => # A read-only parameter set by the...
package_settings => # Settings that can change the contents or...
platform => # A read-only parameter set by the...
reinstall_on_refresh => # Whether this resource should respond to refresh...
responsefile => # A file containing any necessary answers to...
root => # A read-only parameter set by the...
source => # Where to find the package file. This is only...
status => # A read-only parameter set by the...
uninstall_options => # An array of additional options to pass when...
vendor => # A read-only parameter set by the...
# ...plus any applicable metaparameters.
}
package { 'vim': ensure => 'latest' }
Et si tu veux installer de multiples packages avec les mêmes options :
$mon_panier_garni_habituel = = [ 'vim', 'bash-completion', 'tmux', 'ssh', 'sshfs', 'keychain', 'sysstat', 'git' ]
package { $mon_panier_garni_habituel: ensure => 'latest' }
Tu crois que tu peux gérer tout ça en moins de lignes avec ton script ? Bravo tu as réinventé et maintiens un énième outil de gestion de configuration. C'est tout à ton hônneur mais tu t'es forcément bien plus pris la tête qu'un utilisateur simple d'un de ces outils et au final je ne vois pas comment ton code peut être plus court en implémentant à la fois la mécanique derrière et la déclaration des ressources que tu gères, même si le language de ansible est plus verbeux (en terme de lignes) que celui de puppet pour des trucs basiques.
Et dès que tu as des trucs un peu gruik pas prévus d'origine par ton script, c'est à nouveau tout ça à recoder, retester, casser, etc.
Je ne vois pas les difficultés. Dans les outils de gestions de versions tu gères des dépendances. Genre dans puppet avec les directives before ou require voir de simples flèches tu peux gérer les dépendances, avec notify tu mentionnes le nom du service qui doit être redémarré à chaque modification d'un fichier de conf. Je ne trouve pas ça hyper propre dès que la conf est grande mais il est possible d'avoir tout ou partie du contenu d'un fichier dans le code puppet. On peut même le faire avec des templates (inline_template) :
Dans lequel par exemple $header et $footer sont de simples variables et $content est un hash avec des clés/valeurs que tu paramètre avant. Ici à la place du Service qui est "notifié" tu peux utiliser une ressource Exec qui lancera une commande déclarée avant.
J'ai été sceptique aussi à une époque, puisqu'il y'a une petite courbe d'apprentissage du language utilisé et des ressources disponible et que j'avais aussi mes petits scripts maisons à une époque. Mais on y gagne finalement même à très court terme et ça scale très bien le jour où tu dois gérer des centaines voire milliers de serveurs/containers ce qui est mon cas maintenant.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 18 mai 2017 à 12:48.
J'ajouterai que vouloir à tout prix tout faire tenir en 1 seul fichier, ce n'est pas forcément très pertinent. Oui c'était intéressant quand on faisait plein de trucs à la popogne, sans forcément avoir un accès réseau immédiat après l'installation histoire de pouvoir l'embarquer facilement dans une image iso ou une clé usb. Maintenant on a des moyens simples de mettre des trucs en ligne et d'y accéder facilement, même à la maison, que ce soit depuis un service cloud, un serveur git, ton nas ou que sais-je. On sait aussi maintenir une arborescence y gérer le versionning avec des outils à la fois centralisés et décentralisés (à nouveau, git).
Je n'en ferai pas une obsession en tout cas.
[^] # Re: Devops
Posté par Kerro . Évalué à 3.
Tu as oublié (sauf si j'ai raté un paragraphe) de citer quelque chose qui me semble majeur : avec un script, il est délicat de gérer plusieurs cas de figure.
J'ai un cas de figure « poste de travail Fedora », un autre « serveur Debian Proxmox », un autre « serveur web + ftp + sauvegarde + pare-feu spécifique », etc etc. Ça se gère
très bien(n'exagérons pas) avec du Chef/Puppet/whatever, mais pas avec un script.[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Pour "le script de postinstallation de mon PC perso", il n'y a pas plusieurs cas de figure…
[^] # Re: Devops
Posté par claudex . Évalué à 4.
Moi, j'ai déjà le cas de figure laptop et desktop qui n'est pas le même à la maison. Mais après, sur mes serveurs, je veux aussi retrouver le même bashrc et vimrc. Donc, c'est pratique de pouvoir mutualiser.
« 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
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Nope.
Mon message plus haut était « pour la post-installation de mon PC […] je veux pouvoir l'exécuter immédiatement après installation du PC, sans avoir à installer d'abord Ansible ou autre chose »
…auquel tu as répondu « dans le cas d'Ansible il n'y a justement même pas de client à installer. Il faut juste avoir ssh et pousser une clé. »
… auquel j'ai répondu « Quand je viens d'installer mon PC, il n'y a pas de serveur SSH, pas de clé à pousser et aucun moyen d'accéder à un serveur Ansible à partir duquel je déploierais la conf de mon PC, vu que j'utilise mon PC pour ces choses-là »
…auquel tu as répondu « dans le cas de puppet c'est utilisable en local sans avoir à mettre en place une infra client/serveur. »
Cet échange est resté toujours sur la même question : exécuter la postinstall de mon PC.
L'installation de packages est un exemple ultra-simple, facile à gérer en effet. Mais il n'y a pas que ça.
L'explication du nombre de lignes est simple : certaines des fonctions que j'ai développées (à une époque où les logiciels de gestion de configuration commençaient à peine à apparaître) correspondent à des modules existants dans ces logiciels, d'autres nécessiteraient soit de développer de nouveaux modules, soit de télécharger et installer des modules tiers, soit d'éclater ces fonctions en plusieurs plays.
Dans tous les cas, on s'éloigne du but de mon script : pouvoir être exécuté par
./postinstall.shsans avoir à préinstaller un quelconque environnement.De plus, dans ce cas précis, je veux que le script plante dès qu'il y a le moindre problème rencontré, pour pouvoir le corriger immédiatement. Et puis je veux qu'il m'affiche des messages sur son avancement.
Et puis dans certains cas, les sources d'où je prends mes logiciels ne permettent pas un download automatique de la toute dernière version, auquel cas il faut aller sur une page particulière et télécharger la dernière version d'un .deb pour qu'il puisse l'installer (ou alors parser une page web… youpi) [*]. Ça, Ansible ne sait pas le faire non plus à ma connaissance. Bon, aujourd'hui je n'ai ce cas que pour Go [https://golang.org/dl/], si quelqu'un a un lien pour downloader directement la dernière version je suis preneur.
Tu veux dire que chaque instruction qui tenait en une ligne tient maintenant en deux lignes ? Félicitations, tu as transformé les 750 premières lignes de mon script en 1500 lignes !
Bon ok, j'exagère un peu, mais tu vois l'idée :)
Concernant la courbe d'apprentissage, ne t'inquiète pas, je connais ces outils, je sais ce qu'ils peuvent faire, je travaille quotidiennement avec…
[^] # Re: Devops
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 22 mai 2017 à 09:49.
Le principe de l'idempotence,c'est justement de ne pas avoir ce besoin. Tu peux le lancer 1x ou 1000x et il n'y aura que ce qui a besoin d'être changé qui sera changé.
C'est le cas des gestionnaire de config avec une verbosité qui peut être plus ou moins élevée.
https://launchpad.net/~longsleep/+archive/ubuntu/golang-backports
https://hub.docker.com/_/golang/
J'imagine par ailleurs que si tu as besoin de la toute dernière version, c'est que tu as ce besoin à tout moment et donc que ça n'a donc plus rien à voir avec du postinstall.
Je ne comprends pas, ça ne veut rien dire ton histoire de duplication de lignes.
Ben justement, tu n'as pas l'air très au fait des principes de base de leur fonctionnement.
[^] # Re: Devops
Posté par barmic . Évalué à 5.
Oula… Le devops c'est une méthodologie pas des outils. C'est comme si tu disais bienvenu dans l'agilité à quelqu'un qui utilise un bug tracker.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par Sébastien Wilmet . Évalué à 2.
Mais sans les outils la méthodologie serait beaucoup moins praticable.
Je pense qu'on peut dire qu'en général ceux qui font du DevOps sous Linux connaissent bien des outils comme Kickstart, Ansible, Puppet, Docker, etc. Apprendre ces technologies est en quelque sorte un premier pas vers le DevOps. Ça aide en tout cas à décrocher un emploi dans le DevOps, et à avoir des sujets de conversation en commun avec ceux qui font ce boulot :-)
[^] # Re: Devops
Posté par barmic . Évalué à 3.
C'est bien moins critique que le management. Andin le n'a rien de devops. C'est un outil d'administration système. Donc oui c'est un outil qui peut servir en devops au même titre que ssh. Ce n'est pas un sacrum boyard qui rend une équipe agile.
Je fais la remarque parce que c'est important amha de voir que ce n'est pas une question d'outils, mais d'organisation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par BAud (site web personnel) . Évalué à 2.
mici, mici, mici !!!
quelle saleté cette scrum board dont tous les post-it passent leur temps à tomber au sol /o\ ou avec des dates d'objectif de réal' dans le passé (bon, ya pas l'année on va dire…)
bin, « ya pas de doc', on bosse en agile » :p
sérieux, en 2017… j'ai fait de l'XP avant l'heure aussi, ça marchait bien
agile est souvent confondu avec :
oui, j'en ai une palanquées d'exemples (oui, je bosse avec beaucoup de boulets au quotidien… heureusement que j'ai des collègues qui constatent la même chose). T'as des projets, voire des programmes dont l'orga conduit mécaniquement à l'échec, c'est sans doute un choix pour montrer qu'il n'y avait pas besoin de le faire ?! ou de se valoriser en montrant que c'était impossible (déjà vu, lamentable :/)
[^] # Re: Devops
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2.
Oui oui, que ce soit Kickstarter et Ansible ou d'autres outils (je vais pas en faire la liste, hein, sauf si on me demande :p ), je lui souhaite la bienvenue dans l'utilisation d'une telle méthodologie.
Sébastien semble ravi de découvrir les possibilités qu'offre Ansible et la manière dont il pourra simplifier la gestion de ses postes et/ou serveurs et on parle là bien de méthodologie, pas uniquement de l'outil. C'est la porte d'entrée vers l'approche devops dans sa globalité…
# Mauvais lien vers le whitepaper
Posté par Sébastien Wilmet . Évalué à 1.
J'ai été trop vite et je me suis trompé de lien pour le whitepaper, je ne savais pas qu'il y avait en fait plusieurs whitepapers.
Celui dont je voulais parler était Ansible in depth.
# Preseed
Posté par barmic . Évalué à 9.
Pour Debian ça s'appelle Preseed.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Preseed
Posté par Sébastien Wilmet . Évalué à 1.
Merci, c'est bon à savoir.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.