DEV Community đŸ‘©â€đŸ’»đŸ‘šâ€đŸ’»

Luiz Bernardo for AWS Community Builders

Posted on

Infraestrutura como cĂłdigo

O que Ă© infraestrutura como cĂłdigo?

A ideia por trĂĄs da infraestrutura como cĂłdigo (IAC) Ă© que vocĂȘ escreva e execute cĂłdigo para definir, implantar, atualizar e destruir sua infraestrutura. Isso representa uma mudança importante na mentalidade em que vocĂȘ trata todos os aspectos das operaçÔes como software, mesmo aqueles aspectos que representam hardware (por exemplo, configuração de servidores fĂ­sicos).Na verdade, uma percepção importante do DevOps Ă© que vocĂȘ pode gerenciar quase tudo em cĂłdigo, incluindo servidores, bancos de dados, redes, arquivos de log, configuração de aplicativos, documentação, testes automatizados, processos de implantação e assim por diante.

Existem cinco amplas categorias de ferramentas IAC:

  • Scripts ad hoc
  • Ferramentas de gerenciamento de configuração
  • Ferramentas de modelagem de servidor
  • Ferramentas de orquestração
  • Ferramentas de provisionamento

Vejamos um de cada vez.

Scripts Ad Hoc

A abordagem mais direta para automatizar qualquer coisa Ă© escrever um script ad hoc. VocĂȘ pega qualquer tarefa que estava fazendo manualmente, divide-a em etapas, usa sua linguagem de script favorita (por exemplo, Bash, Ruby, Python) para definir cada uma dessas etapas no cĂłdigo e executar esse script em seu servidor.

Por exemplo, aqui estĂĄ um script Bash chamado setup-webserver.sh que configura um servidor web instalando dependĂȘncias, verificando alguns cĂłdigos de um repositĂłrio Git e ativando um servidor da web Apache:

# Update the apt-get cache
sudo apt-get update

# Install PHP and Apache
sudo apt-get install -y php apache2

# Copy the code from the repository
sudo git clone https://github.com/brikis98/php-app.git / var / www / html / app

# Start Apache
sudo service apache2 start
Enter fullscreen mode Exit fullscreen mode

A grande vantagem dos scripts ad hoc Ă© que vocĂȘ pode usar linguagens de programação populares de uso geral e escrever o cĂłdigo como quiser. O terrĂ­vel sobre os scripts ad hoc Ă© que vocĂȘ pode usar linguagens de programação populares de uso geral e escrever o cĂłdigo como quiser.

Enquanto as ferramentas criadas para o IAC fornecem APIs concisas para realizar tarefas complicadas, se vocĂȘ estiver usando uma linguagem de programação de uso geral, precisarĂĄ escrever um cĂłdigo totalmente personalizado para cada tarefa. AlĂ©m disso, ferramentas projetadas para IAC geralmente impĂ”em uma estrutura particular para seu cĂłdigo, enquanto com uma linguagem de programação de propĂłsito geral, cada desenvolvedor usarĂĄ seu prĂłprio estilo e farĂĄ algo diferente. Nenhum desses problemas Ă© grande coisa para um script de oito linhas que instala o Apache, mas fica confuso se vocĂȘ tentar usar scripts ad hoc para gerenciar dezenas de servidores, bancos de dados, balanceadores de carga, configuraçÔes de rede e assim por diante.

Se vocĂȘ jĂĄ teve que manter um grande repositĂłrio de scripts Bash, sabe que quase sempre ele se transforma em uma confusĂŁo de cĂłdigo espaguete impossĂ­vel de manter. Os scripts ad hoc sĂŁo Ăłtimos para tarefas pequenas e pontuais, mas se vocĂȘ vai gerenciar toda a sua infraestrutura como cĂłdigo, deve usar uma ferramenta IaC desenvolvida especificamente para o trabalho.

Ferramentas de gerenciamento de configuração

Chef, Puppet, Ansible e SaltStack são ferramentas de gerenciamento de configuração, o que significa que são projetadas para instalar e gerenciar software em servidores existentes.Por exemplo, aqui estå uma função Ansible chamada web-server.yml que configura o mesmo servidor da web Apache que o script setup-webserver.sh :

- name: Update the apt-get cache
  apt:
    update_cache: yes

- name: Install PHP
  apt:
    name: php

- name: Install Apache
  apt:
    name: apache2

- name: Copy the code from the repository
  git: repo=https://github.com/brikis98/php-app.git dest=/var/www/html/app

- name: Start Apache
  service: name=apache2 state=started enabled=yes
Enter fullscreen mode Exit fullscreen mode

O código é semelhante ao script Bash, mas usando uma ferramenta como o Ansible oferece uma série de de vantagens:

ConvençÔes de codificação

O Ansible impÔe uma estrutura consistente e previsível, incluindo documentação, layout de arquivo, parùmetros claramente nomeados, gerenciamento de segredos e assim por diante. Embora cada desenvolvedor organize seus scripts ad hoc de maneira diferente, a maioria das ferramentas de gerenciamento de configuração vem com um conjunto de convençÔes que torna mais fåcil navegar pelo código.

IdempotĂȘncia

Escrever um script ad hoc que funcione uma vez nĂŁo Ă© muito difĂ­cil; escrever um script ad hoc que funcione corretamente, mesmo se vocĂȘ executĂĄ-lo repetidamente, Ă© muito mais difĂ­cil. Cada vez que vocĂȘ criar uma pasta em seu script, vocĂȘ precisa se lembrar de verificar se essa pasta jĂĄ existe; toda vez que vocĂȘ adiciona uma linha de configuração a um arquivo, precisa verificar se essa linha ainda nĂŁo existe; toda vez que vocĂȘ deseja executar um aplicativo, Ă© necessĂĄrio verificar se o aplicativo ainda nĂŁo estĂĄ em execução.

O cĂłdigo que funciona corretamente, nĂŁo importa quantas vezes vocĂȘ o execute, Ă© chamado de cĂłdigo idempotente. Para tornar o script Bash da seção anterior idempotente, vocĂȘ precisa adicionar muitas linhas de cĂłdigo, incluindo muitas instruçÔes if. A maioria das funçÔes do Ansible, por outro lado, sĂŁo idempotentes por padrĂŁo. Por exemplo, a função web-server.yml Ansible instalarĂĄ o Apache apenas se ainda nĂŁo estiver instalado e tentarĂĄ iniciar o servidor da web Apache apenas se ainda nĂŁo estiver em execução.

Distribuição

Os scripts ad hoc sĂŁo projetados para serem executados em uma Ășnica mĂĄquina local.Ansible e outras ferramentas de gerenciamento de configuração sĂŁo projetadas especificamente para gerenciar um grande nĂșmero de servidores remotos,

Por exemplo, para aplicar a função web-server.yml a cinco servidores, primeiro vocĂȘ cria um arquivo chamado hosts que contĂ©m os endereços IP desses servidores:

[servidores da web]
11.11.11.11
11.11.11.12
11.11.11.13
11.11.11.14
11.11.11.15
Enter fullscreen mode Exit fullscreen mode

Em seguida, vocĂȘ define o seguindo o manual da Ansible:

- hosts: webservers
  roles:
  - webserver
Enter fullscreen mode Exit fullscreen mode

Finalmente, vocĂȘ executa o manual da seguinte maneira:

ansible-playbook playbook.yml
Enter fullscreen mode Exit fullscreen mode

Isso instrui o Ansible a configurar todos os cinco servidores em paralelo. Como alternativa, definindo um parĂąmetro chamado serial no manual, vocĂȘ pode fazer uma implantação contĂ­nua, que atualiza os servidores em lotes. Por exemplo, definir serialpara 2instrui o Ansible a atualizar dois dos servidores por vez, atĂ© que todos os cinco sejam concluĂ­dos. A duplicação de qualquer uma dessa lĂłgica em um script ad hoc levaria dezenas ou mesmo centenas de linhas de cĂłdigo.

MĂĄquinas virtuais

Uma mĂĄquina virtual (VM) emula um sistema de computador inteiro, incluindo o hardware.VocĂȘ executa um hipervisor , como VMWare, VirtualBox ou Parallels, para virtualizar (ou seja, simular) a CPU, memĂłria, disco rĂ­gido e rede subjacentes.O benefĂ­cio disso Ă© que qualquer imagem de VM que vocĂȘ executa sobre o hipervisor pode ver apenas o hardware virtualizado, portanto, Ă© totalmente isolado da mĂĄquina host e de quaisquer outras imagens de VM e serĂĄ executado exatamente da mesma maneira em todos os ambientes ( por exemplo, seu computador, um servidor QA, um servidor de produção). A desvantagem Ă© que virtualizar todo esse hardware e executar um sistema operacional totalmente separado para cada VM incorre em uma grande sobrecarga em termos de uso de CPU, uso de memĂłria e tempo de inicialização. VocĂȘ pode definir imagens de VM como cĂłdigo usando ferramentas como Packer e Vagrant.

Containers

Um contĂȘiner emula o espaço do usuĂĄrio de um sistema operacional. VocĂȘ opera um mecanismo de contĂȘiner, como Docker ou CoreOS, para criar processos isolados, memĂłria, pontos de montagem e rede. O benefĂ­cio disso Ă© que qualquer contĂȘiner executado no mecanismo de contĂȘiner pode ver apenas seu prĂłprio espaço de usuĂĄrio, portanto, Ă© isolado da mĂĄquina host e de outros contĂȘineres e serĂĄ executado exatamente da mesma maneira em todos os ambientes (seu computador, um controle de qualidade servidor, um servidor de produção, etc.). A desvantagem Ă© que todos os contĂȘineres em execução em um Ășnico servidor compartilham o kernel do sistema operacional e o hardware desse servidor, portanto, Ă© muito mais difĂ­cil atingir o nĂ­vel de isolamento e segurança que vocĂȘ obtĂ©m com uma VM. No entanto, como o kernel e o hardware sĂŁo compartilhados, seus contĂȘineres podem inicializar em milissegundos e praticamente nĂŁo possuem sobrecarga de CPU ou memĂłria. 

Por exemplo, aqui estĂĄ um modelo de Packer chamado web-server.json que cria uma Amazon Machine Image (AMI), queĂ© uma imagem de VM que vocĂȘ pode executar no AWS:

{
  "builders": [{
    "ami_name": "packer-example",
    "instance_type": "t2.micro",
    "region": "us-east-2",
    "type": "amazon-ebs",
    "source_ami": "ami-0c55b159cbfafe1f0",
    "ssh_username": "ubuntu"
  }],
  "provisioners": [{
    "type": "shell",
    "inline": [
      "sudo apt-get update",
      "sudo apt-get install -y php apache2",
      "sudo git clone https://github.com/brikis98/php-app.git /var/www/html/app"
    ],
    "environment_vars": [
      "DEBIAN_FRONTEND=noninteractive"
    ]
  }]
}
Enter fullscreen mode Exit fullscreen mode

Este modelo do Packer configura o mesmo servidor da web Apache que vocĂȘ viu em setup-webserver.sh usando o mesmo cĂłdigo Bash. A Ășnica diferença entre o cĂłdigo anterior e os exemplos anteriores Ă© que este modelo do Packer nĂŁo inicia o servidor da web Apache (por exemplo, chamando sudo service apache2 start). Isso ocorre porque os modelos de servidor sĂŁo normalmente usados para instalar software em imagens, mas Ă© apenas quando vocĂȘ executa a imagem, por exemplo, implantando-a em um servidor, que vocĂȘ deve realmente executar esse software.

VocĂȘ pode construir uma AMI a partir deste modelo executando packer build webserver.jsone, apĂłs a conclusĂŁo da construção, vocĂȘ pode instalar essa AMI em todos os seus servidores AWS, configurar cada servidor para executar o Apache quando o servidor estiver inicializando e todos eles serĂŁo executados exatamente da mesma maneira.

Observe que as diferentes ferramentas de modelagem de servidor tĂȘm finalidades ligeiramente diferentes. O Packer Ă© normalmente usado para criar imagens que vocĂȘ executa diretamente nos servidores de produção, como uma AMI que vocĂȘ executa em sua conta de produção da AWS.O Vagrant Ă© normalmente usado para criar imagens que vocĂȘ executa em seus computadores de desenvolvimento, como uma imagem do VirtualBox que vocĂȘ executa em seu Mac ou laptop com Windows. Docker Ă© normalmente usado para criar imagens de aplicativos individuais. VocĂȘ pode executar as imagens Docker em computadores de produção ou desenvolvimento, desde que alguma outra ferramenta tenha configurado esse computador com o Docker Engine. Por exemplo, um padrĂŁo comum Ă© usar o Packer para criar um AMI que tenha o Docker Engine instalado, implantar esse AMI em um cluster de servidores em sua conta AWS e, em seguida, implantar contĂȘineres Docker individuais nesse cluster para executar seus aplicativos.

Os modelos de servidor sĂŁo um componente-chave da mudança para uma infraestrutura imutĂĄvel .Essa ideia Ă© inspirada na programação funcional e envolve variĂĄveis que sĂŁo imutĂĄveis; portanto, depois de definir um valor para uma variĂĄvel, vocĂȘ nunca mais poderĂĄ alterar essa variĂĄvel. Se vocĂȘ precisa atualizar algo, vocĂȘ cria uma nova variĂĄvel. Como as variĂĄveis nunca mudam, Ă© muito mais fĂĄcil raciocinar sobre seu cĂłdigo.

A ideia por trĂĄs da infraestrutura imutĂĄvel Ă© semelhante: uma vez implantado um servidor, vocĂȘ nunca mais farĂĄ alteraçÔes nele. Se vocĂȘ precisar atualizar algo, como implantar uma nova versĂŁo do seu cĂłdigo, vocĂȘ cria uma nova imagem a partir do seu modelo de servidor e a implanta em um novo servidor. Como os servidores nunca mudam, Ă© muito mais fĂĄcil raciocinar sobre o que estĂĄ implantado.

Ferramentas de orquestração

As ferramentas de modelagem de servidor sĂŁo Ăłtimas para criar VMs e contĂȘineres, mas como vocĂȘ realmente os gerencia? Para a maioria dos casos de uso do mundo real, vocĂȘ precisarĂĄ fazer o seguinte:

  • Implante VMs e contĂȘineres, fazendo uso eficiente de seu hardware.
  • Lance atualizaçÔes para uma frota existente de VMs e contĂȘineres usando estratĂ©gias como implantação contĂ­nua, implantação azul-verde e implantação canĂĄrio.
  • Monitore a integridade de suas VMs e contĂȘineres e substitua automaticamente os que nĂŁo estĂŁo Ă­ntegros ( autocorreção ).
  • Aumente ou diminua o nĂșmero de VMs e contĂȘineres em resposta ao carregamento ( escalonamento automĂĄtico ).
  • Distribua o trĂĄfego em suas VMs e contĂȘineres ( balanceamento de carga ).
  • Permita que suas VMs e contĂȘineres encontrem e conversem entre si pela rede ( descoberta de serviço ).

Lidar com essas tarefas Ă© o domĂ­nio das ferramentas de orquestração, como Kubernetes, Amazon Elastic Container Service (Amazon ECS), Docker Swarm e Nomad. Por exemplo, o Kubernetes permite definir como gerenciar seus contĂȘineres do Docker como cĂłdigo. Primeiro, vocĂȘ implanta um cluster do Kubernetes , que Ă© um grupo de servidores que o Kubernetes gerenciarĂĄ e usarĂĄ para executar seus contĂȘineres do Docker. A maioria dos principais provedores de nuvem tem suporte nativo para implantar clusters Kubernetes gerenciados, como Amazon Elastic Container Service para Kubernetes (Amazon EKS), Google Kubernetes Engine (GKE) e Azure Kubernetes Service (AKS).

Depois de ter um cluster de trabalho, vocĂȘ pode definir como executar seu contĂȘiner Docker como cĂłdigo em um arquivo YAML:

apiVersion: apps/v1

# Use a Deployment to deploy multiple replicas of your Docker
# container(s) and to declaratively roll out updates to them
kind: Deployment

# Metadata about this Deployment, including its name
metadata:
  name: example-app

# The specification that configures this Deployment
spec:
  # This tells the Deployment how to find your container(s)
  selector:
    matchLabels:
      app: example-app

  # This tells the Deployment to run three replicas of your
  # Docker container(s)
  replicas: 3

  # Specifies how to update the Deployment. Here, we
  # configure a rolling update.
  strategy:
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 0
    type: RollingUpdate

  # This is the template for what container(s) to deploy
  template:

    # The metadata for these container(s), including labels
    metadata:
      labels:
        app: example-app

    # The specification for your container(s)
    spec:
      containers:

        # Run Apache listening on port 80
        - name: example-app
          image: httpd:2.4.39
          ports:
            - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Este arquivo instrui o Kubernetes a criar uma implantação , que é uma forma declarativa definir:

  • Um ou mais contĂȘineres do Docker para serem executados juntos. Este grupo de contĂȘineres Ă© chamado de Pod .O pod definido no cĂłdigo anterior contĂ©m um Ășnico contĂȘiner do Docker que executa o Apache.
  • As configuraçÔes de cada contĂȘiner do Docker no pod. O pod no cĂłdigo anterior configura o Apache para escutar na porta 80.
  • Quantas cĂłpias (tambĂ©m conhecidas como rĂ©plicas ) do pod executar em seu cluster. O cĂłdigo anterior configura trĂȘs rĂ©plicas.O Kubernetes descobre automaticamente onde implantar cada pod em seu cluster, usando um algoritmo de programação para escolher os servidores ideais em termos de alta disponibilidade (por exemplo, tente executar cada pod em um servidor separado para que uma Ășnica falha de servidor nĂŁo desligue seu app), recursos (por exemplo, escolher servidores que tenham portas disponĂ­veis, CPU, memĂłria e outros recursos exigidos por seus contĂȘineres), desempenho (por exemplo, tentar escolher servidores com menos carga e menos contĂȘineres neles) e assim por diante. O Kubernetes tambĂ©m monitora constantemente o cluster para garantir que sempre haja trĂȘs rĂ©plicas em execução, substituindo automaticamente quaisquer pods que falhem ou parem de responder.
  • Como implantar atualizaçÔes. Ao implantar uma nova versĂŁo do contĂȘiner Docker, o cĂłdigo anterior lança trĂȘs novas rĂ©plicas, espera que estejam Ă­ntegras e, em seguida, desimplanta as trĂȘs rĂ©plicas antigas.

Isso Ă© muito poder em apenas algumas linhas de YAML! VocĂȘ executa kubectl apply -f example-app.ymlpara instruir o Kubernetes a implantar seu aplicativo. VocĂȘ pode entĂŁo fazer alteraçÔes no arquivo YAML e executar kubectl applynovamente para implementar as atualizaçÔes.

Ferramentas de provisionamento

Enquanto as ferramentas de gerenciamento de configuração, modelagem de servidor e orquestração definem o cĂłdigo executado em cada servidor, ferramentas de provisionamento como Terraform, CloudFormation e OpenStack Heat sĂŁo responsĂĄveis por criar os prĂłprios servidores.Na verdade, vocĂȘ pode usar ferramentas de provisionamento nĂŁo apenas para criar servidores, mas tambĂ©m bancos de dados, caches, balanceadores de carga, filas, monitoramento, configuraçÔes de sub-rede, configuraçÔes de firewall, regras de roteamento, certificados Secure Sockets Layer (SSL) e quase todos os outros aspectos de sua infraestrutura.

Por exemplo, o seguinte código implanta um servidor da web usando o Terraform:

resource "aws_instance" "app" {
  instance_type     = "t2.micro"
  availability_zone = "us-east-2a"
  ami               = "ami-0c55b159cbfafe1f0"

  user_data = <<-EOF
              #!/bin/bash
              sudo service apache2 start
              EOF
}
Enter fullscreen mode Exit fullscreen mode

NĂŁo se preocupe se vocĂȘ ainda nĂŁo estiver familiarizado com alguma sintaxe. Por enquanto, apenas se concentre em dois parĂąmetros:

ami*Este parĂąmetro especifica o ID de um AMI para implantar no servidor.VocĂȘ pode definir esse parĂąmetro para o ID de uma AMI construĂ­da a partir do modelo *web-server.json Packer na seção anterior, que tem PHP, Apache e o cĂłdigo-fonte do aplicativo.*user_data*Este Ă© um script Bash executado quando o servidor web estĂĄ inicializando. O cĂłdigo anterior usa esse script para inicializar o Apache.

Em outras palavras, este cĂłdigo mostra o provisionamento e a modelagem de servidor trabalhando juntos, que Ă© um padrĂŁo comum em infraestrutura imutĂĄvel.

Tenho focado meu trabalho e estudo em ferramentas de orquestração e ferramentas de provisionamento para trazerem mais flexibilidade e governança, mas isso estå muito ligado ao meu contexto atual.

Espero ter contribuĂ­do para o entendimento do que Ă© infraestrutura como cĂłdigo no dia a dia para vocĂȘ.

Vlw Flw

Top comments (0)

18 Useful Github Repositories Every Developer Should Bookmark

>> Check out this classic DEV post <<