Muitas pessoas conhecem e usam o Terraform em seu trabalho diário, mas as melhores práticas para isso ainda não foram definidas. Cada equipe tem que inventar suas próprias abordagens e métodos.
Sua infraestrutura quase certamente começa simples: alguns recursos + alguns desenvolvedores. Com o tempo, ele cresce em todas as direções. Você encontra maneiras de agrupar recursos em módulos do Terraform, organizar o código em pastas e o que mais pode dar errado? (últimas palavras famosas)
O tempo passa e você sente que sua infraestrutura é seu novo animal de estimação, mas por quê? Você está preocupado com mudanças inexplicáveis na infraestrutura, tem medo de mexer na infraestrutura e no código - como resultado, você atrasa novas funcionalidades ou reduz a qualidade...
Após três anos gerenciando uma coleção de módulos da comunidade Terraform para AWS no Github e manutenção de longo prazo do Terraform em produção, Anton Babenko está pronto para compartilhar sua experiência: como escrever módulos TF para que não prejudique no futuro.
Ao final da palestra, os participantes estarão mais familiarizados com os princípios de gerenciamento de recursos do Terraform, as melhores práticas associadas aos módulos do Terraform e alguns princípios de integração contínua associados ao gerenciamento de infraestrutura.
Aviso Legal: Observo que este relatório é datado de novembro de 2018 – já se passaram 2 anos. A versão do Terraform 0.11 discutida no relatório não é mais suportada. Nos últimos 2 anos, foram lançados 2 novos lançamentos, que contêm muitas inovações, melhorias e mudanças. Preste atenção a isso e verifique a documentação.
Links:
- +
- - código e documentação de formatação automática
- — gerador de módulos Terraform (WIP)
- — Gerador de código Terraform a partir de diagramas visuais (WIP)
- www.terraform-best-practices.com
- (Novas postagens estão no meu site pessoal www.antonbabenko.com/)
- @antonbabenko - Twitter e um monte de calças diferentes
Meu nome é Anton Babenko. Alguns de vocês provavelmente usaram o código que escrevi. Falarei agora sobre isto com mais confiança do que nunca, porque tenho acesso às estatísticas.
Trabalho no Terraform e tenho participado ativamente e contribuído para um grande número de projetos de código aberto relacionados ao Terraform e Amazon desde 2015.
Desde então, escrevi código suficiente para colocá-lo de uma forma interessante. E vou tentar falar sobre isso agora.
Falarei sobre os meandros e especificidades de trabalhar com o Terraform. Mas esse não é realmente o assunto do HighLoad. E agora você vai entender o porquê.
Com o tempo, comecei a escrever módulos Terraform. Os usuários escreveram perguntas, eu as reescrevi. Então escrevi vários utilitários para formatar o código usando um gancho de pré-confirmação, etc.
Houve muitos projetos interessantes. Gosto de geração de código porque gosto que o computador faça cada vez mais trabalho para mim e para o programador, por isso estou trabalhando atualmente em um gerador de código Terraform a partir de diagramas visuais. Talvez alguns de vocês os tenham visto. São lindas caixas com flechas. E acho ótimo se você puder clicar no botão “Exportar” e obter tudo como código.
Eu sou da Ucrânia. Moro na Noruega há muitos anos.
Além disso, as informações para este relatório foram coletadas de pessoas que sabem meu nome e me encontram nas redes sociais. Quase sempre tenho o mesmo apelido.
Como mencionei, sou o principal mantenedor dos módulos Terraform AWS, que é um dos maiores repositórios no GitHub onde hospedamos módulos para as tarefas mais comuns: VPC, Autoscaling, RDS.
E o que você ouviu agora é o mais básico. Se você duvida que entende o que é Terraform, então é melhor gastar seu tempo em outro lugar. Haverá muitos termos técnicos aqui. E não hesitei em declarar o nível do relatório como o mais elevado. Isso significa que posso falar usando todos os termos possíveis sem muitas explicações.
O Terraform apareceu em 2014 como um utilitário que permitia escrever, planejar e gerenciar infraestrutura como código. O conceito-chave aqui é “infraestrutura como código”.
Toda a documentação, como eu disse, está escrita em . Espero que a maioria das pessoas conheça este site e tenha lido a documentação. Se sim, então você está no lugar certo.
Esta é a aparência de um arquivo de configuração regular do Terraform, onde primeiro definimos algumas variáveis.
Neste caso definimos "aws_region".
Em seguida, descrevemos quais recursos queremos criar.
Executamos alguns comandos, em particular “terraform init” para carregar dependências e provedores.
E executamos o comando “terraform apply” para verificar se a configuração especificada corresponde aos recursos que criamos. Como não criamos nada antes, o Terraform nos solicita a criação desses recursos.
Nós confirmamos isso. Assim criamos um balde chamado seasnail.
Existem também vários utilitários semelhantes. Muitos de vocês que usam a Amazon conhecem AWS CloudFormation, Google Cloud Deployment Manager ou Azure Resource Manager. Cada um deles tem algum tipo de implementação própria para gerenciar recursos dentro de cada um desses provedores de nuvem pública. O Terraform é especialmente útil porque permite gerenciar mais de 100 provedores. (Mais detalhes )
Os objetivos que a Terraform perseguiu desde o início:
- O Terraform fornece uma visão única dos recursos.
- Permite oferecer suporte a todas as plataformas modernas.
- E o Terraform foi projetado desde o início como um utilitário que permite alterar a infraestrutura de forma segura e previsível.
Em 2014, a palavra “previsível” soava muito incomum neste contexto.
Terraform é um utilitário universal. Se você tiver uma API, poderá controlar absolutamente tudo:
- Você pode usar mais de 120 provedores para gerenciar tudo o que quiser.
- Por exemplo, você pode usar o Terraform para descrever o acesso aos repositórios GitHub.
- Você pode até criar e fechar bugs no Jira.
- Você pode gerenciar as métricas do New Relic.
- Você pode até criar arquivos no Dropbox se realmente quiser.
Tudo isso é conseguido usando provedores Terraform, que possuem uma API aberta que pode ser descrita em Go.
Digamos que começamos a usar o Terraform, lemos alguma documentação do site, assistimos a alguns vídeos e começamos a escrever main.tf, como mostrei nos slides anteriores.
E está tudo ótimo, você tem um arquivo que cria uma VPC.
Se você deseja criar uma VPC, especifique aproximadamente essas 12 linhas. Descreva em qual região você deseja criar, qual cidr_block de endereços IP usar. Isso é tudo.
Naturalmente, o projeto crescerá gradativamente.
E você adicionará um monte de coisas novas lá: recursos, fontes de dados, integrará com novos provedores, de repente você desejará usar o Terraform para gerenciar usuários em sua conta GitHub, etc. Provedores de DNS, cruzam tudo. O Terraform torna isso fácil.
Vejamos o exemplo a seguir.
Você adiciona internet_gateway gradualmente porque deseja que os recursos da sua VPC tenham acesso à Internet. Essa é uma boa ideia.
O resultado é este main.tf:
Esta é a parte superior do main.tf.
Esta é a parte inferior do main.tf.
Então você adiciona sub-rede. No momento em que você quiser adicionar gateways NAT, rotas, tabelas de roteamento e várias outras sub-redes, você não terá 38 linhas, mas aproximadamente 200-300 linhas.
Ou seja, seu arquivo main.tf está crescendo gradativamente. E muitas vezes as pessoas colocam tudo em um arquivo. 10-20 Kb aparecem em main.tf. Imagine que 10-20 Kb seja conteúdo de texto. E tudo está conectado a tudo. Isso está gradualmente se tornando difícil de trabalhar. 10-20 Kb é um bom caso de usuário, às vezes mais. E as pessoas nem sempre pensam que isso é ruim.
Como na programação normal, ou seja, não na infraestrutura como código, estamos acostumados a usar várias classes, pacotes, módulos e agrupamentos diferentes. O Terraform permite que você faça praticamente a mesma coisa.
- O código está crescendo.
- As dependências entre recursos também estão aumentando.
E temos uma grande, grande necessidade. Entendemos que não podemos mais viver assim. Nosso código está se tornando imenso. É claro que 10-20 Kb não é muito vasto, mas estamos falando apenas sobre a pilha de rede, ou seja, você adicionou apenas recursos de rede. Não estamos falando de Application Load Balancer, cluster ES de implantação, Kubernetes, etc., onde 100 Kb podem ser facilmente integrados. Se você anotar tudo isso, logo aprenderá que o Terraform fornece módulos Terraform.
Os módulos do Terraform são uma configuração independente do Terraform gerenciada como um grupo. Isso é tudo que você precisa saber sobre os módulos Terraform. Eles não são nada inteligentes, não permitem que você faça conexões complexas dependendo de alguma coisa. Tudo isso recai sobre os ombros dos desenvolvedores. Ou seja, é apenas algum tipo de configuração do Terraform que você já escreveu. E você pode simplesmente chamá-lo como um grupo.
Então, estamos tentando entender como otimizaremos nossos 10-20-30 Kb de código. Aos poucos estamos percebendo que precisamos utilizar alguns módulos.
O primeiro tipo de módulos que você encontra são módulos de recursos. Eles não entendem do que se trata a sua infraestrutura, do que se trata o seu negócio, onde e quais são as condições. Esses são exatamente os módulos que eu, junto com a comunidade de código aberto, administro e que apresentamos como os blocos de construção iniciais para sua infraestrutura.
Um exemplo de módulo de recursos.
Quando chamamos um módulo de recurso, especificamos de qual caminho devemos carregar seu conteúdo.
Indicamos qual versão queremos baixar.
Passamos um monte de argumentos lá. Isso é tudo. Isso é tudo que precisamos saber quando usamos este módulo.
Muitas pessoas pensam que se usarem a versão mais recente, tudo ficará estável. Mas não. A infraestrutura deve ser versionada, devemos responder claramente em qual versão este ou aquele componente foi implantado.
Aqui está o código que está dentro deste módulo. Módulo de grupo de segurança. Aqui o pergaminho vai para a 640ª linha. Criar um recurso de segurança na Amazon em todas as configurações possíveis não é uma tarefa trivial. Não basta simplesmente criar um grupo de segurança e dizer quais regras passar para ele. Seria muito simples. Existem um milhão de restrições diferentes dentro da Amazon. Por exemplo, se você usar Endpoint VPC, lista de prefixos, diversas APIs e tenta combinar tudo isso com todo o resto, então o Terraform não permite que você faça isso. E a API da Amazon também não permite isso. Portanto, precisamos esconder toda essa lógica terrível em um módulo e fornecer o código do usuário parecido com este.
O usuário não precisa saber como é feito por dentro.
O segundo tipo de módulos, que consiste em módulos de recursos, já resolvem problemas mais aplicáveis ao seu negócio. Muitas vezes este é um local que é uma extensão do Terraform e define alguns valores rígidos para tags, para padrões da empresa. Você também pode adicionar funcionalidades que o Terraform não permite usar atualmente. Isto é agora. Agora versão 0.11, que está prestes a se tornar coisa do passado. Mesmo assim, pré-processadores, jsonnet, cookiecutter e um monte de outras coisas são o mecanismo auxiliar que deve ser usado para um trabalho completo.
A seguir mostrarei alguns exemplos disso.
O módulo de infraestrutura é chamado exatamente da mesma maneira.
É indicada a fonte de onde baixar o conteúdo.
Vários valores são passados e passados para este módulo.
Em seguida, dentro deste módulo, vários módulos de recursos são chamados para criar um VPC ou Application Load Balancer, ou para criar um grupo de segurança ou para um cluster do Elastic Container Service.
Existem dois tipos de módulos. É importante entender isso porque a maioria das informações que agrupei neste relatório não está escrita na documentação.
E a documentação do Terraform no momento é bastante problemática porque apenas diz que existem esses recursos, você pode usá-los. Mas ela não diz como usar esses recursos, por que é melhor usá-los. Portanto, um grande número de pessoas escreve algo com o qual não conseguem conviver.
Vamos dar uma olhada em como escrever esses módulos a seguir. Depois veremos como chamá-los e como trabalhar com o código.
Registro Terraform -
A dica nº 0 é não escrever módulos de recursos. A maioria desses módulos já foi escrita para você. Como eu disse, eles são de código aberto, não contêm nenhuma lógica de negócios, não possuem valores codificados para endereços IP, senhas, etc. E provavelmente já foi escrito. Existem muitos módulos para recursos da Amazon. Cerca de 650. E a maioria deles são de boa qualidade.
Neste exemplo, alguém veio até você e disse: “Quero poder gerenciar um banco de dados. Crie um módulo para que eu possa criar um banco de dados." A pessoa não conhece os detalhes de implementação do Amazon ou do Terraform. Ele simplesmente diz: “Quero gerenciar MSSQL”. Ou seja, queremos dizer que ele vai chamar nosso módulo, passar lá o tipo de motor e indicar o fuso horário.
E ninguém deve saber que criaremos dois recursos diferentes dentro deste módulo: um para MSSQL, o segundo para todo o resto, apenas porque no Terraform 0.11 você não pode especificar valores de fuso horário como opcionais.
E ao sair deste módulo, a pessoa poderá simplesmente receber um endereço. Ele não vai saber de qual banco de dados, de qual recurso estamos criando tudo isso internamente. Este é um elemento muito importante de ocultação. E isso se aplica não apenas aos módulos que são públicos em código aberto, mas também aos módulos que você escreverá dentro de seus projetos e equipes.
Este é o segundo argumento, que é muito importante se você já usa o Terraform há algum tempo. Você tem um repositório no qual coloca todos os módulos Terraform da sua empresa. E é normal que com o tempo esse projeto cresça até um ou dois megabytes. Isto é bom.
Mas o problema é como o Terraform chama esses módulos. Por exemplo, se você chamar um módulo para criar cada usuário individual, o Terraform primeiro carregará todo o repositório e depois navegará até a pasta onde esse módulo específico está localizado. Dessa forma, você baixará um megabyte de cada vez. Se você gerencia 100 ou 200 usuários, fará download de 100 ou 200 megabytes e irá para essa pasta. Então, naturalmente, você não quer baixar um monte de coisas toda vez que clicar em "Terraform init".
Existem duas soluções para este problema. A primeira é usar caminhos relativos. Desta forma você indica no código que a pasta é local (./). E antes de lançar qualquer coisa, você faz um clone Git deste repositório localmente. Dessa forma você faz isso uma vez.
É claro que existem muitas desvantagens. Por exemplo, você não pode usar controle de versão. E às vezes é difícil conviver com isso.
Segunda solução. Se você possui muitos submódulos e já possui algum tipo de pipeline estabelecido, existe o projeto MBT, que permite coletar muitos pacotes diferentes de um monorepositório e carregá-los no S3. Esta é uma maneira muito boa. Assim, o arquivo iam-user-1.0.0.zip pesará apenas 1 Kb, pois o código para criar este recurso é muito pequeno. E funcionará muito mais rápido.
Vamos falar sobre o que não pode ser usado em módulos.
Por que esse mal está nos módulos? O pior é assumir usuário. Suponha que usuário seja uma opção de autenticação de provedor que pode ser usada por pessoas diferentes. Por exemplo, todos nós assimilaremos o papel. Isso significa que o Terraform assumirá essa função. E então com essa função ele realizará outras ações.
E o mal é que se Vasya gosta de se conectar à Amazon de uma maneira, por exemplo, usando a variável de ambiente padrão, e Petya gosta de usar sua chave compartilhada, que ele tem em um lugar secreto, então você não pode especificar ambos em Terraforma. E para que não vivenciem sofrimento, não há necessidade de indicar esse bloco no módulo. Isto deve ser indicado em um nível superior. Ou seja, temos um módulo de recursos, um módulo de infraestrutura e uma composição por cima. E isso deve ser indicado em algum lugar acima.
O segundo mal é o provisionador. Aqui o mal não é tão trivial, porque se você escreve código e ele funciona para você, então você pode pensar que se funciona, então por que alterá-lo.
O mal é que nem sempre você controla quando esse provisionador será lançado, em primeiro lugar. E em segundo lugar, você não controla o que significa aws ec2, ou seja, estamos falando de Linux ou Windows agora. Portanto, você não pode escrever algo que funcione da mesma forma em diferentes sistemas operacionais ou para diferentes casos de usuário.
O exemplo mais comum, que também é indicado na documentação oficial, é que se você escrever aws_instance e especificar vários argumentos, então não há nada de errado com isso se você especificar o provisionador “local-exec” lá e executar seu ansible- livro de cantadas .
Na verdade, sim, não há nada de errado com isso. Mas literalmente em breve você perceberá que essa coisa de local-exec não existe, por exemplo, em launch_configuration.
E quando você usa launch_configuration e deseja criar um grupo de escalonamento automático a partir de uma instância, então em launch_configuration não existe o conceito de “provisionador”. Existe o conceito de “dados do usuário”.
Portanto, uma solução mais universal é usar os dados do usuário. E será iniciado na própria instância, quando a instância estiver ativada, ou nos mesmos dados do usuário, quando o grupo de escalonamento automático usar esta launch_configuration.
Se você ainda deseja executar o provisionador, por ser um componente de colagem, quando um recurso é criado, nesse momento você precisa executar o seu provisionador, o seu comando. Existem muitas dessas situações.
E o recurso mais correto para isso se chama null_resource. Null_resource é um recurso fictício que nunca é realmente criado. Não toca em nada, nem API, nem escalonamento automático. Mas permite controlar quando executar o comando. Neste caso, o comando é executado durante a criação.
Link
Existem vários sinais. Não entrarei em detalhes sobre todos os sinais. Existe um artigo sobre isso. Mas se você trabalhou com Terraform ou usou módulos de outras pessoas, então notou frequentemente que muitos módulos, como a maior parte do código em código aberto, são escritos por pessoas para suas próprias necessidades. Um homem escreveu e resolveu seu problema. Coloquei no GitHub, deixei viver. Ele viverá, mas se não houver documentação e exemplos, ninguém o usará. E se não houver uma funcionalidade que permita resolver um pouco mais do que sua tarefa específica, ninguém a utilizará. Existem muitas maneiras de perder usuários.
Se você quiser escrever algo para que as pessoas possam usar, recomendo seguir estes sinais.
Estes são:
- Documentação e exemplos.
- Funcionalidade completa.
- Padrões razoáveis.
- Código limpo.
- Testes
Os testes são uma situação diferente porque são bastante difíceis de escrever. Acredito mais em documentação e exemplos.
Então, vimos como escrever módulos. Existem dois argumentos. A primeira, que é a mais importante, é não escrever se puder, porque muita gente já fez essas tarefas antes de você. E em segundo lugar, se você decidir, tente não usar provedores em módulos e provisionadores.
Esta é a parte cinza da documentação. Agora você pode estar pensando: “Algo não está claro. Não convencido." Mas veremos em seis meses.
Agora vamos falar sobre como chamar esses módulos.
Entendemos que nosso código cresce com o tempo. Não temos mais um arquivo, já temos 20 arquivos. Eles estão todos em uma pasta. Ou talvez cinco pastas. Talvez estejamos começando a decompô-los de alguma forma por região, por alguns componentes. Então entendemos que agora temos alguns rudimentos de sincronização e orquestração. Ou seja, devemos entender o que deveríamos fazer se alterássemos os recursos da rede, o que deveríamos fazer com o restante dos nossos recursos, como causar essas dependências, etc.
Existem dois extremos. O primeiro extremo é tudo em um. Temos um arquivo mestre. Por enquanto, esta era a prática recomendada oficial no site Terraform.
Mas agora está escrito como obsoleto e removido. Com o tempo, a comunidade Terraform percebeu que esta estava longe de ser a melhor prática, porque as pessoas começaram a utilizar o projeto de diferentes maneiras. E há problemas. Por exemplo, quando listamos todas as dependências em um só lugar. Há situações em que clicamos em “plano Terraform” e até que o Terraform atualize os estados de todos os recursos, pode passar muito tempo.
Muito tempo é, por exemplo, 5 minutos. Para alguns, isso é muito tempo. Já vi casos em que demorou 15 minutos. A API da AWS gastou 15 minutos tentando descobrir o que estava acontecendo com o estado de cada recurso. Esta é uma área muito grande.
E, naturalmente, um problema relacionado aparecerá quando você quiser mudar algo em um lugar, então você espera 15 minutos, e isso te dá uma tela de algumas mudanças. Você cuspiu, escreveu “Sim” e algo deu errado. Este é um exemplo muito real. O Terraform não tenta protegê-lo de problemas. Ou seja, escreva o que quiser. Haverá problemas – seus problemas. Embora o Terraform 0.11 não esteja tentando ajudá-lo de forma alguma. Existem certos lugares interessantes em 0.12 que permitem que você diga: “Vasya, você realmente quer isso, pode voltar a si?”
A segunda forma é reduzir essa área, ou seja, chamadas de um local podem ser menos conectadas de outro local.
O único problema é que você precisa escrever mais código, ou seja, você precisa descrever variáveis em um grande número de arquivos e atualizá-los. Algumas pessoas não gostam disso. Isso é normal para mim. E algumas pessoas pensam: “Por que escrever isso em lugares diferentes, vou colocar tudo em um só lugar”. Isto é possível, mas este é o segundo extremo.
Quem tem tudo isso morando em um só lugar? Uma, duas, três pessoas, ou seja, alguém está usando.
E quem chama um determinado componente, um bloco ou um módulo de infraestrutura? Cinco a sete pessoas. Isso é legal.
A resposta mais comum está em algum lugar no meio. Se o projeto for grande, muitas vezes você terá uma situação em que nenhuma solução é adequada e nem tudo dá certo, então você acaba com uma mistura. Não há nada de errado nisso, desde que você entenda que ambos têm vantagens.
Se algo mudou na pilha VPC e você queria aplicar essas mudanças ao EC2, ou seja, você queria atualizar o grupo de escalonamento automático porque tinha uma nova sub-rede, então eu chamo esse tipo de orquestração de dependência. Existem algumas soluções: quem usa o quê?
Posso sugerir quais soluções existem. Você pode usar o Terraform para fazer a mágica ou pode usar makefiles para usar o Terraform. E veja se algo mudou aí, você pode lançar aqui.
O que você achou dessa decisão? Alguém acredita que esta é uma solução legal? Vejo um sorriso, aparentemente surgiram dúvidas.
Claro, não tente isso em casa. O Terraform nunca foi projetado para ser executado no Terraform.
Num relatório disseram-me: “Não, isto não vai funcionar”. A questão é que isso não deveria funcionar. Embora pareça tão impressionante quando você pode iniciar o Terraform a partir do Terraform e depois do Terraform, você não deveria fazer isso. O Terraform deve sempre iniciar com muita facilidade.
Se você precisar de orquestração de chamadas quando algo mudou em um lugar, existe o Terragrunt.
Terragrunt é um utilitário, um complemento do Terraform, que permite coordenar e orquestrar chamadas para módulos de infraestrutura.
Um arquivo de configuração típico do Terraform se parece com isto.
Você especifica qual módulo específico deseja chamar.
Quais dependências o módulo possui?
E quais argumentos este módulo aceita. Isso é tudo que há para saber sobre Terragrunt.
A documentação está aí e há 1 estrelas no GitHub. Mas na maioria dos casos é isso que você precisa saber. E isso é muito fácil de implementar em empresas que estão começando a trabalhar com Terraform.
Então orquestração é Terragrunt. Existem outras opções.
Agora vamos falar sobre como trabalhar com o código.
Se você precisar adicionar novos recursos ao seu código, na maioria dos casos isso será fácil. Você está escrevendo um novo recurso, tudo é simples.
Se você possui algum recurso que criou antecipadamente, por exemplo, você aprendeu sobre o Terraform depois de abrir uma conta AWS e deseja usar os recursos que já possui, então seria apropriado estender seu módulo desta forma, para que apoia a utilização dos recursos existentes.
E apoiou a criação de novos recursos utilizando o recurso de bloco.
Na saída sempre retornamos o id de saída dependendo do que foi usado.
O segundo problema muito significativo no Terraform 0.11 é trabalhar com listas.
A dificuldade é que se tivermos essa lista de usuários.
E quando criamos esses usuários usando recursos de bloco, tudo corre bem. Percorremos toda a lista, criando um arquivo para cada um. Tudo está bem. E aí, por exemplo, o usuário3, que está no meio, deve ser retirado daqui, então todos os recursos que foram criados depois dele serão recriados porque o índice vai mudar.
Trabalhando com listas em um ambiente com estado. O que é um ambiente com estado? Esta é a situação em que um novo valor é criado quando este recurso é criado. Por exemplo, AWS Access Key ou AWS Secret Key, ou seja, quando criamos um usuário, recebemos um novo Access ou Secret Key. E cada vez que excluímos um usuário, esse usuário terá uma nova chave. Mas isso não é feng shui, porque o usuário não vai querer ser nosso amigo se criarmos um novo usuário para ele toda vez que alguém sair do time.
Esta é a solução. Este é um código escrito em Jsonnet. Jsonnet é uma linguagem de modelagem do Google.
Este comando permite aceitar este template e como saída retorna um arquivo json que é feito de acordo com o seu template.
O modelo é assim.
O Terraform permite que você trabalhe com HCL e Json da mesma maneira, portanto, se você tiver a capacidade de gerar Json, poderá inseri-lo no Terraform. O arquivo com a extensão .tf.json será baixado com sucesso.
E então trabalhamos como de costume: terraform init, terramorm apply. E criamos dois usuários.
Agora não temos medo se alguém sair do time. Vamos apenas editar o arquivo json. Vasya Pupkin saiu, Petya Pyatochkin permaneceu. Petya Pyatochkin não receberá uma nova chave.
Integrar o Terraform com outras ferramentas não é realmente o trabalho do Terraform. O Terraform foi criado como uma plataforma de criação de recursos e pronto. E tudo o que surge depois não é da conta do Terraform. E não há necessidade de tecê-lo aí. Existe o Ansible, que faz tudo que você precisa.
Mas surgem situações em que queremos estender o Terraform e chamar algum comando após a conclusão de algo.
Primeira maneira. Criamos uma saída onde escrevemos este comando.
E então chamamos este comando a partir da saída do shell terraform e especificamos o valor que desejamos. Assim, o comando é executado com todos os valores substituídos. É muito confortável.
Segunda maneira. Este é o uso de null_resource dependendo das mudanças em nossa infraestrutura. Podemos chamar o mesmo exe local assim que o ID de algum recurso mudar.
Naturalmente, tudo isso é tranquilo no papel, porque a Amazon, como todos os outros provedores públicos, tem vários casos extremos.
O caso extremo mais comum é que, quando você abre uma conta da AWS, importa quais regiões você usa; esse recurso está habilitado lá; talvez você tenha aberto depois de dezembro de 2013; talvez você esteja usando o padrão no VPC etc. Existem muitas restrições. E a Amazon os espalhou pela documentação.
Existem algumas coisas que recomendo evitar.
Para começar, evite todos os argumentos não secretos dentro do plano Terraform ou da CLI do Terraform. Tudo isso pode ser colocado em um arquivo tfvars ou em uma variável de ambiente.
Mas você não precisa memorizar todo esse comando mágico. Plano Terraform – var e vamos lá. A primeira variável é var, a segunda variável é var, a terceira, quarta. O princípio mais importante da infraestrutura como código que utilizo com mais frequência é que apenas olhando para o código, devo ter uma compreensão clara do que está implantado nele, em que estado e com quais valores. E assim não preciso ler a documentação ou perguntar a Vasya quais parâmetros ele usou para criar nosso cluster. Só preciso abrir um arquivo com a extensão tfvars, que geralmente corresponde ao ambiente, e ver tudo que está lá.
Além disso, não use argumentos de destino para reduzir o escopo. Para isso é muito mais fácil utilizar pequenos módulos de infraestrutura.
Além disso, não há necessidade de limitar e aumentar o paralelismo. Se eu tiver 150 recursos e quiser aumentar o paralelismo da Amazon do padrão 10 para 100, provavelmente algo dará errado. Ou pode correr bem agora, mas quando a Amazon disser que você está fazendo muitas ligações, você terá problemas.
O Terraform tentará reiniciar a maioria desses problemas, mas você não conseguirá quase nada. Parallelism=1 é algo importante a ser usado se você encontrar algum bug na API da AWS ou no provedor Terraform. E então você precisa especificar: paralelismo=1 e esperar até que o Terraform termine uma chamada, depois a segunda e depois a terceira. Ele os lançará um por um.
As pessoas costumam me perguntar: “Por que acho que os espaços de trabalho do Terraform são ruins?” Acredito que o princípio da infra-estrutura como código é ver que infra-estrutura foi criada e com que valores.
Os espaços de trabalho não foram criados pelos usuários. Isso não significa que os usuários escreveram no GitHub questões que não podemos viver sem os espaços de trabalho do Terraform. Não, não assim. Terraform Enterprise é uma solução comercial. O Terraform da HashiCorp decidiu que precisávamos de espaços de trabalho, então arquivamos tudo. Acho muito mais fácil colocá-lo em uma pasta separada. Depois haverá um pouco mais de arquivos, mas ficará mais claro.
Como trabalhar com o código? Na verdade, trabalhar com listas é a única dor. E leve o Terraform com mais facilidade. Não é isso que fará tudo de bom para você. Não há necessidade de colocar ali tudo o que está escrito na documentação.
O tema do relatório foi escrito “para o futuro”. Falarei sobre isso muito brevemente. Para o futuro, isso significa que o 0.12 será lançado em breve.
0.12 é uma tonelada de coisas novas. Se você vem da programação regular, sente falta de todos os tipos de blocos dinâmicos, loops, operações de comparação correta e condicional, onde os lados esquerdo e direito não são calculados simultaneamente, mas dependendo da situação. Você sente muita falta, então 0.12 resolverá para você.
Mas! Se você escreve menos e de forma mais simples, usando módulos prontos e soluções de terceiros, não precisa esperar e torcer para que o 0.12 venha e conserte tudo para você.
Obrigado pelo relatório! Você falou sobre infraestrutura como código e disse literalmente uma palavra sobre testes. Os testes são necessários em módulos? De quem é essa responsabilidade? Preciso escrever sozinho ou é responsabilidade dos módulos?
O próximo ano será repleto de relatos de que decidimos testar tudo. O que testar é a maior questão. Existem muitas dependências, muitas restrições de diferentes provedores. Quando você e eu estamos conversando e você diz: “Preciso de testes”, então eu pergunto: “O que você vai testar?” Você diz que vai testar na sua região. Aí eu falo que isso não funciona na minha região. Ou seja, não conseguiremos nem chegar a acordo sobre isso. Sem falar que existem muitos problemas técnicos. Ou seja, como escrever esses testes para que sejam adequados.
Estou pesquisando ativamente esse tópico, ou seja, como gerar testes automaticamente com base na infraestrutura que você escreveu. Ou seja, se você escreveu esse código, então preciso executá-lo, com base nisso posso criar testes.
é uma das bibliotecas mencionadas com mais frequência que permite escrever testes de integração para Terraform. Este é um dos utilitários. Prefiro o tipo DSL, por exemplo, rspec.
Anton, obrigado pelo relatório! Meu nome é Valéry. Deixe-me fazer uma pequena pergunta filosófica. Existe, condicionalmente, provisionamento, existe implantação. O provisionamento cria minha infraestrutura, na implantação a gente preenche ela com algo útil, por exemplo, servidores, aplicações, etc. E está na minha cabeça que o Terraform é mais para provisionamento, e o Ansible é mais para implantação, porque o Ansible também é para a infraestrutura física permite que você instale nginx, Postgres. Mas, ao mesmo tempo, o Ansible parece permitir o provisionamento, por exemplo, de recursos da Amazon ou do Google. Mas o Terraform também permite implantar alguns softwares usando seus módulos. Do seu ponto de vista, existe algum tipo de fronteira entre o Terraform e o Ansible, onde e o que é melhor usar? Ou, por exemplo, você acha que Ansible já é um lixo, deveria tentar usar o Terraform para tudo?
Boa pergunta, Valéry. Acredito que o Terraform não mudou em termos de propósito desde 2014. Foi criado para infraestrutura e morreu para infraestrutura. Ainda tínhamos e teremos necessidade de gerenciamento de configuração Ansible. O desafio é que existem dados do usuário dentro do launch_configuration. E aí você puxa Ansible, etc. Essa é a distinção padrão que eu mais gosto.
Se estamos falando de uma bela infraestrutura, existem utilitários como o Packer que coletam essa imagem. E então o Terraform usa a fonte de dados para encontrar esta imagem e atualizar sua launch_configuration. Ou seja, desta forma o pipeline é que primeiro puxamos o Tracker e depois puxamos o Terraform. E se ocorrer a construção, ocorrerá uma nova mudança.
Olá! Obrigado pelo relatório! Meu nome é Misha, empresa RBS. Você pode chamar o Ansible por meio do provisionador ao criar um recurso. Ansible também possui um tópico chamado inventário dinâmico. E você pode primeiro ligar para o Terraform e depois para o Ansible, que pegará recursos do estado e os executará. O que é melhor?
As pessoas usam ambos com igual sucesso. Parece-me que o inventário dinâmico no Ansible é algo conveniente, se não estivermos falando de grupo de escalonamento automático. Porque no grupo de escalonamento automático já temos nosso próprio kit de ferramentas, que se chama launch_configuration. Em launch_configuration registramos tudo o que precisa ser lançado quando criamos um novo recurso. Portanto, com a Amazon, usar inventário dinâmico e ler o arquivo Terraform ts, na minha opinião, é um exagero. E se você usa outras ferramentas onde não existe o conceito de “grupo de escalonamento automático”, por exemplo, você usa DigitalOcean ou algum outro provedor onde não existe grupo de escalonamento automático, aí você terá que puxar manualmente a API, encontrar endereços IP, criar um arquivo de inventário dinâmico e o Ansible já irá percorrê-lo. Ou seja, para a Amazon existe launch_configuration e para todo o resto existe inventário dinâmico.
Fonte: habr.com