Journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux

Posté par (page perso) . Licence CC by-sa
30
15
mai
2017

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.

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 (page perso) . Évalué à 5.

    Le journal étant déjà assez long, je n'ai pas expliqué tout ce que je voulais initialement.

    • Kickstart n'est pas du tout une technologie récente, ça existe depuis longtemps.
    • Ansible est relativement récent.
    • Ansible a été racheté par Red Hat en 2015.
    • À la place d'Ansible, un autre outil du même genre très utilisé est Puppet.
    • Ansible peut faire aussi de l'orchestration dans un data center, par exemple pour faire une migration impliquant plusieurs serveurs (exécuter les tâches de manière coordonnée, dans le bon ordre).

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Quelques infos en plus

      Posté par (page perso) . Évalué à 4.

      Kickstart n'est pas du tout une technologie récente, ça existe depuis longtemps.

      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)

      À la place d'Ansible, un autre outil du même genre très utilisé est Puppet

      il y a aussi chef dans le paysage.

      En complément, tu pourrais t'installer :

      • un gitlab pour avoir de bonnes pratiques : le git pour les scripts / les certificats / la conf' de chaque environnement + wiki pour la doc' (exit les fiches de relecture \o/) et les suivis / échanges via les « issues ».
      • un jenkins (ancien^Wfork de hudson) pour les tests unitaires / validation de la mise à disposition, éventuellement reconstruction à la volée d'un environnement réceptionnant les livraisons des dévs et s'assurant qu'ils n'ont pas oublié d'indiquer la nième bibliothèque à la mode (encore un truc qui vient avec node.js, vraiment au hasard /o) ou une montée de version impromptue…

      Ansible peut faire aussi de l'orchestration dans un data center, par exemple pour faire une migration impliquant plusieurs serveurs (exécuter les tâches de manière coordonnée, dans le bon ordre).

      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…

  • # Devops

    Posté par (page perso) . Évalué à 3.

    Bienvenue dans le monde magique des devops :)

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

    • [^] # Re: Devops

      Posté par (page perso) . É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.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Devops

        Posté par (page perso) . Évalué à 2.

        Pour ma part, j'ai gardé un shellscript simple pour la post-installation de mon PC.
        … pour deux raisons toutes simples :

        • je veux pouvoir l'exécuter immédiatement après installation du PC, sans avoir à installer d'abord Ansible ou autre chose ;
        • je veux qu'il soit "self-contained", pour pouvoir le copier-coller facilement.

        À titre pro, je gère quelques dizaines de serveurs et tout ça est géré avec SaltStack.

        https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

        • [^] # Re: Devops

          Posté par . Évalué à 4. Dernière modification le 15/05/17 à 17:02.

          Pour ma part, j'ai gardé un shellscript simple pour la post-installation de mon PC.
          … pour deux raisons toutes simples :

          je veux pouvoir l'exécuter immédiatement après installation du PC, sans avoir à installer d'abord Ansible ou autre chose ;
          je veux qu'il soit "self-contained", pour pouvoir le copier-coller facilement.
          À titre pro, je gère quelques dizaines de serveurs et tout ça est géré avec SaltStack.

          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 (page perso) . Évalué à 1.

            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é.

            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.

            Du reste on parle d'installer des serveurs avec kickstart.

            Non, là c'est une sous-discussion qui parle de nos postes de travail.

            https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

            • [^] # Re: Devops

              Posté par . Évalué à 3.

              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.

              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.pp

              Du 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 . Évalué à 5.

                […] 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.

                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 :

                dpkg -i barmic-config.deb && apt-get -f install

                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 (page perso) . Évalué à 3.

                  ./postinstall.sh

                  Pas 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, du mv, du dconf write, du xdg-mime et 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…

                  https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                  • [^] # Re: Devops

                    Posté par . Évalué à 5. Dernière modification le 18/05/17 à 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 (page perso) . Évalué à 1.

                      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.

                      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). 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 :

                          install vim

                      (qui appelle un script très simple que j'ai écrit une seule fois il y a longtemps)

                      devient, avec Ansible :

                          - name: Install Vim
                            apt:
                              name: vim
                      

                      ou avec Salt :

                      vim:
                        pkg.latest

                      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 :)

                      https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                      • [^] # Re: Devops

                        Posté par . Évalué à 3.

                        devient, avec Ansible :

                            - name: Install Vim
                              apt:
                                name: vim

                        ou :

                        - apt: name=vim

                        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).

                        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 :

                        • tu refais une installation fraîche ?
                        • ton script passe à peu près sur lui même sans trop de problème ?
                        • tu as une vrai gestion de l’idempotence ce qui te permet de jouer autant de fois que tu veux ton script sans avoir à croiser les doigts ?

                        Ansible est plus compliqué à installer c'est un fait, mais :

                        apt install git ansible && git clone <url> && ansible-playbook installation.yml

                        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 (page perso) . Évalué à 1.

                          Tes fichiers sont bien quelque part

                          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 :

                          vim() {
                              install vim
                              install vim-gnome
                              sudo update-alternatives --set editor /usr/bin/vim.basic || abort "Failed setting vim as the default editor"
                              mv_old_conf vim
                              mv_old_conf viminfo
                              mv_old_conf vimrc
                              xdg-mime default gvim.desktop text/plain
                          }

                          Je peux alors lancer ./postinstall.sh vim pour 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 as tes machines qui sont bien installé

                          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.

                          apt install git ansible && git clone <url> && ansible-playbook installation.yml

                          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.

                          https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                          • [^] # Re: Devops

                            Posté par . Évalué à 4.

                            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…

                            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 (page perso) . Évalué à 2.

                              Intéressant, en effet ça répond à une des problématiques.

                              https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                          • [^] # Re: Devops

                            Posté par (page perso) . Évalué à 2.

                            Tu peux toujours planter un clou avec un tournevis en version Ansible :

                            shell: install vim ; install vim-gnome ; sudo update-alternatives --set editor /usr/bin/vim.basic || abort "Failed setting vim as the default editor" ; mv_old_conf vim ; mv_old_conf viminfo ; mv_old_conf vimrc ; xdg-mime default gvim.desktop text/plain
                            changed_when: false
                            

                            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 (page perso) . Évalué à 1.

                              Ouais, on va éviter cette approche hein :D

                              https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                          • [^] # Re: Devops

                            Posté par . Évalué à 3.

                            Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers…

                            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.

                            Je peux alors lancer ./postinstall.sh vim pour 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.

                            Ç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.

                            Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.

                            On à tous pleins de machines. Celle(s) de chez toi, celle du travail,…

                            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.

                            C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.

                            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 :)

                            C'est de la mauvaise fois… Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?

                            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.

                            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 :

                            • te permet d'avoir une configuration descriptive de ta machine
                            • te permet d'appliquer ta configuration sur toutes les machines auxquels tu as accès
                            • te donne accès à des action de plus haut niveau
                            • te donne de l'idempotence en standard
                            • te pousse aux bonnes pratiques

                            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 (page perso) . Évalué à 1.

                              C'est quoi cet intérêt pour n'avoir qu'un seul fichier ?

                              Plus facile à transporter.

                              On à tous pleins de machines. Celle(s) de chez toi, celle du travail,…

                              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…

                              Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?

                              Je n'ai pas de dépôt git pour ça. Ce script est dans $HOME.

                              Regarde tes confs fichiers tout statiques 

                              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…

                              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

                              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 :

                              mv $HOME.old/postinstall.sh .
                              ./postinstall.sh

                              À 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…

                              https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                              • [^] # Re: Devops

                                Posté par . É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 (page perso) . Évalué à 2. Dernière modification le 22/05/17 à 19:54.

                                  À moins que tu copies à la main ton fichier depuis une clé usb ou que tu n'as aucun stockage externe/backup

                                  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…

                                  Par contre prétendre que ta solution est meilleure

                                  Je n'ai pas dit une seule fois que c'est "la meilleure".
                                  J'ai juste dit que ça répond parfaitement à mon besoin…

                                  ton script va installer des trucs de toute manière

                                  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.

                                  globalement c'est moins facilement maintenable

                                  Nope, je le maintiens très facilement…

                                  https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                          • [^] # Re: Devops

                            Posté par . Évalué à 2.

                            Je peux alors lancer ./postinstall.sh vim pour 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…

                            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.

                            Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.

                            Que tu gère 1 ou 10 machine la complexité ne change pas.

                            ce script de postinstallation, je l'utilise une fois tous les 6 mois quand j'installe la version suivante d'Ubuntu.

                            Pourquoi aurais-tu besoin de faire ça ? Ta machine explose à chaque maj d'ubuntu ?

                            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.

                            En gros tu sais pas ce que tu fais ! Pourquoi ne versionnes-tu pas tes fichiers de conf ?

                            apt install git ansible && git clone && ansible-playbook installation.yml
                            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 :)

                            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 . Évalué à 2.

                        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) :

                        file { "/etc/bidule.conf":
                          ensure  => present,
                          content => inline_template($header, $content, $footer),
                          notify  => Service['bidule'],
                        }
                        

                        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 . Évalué à 2. Dernière modification le 18/05/17 à 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 (page perso) . É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 (page perso) . Évalué à 1.

                              Pour "le script de postinstallation de mon PC perso", il n'y a pas plusieurs cas de figure…

                              https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                              • [^] # Re: Devops

                                Posté par (page perso) . É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 (page perso) . Évalué à 1.

                          Je suis cohérent mais tu mélanges 2 posts qui ne répondent pas aux même questions.

                          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.

                          Tu crois que tu peux gérer tout ça en moins de lignes avec ton script ?

                          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.sh sans 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.

                          Dans les outils de gestions de versions tu gères des dépendances.

                          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…

                          https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

                          • [^] # Re: Devops

                            Posté par . Évalué à 2. Dernière modification le 22/05/17 à 09:49.

                            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.

                            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é.

                            Et puis je veux qu'il m'affiche des messages sur son avancement.

                            C'est le cas des gestionnaire de config avec une verbosité qui peut être plus ou moins élevée.

                            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.

                            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.

                            Dans les outils de gestions de versions tu gères des dépendances.
                            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 :)

                            Je ne comprends pas, ça ne veut rien dire ton histoire de duplication de lignes.

                            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…

                            Ben justement, tu n'as pas l'air très au fait des principes de base de leur fonctionnement.

    • [^] # Re: Devops

      Posté par . É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 (page perso) . É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 :-)

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

        • [^] # Re: Devops

          Posté par . É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 (page perso) . Évalué à 2.

            sacrum boyard

            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…)

            qui rend une équipe agile.

            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 :

            • efficace : bin oui, on ne fait que la doc' nécessaire et adapte le modèle à la complexité (si c'est dans le code ou trop technique, spa gênant que tout le monde ne sache pas le lire, tant que ça fonctionne)
            • la méthode la râche, malencontreusement, oubliant généralement ceux qui vont prendre l'action dans les réunions préalable (appelé méthode « je me tire dans le pied » ou « tête dans le guidon » et pas foutu d'apprendre des bonnes pratiques, ni de ses erreurs o_O

            ce n'est pas une question d'outils, mais d'organisation.

            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 (page perso) . É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é…

        https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

  • # Mauvais lien vers le whitepaper

    Posté par (page perso) . É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.

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Preseed

    Posté par . É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 (page perso) . Évalué à 1.

      Merci, c'est bon à savoir.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.