Implemente Ansible Tower y Terraform

¿Alguna vez se preguntó acerca de la sinergia potencial que se puede lograr entre Terraform y Ansible? En este blog, exploro un ejemplo práctico de cómo estas tecnologías pueden simplificar los flujos de trabajo para administradores de sistemas, desarrolladores y usuarios dentro de un ecosistema cada vez más complejo de infraestructuras de nube múltiples e híbridas. .

No es ningún secreto que en 2019, las organizaciones buscan diversificar aún más su infraestructura al tener una participación cero en una sola canasta, ya sea una nube privada, una nube pública o una infraestructura local tradicional. Parte de este movimiento es la migración a una visión del mundo centrada en las aplicaciones donde la infraestructura es puramente agnóstica: no nos importa dónde/qué es o cómo llegó allí, solo nos importa dejarla allí. Para que esto sea manejable, las organizaciones necesitan la capacidad de tener consistencia a gran escala, eficiencia a gran escala y portabilidad para administrar sin importar dónde.

Entrar Infraestructura como código (IaC). Aunque un poco lejos del propósito de este blog, es en sí mismo una demostración de IaC. No es necesariamente un concepto nuevo, herramientas como Ansible, Terraform, Puppet, Chef han existido por un tiempo. Sin embargo, la idea central de este blog es que examinar las fortalezas de una herramienta y admitir sus debilidades puede conducir a una gran innovación en la simplificación de los flujos de trabajo que satisfacen las necesidades informáticas modernas.

Así que echemos un vistazo.

Índice

    El escenario

    Utilice la automatización para implementar AWX (Ansible Tower aguas arriba) en Google Cloud Platform. Este es un caso de uso bastante básico, pero volveré a explicar por qué el paquete de software que seleccionamos no es importante. Elegí Terraform y Ansible como herramientas de automatización simplemente por su popularidad y por el hecho de que he estado trabajando con ellos casi a diario últimamente.

    Opciones a considerar

    Opción 1: Manualmente

    No. Estamos en 2019.

    Opción 2: aprovisionamiento manual + automatización bash

    GCP tiene la idea de un 'url-secuencia de comandos de inicio' que se pueden configurar como metadatos en una instancia de VM. La idea es que siempre use la interfaz de usuario para iniciar una instancia de VM y configurar los metadatos en consecuencia. No es una mala idea, sin embargo, hay espacio para errores en la especificación de la VM y no es escalable, eficiente o portátil de ninguna manera.

    Opción 3: Totalmente en Ansible o Terraform

    Esta opción tiene piernas y es probablemente donde aterrizarían muchos. Ambas herramientas ofrecen consistencia a gran escala, eficiencia a gran escala y son moderadamente portátiles. Ambos ofrecen un excelente soporte para todos los principales proveedores de nube e infraestructura local. Sin embargo, combinar los dos enfoques será ideal y nos llevará a la opción 4.

    Opción 4: Terraform para aprovisionamiento, Ansible para configuración

    Ok, si leíste el título de este blog, sabías que aquí es donde íbamos a aterrizar y estratégicamente dejé lo mejor para el final. Una de las razones por las que me gusta este enfoque es que hay una demarcación muy clara entre proveedor y configuración. Esto hace que su administración de configuración sea completamente portátil, ya sea GCP, AWS, Azure, en las instalaciones, lo que sea. Solo necesita asegurarse de que ha modularizado correctamente su Terraform y que tiene una solución 100% portátil. Esta solución satisface rápidamente la consistencia a gran escala, la eficiencia a gran escala y la portabilidad.

    Flujo de trabajo simplificado

    Un subproducto interesante de este enfoque es un flujo de trabajo muy simplificado. Cuando utiliza módulos Terraform, su principal.tf se convierte en una fuente única y muy limpia de variables definidas por el usuario con un trabajo de configuración y aprovisionamiento completamente abstracto. Veamos una configuración de flujo de trabajo de ejemplo para implementar AWX en GCP:

    ---
    
    main.tf
    module "gcp" {
         source                 = "./modules/gcp"
         awx_admin              = "admin"
         awx_admin_pass         = "supersecretpassword"
         gcp_json               = "~/projects/awx-ansible-setup/secrets/mleblanc-ce-prov.json"
         gcp_project_id         = "solar-cab-231515"
         gcp_region             = "northamerica-northeast1"
         gcp_zone               = "a"
         gcp_instance_name      = "awx01"
         gcp_instance_os        = "centos-cloud/centos-7"
         ssh_key_path           = "~/.ssh/"
         ssh_key_pub            = "gcp_rsa.pub"
         ssh_key_priv           = "gcp_rsa"
         ssh_user               = "mleblanc"
      }
        
      # source             = module path. Do not Change
      # gcp_json           = GCP Service Account Key (path + filename) 
      # gcp_project_id     = GCP Project ID
      # gcp_region         = GCP Region for instances ie northamerica-northeast
      # gcp_zone           = GCP Zone within the region ie a,b,c
      # gcp_instance_name  = The instance name as it will appear in GCP https://cloud.google.com/compute/docs/regions-zones/
      # gcp_instance_os    = The OS Image to use - public images https://cloud.google.com/compute/docs/images#os-compute-support
      # ssh_key_path       = Path to SSH key pair to use
      # ssh_key_pub        = Public Key filename to be provisioned to the instance
      # ssh_key_priv       = Private Key filename 
      # ssh_user           = Username for ssh

    Una vez principal.tf se configuró, este ejemplo se ejecuta completamente a través de terraform, no hay otros archivos o scripts para que un usuario modifique o ejecute.

    --- 
    $ terraform init
            Initializing modules...
            - module.gcp
              Getting source "./modules/gcp"
            
            Initializing provider plugins...
            - Checking for available provider plugins on https://releases.hashicorp.com...
            - Downloading plugin for provider "google" (2.1.0)...
            
            The following providers do not have any version constraints in configuration,
            so the latest version was installed.
            
            To prevent automatic upgrades to new major versions that may contain breaking
            changes, it is recommended to add version = "..." constraints to the
            corresponding provider blocks in configuration, with the constraint strings
            suggested below.
            
            * provider.google: version = "~> 2.1"
            
            Terraform has been successfully initialized!
            
            You may now begin working with Terraform. Try running "terraform plan" to see
            any changes that are required for your Infraestructura. All Terraform commands
            should now work.
            
            If you ever set or change modules or backend configuration for Terraform,
            rerun this command to reinitialize your working directory. If you forget, other
            commands will detect it and remind you to do so if necessary.
    $ terraform plan
            Refreshing Terraform state in-memory prior to plan...
            The refreshed state will be used to calculate this plan, but will not be
            persisted to local or remote state Almacenamiento.
            
            
            ------------------------------------------------------------------------
            
            An execution plan has been generated and is shown below.
            Resource actions are indicated with the following symbols:
              + create
            
            Terraform will perform the following actions:
            
              + module.gcp.google_compute_firewall.default
              + module.gcp.google_compute_instance.awx01
            
            
            Plan: 2 to add, 0 to change, 0 to destroy.
            
            ------------------------------------------------------------------------
    
            
            Note: You didn't specify an "-out" parameter to save this plan, so Terraform
            can't guarantee that exactly these actions will be performed if
            "terraform apply" is subsequently run.

    El plano de Terraform nos dice lo que se va a construir. En este caso, se aprovisionan dos recursos: una regla de firewall asociada con la red predeterminada y una máquina virtual de motor de cómputo denominada awx01. Gran parte de la salida se ha redactado en este caso, pero la salida mostrada es lo que nos interesa.

    $ terraform apply
            module.gcp.google_compute_instance.awx01: Creation complete after 5m35s (ID: awx01)
            
            Apply complete! Resources: 2 added, 0 changed, 0 destroyed.```

    Toda la salida de la aplicación Terraform es demasiado detallada para ser útil en este blog, pero considere esto. Un solo flujo de trabajo realizó las siguientes tareas en 5 minutos y 35 segundos:

    En otra vida, sé que en una empresa con una estructura de departamento de TI más tradicional, realizar este tipo de instalación llevaría semanas o incluso meses. Algunos puntos importantes a tener en cuenta aquí: no importa cuántas veces se ejecute este flujo, el resultado final es el mismo. Sin embargo, lo que es más importante, el número de sistemas a los que esto se aplica es irrelevante. Ya sea 1 servidor, 10, 100, 1000, el flujo de trabajo brindará un resultado final consistente en aproximadamente 5,5 minutos.

    ¡Pero espera! ¡Hay más!

    Hasta ahora, hemos hablado sobre un flujo de trabajo simplificado y mostramos los 3 pasos simples a seguir para implementar esta demostración. Es posible que se haya notado que hubo poca o ninguna mención de ansible más allá del hecho de que creo que es mejor en la gestión de la configuración. Echemos un vistazo a esto.

    Hay varias maneras de manejar esto. En el caso de esta demostración, utilicé Terraform proveedor de ejecución remota para hacer un arranque para ansible + git, luego ejecute un libro de jugadas de Ansible.

    provisioner "remote-exec" {
            connection { 
              type    = "ssh"
              user    = "${var.ssh_user}"
              timeout = "500s"
              private_key = "${file("${var.ssh_key_path}${var.ssh_key_priv}")}"
            }
            inline = [
              "sudo yum -y install git ansible",
              "sudo ansible-playbook install-awx.yml"

    Dependiendo de sus necesidades, podemos considerar el uso de la aprovisionador ejecutivo local bastante. Esto eliminaría el requisito de arrancar Ansible y git en el sistema remoto.

    Envoltura

    Pensando en mis declaraciones anteriores de que una organización necesita consistencia y eficiencia a escala, así como portabilidad, veamos cómo se mantiene esta solución de emparejamiento de Terraform y Ansible.

    1) ¿Es efectivo? 1,10,100,1000 servidores con software instalado en ~5m30s - Sí

    2) ¿Es consistente? Las únicas partes cambiables son específicas del proyecto, la construcción real sigue siendo la misma - Sí

    3) ¿Es transportable? Existen algunos ajustes en la terraformación para asegurarse de que está utilizando los proveedores adecuados. Sin embargo, esta demostración era específica de GCP. Terraform tiene proveedores para muchos proveedores de nube y tecnologías locales

    Vea la demostración en acción en el Canal de Youtube del equipo de Arctiq.

    Artículos de interés

    Subir