Journal Simple Provisioning System

Posté par  . Licence CC By‑SA.
Étiquettes :
21
26
oct.
2016

Hello les moules !

Voici Simple Provisioning System, un tout petit programme de moins de 200 lignes de code en c++11 qui permet de remplir une machine par ssh. N'ayant pas vraiment d'infrastructure je ne voulais pas sortir l'artillerie lourde. Ma problématique était que je voulais simplement un moyen de reproduire facilement une installation avec sa configuration ou la sauvegarder. Pas d'opérations très compliquées. De plus, je n'avais plus envie de maintenir une documentation qui de toutes manières ressemblait peu ou prou au script d'installation et vice-versa.

C'est pourquoi j'ai écrit sps, un truc simple et qui le restera (pas d'évolution dessus) parce qu'il me convient et que je n'aurais pas le temps de m'occuper d'éventuelles contributions.

Il vous suffit donc d'écrire une documentation au format Markdown avec juste quelques règles et ensuite n'exécuter que quelques parties de cette documentation. Les parties exécutées sont les sections de niveau 1 sélectionnées dans les paramètres fournies à sps.

https://github.com/soohwa/sps

  • # Choix du langage

    Posté par  . Évalué à 5.

    Salut,

    C'est chouette de partager ton code avec d'autre dans l'espoir qu'il soit utile. Merci !

    Petite question : pourquoi avoir choisi C++ pour un programme qui consiste essentiellement à manipuler des chaînes de caractères puis à les passer au shell ? Il me semble que ce n'est pas connu pour être une des grandes forces du langage.

    • [^] # Re: Choix du langage

      Posté par  . Évalué à 5.

      La réponse est assez simple : je suis un peu old-school et je ne connais pas bien les autres langages même si je sais qu'ils existent.

      Alors si cela peut donner des idées à d'autres personnes pour en reprendre le principe général (parser une doc pour en exécuter une partie) et l'implémenter dans d'autres langages ce serait plutôt cool et probablement mieux que ce que j'ai fait.

  • # Programmation littéraire

    Posté par  . Évalué à 5.

    Vous devriez jeter un œil sur les outils de programmation littéraire, inventée par Donald Knuth. TeX a été écrit en utilisant cette technique (PDF). Il existe aussi des outils pour le C++.

    Pour citer Knuth :

    Nous devons changer notre attitude traditionnelle envers la construction des programmes : au lieu de considérer que notre tâche principale est de dire à un ordinateur ce qu'il doit faire, appliquons-nous plutôt à expliquer à des êtres humains ce que nous voulons que l'ordinateur fasse.

    • [^] # Re: Programmation littéraire

      Posté par  . Évalué à 3.

      [HS] Ce concept a été inspiré à Donald Knuth par la lecture d'un article de Pierre-Arnoul de Marneffe, que certains lecteurs de ce site ont peut-être connu comme professeur à l'Université de Liège.

    • [^] # Re: Programmation littéraire

      Posté par  (site web personnel) . Évalué à 1.

      Je dirais que ce genre de programmation n'a jamais vraiment percé. Ce qui devient à la mode, c'est l'ingénierie par les modèles : https://fr.wikipedia.org/wiki/Ing%C3%A9nierie_dirig%C3%A9e_par_les_mod%C3%A8les

      "La première sécurité est la liberté"

      • [^] # Re: Programmation littéraire

        Posté par  . Évalué à 2.

        Il n'y a pas beaucoup de programmes écrits avec cette technique en effet.

        Je la trouve adaptée à l'écriture de certains types de programmes, de référence notamment. Tel que TeX, qui est complexe mais dont j'ai trouvé la lecture très claire. LCC, un compilateur C portable a aussi été écrit dans un langage littéraire. Ainsi que le livre "C Interfaces and Implementations" de David Hanson.

        Aussi, c'est que cela demande beaucoup de travail pour créer un programme littéraire bien écrit, plus qu'un programme classique. Et les mises à jour ne sont pas simple à suivre : on ne peut pas se permettre de sortir une nouvelle édition toutes les semaines ou tous les mois.

    • [^] # Re: Programmation littéraire

      Posté par  . Évalué à 0.

      C'est un lien très intéressant, merci.

  • # c++11

    Posté par  (site web personnel) . Évalué à 4.

    Du coup comme tu as dit que tu faisais du C++11, je me permet de commenter deux trois choses :

    • std::istringstream i (source_string.c_str());
      • Pas besoin de .c_str()
    • Pourquoi utiliser une chaîne C dans le main ? (ligne 119)

    Mis à part ça, code moderne :)

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: c++11

      Posté par  . Évalué à 1.

      std::istringstream i (source_string.c_str());
      Pas besoin de .c_str()

      Corrigé, merci :-)

      Pourquoi utiliser une chaîne C dans le main ? (ligne 119)

      En fait, je n'avais pas envie d'utiliser des substr …

  • # Ansible

    Posté par  . Évalué à 8.

    Ansible correspond pourtant bien à ton besoin. En tout cas je l'utilise pour exactement le même besoin.

    Ma problématique était que je voulais simplement un moyen de reproduire facilement une installation avec sa configuration ou la sauvegarder. Pas d'opérations très compliquées. De plus, je n'avais plus envie de maintenir une documentation qui de toutes manières ressemblait peu ou prou au script d'installation et vice-versa.

    Très vite mis en place, un échange de clé, python sur la machine distante et c'est parti !
    Un playbook simple se lit comme une doc, ça n'est pas du Markdown mais ça va bien.
    C'est un peu plus lourd que tes 200 lignes de code en C++, mais ça n'est pas l'artillerie lourde genre Puppet avec des agents partout.

    • [^] # Re: Ansible

      Posté par  . Évalué à 2.

      Ansible est clairement plus simple que puppet ou chef,le coté déploiement par ssh évite d'avoir des clients installés sur les cibles. Par contre niveau syntaxe et organisation des différentes fichiers c'est pas toujours ce qu'il y a de plus simple, le yaml permet pas mal de syntaxe différentes, les playbooks sont vraiment de qualité variables (très peu on des dry-run par exemple). Et malheureusement ça nécessite d'avoir du python sur la cible, ce qui n'est pas gênant pour du x86 mais beaucoup plus si on veut l'utiliser dans l'embarqué.

    • [^] # Re: Ansible

      Posté par  . Évalué à 3.

      Un playbook simple se lit comme une doc, ça n'est pas du Markdown mais ça va bien.

      Bof je trouve pas ça hyper lisible et la gestion du flow de contrôle, des variables, etc n'est pas très agréable je trouve.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Ansible

        Posté par  . Évalué à 1.

        C'est pour ça que j'ai parlé de playbook «simple», effectivement pour des choses complexes avec des appels de rôles dans tous les sens, des variables qui peuvent être à tous les niveaux (group_vars, hosts_vars, internes aux rôles ou aux playbooks, extra vars etc.) ça devient effectivement difficile. Mais du coup c'est beaucoup plus puissant.
        En fait je voulais juste dire que pour faire la même chose que SPS, il y avait déjà Ansible et que ça va bien.

  • # fabric

    Posté par  (Mastodon) . Évalué à 4.

    J'utilise fabric pour faire la même chose, en python.

    Je code des commandes : 

    from fabric import api

def apache_setup():
   api.run('apt-get install apache2')

    Ensuite je les execute:

    $ fab -H monserveur apache_setup

    Et apache2 est installé sur le serveur "monserveur"

    Voila… un fabfile et c'est réglé !

    • [^] # Re: fabric

      Posté par  . Évalué à 4.

      J'en ai profité pour aller voir. Il y a une version d'Invoke et Fabric2 est en cours de développement. C'est super !

      Pour ceux qui ne connaissent pas. Fabric1 c'est une bibliothèque python qui va permettre d’exécuter des actions sur un serveur donné (des fois juste avec un exec, comme dans l'exemple au dessus, des fois avec des syntaxes plus pythonique, comme le changement d'utilisateur qui se fait avec un with).

      La version 2 de fabric est une réécriture dans la quelle ils séparent la partie gestion de tâche/exécution de commande dans une bibliothèque Invoke et la partie SSH dans fabric2.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: fabric

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 27 octobre 2016 à 23:05.

        Malheureusement, fabric2 ne bouge pas beaucoup (du tout ?). Ils ont lancé le projet depuis quelques années, et il n'est toujours pas utilisable.
        De plus, fabric et ansible sont sur le même créneau (code Python lancé depuis le poste d'admin et connexion SSH vers les machines administrées), je ne suis pas sûr qu'il y ait de la place pour les deux outils (sachant qu'Ansible a plus ou moins raflé le marché).

        Bref, je trouve que parier sur fabric est plus risqué que parier sur Ansible comme techno pérenne.

        Note : ce jugement ne porte absolument pas sur les qualités et défauts des deux outils, uniquement sur un des questions les plus importantes pour moi : est-ce que mon investissement sera toujours d'actualité dans 5 ans ? Je pense que fabric sera oublié, contrairement à Ansible.

        • [^] # Re: fabric

          Posté par  . Évalué à 3.

          Alors ansible, à part si tu cherche à créer tes propres modules, le fais qu'il soit en python ne concerne pas l'utilisateur.

          Par contre, fabric est de la vieille école. Il fonctionne par action et pas par description. Et c'est ce second mode qui marche bien pour la gestion de configuration. Je vois plus fabric comme un outil pour développeur. Pour moi il concurrence plus capistrano.

          Mais oui si le développement est au ralenti, il est peut-être en fin de vie.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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