tutorial trabajar repositorio que origin example con comandos cambiar and devops terraform

devops - trabajar - ¿Debo enviar archivos.tfstate a Git?



que es un repositorio git (4)

Esto probablemente se reducirá a preferencia, pero yo diría que git (o cualquier otro control de origen) no es una opción particularmente buena para almacenar archivos de estado, ya que son una salida del código que está escribiendo de manera muy similar a un binario compilado o incluso JS minimizado o MENOS compilado a CSS.

Además de eso, las cosas pueden cambiar bastante rápido en los archivos de estado como resultado de las cosas que se ejecutan en lugar de las cosas que realmente se cambian en el código, lo que hace que todo sea bastante incómodo.

Sin embargo, necesita alguna forma de compartir estos archivos de estado con cualquier miembro del equipo remoto o incluso con otros dispositivos si está desarrollando en diferentes computadoras portátiles / máquinas. También querrá alguna forma de almacenarlos y hacer una copia de seguridad de estos porque tendrá un verdadero dolor si pierde un archivo de estado, ya que Terraform usa los archivos de estado para determinar qué cosas está administrando para no pisar los pies. otras herramientas

Yo diría que S3 es probablemente el mejor lugar donde puedes colocarlos en este momento. Es bastante gratuito, la durabilidad es excelente al igual que la disponibilidad, hay muy buen soporte nativo para ello en Terraform utilizando el recurso de estado remoto . Y probablemente lo más importante es que solo tiene que crear un bucket S3 para comenzar. Tener que construir un clúster Consul o etcd primero sin Terraform (de lo contrario, tiene un problema con el huevo y la gallina de dónde almacena el estado para crearlos) es un poco molesto incluso si tiene la intención de usar cualquiera de esos productos.

Obviamente, si está utilizando OpenStack, Swift debería ser una buena alternativa (aunque no la he usado). Tampoco he usado el Atlas de Hashicorp, pero si está dispuesto a pagar por ese servicio, podría ser igualmente útil.

Estoy un poco desconcertado sobre la cuestión de si .tfstate archivos .tfstate a Git o no. La documentación de Terraform dice:

Terraform también pone algún estado en el archivo terraform.tfstate de forma predeterminada. Este archivo de estado es extremadamente importante; asigna varios metadatos de recursos a ID de recursos reales para que Terraform sepa lo que está administrando. Este archivo debe guardarse y distribuirse a cualquiera que pueda ejecutar Terraform. Recomendamos simplemente ponerlo en control de versiones, ya que generalmente no es demasiado grande.

Ahora, por otro lado, la respuesta aceptada y votada sobre Mejores prácticas al usar Terraform dice:

La configuración de Terraform se puede usar para aprovisionar muchas cajas en diferentes infraestructuras, cada una de las cuales podría tener un estado diferente. Como también puede ser administrado por varias personas, este estado debe estar en una ubicación centralizada (como S3) pero no en git.

(Énfasis por el autor original, no por mí)

¿Quién tiene razón, y si es así, por qué?


Hay algunas razones para no almacenar sus archivos .tfstate en Git:

  1. Es probable que se olvide de confirmar y enviar sus cambios después de ejecutar .tfstate , por lo que sus compañeros de equipo tendrán archivos .tfstate . Además, sin ningún bloqueo en estos archivos de estado, si dos miembros del equipo ejecutan Terraform al mismo tiempo en los mismos archivos .tfstate , pueden sobrescribirse los cambios del otro. Puede resolver ambos problemas: a) almacenando archivos .tfstate en un depósito S3 usando el estado remoto Terraform , que empujará / .tfstate archivos .tfstate automáticamente cada vez que ejecute terraform apply yb) use una herramienta como terragrunt para proporcionar bloqueo para sus archivos .tfstate
  2. Los archivos .tfstate pueden contener secretos. Por ejemplo, si usa el recurso aws_db_instance , debe especificar una contraseña de la base de datos, y Terraform la almacenará, en texto plano, en el archivo .tfstate . Para empezar, esta es una mala práctica en nombre de Terraform y el almacenamiento de secretos no cifrados en el control de versiones solo lo empeora. Al menos si almacena archivos .tfstate en S3, puede habilitar el cifrado en reposo (SSL proporciona cifrado mientras está en movimiento) y configurar las políticas de IAM para limitar quién tiene acceso. Está muy lejos de ser ideal y tendremos que ver si el problema de ver abierto que discute este problema alguna vez se soluciona.

Para obtener más información, consulte Cómo administrar el estado de Terraform y Terraform: Up & Running .


Veo una ventaja de compartir terraform.tfstate a través de otros medios, en lugar de Git.

Por ejemplo: S3, Dropbox, etc. (con el control de versiones activado)

Entonces será posible volver al estado de infraestructura anterior.

Por ejemplo, revierte el repositorio del commit B, vuelve al commit A. Si terraform.tfstate no ha cambiado, terraform pensará cómo revertir todo lo que has agregado durante el commit B. Y la reversión será fácil.

En caso de que terraform.tfstate también se revierta para confirmar A, entonces terraform pensará que terraform.tfstate está sincronizado con la configuración requerida y no aplicará la reversión a su infraestructura.


TL; DR:

¡Importante! El almacenamiento en el control de origen podría exponer datos potencialmente confidenciales y los riesgos de ejecutar Terraform contra una versión antigua del estado. No lo hagas

Terraform ya no recomienda almacenar el estado en el control de fuente. Sus ''buenas'' opciones son remotas o locales.

El estado remoto otorga beneficios significativos en comparación con el control local y el almacenamiento en el origen. Los detalles de estos están a continuación.

Respuesta original:

La respuesta de Yevgeniy es buena. El problema es algo menos controvertido ahora, ya que Terraform ha actualizado sus documentos para indicar:

Terraform también pone algún estado en el archivo terraform.tfstate de forma predeterminada. Este archivo de estado es extremadamente importante; asigna varios metadatos de recursos a ID de recursos reales para que Terraform sepa lo que está administrando. Este archivo debe guardarse y distribuirse a cualquiera que pueda ejecutar Terraform. En general, se recomienda configurar el estado remoto cuando se trabaja con Terraform. Esto significará que los posibles secretos almacenados en el archivo de estado no se verificarán en el control de versiones

Por lo tanto, ya no existe un desacuerdo entre las mejores prácticas establecidas y las recomendaciones oficiales.

Actualizar 2019-05-17

En la versión más reciente de los documentos, esto se ha cambiado para decir:

... Este estado se almacena de forma predeterminada en un archivo local llamado "terraform.tfstate", pero también se puede almacenar de forma remota, lo que funciona mejor en un entorno de equipo. ...

No espero que el consejo vuelva al control de fuente como el método preferido para almacenar el estado.

A pesar de la cita de los documentos, el estado remoto sigue siendo beneficioso como desarrollador en solitario

El estado remoto permite al desarrollador en solitario:

  • Trabajar / ejecutar su código Terraform desde varios dispositivos
  • Realice fácilmente copias de seguridad y proteja contra la pérdida del archivo de estado, dependiendo del backend elegido
  • Segregar secciones de su arquitectura a través de outputs
  • Cifrar automáticamente el archivo de estado en reposo , según el backend elegido