{"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\/es\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migraci\u00f3n de la configuraci\u00f3n de 120 VM de CoreOS a CentOS en 18 meses","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Esta es una transcripci\u00f3n de la presentaci\u00f3n en DevopsConf 2019-10-01<\/a><\/noindex> y SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Esta es la historia de un proyecto que utilizaba un sistema de gesti\u00f3n de configuraciones hecho a medida y por qu\u00e9 la migraci\u00f3n a Ansible se prolong\u00f3 durante 18 meses.<\/p>\n

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

D\u00eda \u2116 -XXX: Antes de comenzar<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Inicialmente, la infraestructura consist\u00eda en numerosos hosts independientes gestionados por Hyper-V. La creaci\u00f3n de una m\u00e1quina virtual requer\u00eda m\u00faltiples acciones: colocar los discos en el lugar correcto, configurar DNS, reservar DHCP, y almacenar la configuraci\u00f3n de la MV en un repositorio git. Este proceso estaba parcialmente automatizado, pero por ejemplo, las MV se distribu\u00edan entre los hosts manualmente. Sin embargo, los desarrolladores pod\u00edan modificar la configuraci\u00f3n de la MV en git y aplicarla reiniciando la MV.<\/p>\n

<\/p>\n

Soluci\u00f3n de Gesti\u00f3n de Configuraciones Personalizada<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

La idea inicial, sospecho, se pens\u00f3 como IaC: numerosas MV sin estado, que al reiniciarse restablec\u00edan su estado. \u00bfC\u00f3mo se ve\u00eda la gesti\u00f3n de configuraciones de las MV? Es esquem\u00e1ticamente simple:<\/p>\n

<\/p>\n

    \n
  1. Se asignaban direcciones MAC est\u00e1ticas a las MV.<\/li>\n
  2. Se conectaba una ISO con CoreOS y un disco de arranque a la MV.<\/li>\n
  3. CoreOS ejecuta un script de personalizaci\u00f3n descarg\u00e1ndolo de un servidor WEB en funci\u00f3n de su IP.<\/li>\n
  4. El script extrae la configuraci\u00f3n de la MV a trav\u00e9s de SCP bas\u00e1ndose en la direcci\u00f3n IP.<\/li>\n
  5. Se inicia una serie de archivos de unidad systemd y una serie de scripts bash.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Esta soluci\u00f3n ten\u00eda muchos problemas evidentes:<\/p>\n

    <\/p>\n

      \n
    1. La ISO en CoreOS estaba en desuso.<\/li>\n
    2. Una multitud de acciones y magia dif\u00edciles de automatizar al migrar\/crear MV.<\/li>\n
    3. Dificultades con las actualizaciones y cuando se necesitaba un software de cierta versi\u00f3n. A\u00fan m\u00e1s complicado con los m\u00f3dulos del n\u00facleo.<\/li>\n
    4. Las MV no estaban completamente vac\u00edas de datos, es decir, hab\u00eda MV que ten\u00edan un disco montado con datos del usuario adicionalmente.<\/li>\n
    5. Constantemente hab\u00eda alguien que comet\u00eda errores con las dependencias de las unidades systemd, y al reiniciar, CoreOS se colgaba. Era problem\u00e1tico detectar esto con los medios disponibles en CoreOS.<\/li>\n
    6. Gesti\u00f3n de secretos.<\/li>\n
    7. No hab\u00eda una gesti\u00f3n de configuraciones, solo hab\u00eda bash y configuraciones YML de CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Para aplicar la configuraci\u00f3n de la MV, era necesario reiniciarla, pero esta podr\u00eda no reiniciarse. Parec\u00eda un problema obvio, pero no hay discos persistentes, no hab\u00eda lugar para guardar los logs. Bueno, intentemos agregar opciones de arranque del n\u00facleo para enviar los logs. Pero no, todo es tan complicado.<\/p>\n

      <\/p>\n

      D\u00eda \u21160: Reconocimiento del problema<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Era una infraestructura de desarrollo com\u00fan: jenkins, entornos de prueba, monitoreos, registry. CoreOS estaba pensado para alojar cl\u00fasteres de k8s, es decir, el problema radicaba en c\u00f3mo se estaba utilizando CoreOS. El primer paso fue elegir la pila.<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> como distribuci\u00f3n base, ya que es la distribuci\u00f3n m\u00e1s cercana a los entornos de producci\u00f3n.<\/li>\n
      2. Ansible<\/strong> para la gesti\u00f3n de configuraciones, dado que hab\u00eda una amplia experiencia en ello.<\/li>\n
      3. Jenkins<\/strong> como un marco para la automatizaci\u00f3n de procesos existentes, ya que ya se utilizaba activamente para procesos de desarrollo.<\/li>\n
      4. Hyper-V<\/strong> como plataforma de virtualizaci\u00f3n. Hay varias razones, m\u00e1s all\u00e1 de lo que se puede contar, pero en resumen: no podemos utilizar la nube, debemos usar nuestro propio hardware.<\/li>\n<\/ol>\n

        <\/p>\n

        D\u00eda N\u00ba30: Formalizando los acuerdos existentes \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Cuando se entendi\u00f3 la pila, comenz\u00f3 la preparaci\u00f3n para la migraci\u00f3n. Formalizando los acuerdos existentes en forma de c\u00f3digo (Agreements as Code<\/strong>!). Transici\u00f3n trabajo manual<\/em> -> mecanizaci\u00f3n<\/em> -> automatizaci\u00f3n<\/em>.<\/p>\n

        <\/p>\n

        1. Configurar VMs<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Ansible se desempe\u00f1a excelentemente en esta tarea. Con m\u00ednimas acciones, se puede gestionar las configuraciones de las VMs:<\/p>\n

        <\/p>\n

          \n
        1. Creamos un repositorio git.<\/li>\n
        2. Almacenamos la lista de VMs en el inventario, las configuraciones en playbooks y roles.<\/li>\n
        3. Configuramos un slave de jenkins especial desde el que se podr\u00e1 ejecutar ansible.<\/li>\n
        4. Creamos un job, configuramos Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          El primer proceso est\u00e1 listo. Los acuerdos est\u00e1n formalizados.<\/p>\n

          <\/p>\n

          2. Crear nueva VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Aqu\u00ed no era muy conveniente. Desde Linux no es muy f\u00e1cil crear VMs en Hyper-V. Uno de los intentos de mecanizar este proceso fue:<\/p>\n

          <\/p>\n

            \n
          1. Ansible se conecta al host de Windows a trav\u00e9s de WinRM.<\/li>\n
          2. Ansible ejecuta un script de PowerShell.<\/li>\n
          3. El script de PowerShell crea una nueva VM.<\/li>\n
          4. Con Hyper-V\/ScVMM, al crear una VM se configura el hostname en el sistema operativo invitado.<\/li>\n
          5. La VM al actualizar el lease de DHCP env\u00eda su hostname.<\/li>\n
          6. La integraci\u00f3n est\u00e1ndar de ddns & dhcp en el controlador de dominio configura la entrada DNS.<\/li>\n
          7. Se pueden a\u00f1adir VMs al inventario y configurarlas con Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Crear plantilla de VM<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Aqu\u00ed no se invent\u00f3 nada; utilizamos packer.<\/p>\n

            <\/p>\n

              \n
            1. En el repositorio git almacenamos la configuraci\u00f3n de packer, kickstart.<\/li>\n
            2. Configuramos un slave de jenkins especial con hyper-v y Packer.<\/li>\n
            3. Creamos un job, configuramos Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              C\u00f3mo funciona esta conexi\u00f3n:<\/p>\n

              <\/p>\n

                \n
              1. Packer crea una VM vac\u00eda, conecta el ISO.<\/li>\n
              2. La VM arranca, Packer introduce en el cargador el comando para usar nuestro archivo kickstart desde un disquete o http.<\/li>\n
              3. Se inicia anaconda con nuestra configuraci\u00f3n, se hace la configuraci\u00f3n inicial del sistema operativo.<\/li>\n
              4. Packer espera la disponibilidad de la VM.<\/li>\n
              5. Packer dentro de la VM ejecuta ansible en modo local.<\/li>\n
              6. Ansible utiliza exactamente los mismos roles que en el paso n\u00ba 1.<\/li>\n
              7. Packer exporta la plantilla de la VM.<\/li>\n<\/ol>\n

                <\/p>\n

                D\u00eda n\u00ba 75: Refactorizamos los acuerdos sin romper = Prueba de ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Fijar acuerdos en el c\u00f3digo puede no ser suficiente. A veces, si deseas cambiar algo durante el proceso, podr\u00edas romper algo. Por eso en la infraestructura tambi\u00e9n aparece la necesidad de probarla. Para sincronizar el conocimiento dentro del equipo, comenzamos a probar los roles de Ansible. No profundizar\u00e9, ya que hay un art\u00edculo que describe los eventos de ese momento. Pruebame si puedes o sue\u00f1an los programadores de YML con probar ansible?<\/a><\/noindex>(spoiler: esta no fue la versi\u00f3n final y despu\u00e9s todo se volvi\u00f3 m\u00e1s complicado) C\u00f3mo empezar a probar Ansible, refactorizar el proyecto en un a\u00f1o y no perder la cabeza.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 130: \u00bfY si CentOS+ansible no es necesario? \u00bfQuiz\u00e1s openshift?<\/h3>\n

                <\/p>\n

                Hay que entender que el proceso de incorporaci\u00f3n de infraestructura no fue el \u00fanico y hab\u00eda subproyectos paralelos. Por ejemplo, recibimos una solicitud para ejecutar nuestra aplicaci\u00f3n en openshift y esto result\u00f3 en investigaciones que tomaron m\u00e1s de una semana. Ejecutamos la aplicaci\u00f3n en Openshift y comparamos las herramientas existentes.<\/a><\/noindex> \u00bfQu\u00e9 ralentiz\u00f3 el proceso de migraci\u00f3n? Al final, result\u00f3 que openshift no cubr\u00eda todas las necesidades; necesit\u00e1bamos hardware real, o al menos la posibilidad de jugar con el n\u00facleo.<\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 170: Openshift no es adecuado, \u00bfnos arriesgamos con Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V no es muy amigable, SCVMM no lo mejora mucho. Pero existe Windows Azure Pack, que es una capa sobre SCVMM y mimetiza Azure. Sin embargo, en realidad, el producto parece abandonado: la documentaci\u00f3n est\u00e1 llena de enlaces rotos y es bastante escasa. Pero como parte de la investigaci\u00f3n de opciones para simplificar la vida de nuestra nube, tambi\u00e9n lo consideramos.<\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 250: Windows Azure Pack no es muy bueno. Nos quedamos en SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Windows Azure Pack parec\u00eda prometedor, pero se decidi\u00f3 no introducir WAP con sus complicaciones en el sistema por caracter\u00edsticas innecesarias y nos quedamos en SCVMM.<\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 360: Comemos al elefante en partes.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Solo despu\u00e9s de un a\u00f1o la plataforma estaba lista para migrar y comenz\u00f3 el proceso de traslado. Para esto, se estableci\u00f3 una tarea S.M.A.R.T. Enumeramos todas las VMs y comenzamos a revisar una por una junto con su configuraci\u00f3n, descripciones en Ansible y pruebas.<\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 450: \u00bfQu\u00e9 sistema se obtuvo?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                El proceso en s\u00ed no es interesante. Es rutinario; se puede se\u00f1alar que la mayor\u00eda de las configuraciones eran relativamente simples o isom\u00f3rficas y, siguiendo el principio de Pareto, el 80% de las configuraciones requiri\u00f3 el 20% del tiempo. Del mismo modo, el 80% del tiempo se dedic\u00f3 a la preparaci\u00f3n de la mudanza y solo el 20% al propio traslado. <\/p>\n

                <\/p>\n

                D\u00eda n\u00ba 540: Final<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                \u00bfQu\u00e9 ha pasado en 18 meses?<\/p>\n

                <\/p>\n

                  \n
                1. Los acuerdos se convirtieron en c\u00f3digo.<\/li>\n
                2. Trabajo manual<\/em> -> Mecanizaci\u00f3n<\/em> -> Automatizaci\u00f3n<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n