View
11
Download
0
Category
Preview:
Citation preview
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)
Recommended