Why we use Terraform and not Chef, Puppet, Ansible, SaltStack, or CloudFormation

Update, November 17, 2016: We took this blog post series, expanded it, and turned it into a book called Terraform: Up & Running!

Update, July 8, 2019: we’ve updated this blog post series for Terraform 0.12 and released the 2nd edition of Terraform: Up & Running!esta é a parte 1 do guia abrangente da série Terraform. Na introdução da série, discutimos por que todas as empresas devem usar o código infra-estrutura (IAC). Neste post, vamos discutir porque escolhemos Terraform como nossa ferramenta de escolha da IAC.

Se você pesquisar na Internet por “infra-estrutura-como-código”, é muito fácil vir acima com uma lista das ferramentas mais populares:

• Chefe
• Fantoche
• Ansible
• SaltStack
• CloudFormation
• Transformar

o Que não é fácil é descobrir qual desses você deve usar. Todas estas ferramentas podem ser usadas para gerenciar a infraestrutura como código. Todos eles são de código aberto, apoiados por grandes comunidades de colaboradores, e trabalham com muitos provedores de nuvem diferentes (com a notável exceção da CloudFormation, que é de código fechado e somente AWS). Todos eles oferecem apoio empresarial. Todos eles estão bem documentados, tanto em termos de documentação oficial e recursos comunitários, como posts em blogs e perguntas StackOverflow. Então, como é que decides?

O que torna isto ainda mais difícil é que a maioria das comparações que você encontra online entre estas ferramentas fazem pouco mais do que listar as propriedades gerais de cada ferramenta e fazer com que pareça que você poderia ser igualmente bem sucedido com qualquer uma delas. E embora isso seja tecnicamente verdade, não ajuda. É um pouco como dizer a um novato de programação que você poderia ser igualmente bem sucedido na construção de um site com PHP, C, ou montagem — uma declaração que é tecnicamente verdade, mas que omite uma enorme quantidade de informação que seria incrivelmente útil para tomar uma boa decisão.

neste post, vamos mergulhar em algumas razões muito específicas por que escolhemos Terraform sobre as outras ferramentas da IAC. Tal como acontece com todas as decisões tecnológicas, é uma questão de compromissos e prioridades, e embora as suas prioridades específicas possam ser diferentes das nossas, esperamos que partilhar o nosso processo de pensamento o ajude a tomar a sua própria decisão. Aqui estão os principais compromissos que consideramos:

• Gerenciamento de Configuração vs Provisionamento
• Mutável Infra-estrutura vs Imutável Infra-estrutura
• Processual vs Declarativa
• Mestre vs Masterless
• Agente vs sem Agente
• Grande Comunidade vs Pequena Comunidade
• Maduro vs Aresta de Corte
• Usar Várias Ferramentas

o Chef, Fantoches, Ansible, e SaltStack são todas as ferramentas de gerenciamento de configuração, o que significa que eles são projetados para instalar e gerenciar o software em servidores existentes. CloudFormation e Transformar são ferramentas de provisionamento, o que significa que eles são projetados para fornecer os próprios servidores (bem como o resto de sua infra-estrutura, como balanceadores de carga, bancos de dados, configuração de rede, etc), deixando o trabalho de configurar os servidores para outras ferramentas. Essas duas categorias não são mutuamente exclusivas, como a maioria das ferramentas de gerenciamento de configuração pode fazer algum grau de aprovisionamento e mais ferramentas de provisionamento pode fazer algum grau de gerenciamento de configuração. Mas o foco na gestão de configuração ou provisionamento significa que algumas das ferramentas serão mais adequadas para certos tipos de Tarefas.

em particular, descobrimos que se você usar o Docker ou Packer, A grande maioria de suas necessidades de gerenciamento de configuração já estão sendo atendidas. Com o Docker e o Packer, você pode criar imagens (como contêineres ou imagens de máquinas virtuais) que tenham todo o software que o seu servidor precisa já instalado e configurado. Uma vez que você tem tal imagem, tudo que você precisa é um servidor para executá-la. E se tudo o que você precisa fazer é fornecer um monte de servidores, então uma ferramenta de provisionamento como Terraform normalmente vai ser um ajuste melhor do que uma ferramenta de gerenciamento de configuração (aqui está um exemplo de como usar Terraform para implantar o Docker no AWS).

infra-estrutura mutável vs infra-estrutura imutável

ferramentas de gestão de configuração, tais como Chef, Puppet, Ansible, e SaltStack normalmente padrão para um paradigma de infra-estrutura mutável. Por exemplo, se você disser ao Chef para instalar uma nova versão do OpenSSL, ele executará a atualização do software em seus servidores existentes e as mudanças acontecerão no local. Ao longo do tempo, à medida que você aplica mais e mais atualizações, cada servidor constrói um histórico único de mudanças. Isso muitas vezes leva a um fenômeno conhecido como deriva de configuração, onde cada servidor se torna ligeiramente diferente de todos os outros, levando a bugs de configuração sutis que são difíceis de diagnosticar e quase impossíveis de reproduzir.

Se você está usando uma ferramenta de provisionamento como Terraform para implantar imagens de máquinas criadas por Docker ou Packer, então cada “mudança” é na verdade uma implantação de um novo servidor (assim como cada “mudança” para uma variável em programação funcional realmente retorna uma nova variável). Por exemplo, para implantar uma nova versão do OpenSSL, você criaria uma nova imagem usando o Packer ou o Docker com a nova versão do OpenSSL já instalada, implantaria essa imagem através de um conjunto de servidores totalmente novos, e então uniploy os servidores antigos. Esta abordagem reduz a probabilidade de erros de deriva de configuração, torna mais fácil saber exatamente o que o software está executando em um servidor, e permite que você implemente trivialmente qualquer versão anterior do software a qualquer momento. É claro que é possível forçar as ferramentas de gerenciamento de configuração a fazer implementos imutáveis também, mas não é a abordagem idiomática para essas ferramentas, ao passo que é uma maneira natural de usar ferramentas de provisionamento.

Procedural vs Declarative

Chef and an possible incentive a procedural style where you write code that specifies, step-by-step, how to achieve some Wished end state. Terraform, CloudFormation, SaltStack e Puppet todos encorajam um estilo mais declarativo onde você escreve código que especifica o seu estado final desejado, e a ferramenta IAC em si é responsável por descobrir como alcançar esse estado.

Por exemplo, digamos que você queria implantar 10 servidores (“instâncias EC2” no lingo AWS) para executar v1 de um aplicativo. Aqui está um exemplo simplificado de um Ansible modelo que faz isso com uma abordagem procedural:

- ec2:
count: 10
image: ami-v1 
instance_type: t2.micro

E aqui está um exemplo simplificado de um Terraform modelo que faz a mesma coisa usando uma abordagem declarativa:

resource "aws_instance" "example" {
count = 10
ami = "ami-v1"
instance_type = "t2.micro"
}

Agora na superfície, essas duas abordagens podem ser semelhantes, e quando você começa a executá-los com Ansible ou Transformar, eles vão produzir resultados semelhantes. O interessante é o que acontece quando se quer fazer uma mudança.

por exemplo, imagine que o tráfego subiu e você quer aumentar o número de servidores para 15. Com o An possible, o código processual que você escreveu anteriormente não é mais útil; se você apenas atualizou o número de servidores para 15 e reanalisar esse código, ele iria implantar 15 novos servidores, dando-lhe um total de 25! Então, em vez disso, você tem que estar ciente do que já está implantado e escrever um script processual totalmente novo para adicionar os 5 novos servidores:

- ec2:
count: 5
image: ami-v1 
instance_type: t2.micro

com código declarativo, uma vez que tudo o que você faz é declarar o estado final que deseja, e Terraform descobre como chegar a esse estado final, Terraform também estará ciente de qualquer estado que criou no passado. Portanto, para implantar mais 5 (cinco) servidores, tudo que você tem a fazer é voltar para o mesmo Terraform modelo e atualizar a contagem de 10 a 15 de:

resource "aws_instance" "example" {
count = 15
ami = "ami-v1"
instance_type = "t2.micro"
}

Se você executou este modelo, Transformar iria perceber que ele já tinha criado a 10 de servidores e, por conseguinte, de que tudo o que precisava fazer era criar 5 novos servidores. Na verdade, antes de executar este modelo, você pode usar o comando Terraform plan para visualizar as alterações que ele faria:

$ terraform plan+ aws_instance.example.11
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.12
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.13
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.14
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.15
ami: "ami-v1"
instance_type: "t2.micro"Plan: 5 to add, 0 to change, 0 to destroy.

Agora o que acontece quando você deseja implantar o serviço v2? Com a abordagem processual, ambos os seus modelos anteriores não são mais úteis, então você tem que escrever mais um modelo para rastrear os 10 servidores que você implantou anteriormente(ou era 15 agora?) e cuidadosamente atualizar cada um para a nova versão. Com a abordagem declarativa da Terraform, você volta ao mesmo modelo mais uma vez e simplesmente muda o número da versão ami para v2:

resource "aws_instance" "example" {
count = 15
ami = "ami-v2"
instance_type = "t2.micro"
}

obviamente, os exemplos acima são simplificados. Ansible permita o uso de tags para pesquisa existentes para instâncias do EC2 antes de implantar novos (e.g. utilizando o instance_tags e count_tag parâmetros), mas ter de manualmente descobrir esse tipo de lógica para cada recurso que você gerenciar com Ansible, com base em cada recurso é passado histórico, pode ser surpreendentemente complicado (por exemplo, encontrar instâncias existentes não só por tag, mas também versão de imagem, zona de disponibilidade, etc). Isto destaca dois grandes problemas com as ferramentas processuais IAC:

1. Quando se trata de código processual, o estado da infra-estrutura não é totalmente captado no código. Ler através dos três modelos possíveis que criamos acima não é suficiente para saber o que está implantado. Você também teria que saber a ordem pela qual aplicamos esses modelos. Se as tivéssemos aplicado em uma ordem diferente, poderíamos acabar com uma infraestrutura diferente, e isso não é algo que você possa ver na própria base de código. Em outras palavras, para raciocinar sobre uma base de codebase Anossível ou Chef, você tem que saber a história completa de cada mudança que já aconteceu.
2. a reutilização do código processual é inerentemente limitada porque você tem que levar manualmente em conta o estado atual da base de código. Uma vez que esse estado está constantemente mudando, o código que você usou há uma semana pode não ser mais utilizável porque foi projetado para modificar um estado de sua infra-estrutura que já não existe. Como resultado, as bases processuais do Código tendem a crescer grandes e complicadas ao longo do tempo.por outro lado, com o tipo de abordagem declarativa utilizada na Terraform, o código representa sempre o estado mais recente da sua infra-estrutura. Num piscar de olhos, você pode dizer o que está atualmente implantado e como ele está configurado, sem ter que se preocupar com a história ou tempo. Isso também facilita a criação de código reutilizável, já que você não tem que contabilizar manualmente o estado atual do mundo. Em vez disso, você apenas se concentra em descrever o seu estado desejado, e Terraform descobre como chegar de um estado para o outro automaticamente. Como resultado, as bases de codebases Terraform tendem a permanecer pequenas e fáceis de entender.

   é claro que também existem desvantagens nas línguas declarativas. Sem acesso a uma linguagem de programação completa, seu poder expressivo é limitado. Por exemplo, alguns tipos de alterações de infra-estruturas, como uma implantação móvel, zero-downtime, são difíceis de expressar em termos puramente declarativos. Da mesma forma, sem a capacidade de fazer “lógica” (por exemplo, if-statements, loops), a criação de código genérico e reutilizável Pode ser complicada (especialmente em CloudFormation). Felizmente, Transformar fornece um número de poderosos primitivos , tais como variáveis de entrada variáveis de saída, módulos, create_before_destroy e count, que tornam possível a criação de limpar, configuráveis, de código modular, mesmo em uma linguagem declarativa. Discutiremos estas ferramentas mais na Parte 4, Como criar infra-estrutura reutilizável com módulos Terraform e Parte 5, dicas Terraform & truques: loops, if-statements, and pitfalls.

   Master Versus Masterless

   por padrão, Chef, Puppet, e SaltStack todos requerem que você execute um servidor mestre para armazenar o estado de sua infra-estrutura e distribuir atualizações. Cada vez que você deseja atualizar algo em sua infra-estrutura, você pode usar um cliente (por exemplo, uma ferramenta de linha de comando para a emissão dos comandos para o servidor mestre, e o mestre, o servidor envia as atualizações para todos os outros servidores, ou os servidores de puxar as atualizações mais recentes para baixo a partir do servidor mestre em uma base regular.um servidor mestre oferece algumas vantagens. Primeiro, é um lugar único e central onde você pode ver e gerenciar o status de sua infra-estrutura. Muitas ferramentas de gerenciamento de configuração até fornecem uma interface web (por exemplo, o console Chef, O Console Puppet Enterprise) para o servidor mestre para tornar mais fácil ver o que está acontecendo. Em segundo lugar, alguns servidores mestres podem executar continuamente em segundo plano, e reforçar a sua configuração. Dessa forma, se alguém fizer uma alteração manual em um servidor, o servidor mestre pode reverter essa alteração para evitar a deriva de configuração.

   no entanto, ter que executar um servidor mestre tem algumas desvantagens graves:

   • infra-estrutura Extra: você tem que implantar um servidor extra, ou mesmo um conjunto de servidores extras (para alta disponibilidade e escalabilidade), apenas para executar o mestre.Manutenção: você tem que manter, atualizar, fazer backup, monitorar e escalar o(s) servidor (s) Mestre (s).
   • Segurança: Você tem que fornecer uma maneira para o cliente para se comunicar com o servidor mestre(s) e um caminho para o servidor mestre(s) para se comunicar com todos os outros servidores, o que normalmente significa a abertura de portas extras e configuração extra sistemas de autenticação, todos os que aumenta a sua área de superfície para os atacantes.

   Chef, Puppet, e SaltStack têm diferentes níveis de suporte para modos sem-mestre, onde você apenas executa o seu software de agente em cada um dos seus servidores, tipicamente em um cronograma periódico (por exemplo, uma tarefa cron que corre a cada 5 minutos), e usar isso para retirar as últimas atualizações do controle de versão (em vez de um servidor mestre). Isso reduz significativamente o número de peças móveis, mas, como discutido na próxima seção, isso ainda deixa uma série de perguntas sem resposta, especialmente sobre como fornecer os servidores e instalar o software do agente neles em primeiro lugar.

   Ansible, CloudFormation, Heat, and Terraform are all masterless by default. Ou, para ser mais preciso, alguns deles podem confiar em um servidor mestre, mas já faz parte da infraestrutura que você está usando e não uma peça extra que você tem que gerenciar. Por exemplo, Terraform se comunica com os provedores de nuvem usando as APIs do provedor de nuvem, então, em algum sentido, os servidores de API são servidores mestre, exceto que eles não necessitam de qualquer infra-estrutura extra ou quaisquer mecanismos de autenticação extra (ou seja, basta usar suas chaves de API). O An possible funciona conectando-se diretamente a cada servidor através do SSH, então, novamente, você não tem que executar qualquer infra-estrutura extra ou gerenciar mecanismos de autenticação extra (ou seja, basta usar suas chaves SSH).

   Agent Versus Agentless

   Chef, Puppet, and SaltStack all require you to install agent software (e.g., Chef Client, Puppet Agent, Salt Minion) on each server you want to configure. O agente normalmente corre em segundo plano em cada servidor e é responsável por
   instalar as últimas atualizações de gerenciamento de configuração.

   isto tem algumas desvantagens:

   • Bootstraping: Como você fornece seus servidores e instala o software do agente neles em primeiro lugar? Algumas ferramentas de gerenciamento de configuração chutar a lata para baixo a estrada, supondo que algum processo externo vai cuidar do presente para eles (por exemplo, você primeiro uso Terraform para implantar um grupo de servidores com uma imagem de VM que tem o agente já está instalado); outras ferramentas de gerenciamento de configuração de ter um especial processo de inicialização, onde você executar fora de comandos para configurar os servidores usando o provedor de nuvem APIs e instalar o software do agente nesses servidores através de SSH.manutenção: Você tem que atualizar cuidadosamente o software do agente em uma base periódica, tendo o cuidado de mantê-lo em sincronia com o servidor mestre se houver um. Você também tem que monitorar o software do agente e reiniciá-lo se ele falhar.
   • segurança: se o software do agente retirar a configuração de um servidor mestre (ou de outro servidor se não estiver a usar um mestre), então terá de abrir portas de saída em todos os servidores. Se o servidor mestre encaminha a configuração para o agente, então você tem que abrir portas de entrada em cada servidor. Em qualquer dos casos, tens de descobrir como autenticar o agente para o servidor com quem ele está a falar. Tudo isso aumenta a sua área de superfície para os atacantes.

   Mais uma vez, Chef, Puppet, e SaltStack têm diferentes níveis de suporte para modos agentless (por exemplo, salt-ssh), mas estes muitas vezes se sentem como que eles foram combinados como uma reflexão posterior e nem sempre suportam o conjunto completo de recursos da ferramenta de gerenciamento de configuração. É por isso que na natureza, a configuração padrão ou idiomática para Chef, Puppet, e SaltStack quase sempre inclui um agente, e geralmente um mestre também.todas estas peças móveis extras introduzem um grande número de novos modos de falha na sua infra-estrutura. A cada vez que você receber um relatório de bug, às 3 horas da manhã, você vai ter que descobrir se é um bug no código de sua aplicação, ou seu IAC código, ou a configuração de gerenciamento de cliente ou servidor mestre(s), ou a forma como o cliente se comunica com o servidor mestre(s), ou a forma como outros servidores de falar para o servidor mestre(s), ou…

   Ansible, CloudFormation, Calor, e Terraform não requer a instalação de qualquer extra agentes. Ou, para ser mais preciso, alguns deles requerem agentes, mas estes normalmente já estão instalados como parte da infra-estrutura que você está usando. Por exemplo, AWS, Azure, Google Cloud e todos os outros provedores de cloud se encarregam de instalar, gerenciar e autenticar software do agente em cada um de seus servidores físicos. Como um usuário do Terraform, você não tem que se preocupar com nada disso: você apenas emite comandos e os agentes do provedor de nuvem executam
   eles para você em todos os seus servidores. Com o Ansible, seus servidores precisam executar o servidor SSH, que é comum executar na maioria dos servidores de qualquer maneira.sempre que você escolhe uma tecnologia, você também está escolhendo uma comunidade. Em muitos casos, o ecossistema em torno do projeto pode ter um impacto maior em sua experiência do que a qualidade inerente da própria tecnologia. A comunidade determina quantas pessoas contribuem para o projeto, como muitos plugins,
   integrações, e extensões estão disponíveis, como é fácil de encontrar ajuda on-line (por exemplo, os posts do blog, perguntas no StackOverflow), e como é fácil contratar alguém para ajudá-lo (por exemplo, um funcionário, consultor ou suporte da empresa).é difícil fazer uma comparação precisa entre comunidades, mas você pode detectar algumas tendências pesquisando online. A tabela abaixo mostra uma comparação de populares IAC ferramentas, com dados que se reuniram em Maio de 2019, inclusive se o IAC ferramenta é open source ou de código fechado, o que provedores de nuvem suporta, o número total de contribuintes e as estrelas no GitHub, como muitos compromete-se ativo e problemas que havia mais de um período de um mês a partir de meados de abril a meados de Maio, quantos de fonte aberta bibliotecas estão disponíveis para a ferramenta, o número de perguntas para essa ferramenta no StackOverflow, e o número de trabalhos que mencionam a ferramenta Indeed.com.