Moitas persoas coñecen e usan Terraform no seu traballo diario, pero aínda non se formaron as mellores prácticas para iso. Cada equipo ten que inventar os seus propios enfoques e métodos.
A túa infraestrutura case con toda seguridade comeza de forma sinxela: algúns recursos + algúns desenvolvedores. Co paso do tempo, crece en todo tipo de direccións. Atopa formas de agrupar recursos en módulos de Terraform, organizar o código en cartafoles e que máis pode saír mal? (últimas palabras famosas)
Pasa o tempo e sentes que a túa infraestrutura é a túa nova mascota, pero por que? Estás preocupado polos cambios inexplicables na infraestrutura, tes medo de tocar a infraestrutura e o código; como resultado, atrasás novas funcionalidades ou reduces a calidade...
Despois de tres anos xestionando unha colección de módulos da comunidade de Terraform para AWS en Github e o mantemento a longo prazo de Terraform en produción, Anton Babenko está preparado para compartir a súa experiencia: como escribir módulos TF para que non se faga mal no futuro.
Ao final da charla, os participantes estarán máis familiarizados cos principios de xestión de recursos en Terraform, as mellores prácticas asociadas aos módulos en Terraform e algúns principios de integración continua asociados á xestión de infraestruturas.
Disclaimer: Observo que este informe ten data de novembro de 2018; xa pasaron 2 anos. A versión de Terraform 0.11 que se comenta no informe xa non é compatible. Durante os últimos 2 anos, lanzáronse 2 novos lanzamentos, que conteñen moitas innovacións, melloras e cambios. Preste atención a isto e comprobe a documentación.
Referencias:
- +
- — Código de formato automático e documentación
- - xerador de módulos Terraform (WIP)
- — Xerador de código Terraform a partir de diagramas visuais (WIP)
- www.terraform-best-practices.com
- (As novas publicacións están no meu sitio web persoal www.antonbabenko.com/)
- @antonbabenko - Twitter e unha morea de Slacks diferentes
Chámome Anton Babenko. Algúns de vós probablemente usaron o código que escribín. Agora falarei disto con máis confianza que nunca, porque teño acceso ás estatísticas.
Traballo en Terraform e desde 2015 fun un participante activo e colaborador dun gran número de proxectos de código aberto relacionados con Terraform e Amazon.
Desde entón escribín código suficiente para poñelo dun xeito interesante. E tentarei falarche disto agora.
Falarei sobre as complejidades e as particularidades do traballo con Terraform. Pero ese non é realmente o tema de HighLoad. E agora entenderás por que.
Co tempo, comecei a escribir módulos de Terraform. Os usuarios escribiron preguntas, eu reescribínas. Despois escribín varias utilidades para formatar o código usando un gancho de pre-commit, etc.
Houbo moitos proxectos interesantes. Gústame a xeración de código porque me gusta que a computadora faga cada vez máis traballo para min e para o programador, polo que actualmente estou traballando nun xerador de código Terraform a partir de diagramas visuais. Quizais algún de vós os vira. Estas son fermosas caixas con frechas. E creo que é xenial se podes facer clic no botón "Exportar" e obtelo todo como código.
Eu son de Ucraína. Levo moitos anos vivindo en Noruega.
Ademais, recompilouse información para este informe de persoas que coñecen o meu nome e que me atopan nas redes sociais. Case sempre teño o mesmo apelido.
Como dixen, son o principal mantedor dos módulos Terraform AWS, que é un dos maiores repositorios de GitHub onde aloxamos módulos para as tarefas máis comúns: VPC, Autoscaling, RDS.
E o que escoitaches agora é o máis básico. Se dubidas de entender o que é Terraform, é mellor pasar o teu tempo noutro lugar. Aquí haberá moitos termos técnicos. E non dubidei en declarar o nivel do informe como o máis alto. Isto significa que podo falar usando todos os termos posibles sen moita explicación.
Terraform apareceu en 2014 como unha utilidade que che permitía escribir, planificar e xestionar a infraestrutura como código. O concepto clave aquí é "infraestrutura como código".
Toda a documentación, como dixen, está escrita . Espero que a maioría da xente coñeza este sitio e lera a documentación. Se é así, entón estás no lugar correcto.
Este é o aspecto dun ficheiro de configuración de Terraform normal, onde primeiro definimos algunhas variables.
Neste caso definimos "aws_region".
Despois describimos que recursos queremos crear.
Executamos algúns comandos, en particular "terraform init" para cargar dependencias e provedores.
E executamos o comando "terraform apply" para comprobar se a configuración especificada coincide cos recursos que creamos. Como non creamos nada antes, Terraform solicítanos que creemos estes recursos.
Confirmamos isto. Así creamos un balde chamado caracol.
Tamén hai varias utilidades similares. Moitos de vostedes que usan Amazon coñecen AWS CloudFormation ou Google Cloud Deployment Manager ou Azure Resource Manager. Cada un deles ten a súa propia implementación dalgún tipo para xestionar os recursos dentro de cada un destes provedores de nube pública. Terraform é especialmente útil porque che permite xestionar máis de 100 provedores. (Máis detalles )
Os obxectivos que perseguiu Terraform desde o principio:
- Terraform ofrece unha única visión dos recursos.
- Permítelle admitir todas as plataformas modernas.
- E Terraform foi deseñado dende o principio como unha utilidade que che permite cambiar a infraestrutura de forma segura e previsible.
En 2014, a palabra "previsible" soou moi inusual neste contexto.
Terraform é unha utilidade universal. Se tes unha API, podes controlar absolutamente todo:
- Podes usar máis de 120 provedores para xestionar todo o que queiras.
- Por exemplo, pode usar Terraform para describir o acceso aos repositorios de GitHub.
- Incluso podes crear e pechar erros en Jira.
- Podes xestionar as métricas de New Relic.
- Incluso podes crear ficheiros en Dropbox se realmente queres.
Todo isto conséguese mediante provedores de Terraform, que teñen unha API aberta que se pode describir en Go.
Digamos que comezamos a usar Terraform, lemos algunha documentación no sitio, miramos algún vídeo e comezamos a escribir main.tf, como mostrei nas diapositivas anteriores.
E todo é xenial, tes un ficheiro que crea un VPC.
Se queres crear un VPC, especifica aproximadamente estas 12 liñas. Describe en que rexión queres crear, que cidr_block de enderezos IP queres usar. Iso é todo.
Por suposto, o proxecto crecerá aos poucos.
E engadirás un montón de cousas novas alí: recursos, fontes de datos, integrarás con novos provedores, de súpeto quererás usar Terraform para xestionar usuarios na túa conta de GitHub, etc. Quizais queiras usar diferentes Provedores de DNS, cruza todo. Terraform facilita isto.
Vexamos o seguinte exemplo.
Engades internet_gateway aos poucos porque queres que os recursos do teu VPC teñan acceso a Internet. Esta é unha boa idea.
O resultado é este main.tf:
Esta é a parte superior de main.tf.
Esta é a parte inferior de main.tf.
Despois engades a subrede. No momento en que queiras engadir pasarelas NAT, rutas, táboas de enrutamento e outras subredes, non terás 38 liñas, senón aproximadamente 200-300 liñas.
É dicir, o teu ficheiro main.tf está crecendo aos poucos. E moitas veces a xente pon todo nun só ficheiro. 10-20 Kb aparece en main.tf. Imaxina que 10-20 Kb son contido de texto. E todo está ligado a todo. Isto é pouco a pouco difícil de traballar. 10-20 Kb é un bo caso de usuario, ás veces máis. E a xente non sempre pensa que isto é malo.
Como na programación normal, é dicir, non a infraestrutura como código, estamos afeitos a usar unha morea de clases, paquetes, módulos e agrupacións diferentes. Terraform permíteche facer o mesmo.
- O código vai medrando.
- Tamén medran as dependencias entre recursos.
E temos unha gran, gran necesidade. Entendemos que xa non podemos vivir así. O noso código está a ser inmenso. 10-20 Kb, por suposto, non é moi grande, pero estamos a falar só da pila de rede, é dicir, só engadiches recursos de rede. Non estamos a falar de Application Load Balancer, clúster ES de implementación, Kubernetes, etc., onde se poden tecer facilmente 100 Kb. Se anotas todo isto, moi pronto aprenderás que Terraform ofrece módulos de Terraform.
Os módulos de Terraform son unha configuración autónoma de Terraform que se xestiona como un grupo. Iso é todo o que necesitas saber sobre os módulos de Terraform. Non son intelixentes en absoluto, non che permiten facer conexións complexas dependendo de algo. Todo isto recae sobre os ombreiros dos desenvolvedores. É dicir, esta é só algún tipo de configuración de Terraform que xa escribiu. E pode simplemente chamalo como un grupo.
Polo tanto, estamos tentando entender como optimizaremos os nosos 10-20-30 Kb de código. Pouco a pouco ímonos decatando de que necesitamos utilizar algúns módulos.
O primeiro tipo de módulos que atopas son módulos de recursos. Non entenden de que se trata a túa infraestrutura, de que trata o teu negocio, onde e cales son as condicións. Estes son exactamente os módulos que eu, xunto coa comunidade de código aberto, administro e que propoñemos como os primeiros bloques de construción da túa infraestrutura.
Un exemplo de módulo de recursos.
Cando chamamos a un módulo de recursos, especificamos desde que camiño debemos cargar o seu contido.
Indicamos que versión queremos descargar.
Pasamos alí unha morea de argumentos. Iso é todo. Iso é todo o que necesitamos saber cando usamos este módulo.
Moita xente pensa que se usan a última versión, todo será estable. Pero non. A infraestrutura debe ser versionada; debemos responder claramente a que versión se implantou este ou aquel compoñente.
Aquí está o código que hai dentro deste módulo. Módulo de grupo de seguridade. Aquí o rolo vai ata a liña 640. Crear un recurso de grupo de seguridade en Amazon en todas as configuracións posibles é unha tarefa moi pouco trivial. Non basta con simplemente crear un grupo de seguridade e dicirlle cales son as regras que lle deben pasar. Sería moi sinxelo. Hai un millón de restricións diferentes dentro de Amazon. Por exemplo, se usas Punto final de VPC, lista de prefixos, varias API e intenta combinar todo isto con todo o demais, entón Terraform non che permite facelo. E a API de Amazon tampouco o permite. Polo tanto, necesitamos ocultar toda esta terrible lóxica nun módulo e dar o código de usuario que se vexa así.
O usuario non precisa saber como se fai dentro.
O segundo tipo de módulos, que consiste en módulos de recursos, xa resolve problemas que son máis aplicables ao teu negocio. Moitas veces este é un lugar que é unha extensión para Terraform e establece uns valores ríxidos para as etiquetas, para os estándares da empresa. Tamén pode engadir aí unha funcionalidade que Terraform non lle permite usar actualmente. Isto é agora mesmo. Agora a versión 0.11, que está a piques de converterse en cousa do pasado. Pero aínda así, os preprocesadores, jsonnet, cookiecutter e un montón de cousas máis son o mecanismo auxiliar que debe usarse para un traballo completo.
A continuación mostrarei algúns exemplos diso.
O módulo de infraestrutura chámase exactamente do mesmo xeito.
Indícase a fonte desde onde descargar o contido.
Pasan unha morea de valores e pásanse a este módulo.
A continuación, dentro deste módulo, chámanse unha morea de módulos de recursos para crear un VPC ou un equilibrador de carga de aplicacións, ou para crear un grupo de seguridade ou un clúster de Elastic Container Service.
Hai dous tipos de módulos. É importante entender isto porque a maioría da información que agrupei neste informe non está escrita na documentación.
E a documentación en Terraform agora mesmo é bastante problemática porque só di que hai estas funcións, podes usalas. Pero ela non di como usar estas funcións, por que é mellor usalas. Polo tanto, un gran número de persoas escriben algo co que non poden vivir.
Vexamos a continuación como escribir estes módulos. Despois veremos como chamalos e como traballar co código.
Rexistro Terraform -
O consello #0 é non escribir módulos de recursos. A maioría destes módulos xa están escritos para ti. Como dixen, son de código aberto, non conteñen ningunha lóxica empresarial, non teñen valores codificados para enderezos IP, contrasinais, etc. O módulo é moi flexible. E moi probablemente xa está escrito. Hai moitos módulos para recursos de Amazon. Uns 650. E a maioría deles son de boa calidade.
Neste exemplo, alguén veu a ti e dixo: "Quero poder xestionar unha base de datos. Cree un módulo para que poida crear unha base de datos". A persoa non coñece os detalles de implementación nin de Amazon nin de Terraform. Simplemente di: "Quero xestionar MSSQL". É dicir, queremos dicir que chamará ao noso módulo, pasará alí o tipo de motor e indicará a zona horaria.
E unha persoa non debe saber que imos crear dous recursos diferentes dentro deste módulo: un para MSSQL, o segundo para todo o demais, só porque en Terraform 0.11 non pode especificar valores de zona horaria como opcional.
E á saída deste módulo, unha persoa poderá simplemente recibir un enderezo. Non saberá a partir de que base de datos, de que recurso estamos a crear todo isto internamente. Este é un elemento moi importante de ocultación. E isto aplícase non só a aqueles módulos que son públicos en código aberto, senón tamén a aqueles módulos que escribirá dentro dos seus proxectos e equipos.
Este é o segundo argumento, que é moi importante se levas un tempo usando Terraform. Tes un repositorio no que colocas todos os teus módulos de Terraform para a túa empresa. E é bastante normal que co paso do tempo este proxecto medre ata alcanzar un tamaño dun ou dous megabytes. Isto está ben.
Pero o problema é como Terraform chama estes módulos. Por exemplo, se chamas a un módulo para crear cada usuario individual, Terraform cargará primeiro todo o repositorio e despois navegará ata o cartafol onde se atopa ese módulo específico. Deste xeito, descargará un megabyte cada vez. Se xestionas 100 ou 200 usuarios, descargarás 100 ou 200 megabytes e despois irás a ese cartafol. Entón, naturalmente, non queres descargar un montón de cousas cada vez que premes "Terraform init".
Hai dúas solucións a este problema. O primeiro é utilizar camiños relativos. Deste xeito indicas no código que o cartafol é local (./). E antes de lanzar nada, fai un clon de Git deste repositorio localmente. Deste xeito, faino unha vez.
Hai, por suposto, moitas desvantaxes. Por exemplo, non pode usar a versión. E isto ás veces é difícil de vivir.
Segunda solución. Se tes moitos submódulos e xa tes algún tipo de canalización establecida, entón está o proxecto MBT, que che permite recoller moitos paquetes diferentes dun monorepositorio e cargalos a S3. Este é un xeito moi bo. Así, o ficheiro iam-user-1.0.0.zip pesará só 1 Kb, porque o código para crear este recurso é moi pequeno. E funcionará moito máis rápido.
Falemos do que non se pode usar nos módulos.
Por que está este mal nos módulos? O peor é asumir usuario. Supoña que o usuario é unha opción de autenticación de provedor que pode ser usada por diferentes persoas. Por exemplo, todos asimilaremos o papel. Isto significa que Terraform asumirá este papel. E despois con este papel realizará outras accións.
E o mal é que se a Vasya lle gusta conectarse a Amazon dun xeito, por exemplo, usando a variable de ambiente predeterminada, e a Petya gústalle usar a súa chave compartida, que ten nun lugar secreto, entón non podes especificar ambas as dúas en Terraform. E para que non experimenten sufrimento, non é necesario indicar este bloque no módulo. Isto debe ser indicado nun nivel superior. É dicir, temos un módulo de recursos, un módulo de infraestrutura e unha composición enriba. E isto debería indicarse nalgún lugar máis alto.
O segundo mal é o provedor. Aquí o mal non é tan trivial, porque se escribes código e funciona para ti, entón podes pensar que se funciona, entón por que cambialo.
O mal é que non sempre controlas cando se lanzará este aprovisionador, en primeiro lugar. E en segundo lugar, non controlas o que significa aws ec2, é dicir, estamos falando agora de Linux ou Windows. Polo tanto, non pode escribir algo que funcione igual en diferentes sistemas operativos ou para diferentes casos de usuario.
O exemplo máis común, que tamén se indica na documentación oficial, é que se escribes aws_instance e especificas un montón de argumentos, non hai nada de malo se especificas alí o provedor "local-exec" e executas o teu ansible- libro de xogadas.
De feito, si, non hai nada de malo con iso. Pero, literalmente, pronto darás conta de que esta cousa do executivo local non existe, por exemplo, en launch_configuration.
E cando usas launch_configuration e queres crear un grupo de escalado automático a partir dunha instancia, entón en launch_configuration non hai concepto de "provisionador". Existe o concepto de "datos de usuario".
Polo tanto, unha solución máis universal é utilizar os datos do usuario. E lanzarase na propia instancia, cando a instancia estea activada, ou nos mesmos datos de usuario, cando o grupo de escalado automático use esta launch_configuration.
Se aínda queres executar o aprovisionador, porque é un compoñente de pegado, cando se crea un recurso, nese momento debes executar o teu aprovisionador, o teu comando. Hai moitas situacións deste tipo.
E o recurso máis correcto para iso chámase recurso_nulo. Null_resource é un recurso ficticio que nunca se crea. Non toca nada, nin API, nin autoescalado. Pero permítelle controlar cando executar o comando. Neste caso, o comando execútase durante a creación.
Ligazón
Hai varios sinais. Non vou entrar en todos os sinais con moito detalle. Hai un artigo sobre isto. Pero se traballaches con Terraform ou utilizaches módulos doutras persoas, moitas veces notaches que moitos módulos, como a maioría do código en código aberto, son escritos por persoas para as súas propias necesidades. Un home escribiuno e resolveu o seu problema. Pegueino en GitHub, deixeino vivir. Vivirá, pero se non hai documentación e exemplos alí, ninguén o utilizará. E se non hai ningunha funcionalidade que che permita resolver un pouco máis que a súa tarefa específica, tampouco ninguén a usará. Hai moitas formas de perder usuarios.
Se queres escribir algo para que a xente o use, recoméndoche seguir estes sinais.
Estes son:
- Documentación e exemplos.
- Funcionalidade completa.
- Valores predeterminados razoables.
- Código limpo.
- Probas.
As probas son unha situación diferente porque son bastante difíciles de escribir. Creo máis na documentación e nos exemplos.
Entón, miramos como escribir módulos. Hai dous argumentos. O primeiro, que é o máis importante, é non escribir se podes, porque unha morea de persoas xa fixeron estas tarefas antes que ti. E en segundo lugar, se aínda decides, intenta non usar provedores en módulos e provedores.
Esta é a parte gris da documentación. Agora podes estar pensando: "Algo non está claro. Non está convencido". Pero xa veremos dentro de seis meses.
Agora imos falar de como chamar a estes módulos.
Entendemos que o noso código crece co paso do tempo. Xa non temos un ficheiro, xa temos 20 ficheiros. Están todos nun cartafol. Ou quizais en cinco cartafoles. Quizais empecemos a desglosalas dalgún xeito por rexións, por algúns compoñentes. Entón entendemos que agora temos algúns rudimentos de sincronización e orquestración. É dicir, debemos entender que debemos facer se cambiamos os recursos da rede, que debemos facer co resto dos nosos recursos, como provocar estas dependencias, etc.
Hai dous extremos. O primeiro extremo está todo nun. Temos un ficheiro mestre. Polo momento, esta foi a mellor práctica oficial no sitio web de Terraform.
Pero agora está escrito como obsoleto e eliminado. Co paso do tempo, a comunidade de Terraform deuse conta de que esta estaba lonxe de ser a mellor práctica, porque a xente comezou a utilizar o proxecto de diferentes xeitos. E hai problemas. Por exemplo, cando enumeramos todas as dependencias nun só lugar. Hai situacións nas que facemos clic en "Plan Terraform" e ata que Terraform actualice os estados de todos os recursos, pode pasar moito tempo.
Moito tempo é, por exemplo, 5 minutos. Para algúns isto é moito tempo. Vin casos nos que tardaron 15 minutos. A API de AWS pasou 15 minutos intentando descubrir o que estaba a suceder co estado de cada recurso. Esta é unha área moi grande.
E, naturalmente, aparecerá un problema relacionado cando queiras cambiar algo nun só lugar, despois esperas 15 minutos e ofréceche un lenzo con algúns cambios. Cuspiches, escribiches "Si" e algo saíu mal. Este é un exemplo moi real. Terraform non intenta protexerte dos problemas. É dicir, escribe o que queiras. Haberá problemas - os teus problemas. Aínda que Terraform 0.11 non intenta axudarche de ningún xeito. Hai certos lugares interesantes en 0.12 que che permiten dicir: "Vasya, realmente queres isto, podes recuperar o teu sentido?"
A segunda forma é reducir esta área, é dicir, as chamadas desde un lugar poden estar menos conectadas desde outro lugar.
O único problema é que necesitas escribir máis código, é dicir, debes describir variables nun gran número de ficheiros e actualizar isto. A algunhas persoas non lles gusta. Isto é normal para min. E algunhas persoas pensan: "Por que escribir isto en diferentes lugares, poñerei todo nun só lugar". Isto é posible, pero este é o segundo extremo.
Quen ten todo isto vivindo nun só lugar? Unha, dúas, tres persoas, é dicir, alguén o está a usar.
E quen chama a un determinado compoñente, un bloque ou un módulo de infraestrutura? De cinco a sete persoas. Isto é xenial.
A resposta máis común está nalgún lugar no medio. Se o proxecto é grande, moitas veces terás unha situación na que ningunha solución é axeitada e non todo funciona, polo que acabas cunha mestura. Non hai nada de malo con isto, sempre que entendas que ambos teñen vantaxes.
Se algo cambiou na pila VPC e querías aplicar estes cambios a EC2, é dicir, querías actualizar o grupo de escalado automático porque tiñas unha subrede nova, entón chamo a este tipo de orquestración de dependencias. Hai algunhas solucións: quen usa que?
Podo suxerir que solucións hai. Podes usar Terraform para facer a maxia, ou podes usar makefiles para usar Terraform. E mira se algo cambiou alí, podes lanzalo aquí.
Como che parece esta decisión? Alguén cre que esta é unha solución xenial? Vexo un sorriso, ao parecer apareceron dúbidas.
Por suposto, non o probes na casa. Terraform nunca foi deseñado para ser executado desde Terraform.
Nun informe dixéronme: "Non, isto non funcionará". A cuestión é que non debería funcionar. Aínda que parece tan impresionante cando podes lanzar Terraform desde Terraform, e despois Terraform, non deberías facelo. Terraform debe comezar sempre con moita facilidade.
Se necesitas orquestración de chamadas cando algo cambiou nun lugar, entón está Terragrunt.
Terragrunt é unha utilidade, un complemento de Terraform, que che permite coordinar e orquestrar chamadas a módulos de infraestrutura.
Un ficheiro de configuración típico de Terraform ten este aspecto.
Especifica a que módulo específico quere chamar.
Que dependencias ten o módulo?
E que argumentos acepta este módulo. Iso é todo o que hai que saber sobre Terragrunt.
A documentación está aí e hai 1 estrelas en GitHub. Pero na maioría dos casos isto é o que necesitas saber. E isto é moi sinxelo de implementar en empresas que están empezando a traballar con Terraform.
Así que a orquestración é Terragrunt. Hai outras opcións.
Agora imos falar sobre como traballar co código.
Se precisas engadir novas funcións ao teu código, na maioría dos casos isto é sinxelo. Estás escribindo un novo recurso, todo é sinxelo.
Se tes algún recurso que creaches con antelación, por exemplo, coñeceches Terraform despois de abrir unha conta de AWS e queres utilizar os recursos que xa tes, sería apropiado ampliar o teu módulo deste xeito, para que apoia o uso dos recursos existentes.
E apoiou a creación de novos recursos utilizando o recurso de bloque.
Na saída sempre devolvemos o ID de saída dependendo do que se utilizou.
O segundo problema moi significativo en Terraform 0.11 é traballar con listas.
A dificultade é que si temos unha lista de usuarios así.
E cando creamos estes usuarios usando recursos de bloque, todo vai ben. Percorremos toda a lista, creando un ficheiro para cada un. Todo está ben. E entón, por exemplo, o usuario3, que está no medio, debería eliminarse de aquí, entón todos os recursos que se crearon despois del serán recreados porque o índice cambiará.
Traballar con listas nun ambiente con estado. Que é un ambiente estatal? Esta é a situación na que se crea un novo valor cando se crea este recurso. Por exemplo, AWS Access Key ou AWS Secret Key, é dicir, cando creamos un usuario, recibimos unha nova Access ou Secret Key. E cada vez que eliminemos un usuario, este terá unha nova clave. Pero isto non é feng shui, porque o usuario non quererá ser amigo de nós se creamos un novo usuario para el cada vez que alguén abandone o equipo.
Esta é a solución. Este é código escrito en Jsonnet. Jsonnet é unha linguaxe de modelos de Google.
Este comando permítelle aceptar este modelo e como saída devolve un ficheiro json que está feito segundo o seu modelo.
O modelo ten este aspecto.
Terraform permítelle traballar tanto con HCL como con Json do mesmo xeito, polo que se tes a capacidade de xerar Json, podes introducilo en Terraform. O ficheiro coa extensión .tf.json descargarase correctamente.
E despois traballamos con el como sempre: terraform init, terramorm apply. E creamos dous usuarios.
Agora non temos medo se alguén deixa o equipo. Simplemente editaremos o ficheiro json. Vasya Pupkin marchou, Petya Pyatochkin quedou. Petya Pyatochkin non recibirá unha nova chave.
Integrar Terraform con outras ferramentas non é realmente o traballo de Terraform. Terraform creouse como unha plataforma para crear recursos e xa está. E todo o que xurda despois non é a preocupación de Terraform. E non hai necesidade de tecelo alí dentro. Hai Ansible, que fai todo o que necesitas.
Pero xorden situacións cando queremos estender Terraform e chamar a algún comando despois de que algo se complete.
Primeiro camiño. Creamos unha saída onde escribimos este comando.
E entón chamamos a este comando desde a saída de terraform de shell e especificamos o valor que queremos. Así, o comando execútase con todos os valores substituídos. É moi cómodo.
Segundo camiño. Este é o uso de null_resource dependendo dos cambios na nosa infraestrutura. Podemos chamar ao mesmo local-exe tan pronto como o ID dalgún recurso cambie.
Por suposto, todo isto é suave no papel, porque Amazon, como todos os outros provedores públicos, ten unha morea de casos propios.
O caso máis común é que cando abres unha conta de AWS, importan as rexións que uses; esta función está habilitada alí; quizais o abriches despois de decembro de 2013; quizais esteas a usar o predeterminado en VPC, etc. Hai moitas restricións. E Amazon espallounas por toda a documentación.
Hai algunhas cousas que recomendo evitar.
Para comezar, evite todos os argumentos non secretos dentro do plan Terraform ou da CLI de Terraform. Todo isto pódese poñer nun ficheiro tfvars ou nunha variable de ambiente.
Pero non necesitas memorizar todo este comando máxico. Plan Terraform - var e imos. A primeira variable é var, a segunda variable é var, a terceira, a cuarta. O principio máis importante da infraestrutura como código que uso máis a miúdo é que só con mirar o código, debería ter unha comprensión clara do que se implanta alí, en que estado e con que valores. E así non teño que ler a documentación nin preguntarlle a Vasya que parámetros utilizou para crear o noso clúster. Só teño que abrir un ficheiro coa extensión tfvars, que moitas veces coincide co entorno, e mirar todo alí.
Ademais, non use argumentos de destino para reducir o alcance. Para iso é moito máis doado empregar pequenos módulos de infraestrutura.
Ademais, non hai que limitar e aumentar o paralelismo. Se teño 150 recursos e quero aumentar o paralelismo de Amazon desde o valor predeterminado de 10 a 100, o máis probable é que algo saia mal. Ou pode ir ben agora, pero cando Amazon diga que estás facendo demasiadas chamadas, terás problemas.
Terraform tentará reiniciar a maioría destes problemas, pero non conseguirás case nada. Paralelismo=1 é unha cousa importante para usar se se atopa algún erro dentro da API de AWS ou dentro do provedor de Terraform. E entón cómpre especificar: paralelismo=1 e esperar ata que Terraform remate unha chamada, despois a segunda, despois a terceira. Vainos lanzar un por un.
A xente adoita preguntarme: "Por que creo que os espazos de traballo de Terraform son malvados?" Creo que o principio da infraestrutura como código é ver que infraestrutura se creou e con que valores.
Os espazos de traballo non foron creados polos usuarios. Isto non significa que os usuarios escribiron en GitHub problemas que non podemos vivir sen espazos de traballo de Terraform. Non, non así. Terraform Enterprise é unha solución comercial. Terraform de HashiCorp decidiu que necesitábamos espazos de traballo, polo que o arquivamos. Paréceme moito máis doado poñelo nun cartafol separado. Despois haberá un pouco máis de ficheiros, pero quedará máis claro.
Como traballar co código? De feito, traballar con listas é a única dor. E toma Terraform máis fácil. Isto non é o que fará todo ben por ti. Non hai que meter alí todo o que está escrito na documentación.
O tema do informe foi escrito "para o futuro". Vou falar disto moi brevemente. Para o futuro, isto significa que 0.12 será lanzado en breve.
0.12 é un montón de cousas novas. Se procedes da programación normal, perderás todo tipo de bloques dinámicos, bucles, operacións de comparación correctas e condicionais, onde os lados esquerdo e dereito non se calculan simultáneamente, senón dependendo da situación. Botas moito de menos, así que 0.12 resolverao por ti.
Pero! Se escribes cada vez de forma máis sinxela, utilizando módulos prefabricados e solucións de terceiros, non terás que esperar e esperar que chegue o 0.12 e che solucione todo.
Grazas polo informe! Falaches da infraestrutura como código e literalmente dixo unha palabra sobre probas. Necesítanse probas nos módulos? De quen é esta responsabilidade? Necesito escribilo eu ou é responsabilidade dos módulos?
O ano que vén encherase de informes de que decidimos probar todo. Que probar é a maior pregunta. Hai moitas dependencias, moitas restricións de diferentes provedores. Cando falamos ti e eu e dis: "Necesito probas", entón pregunto: "Que probarás?" Vostede di que probará na súa rexión. Despois digo que isto non funciona na miña comarca. É dicir, nin sequera poderemos poñernos de acordo nisto. Sen esquecer que hai moitos problemas técnicos. É dicir, como escribir estas probas para que sexan adecuadas.
Estou investigando activamente este tema, é dicir, como xerar probas automaticamente en función da infraestrutura que escribiches. É dicir, se escribiu este código, entón teño que executalo, en base a isto podo crear probas.
é unha das bibliotecas máis mencionadas que che permite escribir probas de integración para Terraform. Esta é unha das utilidades. Prefiro o tipo DSL, por exemplo, rspec.
Antón, grazas pola reportaxe! Chámome Valery. Permíteme facer unha pequena pregunta filosófica. Hai, condicionalmente, aprovisionamento, hai despregamento. O aprovisionamento crea a miña infraestrutura, no despregamento enchémola con algo útil, por exemplo, servidores, aplicacións, etc. E na miña cabeza está Terraform máis para aprovisionamento, e Ansible é máis para o despregamento, porque Ansible tamén é para a infraestrutura física. permítelle instalar nginx, Postgres. Pero ao mesmo tempo, Ansible parece permitir o aprovisionamento, por exemplo, de recursos de Amazon ou Google. Pero Terraform tamén permite implementar algún software usando os seus módulos. Desde o teu punto de vista, hai algún tipo de fronteira que transcorra entre Terraform e Ansible, onde e que é mellor usar? Ou, por exemplo, cres que Ansible xa é lixo, deberías intentar usar Terraform para todo?
Boa pregunta, Valery. Creo que Terraform non cambiou en termos de propósito desde 2014. Creouse para as infraestruturas e morreu para as infraestruturas. Aínda tiñamos e teremos necesidade de xestión de configuración Ansible. O reto é que hai datos de usuario dentro de launch_configuration. E alí tiras Ansible, etc. Esta é a distinción estándar que máis me gusta.
Se estamos a falar dunha infraestrutura fermosa, entón hai utilidades como Packer que recollen esta imaxe. E entón Terraform usa a fonte de datos para atopar esta imaxe e actualizar a súa configuración_lanzamento. É dicir, deste xeito a canalización é que primeiro tiramos de Tracker e despois tiramos de Terraform. E se se produce a construción, prodúcese un novo cambio.
Ola! Grazas polo informe! Chámome Misha, empresa de RBS. Podes chamar a Ansible a través do provedor ao crear un recurso. Ansible tamén ten un tema chamado inventario dinámico. E primeiro podes chamar a Terraform e despois chamar a Ansible, que tomará recursos do estado e executarao. Que é mellor?
A xente usa ambos con igual éxito. Paréceme que o inventario dinámico en Ansible é algo conveniente, se non estamos a falar de grupo de escalado automático. Porque no grupo de escalado automático xa temos o noso propio kit de ferramentas, que se chama launch_configuration. En launch_configuration rexistramos todo o que hai que lanzar cando creamos un novo recurso. Polo tanto, con Amazon, usar o inventario dinámico e ler o ficheiro Terraform ts, na miña opinión, é excesivo. E se usas outras ferramentas onde non hai concepto de "grupo de escalado automático", por exemplo, usas DigitalOcean ou algún outro provedor onde non hai un grupo de escalado automático, entón terás que tirar manualmente a API, atopar enderezos IP, crear un ficheiro de inventario dinámico e Ansible xa o percorrerá. É dicir, para Amazon hai launch_configuration e para todo o demais hai inventario dinámico.
Fonte: www.habr.com