Parece que os desenvolvedores do Terraform oferecem práticas recomendadas bastante convenientes para trabalhar com a infraestrutura AWS. Só há uma nuance. Com o tempo, o número de ambientes aumenta, recursos aparecem em cada um. Aparece quase uma cópia da pilha de aplicativos na região vizinha. E o código do Terraform precisa ser cuidadosamente copiado e editado de acordo com os novos requisitos ou para fazer um floco de neve.
Meu relatório é sobre padrões no Terraform para combater o caos e a rotina manual em projetos grandes e longos.
Vídeo:
Tenho 40 anos, trabalho em TI há 20 anos. Trabalho na Ixtens há 12 anos. Estamos engajados no desenvolvimento orientado ao comércio eletrônico. E pratico práticas de DevOps há 5 anos.
Minha história será sobre a experiência em um projeto em uma empresa cujo nome não direi, escondida atrás de um acordo de sigilo.
Os números do slide são fornecidos para entender o escopo do projeto. E tudo o que vou dizer a seguir está relacionado à Amazon.
Entrei neste projeto há 4 anos. E a refatoração da infraestrutura estava a todo vapor, porque o projeto havia crescido. E aqueles padrões que eram usados, não servem mais. E diante de todo o crescimento planejado do projeto, foi preciso inventar algo novo.
Obrigado ao Matvey, que ontem nos contou o que aconteceu na Dodo Pizza. Foi o que aconteceu conosco há 4 anos.
Os desenvolvedores vieram e começaram a fazer código de infraestrutura.
A razão mais óbvia pela qual isso foi necessário foi o tempo de lançamento no mercado. Era necessário garantir que a equipe DevOps não fosse um gargalo durante a implementação. E entre outras coisas, Terraform e Puppet foram usados no primeiro nível.
Terraform é um projeto de código aberto da HashiCorp. E para quem não sabe o que é, os próximos slides.
Infraestrutura como código significa que podemos descrever nossa infraestrutura e pedir a alguns robôs que garantam que obteremos os recursos que descrevemos.
Por exemplo, precisamos de uma máquina virtual. Descreveremos e adicionaremos alguns parâmetros necessários.
Depois disso, configuraremos o acesso à Amazon no console. E peça o plano Terraform. O plano Terraform dirá: "Ok, com seus recursos, podemos fazer essas coisas." E pelo menos um recurso será adicionado. E nenhuma mudança é esperada.
Depois que tudo lhe convier, você pode solicitar a aplicação do Terraform e o Terraform criará uma instância para você, e você obterá uma máquina virtual em sua nuvem.
Além disso, nosso projeto se desenvolve. Estamos adicionando algumas mudanças lá. Pedimos mais instâncias, adicionamos 53 entradas.
E repetimos. Por favor, planeje. Vemos quais mudanças estão planejadas. Aplicar. E assim nossa infraestrutura cresce.
O Terraform usa arquivos de estado. Ou seja, ele salva todas as alterações que vão para a Amazon em um arquivo, onde para cada recurso que você descreveu, existem recursos correspondentes que foram criados na Amazon. Assim, ao alterar a descrição de um recurso, o Terraform sabe exatamente o que precisa ser alterado na Amazon.
Esses arquivos de estado eram originalmente apenas arquivos. E nós os armazenamos no Git, o que foi extremamente inconveniente. Constantemente alguém se esquecia de fazer alterações e havia muitos conflitos.
Agora é possível utilizar o backend, ou seja, o Terraform é indicado em qual bucket, por qual chave o arquivo de estado deve ser salvo. E o próprio Terraform se encarregará de pegar esse arquivo de estado, fazer toda a mágica e devolver o resultado final.
Nossa infraestrutura está crescendo. Aqui está nosso código. E agora não queremos apenas criar uma máquina virtual, queremos ter um ambiente de testes.
O Terraform permite que você crie um módulo, ou seja, descreva a mesma coisa em alguma pasta.
E, por exemplo, em testes, chame este módulo e obtenha a mesma coisa como se estivéssemos aplicando o Terraform no próprio módulo. Aqui está o código para teste.
Para produção, podemos enviar algumas alterações para lá, pois em testes não precisamos de instâncias grandes, em produção instâncias grandes serão úteis.
E então voltarei ao projeto. Foi uma tarefa difícil, a infraestrutura foi planejada de forma muito grande. E foi necessário colocar de alguma forma todo o código para que fosse conveniente para todos: para quem faz manutenção nesse código e para quem faz alterações. E foi planejado que qualquer desenvolvedor pudesse consertar a infraestrutura conforme necessário para sua parte da plataforma.
Esta é uma árvore de diretórios recomendada pela HashiCorp se você tiver um projeto grande e fizer sentido dividir toda a infraestrutura em algumas partes pequenas e descrever cada parte em uma pasta separada.
Tendo uma extensa biblioteca de recursos, você pode chamar a mesma coisa em testes e em produção.
No nosso caso, isso não era totalmente adequado, porque a pilha de testes para desenvolvedores ou para testes precisava ser obtida de alguma forma mais simples. E eu não queria passar pelas pastas e aplicar na sequência certa, e me preocupar que a base subisse, e então a instância que usa essa base subisse. Portanto, todos os testes foram iniciados a partir de uma pasta. Os mesmos módulos foram chamados lá, mas tudo aconteceu de uma só vez.
O Terraform cuida de todas as dependências. E sempre cria recursos nessa sequência para que você possa obter um endereço IP, por exemplo, de uma instância recém-criada, e obter esse endereço IP na entrada route53.
Além disso, a plataforma é muito grande. E executar uma pilha de testes, mesmo que por uma hora, mesmo que por 8 horas, é um negócio bastante caro.
E automatizamos esse negócio. E o trabalho do Jenkins permitiu que a pilha funcionasse. Foi necessário lançar nele um pull request com as alterações que o desenvolvedor deseja testar, especificar todas as opções, componentes e dimensões necessárias. Se ele quiser testes de desempenho, poderá realizar mais instâncias. Se ele precisar apenas verificar se algum formulário é aberto, ele poderá começar pelo mínimo. E também indique se um cluster é necessário ou não, etc.
E então Jenkins enviou um script de shell que modificou ligeiramente o código na pasta Terraform. Arquivos desnecessários removidos, adicionados os arquivos necessários. E então, com uma aplicação do Terraform, a pilha aumentou.
E depois houve outras etapas que não quero abordar.
Devido ao fato de que para os testes precisávamos de um pouco mais de opções do que na produção, tivemos que fazer cópias dos módulos para que nessas cópias pudéssemos adicionar aqueles recursos que são necessários apenas nos testes.
E aconteceu que, nos testes, parece que você deseja testar as alterações que eventualmente irão para produção. Mas, na verdade, uma coisa foi testada e uma coisa diferente foi usada na produção. E houve uma pequena quebra no padrão de que na produção todas as alterações eram aplicadas pela equipe de operação. E às vezes acontecia que aquelas mudanças que deveriam passar dos testes para a produção permaneciam em outra versão.
Além disso, o problema foi tão grande que foi adicionado um novo serviço, ligeiramente diferente de algum já existente. E em vez de modificar um módulo existente, era necessário fazer uma cópia dele e adicionar as alterações necessárias.
Na verdade, o Terraform não é uma linguagem real. Esta é uma declaração. Se precisarmos declarar algo, então declaramos. E tudo funciona.
A certa altura, ao discutir um dos meus pull requests, um dos meus colegas disse que não é necessário produzir flocos de neve. Eu me perguntei o que ele quis dizer. É um fato científico que não existem dois flocos de neve idênticos no mundo, são todos pequenos, mas diferentes. E assim que ouvi isso, imediatamente senti todo o peso do código Terraform. Porque quando era necessário passar de uma versão para outra, o Terraform exigia uma mudança significativa na cadeia, ou seja, o código não era mais compatível com a próxima versão. E tive que fazer uma solicitação pull, que cobria quase metade dos arquivos da infraestrutura, para trazer a infraestrutura para a próxima versão do Terraform.
E depois que esse floco de neve apareceu, todo o código Terraform que havíamos transformado em uma grande pilha de neve.
Para um desenvolvedor externo que está fora da operação isso não importa muito para ele, pois ele fez um pull request, seu recurso foi iniciado. E isso é tudo, não é mais da conta dele. E a equipe DevOps, que garante que tudo está bem, é obrigada a fazer todas essas alterações. E o custo dessas mudanças aumentou muito com cada floco de neve adicional.
Há uma história sobre como um aluno em um seminário desenha dois círculos perfeitos com giz em um quadro negro. E o professor fica surpreso como ele conseguiu desenhar tão bem sem compasso. O aluno responde: “Muito simples, passei dois anos no exército girando um moedor de carne”.
E dos quatro anos que estou neste projeto, venho fazendo o Terraform há cerca de dois anos. E, claro, tenho alguns truques, algumas dicas de como simplificar o código do Terraform, trabalhar com ele como uma linguagem de programação e reduzir a carga dos desenvolvedores que devem manter esse código atualizado.
A primeira coisa que gostaria de começar são os links simbólicos. Terraform tem muito código repetitivo. Por exemplo, ligar para um provedor em quase todos os pontos onde criamos uma infraestrutura é a mesma coisa. E é lógico colocá-lo em um pai separado. E onde quer que o provedor seja obrigado a criar links simbólicos para este arquivo.
Por exemplo, você usa assumir função na produção, o que permite obter direitos de acesso a alguma conta externa da Amazon. E ao alterar um arquivo, todos os demais que estão na árvore de recursos terão os direitos necessários para que o Terraform saiba qual segmento Amazon acessar.
Onde os links simbólicos não funcionam? Como eu disse, o Terraform possui arquivos de estado. E eles são muito, muito legais. Mas o fato é que o Terraform inicializa o backend logo no primeiro. E ele não pode utilizar nenhuma variável nesses parâmetros, eles sempre precisam estar escritos em texto.
E como resultado, quando alguém cria um novo recurso, ele copia parte do código de outras pastas. E ele pode errar com a chave ou com o balde. Por exemplo, ele faz uma sandbox a partir de uma sandbox e depois a produz em produção. E assim pode acontecer que o balde em produção seja usado na caixa de areia. Claro, eles encontrarão isso rapidamente. Será possível consertar isso de alguma forma, mas mesmo assim é uma perda de tempo e, até certo ponto, de recursos.
O que podemos fazer a seguir? Antes de trabalhar com o Terraform, você precisa inicializá-lo. Na inicialização, o Terraform baixa todos os plugins. Em algum momento, eles passaram de uma arquitetura monolítica para uma arquitetura mais de microsserviços. E você sempre precisa fazer o init do Terraform para que ele abra todos os módulos, todos os plugins.
E você pode usar um shell script, que, em primeiro lugar, pode obter todas as variáveis. O script Shell é ilimitado. E, em segundo lugar, o caminho. Se sempre usarmos o caminho que está no repositório como chave para o arquivo de estado, então, portanto, o erro será excluído aqui.
Onde obter dados? Arquivo JSON. O Terraform permite escrever infraestrutura não apenas em hcl (HashiCorp Configuration Language), mas também em JSON.
JSON é fácil de ler em um script de shell. Assim, você pode colocar um arquivo de configuração com um bucket em algum lugar. E use esse bucket no código do Terraform e no script de shell para inicialização.
Por que é importante ter um bucket Terraform? Porque existem arquivos de estado remoto. Ou seja, quando eu levanto algum recurso, para dizer à Amazon: “Por favor, levante a instância”, preciso especificar vários parâmetros obrigatórios.
E esses identificadores são armazenados em alguma outra pasta. E posso pegá-lo e dizer: "Terraform, por favor, execute o arquivo de estado desse mesmo recurso e obtenha esses identificadores". E assim há uma espécie de unificação entre diferentes regiões ou ambientes.
Nem sempre é possível usar um arquivo de estado remoto. Por exemplo, você criou manualmente uma VPC. E o código Terraform que cria o VPC cria um VPC tão diferente que leva muito tempo e você tem que ajustar um ao outro, então você pode usar o seguinte truque.
Ou seja, fazer um módulo que, por assim dizer, faça VPC e forneça identificadores, mas na verdade existe apenas um arquivo com valores codificados que pode ser usado para criar a mesma instância.
Nem sempre é necessário salvar o arquivo de estado na nuvem. Por exemplo, ao testar módulos, você pode usar a inicialização backend, quando o arquivo será salvo apenas no disco no momento do teste.
Agora um pouco sobre testes. O que pode ser testado no Terraform? Provavelmente muito é possível, mas falarei sobre essas 4 coisas.
A HashiCorp sabe como formatar o código Terraform. E o Terraform fmt permite formatar o código editado de acordo com essa crença. Dessa forma, os testes devem necessariamente verificar se a formatação corresponde ao que a HashiCorp legou, para que não seja necessário alterar a localização dos colchetes, etc.
O próximo é a validação do Terraform. Ele faz um pouco mais do que uma verificação de sintaxe - todos os colchetes estão emparelhados. O que é importante aqui? Temos uma infraestrutura muito tênue. Tem muitas pastas diferentes. E em cada um você precisa executar a validação do Terraform.
Assim, para agilizar os testes, executamos vários processos em paralelo usando paralelo.
Paralelo é uma coisa muito legal, use.
Mas toda vez que o Terraform é inicializado, ele vai até a HashiCorp e pergunta: “Quais são os plug-ins mais recentes? E o plugin que tenho no cache - é esse ou não? E diminuiu a velocidade a cada passo.
Se o Terraform lhe disser onde estão os plug-ins, o Terraform dirá: “OK, esta é provavelmente a coisa mais recente que existe. Não irei a lugar nenhum, começarei a validar seu código Terraform imediatamente."
Para preencher a pasta com os plugins necessários, temos um código Terraform muito simples que só precisa ser inicializado. Aqui, claro, você precisa especificar todos os provedores que de alguma forma participam do seu código, caso contrário o Terraform dirá: “Não conheço nenhum provedor, porque não está no cache”.
O próximo é o plano Terraform. Como eu disse, o desenvolvimento é cíclico. Fazemos código com alterações. E então você precisa descobrir quais mudanças estão planejadas para a infraestrutura.
E quando a infraestrutura é muito, muito grande, você pode alterar um módulo, consertar algum ambiente de teste ou alguma região específica e quebrar algum vizinho. Portanto, deve ser feito um plano Terraform para toda a infraestrutura e mostrar quais mudanças estão previstas.
Você pode fazer isso de maneira inteligente. Por exemplo, escrevemos um script Python que resolve dependências. E dependendo do que foi alterado: um módulo Terraform ou apenas um componente específico, ele faz planos para todas as pastas dependentes.
O plano Terraform deve ser feito mediante solicitação. Pelo menos é isso que fazemos.
Os testes, é claro, são bons para cada mudança, para cada commit, mas os planos são algo bastante caro. E em uma solicitação pull dizemos: “Por favor, me dê os planos”. O robô é iniciado. E envia para comentários ou para anexar todos os planos que se espera de suas alterações.
O plano é algo bastante caro. Leva tempo porque o Terraform vai até a Amazon e pergunta: “Essa instância ainda existe? Essa autoescala tem exatamente os mesmos parâmetros?”. E para agilizar, você pode usar um parâmetro como refresh=false. Isso significa que o Terraform esvaziará o estado S3. E acreditará que o estado corresponderá exatamente ao que existe na Amazônia.
Esse plano do Terraform é muito mais rápido, mas o estado deve corresponder à sua infraestrutura, ou seja, em algum lugar, em algum momento, a atualização do Terraform deve começar. A atualização do Terraform faz exatamente isso, para que o estado corresponda ao que está na infraestrutura real.
E devo dizer sobre segurança. É aqui que deveria ter começado. Onde você executa o Terraform e o Terraform funciona com sua infraestrutura, há uma vulnerabilidade. Ou seja, você está essencialmente executando código. E se a solicitação pull contiver algum tipo de código malicioso, ela poderá ser executada em uma infraestrutura com muito acesso. Portanto, tenha cuidado ao iniciar o plano Terraform.
A próxima coisa sobre a qual gostaria de falar é o teste de dados do usuário.
O que são dados do usuário? Na Amazon, quando criamos uma instância, podemos enviar algum tipo de carta da instância - metadados. Quando uma instância é iniciada, geralmente o cloud init está sempre presente nessas instâncias. O Cloud init lê esta carta e diz: "OK, hoje sou um balanceador de carga." E de acordo com esses preceitos, ele realiza algumas ações.
Mas, infelizmente, quando fazemos o plano do Terraform e o aplicamos, os dados do usuário se parecem com uma mistura de números. Ou seja, ele apenas lhe envia um hash. E tudo o que você pode ver no plano é se haverá alguma alteração ou se o hash permanecerá o mesmo.
E se você não prestar atenção nisso, algum arquivo de texto batido pode ir para a Amazon, para a infraestrutura real.
Alternativamente, você pode especificar não toda a infraestrutura durante a execução, mas apenas o modelo. E no código, diga: "Por favor, mostre este modelo para mim." E, como resultado, você pode obter uma impressão da aparência dos seus dados na Amazon.
Outra opção é usar um módulo para gerar dados do usuário. Você aplicará este módulo. Obtenha o arquivo no disco. Compare-o com a referência. E assim, se algum junho decidir corrigir alguns dados do usuário, seus testes dirão: “OK, há algumas mudanças aqui e ali - isso é normal”.
A próxima coisa que gostaria de falar é a aplicação do Automate Terraform.
Claro, é assustador o suficiente aplicar o Terraform em modo automático, porque quem sabe quais mudanças ocorreram e quão prejudiciais elas podem ser para uma infraestrutura viva.
Para um ambiente de teste, tudo bem. Ou seja, um trabalho que crie um ambiente de teste é o que todos os desenvolvedores precisam. E uma expressão como “tudo funcionou para mim” não é um meme engraçado, mas uma prova de que uma pessoa se confundiu, levantou uma pilha, lançou alguns testes nessa pilha. E ele se certificou de que estava tudo bem ali e disse: “OK, o código que eu lanço foi testado”.
Na produção, sandbox e outros ambientes que são mais críticos para os negócios, você pode usar parcialmente alguns recursos com bastante segurança, pois isso não resulta na morte de ninguém. São eles: grupos de escalonamento automático, grupos de segurança, funções, rota53 e a lista pode ser bem grande. Mas fique de olho no que está acontecendo, leia os relatórios da aplicação automatizada.
Onde for perigoso ou assustador usar, por exemplo, se forem alguns recursos persistentes, de um banco de dados, obtenha relatórios de que há alterações não aplicadas em alguma parte da infraestrutura. E o engenheiro já está supervisionado executando trabalhos para aplicar ou fazendo isso em seu console.
A Amazon tem algo como proteção contra rescisão. E pode proteger, em alguns casos, contra alterações que não são necessárias para você. Então o Terraform foi até a Amazon e disse “Preciso matar esta instância para fazer outra”. E a Amazon diz: “Desculpe, hoje não. Temos proteção contra rescisão.
E a cereja do bolo é a otimização do código. Quando trabalhamos com código Terraform, devemos passar um número muito grande de parâmetros para o módulo. Esses são os parâmetros necessários para criar algum tipo de recurso. E o código se transforma em grandes listas de parâmetros que precisam ser passados de módulo para módulo, de módulo para módulo, principalmente se os módulos estiverem aninhados.
E é muito difícil de ler. É muito difícil revisar isso. E muitas vezes acontece que alguns parâmetros estão sendo revisados e não são exatamente os necessários. E custa tempo e dinheiro consertar isso mais tarde.
Portanto, sugiro que você use um parâmetro complexo que inclua uma determinada árvore de valores. Ou seja, você precisa de algum tipo de pasta onde você tenha todos os valores que gostaria de ter em algum tipo de ambiente.
E chamando este módulo, você consegue uma árvore que é gerada em um módulo comum, ou seja, em um módulo comum que funciona da mesma forma para toda a infraestrutura.
Neste módulo, você pode fazer alguns cálculos usando um recurso novo no Terraform como locais. E então, em uma saída, emita algum tipo de parâmetro complexo, que pode incluir hashes, arrays, etc.
Isso conclui todas as melhores descobertas que terminei. E eu gostaria de contar uma história sobre Colombo. Quando procurava dinheiro para a sua expedição à descoberta da Índia (como pensava então), ninguém acreditou nele e acreditou que era impossível. Aí ele disse: “Cuidado para que o ovo não caia”. Todos os banqueiros, pessoas muito ricas e provavelmente inteligentes, tentaram colocar o ovo de alguma forma, e ele caiu o tempo todo. Aí Colombo pegou o ovo, apertou um pouco. A casca amassou-se e o ovo permaneceu imóvel. Eles disseram: “Oh, isso é muito fácil!” E Colombo respondeu: “Sim, é muito simples. E quando eu abrir a Índia, todos usarão esta rota comercial.”
E o que acabei de dizer são provavelmente coisas bastante simples e triviais. E quando você descobre sobre eles e começa a usá-los, está na ordem das coisas. Então use-o. E se essas coisas são normais para você, pelo menos você sabe colocar um ovo para que ele não caia.
Vamos resumir:
- Tente evitar flocos de neve. E quanto menos flocos de neve, menos recursos você precisará para fazer alterações em toda a sua grande infraestrutura.
- Mudança constante. Ou seja, quando ocorrerem algumas alterações no código, você precisará alinhar sua infraestrutura com essas alterações o mais rápido possível. Não deveria haver uma situação em que alguém chegasse em dois ou três meses para dar uma olhada no Elasticsearch, fizesse um plano do Terraform e houvesse muitas mudanças que ele não esperava. E leva muito tempo para colocar tudo em ordem.
- Testes e automação. Quanto mais seu código for coberto com testes e chips, mais confiança você terá de que está fazendo tudo certo. E a entrega automática aumentará muitas vezes sua confiança.
- O código dos ambientes de teste e produção deve ser quase o mesmo. Praticamente, porque afinal a produção é um pouco diferente e ainda haverá algumas nuances que vão além do ambiente de testes. Mesmo assim, mais ou menos pode ser fornecido.
- E se você tem muito código Terraform e leva muito tempo para mantê-lo atualizado, nunca é tarde para refatorá-lo e colocá-lo em boa forma.
- infraestrutura imutável. Entrega AMI dentro do prazo.
- Estrutura para route53 quando você tem muitas entradas e deseja que elas estejam em uma ordem consistente.
- Lute contra os limites de taxa de API. É quando a Amazon diz: “É isso, não posso aceitar mais solicitações, aguarde”. E metade do escritório está esperando até poder lançar sua infraestrutura.
- instâncias pontuais. A Amazon não é um evento barato e as vagas permitem que você economize bastante. E aí você pode contar um relatório completo sobre isso.
- Funções de segurança e IAM.
- Procure recursos perdidos, quando você tem instâncias de origem desconhecida na Amazone, elas comem dinheiro. Mesmo que as instâncias custem entre US$ 100 e US$ 150 por mês, são mais de US$ 1 por ano. Encontrar esses recursos é um negócio lucrativo.
- E instâncias reservadas.
Isso é tudo para mim. Terraform é muito legal, use-o. Obrigado!
perguntas
Obrigado pelo relatório! Você tem um arquivo de estado no S3, mas como resolver o problema de várias pessoas poderem pegar esse arquivo de estado e tentar implantar?
Primeiro, não temos pressa. Em segundo lugar, existem sinalizadores, nos quais informamos que estamos trabalhando em algum trecho de código. Ou seja, apesar da infraestrutura ser muito grande, isso não significa que alguém esteja usando algo constantemente. E quando havia uma fase ativa, isso era um problema, mantivemos os arquivos de estado no Git. Isso era importante, caso contrário alguém criaria um arquivo de estado e teríamos que coletá-los manualmente para continuar. Agora não existe esse problema. Em geral, o Terraform resolveu esse problema. E se algo muda constantemente, você pode usar bloqueios que impedem o que você disse.
Você está usando código aberto ou corporativo?
Nenhuma empresa, ou seja, tudo o que você pode baixar gratuitamente.
Meu nome é Stanislav. Eu queria fazer uma pequena adição. Você falou sobre o recurso da Amazon que permite tornar uma instância impossível de matar. Isso também está no próprio Terraform, no bloco Life Second, você pode prescrever uma proibição de mudança ou uma proibição de destruição.
Foi limitado no tempo. Bom ponto.
Eu também queria perguntar duas coisas. Primeiro, você falou sobre testes. Você usou alguma ferramenta de teste? Ouvi falar do plugin Test Kitchen. Talvez haja algo mais. E eu gostaria de perguntar sobre Valores Locais. Como elas diferem basicamente das variáveis de entrada? E por que não consigo parametrizar algo apenas através de Valores Locais? Tentei lidar com esse assunto, mas de alguma forma não consegui descobrir sozinho.
Podemos conversar com mais detalhes fora desta sala. Nossas ferramentas de teste são totalmente feitas por você mesmo. Não há nada lá para testar. Em geral, existem opções quando os testes automatizados pegam a infraestrutura em algum lugar, verificam se está tudo bem e depois destroem tudo com um relatório de que sua infraestrutura ainda está em boas condições. Não temos isso porque as pilhas de teste são executadas todos os dias. E isso é o suficiente. E se algo começar a quebrar, começará a quebrar sem que verifiquemos em outro lugar.
Em relação aos Valores Locais, vamos continuar a conversa fora do público.
Olá! Obrigado pelo relatório! Muito informativo. Você disse que tem muito do mesmo tipo de código para descrever a infraestrutura. Você já pensou em gerar esse código?
Ótima pergunta, obrigado! A questão é que quando usamos infraestrutura como código, presumimos que olhamos para o código e entendemos que tipo de infraestrutura está por trás desse código. Se o código for gerado, precisamos imaginar qual código será gerado para entender que tipo de infraestrutura estará lá. Ou geramos o código, fazemos commit e, de fato, obtemos a mesma coisa. Portanto, seguimos como escrevemos, conseguimos. Além disso, os geradores apareceram um pouco mais tarde, quando começamos a fabricar. E era tarde demais para mudar.
Você já ouviu falar em jsonnet?
Нет.
Olha, isso é uma coisa muito legal. Vejo um caso específico onde você pode aplicar e gerar uma estrutura de dados.
Geradores são bons quando você os tem, como na piada sobre a máquina de barbear. Ou seja, na primeira vez o rosto é diferente, mas depois todos ficam com o mesmo rosto. Os geradores são muito legais. Mas, infelizmente, nossos rostos são um pouco diferentes. Isso é um problema.
Apenas olhe. Obrigado!
Meu nome é Maxim, sou do Sberbank. Você disse um pouco que tentou trazer o Terraform para um análogo de uma linguagem de programação. Não é mais fácil usar o Ansible?
São coisas muito diferentes. Ansible pode criar recursos e Puppet pode criar recursos na Amazon. Mas o Terraform é totalmente aprimorado.
Você só tem Amazon?
Não é que tenhamos apenas a Amazon. Quase só temos Amazon. Mas a principal característica é que o Terraform lembra. No Ansible, se você disser: “Pegue-me 5 instâncias”, então ele aumentará, e então você diz: “E agora preciso de 3”. E o Terraform dirá: “Ok, vou matar 2”, e o Ansible dirá: “Ok, aqui estão 3 para você”. Total 8.
Olá! Obrigado pelo seu relatório! Foi muito interessante ouvir sobre o Terraform. Quero apenas fazer um pequeno comentário sobre o fato do Terraform ainda não possuir uma versão estável, então tome muito cuidado com o Terraform.
Bela colher para o jantar. Ou seja, se você precisa de uma solução, às vezes você adia o que está instável, etc., mas funciona e nos ajudou.
A questão é esta. Você usa backend remoto, usa S 3. Por que não usa o backend oficial?
Oficial?
Nuvem Terraform.
Quando ele apareceu?
Cerca de 4 meses atrás.
Se tivesse aparecido há 4 anos, provavelmente eu teria respondido à sua pergunta.
Já existe uma função e bloqueios integrados, e você pode armazenar um arquivo de estado. De uma chance. Mas também não testei.
Estamos em um grande trem que se move em alta velocidade. E você não pode simplesmente pegar e jogar fora alguns carros.
Você estava falando sobre flocos de neve, por que não usou galho? Por que não funcionou assim?
Nossa abordagem é que toda a infraestrutura esteja em um repositório. Terraform, Puppet, todos os scripts que estão de alguma forma relacionados a isso, estão todos em um repositório. Dessa forma, podemos garantir que as alterações incrementais sejam testadas uma após a outra. Se fosse um monte de filiais, seria quase impossível manter tal projeto. Seis meses se passam e eles divergem tanto que é apenas uma espécie de punição. Era disso que eu queria escapar antes de refatorar.
ou seja, não funciona?
Isso não funciona de jeito nenhum.
No galho recortei o slide da pasta. Ou seja, se você fizer isso para cada pilha de teste, por exemplo, o time A tem sua própria pasta, o time B tem sua própria pasta, então isso também não funciona. Criamos um código de ambiente de teste unificado que era flexível o suficiente para atender a todos. Ou seja, servimos um código.
Olá! Meu nome é Yura! Obrigado pelo relatório! Dúvida sobre módulos. Você diz que está usando módulos. Como você resolve o problema se foram feitas alterações em um módulo que não são compatíveis com a alteração de outra pessoa? De alguma forma, versionando módulos ou tentando trazer um prodígio para atender a dois requisitos?
Este é um grande problema de pilha de neve. É disto que sofremos quando alguma mudança inócua pode quebrar alguma parte da infra-estrutura. E isso só será perceptível depois de algum tempo.
Ou seja, ainda não foi decidido?
Você faz módulos universais. Evite flocos de neve. E tudo vai dar certo. A segunda metade do relatório é sobre como evitá-lo.
Olá! Obrigado pelo relatório! Eu gostaria de esclarecer. Nos bastidores havia uma grande pilha, pela qual vim. Como a distribuição de fantoches e funções é integrada?
dados do usuário.
Ou seja, você simplesmente cospe o arquivo e de alguma forma o executa?
Os dados do usuário são uma nota, ou seja, quando fazemos um clone de imagem, então o Daemon sobe lá e tentando descobrir quem ele é, lê uma nota de que ele é um balanceador de carga.
Ou seja, é algum tipo de processo separado que é doado?
Nós não inventamos isso. Nós usamos isso.
Olá! Só tenho uma pergunta sobre dados do usuário. Você disse que há problemas aí, que alguém pode mandar algo para o lugar errado. Existe alguma maneira de armazenar dados do usuário no mesmo Git, para que fique sempre claro a que se referem os dados do usuário?
Geramos dados do usuário a partir do modelo. Ou seja, um certo número de variáveis recorrem ali. E o Terraform gera o resultado final. Portanto, você não pode simplesmente olhar o template e dizer o que acontece, pois todos os problemas estão relacionados ao fato do desenvolvedor pensar que está passando uma string nesta variável, e então um array é usado. E ele - bang e eu - fulano de tal, fulano de tal, a próxima linha, e tudo quebrou. Se for um recurso novo e uma pessoa levanta, vê que algo não está funcionando, então isso se resolve rapidamente. E se este grupo de autoescala tiver sido atualizado, em algum momento as instâncias do grupo de autoescala começarão a ser substituídas. E bata palmas, algo não está funcionando. Isso dói.
Acontece que a única solução é testar?
Sim, você vê o problema, adiciona etapas de teste lá. Ou seja, a saída também pode ser testada. Talvez não seja tão conveniente, mas você também pode colocar algumas marcas - verifique se os dados do usuário estão pregados aqui.
Meu nome é Timur. É muito legal que existam relatos sobre como organizar corretamente o Terraform.
Eu nem comecei.
Acho que na próxima conferência talvez haja. Eu tenho uma pergunta simples. Por que você está codificando o valor em um módulo separado em vez de usar tfvars, ou seja, um módulo com valores é melhor que tfvars ?
Ou seja, devo escrever aqui (slide: Production/environment/settings.tf): domínio = variável, domínio vpcnetwork, variável vpcnetwork e stvars - obtêm a mesma coisa?
Nós fazemos exatamente isso. Referimo-nos à configuração do módulo fonte, por exemplo.
Na verdade, este é um grande tfvars. Tfvars é muito útil em um ambiente de teste. Tenho tfvars para instâncias grandes, para instâncias pequenas. E joguei um arquivo na pasta. E consegui o que queria. Quando vimos infraestrutura, queremos poder ver e compreender tudo imediatamente. E acontece que você precisa olhar aqui e depois olhar em tfvars.
Acontece que tudo estava em um só lugar?
Sim, tfvars é quando você tem um código. E é usado em diversos locais com nuances diferentes. Então você lançaria tfvars e obteria suas nuances. E somos infraestrutura como código na sua forma mais pura. Olhei e entendi.
Olá! Você já se deparou com situações em que o provedor de nuvem interfere no que você fez com o Terraform? Digamos que editamos os metadados. Existem chaves ssh. E o Google constantemente transfere seus metadados e suas chaves para lá. E o Terraform sempre escreve que tem mudanças. Após cada execução, mesmo que nada mude, ele sempre diz que irá atualizar este campo agora.
Com chaves, mas - sim, parte da infraestrutura é afetada por tal coisa, ou seja, o Terraform não pode mudar nada. Também não podemos mudar nada com as mãos. Enquanto vivermos com isso.
Ou seja, você se deparou com isso, mas não descobriu nada, como ele faz e faz sozinho?
Infelizmente sim.
Olá! Meu nome é Stanislav Starkov. Correspondência. en Grupo. Como você resolve o problema de gerar uma tag em ..., como você passa ela para dentro? Pelo que entendi, através dos dados do usuário, para especificar o nome do host, incite o Puppet? E a segunda parte da pergunta. Como você resolve esse problema no SG, ou seja, quando você gera SG, cem instâncias do mesmo tipo, como nomeá-las corretamente?
Aqueles casos que são muito importantes para nós, nós os nomearemos lindamente. Aqueles que não são necessários, há um postscript de que este é um grupo de autoescala. E, em teoria, pode ser pregado e conseguir um novo.
Quanto ao problema com a tag, esse problema não existe, mas existe essa tarefa. E usamos tags muito, muito, porque a infraestrutura é grande e cara. E precisamos ver em que dinheiro é gasto, para que as tags nos permitam identificar o que e para onde foi gasto. E, consequentemente, procurar algo aqui é muito dinheiro gasto.
Sobre o que mais era a pergunta?
Quando o SG cria cem instâncias, elas precisam ser distinguidas de alguma forma?
Não, não. Cada instância tem um agente que me informa que tenho um problema. Se o agente reportar, então o agente sabe sobre ele e, pelo menos, seu endereço IP existe. Você já pode correr. Em segundo lugar, usamos o Consul for Discovery, onde não há Kubernetes. E o Consul também mostra o endereço IP da instância.
Ou seja, você está visando exatamente o IP e não o nome do host?
É impossível navegar pelo nome do host, ou seja, existem muitos deles. Existem identificadores de instância - AE, etc. Você pode encontrá-lo em algum lugar, pode jogá-lo na pesquisa.
Olá! Percebi que o Terraform é uma coisa boa, feito sob medida para as nuvens.
Não só isso.
Esta é a questão que me interessa. Se você decidir migrar, digamos, para o Bare Metal em massa com todas as suas instâncias? Haverá algum problema? Ou ainda precisa usar outros produtos, por exemplo, o mesmo Ansible que foi citado aqui?
Ansible é um pouco sobre outra coisa. Ou seja, o Ansible já funciona quando a instância é iniciada. E o Terraform funciona antes do início da instância. Mudar para Bare Metal não é.
Agora não, mas os negócios virão e dirão: "Vamos".
Mudar para outra nuvem - sim, mas há um recurso um pouco diferente aqui. Você precisa escrever o código Terraform de forma que possa mudar para alguma outra nuvem com menos derramamento de sangue.
Inicialmente, a tarefa era que toda a nossa infraestrutura fosse agnóstica, ou seja, qualquer nuvem deveria servir, mas em algum momento o negócio desistiu e disse: “OK, nos próximos N anos não iremos a lugar nenhum, você pode usar os serviços de Amazônia".
O Terraform permite criar trabalhos Front-End, configurar PagerDuty, documentos de dados, etc. Ele pode praticamente controlar o mundo inteiro.
Obrigado pelo relatório! Também tenho girado o Terraform há 4 anos. Na fase de transição suave para o Terraform, para a infraestrutura, para uma descrição declarativa, nos deparamos com uma situação em que alguém fazia algo manualmente e você tentava fazer um plano. E eu recebi algum erro aí. Como você lida com esses problemas? Como você encontra os recursos perdidos que foram indicados?
Principalmente com as mãos e os olhos, se vemos algo estranho no relatório, então analisamos o que está acontecendo ali, ou simplesmente matamos. Em geral, solicitações pull são comuns.
Se houver um erro, você reverte? Você já tentou fazer isso?
Não, esta é uma decisão da pessoa no momento em que ela vê um problema.
Fonte: habr.com