Automação na nuvem e infraestrutura como código

Automação na nuvem e
infraestrutura como
código
Quem é a
?
Destacando:
 AWS Premier Partner
 Managed Service Partner
 Parceiro do ano de 2015
 Latam Best case 2013
 Nerd de nascença
 AWS Professional Certified
 Trabalha com Software Livre/Open Source desde 2001
 Últimos 4 anos tem usado infraestrutura como código
para manter sistemas em produção
 Abraçando a cultura Devops e Big Data
Solution Architect
Quem usa o serviço
 Blocos básicos para criação de stacks para suas aplicações
 API autenticada para criação e manutenção de recursos
 Vários recursos auto gerenciados
 Agilizar a repetição de tarefas cotidianas
 Diminuir a incidência de erros
 Vários tipos:
 Tarefas agendadas
 Continuous Delivery/Continous Integration
 Infraestrutura base (instâncias, volumes, etc)
 Sistemas Operacionais e serviços
 Nem tudo são flores:
 Precisa de conhecimento, tanto nas ferramentas como no
ambiente.
 Você só pode fazer alterações via automação, para evitar
quebra da mesma.
 Você não pode ter medo de rodar a automação, ela tem que
ser idempotente
 Criar blocos de recursos de infraestrutura rapidamente.
 Padronizar recursos (nomes, tags, parâmetros default, monitoração,
logs, etc.)
 Facilitar mudanças (parametrização)
 Versionar sua infra (git)
 Testar o código antes de aplicar em produção
 Utilizado para infraestrutura básica
 Possui muitos providers (AWS, Azure, OpenStack)
 É executado na sua workstation
 Salva o estado da execução (local, S3, Atlas)
 Cria resources baseado em código declarativo
 Permite modularizar blocos de recursos (reaproveitamento de código)
 Modularize seu código
 Parametrizar, parametrizar, parametrizar (variables → parâmetro;
output → retorno)
 Inputs podem vir de variaveis de ambiente, via arquivo (*.tfvars) ou
setada diretamente na chamada do terraform
 Usar providers somente nos módulos internos
 Carregar templates nos módulos externos
 Gerencia cookbooks e recursos AWS
 Divide sua estrutura em stacks e layers como se fosse uma pilha de
aplicação
 Você pode usar os campos de custom json para parametrizar suas
recipes através do Terraform
 Vamos usar uma estratégia de registering ao invés de deixar o
OpsWorks manejar as instâncias
 É executado dentro da instância EC2
 Usa Ruby como base mas tem dezenas de resources criados
 Recomenda-se personalizar trechos de código criando
resources/providers/libraries
 Ponto de atenção: Na versão mais recente são usados dois estágios
(compile e execution queue), por isso não deixe seu código ruby
flutuando
 Cookbooks (módulos especializados)
 centenas deles no marketplace da OpsCode e no GitHub)
 Cookbooks possuem múltiplos recursos internos:
 Attributes (input)
 Recipes (execução)
 Resources/providers/libraries (fabricar DSL)
 Static files
 Templates
 Chefdk a seu dispor!
 Usar Rubocop e Foodcritic para avaliar seu código
 Kitchen com driver para EC2
 Berkshelf para gerenciar dependências
 Chef specs para TDD/BDD
 Como passar os parâmetros (node variable) para os specs? Usando o
próprio Chef!!!
 Ambiente complexo, automatizado via TerraForm, ECS e Consul
 MongoDB em HA replicaset, automatizado com TerraForm, Chef e
OpsWorks
 Pipeline de deploy com Jenkins e .NET, mais autoscaling de aplicação,
também usa TerraForm, Chef e OpsWorks (em andamento)
 TDD/BDD com o Terraform
 Repositório de módulos internos separado para sharing
 Pipeline de CI/CD para aplicar seu código nos seus ambientes
 Contribuir para o Terraform
 Caminhar para padronização dos cookbooks
 Suporte a custom data bags no OpsWorks
 Arquiteturas serverless com Lambda!
 Sempre pesquisar outras soluções (não existe bala de prata)