{"id":80289,"date":"2020-05-05T01:42:36","date_gmt":"2020-05-04T23:42:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev"},"modified":"2020-05-05T01:42:36","modified_gmt":"2020-05-04T23:42:36","slug":"ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible : Migration de la configuration de 120 VM de CoreOS vers CentOS en 18 mois","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible<\/p>\n

<\/p>\n

Ceci est la transcription de la pr\u00e9sentation \u00e0 DevopsConf 2019-10-01<\/a><\/noindex> et SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

C'est l'histoire d'un projet qui utilisait un syst\u00e8me de gestion des configurations fait maison et pourquoi la migration vers Ansible a dur\u00e9 18 mois.<\/p>\n

<\/a><\/noindex><\/p>\n

Jour n\u00b0 -XXX : Avant le d\u00e9but<\/h2>\n

<\/p>\n

\"Ansible<\/p>\n

<\/p>\n

Au d\u00e9part, l'infrastructure se composait de plusieurs h\u00f4tes autonomes g\u00e9r\u00e9s par Hyper-V. Cr\u00e9er une machine virtuelle n\u00e9cessitait de nombreuses actions : placer les disques au bon endroit, configurer le DNS, r\u00e9server le DHCP, placer la configuration de la VM dans un d\u00e9p\u00f4t git. Ce processus \u00e9tait partiellement automatis\u00e9, mais par exemple, les VMs \u00e9taient r\u00e9parties entre les h\u00f4tes manuellement. Cependant, les d\u00e9veloppeurs pouvaient appliquer une configuration de VM en la modifiant dans git et en red\u00e9marrant la VM.<\/p>\n

<\/p>\n

Solution de gestion de configuration personnalis\u00e9e<\/h3>\n

<\/p>\n

\"Ansible<\/p>\n

<\/p>\n

L'id\u00e9e de d\u00e9part, je le soup\u00e7onne, \u00e9tait con\u00e7ue comme IaC : de nombreuses VMs sans \u00e9tat, qui r\u00e9initialisaient leur \u00e9tat lors du red\u00e9marrage. Que repr\u00e9sentait la gestion des configurations des VMs ? Cela semblait simple sch\u00e9matiquement :<\/p>\n

<\/p>\n

    \n
  1. Pour les VMs, un MAC statique \u00e9tait fix\u00e9.<\/li>\n
  2. On connectait \u00e0 la VM un ISO avec CoreOS et un disque de d\u00e9marrage.<\/li>\n
  3. CoreOS ex\u00e9cute un script de personnalisation en le t\u00e9l\u00e9chargeant depuis un serveur WEB en fonction de son IP.<\/li>\n
  4. Le script r\u00e9cup\u00e8re la configuration de la VM via SCP en se basant sur l'adresse IP.<\/li>\n
  5. Une s\u00e9rie de fichiers unitaires systemd et une s\u00e9rie de scripts bash sont lanc\u00e9s.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible<\/p>\n

    <\/p>\n

    Cette solution avait de nombreux probl\u00e8mes \u00e9vidents :<\/p>\n

    <\/p>\n

      \n
    1. L'ISO dans CoreOS \u00e9tait obsol\u00e8te.<\/li>\n
    2. Nombreux actes et magie difficilement automatissables lors de la migration\/cr\u00e9ation des VMs.<\/li>\n
    3. Difficult\u00e9 de mise \u00e0 jour lorsque certains logiciels n\u00e9cessitent une version donn\u00e9e. C\u2019est encore plus amusant avec les modules du noyau.<\/li>\n
    4. Les VMs n'\u00e9taient pas si d\u00e9pourvues de donn\u00e9es, c'est-\u00e0-dire qu'il y avait des VMs avec un disque mont\u00e9 contenant des donn\u00e9es utilisateur en suppl\u00e9ment.<\/li>\n
    5. Quelqu'un avait constamment des probl\u00e8mes avec les d\u00e9pendances des unit\u00e9s systemd et lors du red\u00e9marrage, CoreOS se bloquait. Il \u00e9tait difficile de rep\u00e9rer \u00e7a avec les outils disponibles dans CoreOS.<\/li>\n
    6. Gestion des secrets.<\/li>\n
    7. La gestion de configuration \u00e9tait quasiment inexistante. Il y avait des scripts bash et des configurations YML de CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Pour appliquer la configuration de la VM, il fallait la red\u00e9marrer, mais elle pouvait ne pas red\u00e9marrer. Cela semble \u00eatre un probl\u00e8me \u00e9vident, mais il n'y avait pas de disques persistants \u2014 les journaux n'avaient nulle part o\u00f9 \u00eatre enregistr\u00e9s. Eh bien, d'accord, essayons d'ajouter des options de d\u00e9marrage du noyau pour transmettre les journaux. Mais non, tout cela est si compliqu\u00e9.<\/p>\n

      <\/p>\n

      Jour n\u00b00 : Reconnaissance du probl\u00e8me<\/h2>\n

      <\/p>\n

      \"Ansible<\/p>\n

      <\/p>\n

      C'\u00e9tait une infrastructure de d\u00e9veloppement classique : jenkins, environnements de test, surveillances, registry. CoreOS \u00e9tait con\u00e7u pour l'h\u00e9bergement de clusters k8s, c'est-\u00e0-dire que le probl\u00e8me \u00e9tait comment CoreOS \u00e9tait utilis\u00e9. La premi\u00e8re \u00e9tape a \u00e9t\u00e9 de choisir la stack. Nous avons opt\u00e9 pour :<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> comme distribution de base, car c'est la distribution la plus proche des environnements de production.<\/li>\n
      2. Ansible<\/strong> pour la gestion des configurations, car il y avait une vaste expertise \u00e0 ce sujet.<\/li>\n
      3. Jenkins<\/strong> comme framework d'automatisation des processus existants, car il \u00e9tait d\u00e9j\u00e0 utilis\u00e9 de mani\u00e8re active pour les processus de d\u00e9veloppement.<\/li>\n
      4. Hyper-V<\/strong> comme plateforme de virtualisation. Il y a plusieurs raisons qui vont au-del\u00e0 de ce r\u00e9cit, mais en r\u00e9sum\u00e9 \u2014 nous ne pouvons pas utiliser le cloud, nous devons utiliser notre propre mat\u00e9riel.<\/li>\n<\/ol>\n

        <\/p>\n

        Jour n\u00b030 : Formalisation des accords existants \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible<\/p>\n

        <\/p>\n

        Une fois la stack d\u00e9finie, la pr\u00e9paration \u00e0 la migration a commenc\u00e9. Formaliser les accords existants sous forme de code (Agreements as Code<\/strong>!). Migration travail manuel<\/em> -> m\u00e9canisation<\/em> -> qui permet de tester, d\u00e9ployer et livrer de nouvelles fonctionnalit\u00e9s aux utilisateurs beaucoup plus rapidement. Par exemple, dans tous nos projets, un pipeline CI est automatiquement cr\u00e9\u00e9 \u00e0 chaque commit. Celui-ci construit l'image, la teste, la d\u00e9ploie dans divers environnements Kubernetes pour le d\u00e9bogage et les v\u00e9rifications restantes, et si tout va bien, les modifications atteignent l'utilisateur final. Ce n'est plus une science-fus\u00e9e, mais une banalit\u00e9 pour beaucoup \u2014 probablement pour vous \u00e9galement, puisque vous lisez cet article.<\/em>.<\/p>\n

        <\/p>\n

        1. Configurer les VM<\/h4>\n

        <\/p>\n

        \"Ansible<\/p>\n

        <\/p>\n

        Ansible g\u00e8re tr\u00e8s bien cette t\u00e2che. Avec un minimum d'efforts, nous pouvons prendre en charge les configurations des VM :<\/p>\n

        <\/p>\n

          \n
        1. Cr\u00e9ons un d\u00e9p\u00f4t git.<\/li>\n
        2. Nous pla\u00e7ons la liste des VM dans l'inventaire, les configurations dans des playbooks et des r\u00f4les.<\/li>\n
        3. Nous configurons un esclave jenkins sp\u00e9cial \u00e0 partir duquel nous pourrons ex\u00e9cuter ansible.<\/li>\n
        4. Cr\u00e9ons un job, configurons Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          Le premier processus est pr\u00eat. Les accords sont formalis\u00e9s.<\/p>\n

          <\/p>\n

          2. Cr\u00e9er une nouvelle VM<\/h4>\n

          <\/p>\n

          \"Ansible<\/p>\n

          <\/p>\n

          Ici, tout n'\u00e9tait pas tr\u00e8s pratique. Il n'est pas tr\u00e8s commode de cr\u00e9er des VM sous Hyper-V depuis Linux. Une des tentatives de m\u00e9caniser ce processus a \u00e9t\u00e9 :<\/p>\n

          <\/p>\n

            \n
          1. Ansible se connecte via WinRM \u00e0 l'h\u00f4te Windows.<\/li>\n
          2. Ansible ex\u00e9cute un script powershell.<\/li>\n
          3. Le script Powershell cr\u00e9e une nouvelle VM.<\/li>\n
          4. Avec Hyper-V\/ScVMM, lors de la cr\u00e9ation de la VM, le nom d'h\u00f4te est configur\u00e9 dans le syst\u00e8me d'exploitation invit\u00e9.<\/li>\n
          5. La VM, lors de la mise \u00e0 jour du bail DHCP, envoie son nom d'h\u00f4te.<\/li>\n
          6. L'int\u00e9gration standard ddns & dhcp du c\u00f4t\u00e9 du Contr\u00f4leur de Domaine configure l'enregistrement DNS.<\/li>\n
          7. Nous pouvons ajouter la VM \u00e0 l'inventaire et la configurer avec Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Cr\u00e9er un mod\u00e8le de VM<\/h4>\n

            <\/p>\n

            \"Ansible<\/p>\n

            <\/p>\n

            Ici, nous n'avons rien invent\u00e9 \u2014 nous avons pris packer.<\/p>\n

            <\/p>\n

              \n
            1. Nous pla\u00e7ons la configuration de packer, kickstart dans le d\u00e9p\u00f4t git.<\/li>\n
            2. Nous configurons un esclave jenkins sp\u00e9cial avec hyper-v et Packer.<\/li>\n
            3. Cr\u00e9ons un job, configurons Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Comment ce lien fonctionne :<\/p>\n

              <\/p>\n

                \n
              1. Packer cr\u00e9e une VM vide, y attache l'ISO.<\/li>\n
              2. La VM d\u00e9marre, Packer entre dans le chargeur de d\u00e9marrage la commande d'utiliser notre fichier kickstart depuis la disquette ou http.<\/li>\n
              3. Anaconda se lance avec notre configuration, la mise en place initiale de l'OS se fait.<\/li>\n
              4. Packer attend la disponibilit\u00e9 de la VM.<\/li>\n
              5. Packer ex\u00e9cute Ansible \u00e0 l'int\u00e9rieur de la VM en mode local.<\/li>\n
              6. Ansible utilise exactement les m\u00eames r\u00f4les que dans l'\u00e9tape n\u00b01.<\/li>\n
              7. Packer exporte le mod\u00e8le de VM.<\/li>\n<\/ol>\n

                <\/p>\n

                Jour n\u00b075 : Refactorisation des accords sans casser = Test ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Fixer les accords dans le code peut \u00eatre insuffisant. En effet, si tu veux changer quelque chose en profondeur dans le processus, tu risques de tout casser. C'est pourquoi, en mati\u00e8re d'infrastructure, il devient crucial de tester cette m\u00eame infrastructure. Pour synchroniser les connaissances au sein de l'\u00e9quipe, nous avons commenc\u00e9 \u00e0 tester les r\u00f4les Ansible. Je ne vais pas entrer dans les d\u00e9tails, car il existe un article qui d\u00e9crit les \u00e9v\u00e9nements \u00e0 ce moment-l\u00e0. Teste-moi si tu peux ou les programmeurs YML r\u00eavent-ils de tester ansible ?<\/a><\/noindex>(spoiler, ce n'\u00e9tait pas la version finale et tout est devenu plus compliqu\u00e9 par la suite) Comment commencer \u00e0 tester Ansible, refactoriser un projet en un an et ne pas perdre la raison.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Jour n\u00b0130 : Et si CentOS+ansible n'\u00e9tait pas n\u00e9cessaire ? Peut-\u00eatre openshift ?<\/h3>\n

                <\/p>\n

                Il faut comprendre que le processus d'int\u00e9gration de l'infrastructure n'\u00e9tait pas unique et qu'il y avait des sous-projets connexes. Par exemple, une demande est arriv\u00e9e pour d\u00e9ployer notre application sur openshift, ce qui a entra\u00een\u00e9 des recherches durant plus d'une semaine. Nous d\u00e9ployons l'application sur Openshift et comparons les outils existants.<\/a><\/noindex> Ce qui a retard\u00e9 le processus de migration. Au final, il s'est av\u00e9r\u00e9 qu'openshift ne satisfait pas tous les besoins, il faut du mat\u00e9riel r\u00e9el, ou au moins la possibilit\u00e9 de jouer avec le noyau.<\/p>\n

                <\/p>\n

                Jour n\u00b0170 : Openshift n'est pas adapt\u00e9, prenons le risque avec Windows Azure Pack ?<\/h3>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Hyper-V n'est pas tr\u00e8s amical, SCVMM ne l'am\u00e9liore pas beaucoup. Mais il existe un outil appel\u00e9 Windows Azure Pack, qui est une surcouche \u00e0 SCVMM et imite Azure. Cependant, en r\u00e9alit\u00e9, le produit semble abandonn\u00e9 : documentation avec des liens cass\u00e9s et plut\u00f4t succinte. Mais dans le cadre de la recherche de solutions pour simplifier notre cloud, nous avons \u00e9galement examin\u00e9 cela.<\/p>\n

                <\/p>\n

                Jour n\u00b0250 : Windows Azure Pack n'est pas super. Nous restons sur SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Windows Azure Pack semblait prometteur, mais il a \u00e9t\u00e9 d\u00e9cid\u00e9 de ne pas introduire WAP avec ses complications dans le syst\u00e8me pour des fonctionnalit\u00e9s inutiles et nous sommes rest\u00e9s avec SCVMM.<\/p>\n

                <\/p>\n

                Jour n\u00b0360 : Nous mangeons l'\u00e9l\u00e9phant morceau par morceau.<\/h3>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Ce n'est qu'un an plus tard que la plateforme \u00e0 laquelle migrer a \u00e9t\u00e9 pr\u00eate et le processus de migration a commenc\u00e9. Pour cela, une t\u00e2che S.M.A.R.T. a \u00e9t\u00e9 d\u00e9finie. Nous avons dress\u00e9 une liste de toutes les VMs et avons commenc\u00e9 \u00e0 examiner leur configuration une par une, \u00e0 la d\u00e9crire sur Ansible et \u00e0 la couvrir de tests.<\/p>\n

                <\/p>\n

                Jour n\u00b0450 : Quel syst\u00e8me a \u00e9t\u00e9 obtenu ?<\/h3>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Le processus lui-m\u00eame n'est pas int\u00e9ressant. Il est routinier, on peut noter que la plupart des configurations \u00e9taient relativement simples ou isomorphes et selon le principe de Pareto, 80 % des configurations ont n\u00e9cessit\u00e9 20 % du temps. De la m\u00eame mani\u00e8re, 80 % du temps a \u00e9t\u00e9 consacr\u00e9 \u00e0 la pr\u00e9paration du d\u00e9m\u00e9nagement et seulement 20 % au d\u00e9m\u00e9nagement lui-m\u00eame. <\/p>\n

                <\/p>\n

                Jour n\u00b0540 : La finale<\/h2>\n

                <\/p>\n

                \"Ansible<\/p>\n

                <\/p>\n

                Que s'est-il pass\u00e9 en 18 mois ?<\/p>\n

                <\/p>\n

                  \n
                1. Les accords sont devenus un code.<\/li>\n
                2. Travail manuel<\/em> -> M\u00e9canisation<\/em> -> Automatisation<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Liens<\/h2>\n

                  <\/p>\n