También estoy en un estado de migración de la infraestructura de AWS existente a Terraform, por lo que intentaré actualizar la respuesta a medida que la desarrolle.
Me he basado en gran medida en los ejemplos oficiales de Terraform y en múltiples pruebas y errores para desarrollar áreas en las que no estaba seguro.
.tfstate
archivos
La configuración de Terraform se puede utilizar para aprovisionar muchas cajas en diferentes infraestructuras, cada una de las cuales podría tener un estado diferente. Como también puede ser ejecutado por varias personas, este estado debe estar en una ubicación centralizada (como S3) pero no en git.
Esto se puede confirmar mirando el Terraform .gitignore
.
Control del desarrollador
Nuestro objetivo es proporcionar un mayor control de la infraestructura a los desarrolladores al tiempo que mantenemos una auditoría completa (git log) y la capacidad de verificar los cambios (solicitudes de extracción). Con eso en mente, el nuevo flujo de trabajo de infraestructura al que apunto es:
- Base de base de AMI comunes que incluyen módulos reutilizables, por ejemplo, títeres.
- Infraestructura central provista por DevOps usando Terraform.
- Los desarrolladores cambian la configuración de Terraform en Git según sea necesario (número de instancias; nueva VPC; adición de región / zona de disponibilidad, etc.).
- Se envió la configuración de Git y se envió una solicitud de extracción para que un miembro del equipo de DevOps verificara la cordura.
- Si se aprueba, llama al webhook a CI para compilar e implementar (no está seguro de cómo particionar múltiples entornos en este momento)
Edición 1: actualización del estado actual
Desde que comencé esta respuesta, he escrito mucho código TF y me siento más cómodo en nuestro estado de cosas. Hemos encontrado errores y restricciones en el camino, pero acepto que esta es una característica del uso de software nuevo que cambia rápidamente.
Diseño
Tenemos una infraestructura de AWS complicada con varias VPC, cada una con varias subredes. La clave para gestionar esto fácilmente fue definir una taxonomía flexible que abarque la región, el medio ambiente, el servicio y el propietario, que podamos utilizar para organizar nuestro código de infraestructura (tanto terraform como títere).
Módulos
El siguiente paso fue crear un único repositorio de git para almacenar nuestros módulos terraform. Nuestra estructura de directorios de nivel superior para los módulos se ve así:
tree -L 1 .
Resultado:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Cada uno establece algunos valores por defecto sensatos pero los expone como variables que pueden ser sobrescritas por nuestro "pegamento".
pegamento
Tenemos un segundo repositorio con nuestro glue
que hace uso de los módulos mencionados anteriormente. Se presenta de acuerdo con nuestro documento de taxonomía:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tf
Dentro del nivel de cliente, tenemos .tf
archivos específicos de la cuenta de AWS que proporcionan recursos globales (como roles de IAM); el siguiente es el nivel de región con claves públicas EC2 SSH; Por último, en nuestro entorno ( dev
, stg
, prod
etc.) son nuestra configuraciones de VPC, la creación de instancias y mirando uniones y conexiones están almacenados.
Nota al margen: Como puede ver, voy en contra de mi propio consejo anterior de mantenerme terraform.tfstate
en git. Esta es una medida temporal hasta que me cambie a S3, pero me conviene ya que actualmente soy el único desarrollador.
Próximos pasos
Este sigue siendo un proceso manual y aún no está en Jenkins, pero estamos portando una infraestructura bastante grande y complicada y hasta ahora todo va bien. Como dije, ¡pocos errores pero van bien!
Edición 2 - Cambios
Ha pasado casi un año desde que escribí esta respuesta inicial y el estado de Terraform y yo hemos cambiado significativamente. Ahora estoy en una nueva posición usando Terraform para administrar un clúster de Azure y Terraform ahora v0.10.7
.
Estado
La gente me ha dicho repetidamente que el estado no debería entrar en Git, y tienen razón. Usamos esto como una medida provisional con un equipo de dos personas que se basó en la comunicación y la disciplina de los desarrolladores. Con un equipo distribuido más grande, ahora estamos aprovechando por completo el estado remoto en S3 con el bloqueo proporcionado por DynamoDB. Idealmente, esto se migrará a consul ahora es v1.0 para cortar proveedores de nube cruzada.
Módulos
Anteriormente creamos y usamos módulos internos. Este sigue siendo el caso, pero con la llegada y el crecimiento del registro de Terraform , intentamos utilizarlos como al menos una base.
Estructura de archivo
La nueva posición tiene una taxonomía mucho más simple con solo dos entornos infx: dev
y prod
. Cada uno tiene sus propias variables y salidas, reutilizando nuestros módulos creados anteriormente. El remote_state
proveedor también ayuda a compartir los resultados de los recursos creados entre entornos. Nuestro escenario son los subdominios en diferentes grupos de recursos de Azure para un TLD administrado globalmente.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Planificación
Nuevamente, con los desafíos adicionales de un equipo distribuido, ahora siempre guardamos nuestra salida del terraform plan
comando. Podemos inspeccionar y saber qué se ejecutará sin el riesgo de algunos cambios entre la etapa plan
y apply
(aunque el bloqueo ayuda con esto). Recuerde eliminar este archivo de plan, ya que podría contener variables "secretas" de texto sin formato.
En general, estamos muy contentos con Terraform y seguimos aprendiendo y mejorando con las nuevas funciones agregadas.