PsychoFox, il faudrait que tu penses à être cohérent :)
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é.
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.
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.
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.
qui te prendra peut-être un dixième de tes 900 lignes
Alors là, carrément pas. Ce que j'ai appelé "helpers" dans mon script, donc l'équivalent des ça prend 175 lignes (tout compris). [...] À vue de nez, un playbook Ansible équivalent ferait 150% à 200% de la taille de mon script.
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.
} Et si tu n'as besoin que d'une ou deux ça peut toujours tenir en 1 ligne :
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' } Idem pour tout ce qui peut exister comme ressources (users, fichiers, services, etc).
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.
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).
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) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. É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.