Automação na nuvem e

infraestrutura como

código

Destacando:

AWS Premier Partner

Managed Service Partner

Parceiro do ano de 2015

Latam Best case 2013

Quem é a

?

Solution Architect

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

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)