El libro "Terraform: infraestructura a nivel de código"

imagenHola habrozhiteli! El libro está destinado a todos los responsables del código ya escrito. Esto se aplica a los administradores de sistemas, especialistas de operaciones, ingenieros de SR, DevOps, desarrolladores de infraestructura, desarrolladores de ciclo completo, líderes de equipos de ingeniería y directores técnicos. Cualquiera sea su posición, si está involucrado en infraestructura, despliegue código, configure servidores, escale clústeres, haga copias de seguridad de datos, monitoree aplicaciones y responda llamadas a las tres de la mañana, este libro es para usted.

En conjunto, estas responsabilidades se denominan comúnmente actividades operativas (o administración del sistema). Anteriormente, los desarrolladores que sabían cómo escribir código pero no entendían la administración del sistema a menudo se encontraban; Los administradores de sistemas a menudo se encontraron sin la capacidad de escribir código. Una vez que esta separación fue aceptable, pero en el mundo moderno, que ya no se puede imaginar sin la computación en la nube y el movimiento DevOps, casi cualquier desarrollador necesita habilidades administrativas, y cualquier administrador del sistema debe poder programar.

No solo aprenderá cómo administrar la infraestructura en forma de código utilizando Terraform, sino que también aprenderá cómo encaja en el concepto general de DevOps. Aquí hay algunas preguntas que puede responder leyendo este libro.

  • ¿Por qué usar IaC?
  • , , ?
  • Terraform, Chef, Ansible, Puppet, Salt, CloudFormation, Docker, Packer Kubernetes?
  • Terraform ?
  • Terraform, ?
  • Terraform, ?
  • Terraform?
  • Terraform ?
  • Terraform ?

2017 . 2019- , ! . , .

, , , Terraform, .

  • Terraform. , Terraform 0.8. Terraform 0.12. , . , !
  • . Terraform. , , , , , , , .
  • . Terraform . , , — , .
  • . 8 , Terraform . , , , : , .
  • HCL2. Terraform 0.12 HCL HCL2. ( ${…}!), , , null, for_each for, . HCL2, 5 6.
  • . Terraform 0.9 . Terraform . Terraform 0.9 , ; 0.10 . 3.
  • Terraform. Terraform 0.10 ( AWS, GCP, Azure . .). , . terraform init , . 2 7.
  • . 2016 Terraform (AWS, GCP Azure). 100, , , 1. (, Alicloud, Oracle Cloud Infrastructure, VMware vSphere .), , (GitHub, GitLab BitBucket), (MySQL, PostreSQL InfluxDB), ( DataDog, New Relic Grafana), Kubernetes, Helm, Heroku, Rundeck Rightscale . , : , AWS , , CloudFormation!
  • Terraform. 2017 HashiCorp Terraform (registry.terraform.io) — , Terraform, . 2018 . Terraform 0.11 . « » . 153.
  • . Terraform 0.9 : , , errored.tfstate. Terraform 0.12 . , , .
  • . , (. « » . 144), « » (, « Terraform» . 242), plan apply (. « » . 64), create_before_destroy, count, (. «» . 160), , provider .

. Terraform


(se presta mucha más atención a los problemas de las pruebas automáticas en el libro más adelante)

El mundo DevOps está lleno de temores diferentes: todos tienen miedo de permitir que las cosas funcionen, pierdan datos o sean pirateados. Al realizar cualquier cambio, siempre se pregunta qué consecuencias tendrá. ¿Se comportará igual en todos los entornos? ¿Causará otra interrupción? Y, si eso sucede, ¿cuánto tendrá que permanecer en el trabajo esta vez para arreglarlo? A medida que la empresa crece, hay más en juego, lo que empeora el proceso de implementación y aumenta el riesgo de errores. Muchas compañías intentan minimizar este riesgo a través de implementaciones menos frecuentes, pero como resultado, cada implementación individual se vuelve más grande y más propensa a errores.

Si administra su infraestructura en forma de código, tiene una mejor manera de minimizar los riesgos: las pruebas. Su objetivo es darle suficiente confianza para hacer cambios. La palabra clave aquí es confianza: ninguna prueba puede garantizar que no haya errores, por lo que es más probable que lidie con la probabilidad. Si puede capturar toda su infraestructura y procesos de implementación como código, puede probar este código en un entorno de prueba. Si tiene éxito, existe una gran posibilidad de que el mismo código funcione en un entorno industrial. En un mundo de miedo e incertidumbre, la alta probabilidad y la confianza son caras.

En este capítulo, veremos el proceso de probar el código de infraestructura, tanto manual como automático, con énfasis en este último.

Pruebas manuales:

  • conceptos básicos de pruebas manuales;
  • limpieza de recursos después de las pruebas.

Pruebas automatizadas:

  • pruebas unitarias;
  • pruebas de integración;
  • pruebas de extremo a extremo;
  • Otros enfoques de prueba.

Pruebas manuales


Al pensar en cómo probar el código de Terraform, es útil establecer algunos paralelos con el código de prueba escrito en lenguajes de programación de uso general como Ruby. Imagina que estás escribiendo un simple servidor web Ruby en el archivo web-server.rb:

class WebServer < WEBrick::HTTPServlet::AbstractServlet
  def do_GET(request, response)
     case request.path
     when "/"
         response.status = 200
         response['Content-Type'] = 'text/plain'
         response.body = 'Hello, World'
     else
         response.status = 404
         response['Content-Type'] = 'text/plain'
         response.body = 'Not Found'
     end
  end
end

Este código devolverá una respuesta 200 OK con el cuerpo Hello, World para la URL /; para cualquier otra dirección, la respuesta será 404. ¿Cómo probaría este código manualmente? Por lo general, se agrega más código para ejecutar el servidor web localmente:

#   ,      
#  ,       
if __FILE__ == $0
  #      8000
  server = WEBrick::HTTPServer.new :Port => 8000
  server.mount '/', WebServer

  #    Ctrl+C
  trap 'INT' do server.shutdown end

  #  
  server.start
end

Si ejecuta este archivo en la terminal, cargará el servidor web en el puerto 8000:

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000

Para verificar el funcionamiento de este servidor, puede usar el navegador o curl:

$ curl localhost:8000/
Hello, World

$ curl localhost:8000/invalid-path
Not Found

Ahora imagine que cambiamos este código agregando un punto de entrada / api que devuelve 201 Created y un cuerpo en formato JSON:

class WebServer < WEBrick::HTTPServlet::AbstractServlet
  def do_GET(request, response)
     case request.path
     when "/"
         response.status = 200
         response['Content-Type'] = 'text/plain'
         response.body = 'Hello, World'
     when "/api"
         response.status = 201
         response['Content-Type'] = 'application/json'
         response.body = '{"foo":"bar"}'
     else
         response.status = 404
         response['Content-Type'] = 'text/plain'
         response.body = 'Not Found'
     end
  end
end

Para probar manualmente este código actualizado, presione Ctrl + C y reinicie el servidor web ejecutando el script nuevamente:

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000
^C
[2019-05-25 14:15:54] INFO going to shutdown ...
[2019-05-25 14:15:54] INFO WEBrick::HTTPServer#start done.

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000

Para verificar la nueva versión, puede usar nuevamente el comando curl:

$ curl localhost:8000/api
{"foo":"bar"}

Fundamentos de pruebas manuales


¿Cómo será este tipo de prueba manual en Terraform? Por ejemplo, de los capítulos anteriores, todavía tiene el código para implementar ALB. Aquí hay un fragmento del archivo modules / networking / alb / main.tf:

resource "aws_lb" "example" {
   name                     = var.alb_name
   load_balancer_type = "application"
   subnets                  = var.subnet_ids
   security_groups      = [aws_security_group.alb.id]
}

resource "aws_lb_listener" "http" {
   load_balancer_arn = aws_lb.example.arn
   port                      = local.http_port
   protocol                = "HTTP"

   #      404
   default_action {
      type = "fixed-response"

      fixed_response {
        content_type = "text/plain"
        message_body = "404: page not found"
        status_code = 404
      }
    }
}

resource "aws_security_group" "alb" {
   name = var.alb_name
}

# (...)

Si compara esta lista con el código Ruby, puede ver una diferencia bastante obvia: AWS ALB, grupos objetivo, escuchas, grupos de seguridad y cualquier otro recurso no se pueden implementar en su propia computadora.

La conclusión clave sobre la prueba No. 1 se deduce de esto: la prueba de código Terraform no puede llevarse a cabo localmente.

Esto se aplica no solo a Terraform, sino también a la mayoría de las herramientas de IaC. La única forma práctica de hacer pruebas manuales en Terraform es implementar el código en un entorno real (es decir, en AWS). En otras palabras, iniciar independientemente los comandos terraform apply y terraform destroy en los que trabajó mientras leía el libro es una prueba manual en Terraform.

Esta es una de las razones por las que es tan importante tener ejemplos fáciles de implementar en la carpeta de ejemplos de cada módulo (consulte el capítulo 6). Para probar el módulo alb, la forma más fácil es usar el código de demostración que creó en examples / alb:

provider "aws" {
   region = "us-east-2"

   #     AWS  2.x
   version = "~> 2.0"
}

module "alb" {
    source = "../../modules/networking/alb"

    alb_name = "terraform-up-and-running"
    subnet_ids = data.aws_subnet_ids.default.ids
}

Para implementar este ejemplo, debe ejecutar el comando terraform apply, como lo ha hecho repetidamente:

$ terraform apply

(...)

Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

Outputs:

alb_dns_name = hello-world-stage-477699288.us-east-2.elb.amazonaws.com

Al final de la implementación, puede usar una herramienta como curl para, por ejemplo, asegurarse de que ALB devuelva 404 de forma predeterminada:

$ curl \
   -s \
   -o /dev/null \
   -w "%{http_code}" \
hello-world-stage-477699288.us-east-2.elb.amazonaws.com

404

Verificación de infraestructura

, HTTP, , , curl HTTP-. . , MySQL, MySQL. VPN-, VPN. , , SSH - . . , , . , .

Permítame recordarle: ALB devuelve 404 debido a la ausencia de otras reglas de escucha en la configuración, y la acción predeterminada en el módulo alb tiene una respuesta de 404:

resource "aws_lb_listener" "http" {
   load_balancer_arn = aws_lb.example.arn
   port                      = local.http_port
   protocol                = "HTTP"

   #      404
   default_action {
      type = "fixed-response"

      fixed_response {
       content_type = "text/plain"
       message_body = "404: page not found"
       status_code = 404
      }
   }
}

Entonces, ya sabes cómo ejecutar y probar tu código. Ahora puedes comenzar a hacer cambios. Cada vez que cambia algo (de modo que, por ejemplo, la acción predeterminada devuelve 401), debe usar el comando terraform apply para implementar el nuevo código:

$ terraform apply

(...)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Outputs:

alb_dns_name = hello-world-stage-477699288.us-east-2.elb.amazonaws.com

Para verificar la nueva versión, puede reiniciar curl:

$ curl \
   -s \
   -o /dev/null \
   -w "%{http_code}" \
   hello-world-stage-477699288.us-east-2.elb.amazonaws.com
401

Cuando termine, ejecute el comando terraform destroy para eliminar los recursos:

$ terraform destroy

(...)

Apply complete! Resources: 0 added, 0 changed, 5 destroyed.

En otras palabras, cuando se trabaja con Terraform, cada desarrollador necesita buenos ejemplos de código para las pruebas y un entorno de desarrollo real (como una cuenta de AWS), que sirve como el equivalente de una computadora local y se utiliza para ejecutar pruebas. En el proceso de prueba manual, lo más probable es que tenga que crear y eliminar una gran cantidad de componentes de infraestructura, y esto puede provocar muchos errores. A este respecto, el entorno debe estar completamente aislado de los entornos más estables destinados a las pruebas finales y, en particular, para aplicaciones industriales.

Dado lo anterior, recomiendo encarecidamente que cada equipo de desarrollo prepare un entorno aislado en el que pueda crear y eliminar cualquier infraestructura sin consecuencias. Para minimizar la probabilidad de conflictos entre diferentes desarrolladores (imagine que dos desarrolladores están tratando de crear un equilibrador de carga con el mismo nombre), la solución ideal sería proporcionar a cada miembro del equipo un entorno separado y completamente aislado. Por ejemplo, si usa Terraform junto con AWS, cada desarrollador idealmente debería tener su propia cuenta donde pueda probar todo lo que quiera.

Limpieza de recursos después de las pruebas.


La presencia de muchos entornos aislados es necesaria para la alta productividad de los desarrolladores, pero si no tiene precaución, puede acumular muchos recursos adicionales que saturarán todos sus entornos y le costarán una suma redonda.
Para mantener los costos bajo control, limpie regularmente sus medios aislados. Esta es la conclusión clave sobre la prueba número 2 .

Como mínimo, debe crear tal cultura en el equipo cuando, después de las pruebas, los desarrolladores eliminen todo lo que implementaron usando el comando terraform destroy. Es posible encontrar herramientas para limpiar recursos excedentes o antiguos que se pueden ejecutar de forma regular (por ejemplo, usando cron). Aquí hay algunos ejemplos para diferentes entornos de implementación.

  • cloud-nuke (http://bit.ly/2OIgM9r). , . AWS ( Amazon EC2 Instances, ASG, ELB . .). (Google Cloud, Azure) . — , . , cloud-nuke cron, . , , , :

    $ cloud-nuke aws --older-than 48h
  • Janitor Monkey (http://bit.ly/2M4GoLB). , AWS , ( — ). , , , . Netflix Simian Army, Chaos Monkey . , Simian Army , : , Janitor Monkey Swabbie (http://bit.ly/2OLrOLb).
  • aws-nuke (http://bit.ly/2ZB8lOe). Esta es una herramienta de código abierto para eliminar todo el contenido de una cuenta de AWS. Las cuentas y los recursos que se eliminarán se especifican en el archivo de configuración en el formato YAML:

    #   
    regions:
    - us-east-2
    
    #    
    accounts:
       "111111111111": {}
    
    #    
    resource-types:
       targets:
       - S3Object
       - S3Bucket
       - IAMRole

    Aws-nuke comienza de la siguiente manera:

    $ aws-nuke -5c config.yml

Pruebas automatizadas


El concepto de prueba automática es que las pruebas se escriben para probar el comportamiento del código real. En el Capítulo 8, aprenderá que con el servidor CI, estas pruebas se pueden ejecutar después de cada confirmación individual. Si no se completan, la fijación se puede deshacer o corregir de inmediato. Por lo tanto, su código siempre estará operativo.

Hay tres tipos de pruebas automatizadas.

  • . — . , . (, , - ) mock-. (, mock- , ) , .
  • . . , . mock-: , , , , , , , mock-.
  • . (, , , ) . : , Selenium . - mock-, ( , ).

Cada tipo de prueba tiene su propio propósito y, con su ayuda, puede identificar todo tipo de errores, por lo que deben usarse juntos. Las pruebas unitarias son rápidas y le permiten tener una idea inmediata de los cambios realizados y verificar una variedad de combinaciones. Esto le da la confianza de que los componentes elementales de su código (módulos individuales) se comportan como esperaba. Sin embargo, el hecho de que los módulos funcionen correctamente por separado no significa en absoluto que puedan trabajar juntos, por lo tanto, para asegurarse de que sus componentes elementales sean compatibles, se necesitan pruebas de integración. Por otro lado, el comportamiento correcto de las diferentes partes del sistema no garantiza que este sistema funcione como debería después de la implementación en un entorno industrial, por lo que se necesitan pruebas para probar su código en condiciones cercanas a las reales.

»Se puede encontrar más información sobre el libro en el sitio web del editor
» Contenido
» Extracto de

Khabrozhiteley 25% de cupón de descuento - Terraform

Al pagar la versión impresa del libro, se envía un libro electrónico por correo electrónico.

All Articles