A workshop on Virtual Datacenters, given at FISL15. Portuguese.

1. Um Workshop.
Datacenter na nuvem

2. O workshop
• Começaremos com uma pequena introdução onde vamos discutir
os principais conceitos do trabalho
• Administração e organização interna dum centro de dados
• AWS EC2, VPN
• Automatização e orquestração
• Privacidade

3. Objetivos
• Que o participante ganhar familiaridade com as
tecnologias vistas (openvpn, AWS, ansible) e as
estrutura interna e organização geral de um
centro de dados

4. Hands On
• Para la parte de Hands On, criaremos un
datacenter desde cero, y desdobraremos una
aplicación web
• Vamos nos dividir em três grupos e cada um vai
executar tarefas específicas

5. Datacenter
O que é?

6. Algumas desvantagens
• Colocations geralmente em
locaciones remotas
• Custos em traslado pra
administrar
• Esse cabo… ?
• Servidores antigos
• Falhas físicas
• Redesenho pode ser
problemático: subredes, etc

7. Administração remota
• Mudas en hardware como tickets
• Falhas físicas são resolvidos com tickets
• Topologia de rede
• Topologia plana
• Regras de rede nos servidores

8. Datacenter virtual
Vantagens
• Exposição a falhas físicas
reduzida
• Maior versatilidade para
mudar hardware
• Versatilidade extrema para
desenho de topologia de rede
• AMIs: clonagem
Desvantagens
• Hardware virtual
• Performance
• Bons recursos são caros

9. AWS EC2
Servidores virtuais
Quando un servidor é gerado, uma IP elástica é assinada.
O servidor é clonado a partir de uma AMI.

11. AWS VPC
• É o equivalente a um rack num datacenter físico
• Sem uma VPC (Nuvem Privada Virtual), as
instâncias geradas estariam expostas e sem
organização
• Interação via IP somente
• NAT
• Subredes, isolamento

13. VPN
• Tradicionalmente implementado en hardware
• Isto requer conhecimento específico da plataforma
• OpenVPN: VPN por software
• Dispositivo virtual de rede nas máquinas conetadas
• Tráfego recibido no dispositivo virtual é criptografado,
enviado ao servidor OpenVPN, e é encaminhado ao destino.
• No destino, o tráfego é descriptografado e encaminhado na
rede local

14. VPN
• Tradicionalmente implementado en hardware
• Isto requer conhecimento específico da plataforma
• OpenVPN: VPN por software
• Dispositivo virtual de rede nas máquinas conetadas
• Tráfego recibido no dispositivo virtual é criptografado,
enviado ao servidor OpenVPN, e é encaminhado ao destino.
• No destino, o tráfego é descriptografado e encaminhado na
rede local

17. Orquestração /
Automatização
• Puppet: estilo declarativo
• Chef: estilo imperativo
• Ansible: imperativo, mas não ligado à língua
• Declarações em arquivos .yml
• Desvantagens:
• Ad-hoc
• Poucos elementos para programar
• Mas essas podem ser vantagens também

18. Hands on

19. Hands on
• Criar um datacenter em uma VPC, equipado com uma
VPN pra acesso
• Subredes para front-end, back-end, e de proxy
(pública)
• Desdobrar uma aplicação web, com um servidor
HTTP e base de dados
• Usar ansible para executar tarefas
• Romper tudo, FORMAT C:, etc.

20. Parte 1: AWS VPC
• Nesta parte vamos testar o acesso à consola AWS, e vamos criar três
subredes na VPC
• Vamos usar uma VPC com uma classe “B” de endereços IP: 10.100.0.0/16
• As tres subredes servirão para dividir logicamente nosso Datacenter
• Essas serão:
• Proxies/Acesso: 10.100.10.0/24
• Front-end: 10.100.20.0/24
• Back-end: 10.100.30.0/24
• Mais tarde a VPN vai existir na subrede 10.200.0.0/24

21. Subredes e routing tables
• As subredes precisam de saber como conetar
às internets
• Internet Gateway
• NAT Instance
• Para as subredes frontend e backend,
criaremos uma instância NAT

22. Routing tables
• Toda subrede têm uma routing table por defeito
• Proxies:
• 10.100.0.0/16 -> local
• 10.200.0.0/24 -> VPN server
• default -> Internet gateway (as internets direitinho)
• Subredes privadas:
• 10.100.0.0/16 -> local
• 10.200.0.0/24 -> VPN server
• default -> instância NAT

23. Organização em subredes
• É desejável a divisão em grupos dos servidores,
dependendo da sua função
• Uma manera de organizar é dividindo em Front-end/
Back-end, e interação com as internets
• As capaz dialogam através de proxies.
• haproxy
• ProxySQL
• Acesso direito

24. AWS Security Groups
• Firewall muito básico
• Para a oficina, vamos usar só:
• Back-end só pode ser acessado do Front-end
e a VPN

25. Parte 2: VPN
• OpenVPN: uma solução muito completa
• Servidor/cliente: os clientes conectam ao
servidor e o servidor centraliza todo o tráfego
openvpn encaminha os pacotes aos clientes ou
pra fora da rede virtual
• client-to-client opcional (não vamos utilizar, ou
vamos?)

27. Encaminhado
• O servidor OpenVPN necessita de configuração de rede especial
• ip_forward = 1
• -j MASQUERADE para tudo o tráfego que vem da VPN e vai para a VPC
• openvpn faz o MASQUERADE para o tráfego que vem da VPC e vai
para a VPN
• A VPC necessita saber que o tráfego para a VPN (destino 10.200.0.0/24)
deve ser encaminhado pelo servidor openvpn
• Fazemos isso na consola AWS, nas Routing Tables da VPC: o tráfego
para 10.200.0.0/24 é dirigido para o servidor VPN
• E mais um truco é preciso: Source/Dest check

28. Clientes VPN
• Ou, vocês ;)
• Instale openvpn na VirtualBox, ou TunnelBlick na Mac
• Para a configuração são precisos 4 arquivos
• ca.crt
• client.conf
• Um certificado (que a gente vai criar) e a chave,
firmados pelo master ca.key

29. Criação do certificado do
cliente
• Usaremos easy-rsa
• No fedora, têm uma copia no seu home dir pra trabalhar
• No Mac OS X, abra TunnelBlick e em Utilidades -> easy-rsa
• Copie ca.crt, ca.key, dh2048.pem ao easy-rsa/keys/
• Execute ./vars
• Execute ./build-req seu-nome
• seu-nome.csr e seu-nome.key serão criados
• Para assinar o CSR, execute ./sign-req seu-nome. O certificado será criado
• Este paso é efetuado pelo administrador da rede, no seu computador. ca.key
só é preciso para assinar certificados, e é um arquivo super secreto.

30. Conetando ao servidor
openvpn
• Em linux, copie esses arquivos ao dir /etc/openvpn/
• ca.crt (desde openvpn-config/ no home dir)
• seu-nome.{crt,key} (desde easy-rsa/keys/)
• client.conf (precisa ser editado) (desde openvpn-config/)
• No Mac OS X, copie-los pra o dir indicado por TunnelBlick, logo mude o nome
do dir para fisl.tblk.
• Para iniciar o serviço, em fedora execute:
• systemctl enable openvpn@client
• systemctl start openvpn@client
• No Mac OS X, é pipoca.

31. Parte 3: Criação das
instâncias
• Nesta parte vamos a criar as instâncias EC2 que logo
usaremos
• Vamos nos separar em 3 grupos:
• A subrede de proxies precisa uma instância
• Vamos alocar até 5 instâncias na subrede de backend
• As restantes vão ser criadas na subrede de frontend
• Se alguém quiser aprofundar nos conhecimentos da VPN, pode
criar a instância por fora da VPC, e vamos integrá-la usando
OpenVPN.

32. Criar uma instância EC2
• Na consola EC2, use Launch Instance
• Selecione em My AMIs, FISL15 Workshop Base
• Tipo da instância: t1.micro
• Subrede:
• Proxies: 10.100.10.0/24
• Frontend: 10.100.20.0/24
• Backend: 10.100.30.0/24
• Fora da VPC: vpc 172.32.0.0/16

33. Nome e tag
• Selecione um bom nome para a instância, para que a
gente poda reconhece-la na consola.
• frontend1, frontend2, backend1, backend2…
• O tag vai fazer possible a identificação da instância com
ansible. Adicione o tag Group:
• Frontend: Group = Frontend
• Backend: Group = Backend / BackendWrite
• Proxy: Group = Proxy

34. Security Group
• Proxies: VPN/VPC access + HTTP access
• Frontend: VPN/VPC access
• Backend: Backend access
• Fora da VPC: VPN/VPC + SSH access

35. Teste acesso
• Uma vez a instância é operacional, tome nota
do endereço IP e teste ssh pra ela com usuario
fedora.
• A chave ssh está presente no entorno do
usuario fedora da VirtualBox

36. Parte 4: Set up (ansible)
• Nesta parte vamos fazer o set up dos
servidores, usando scripts en ansible
• Temos scripts diferentes para
• Servidores drupal (frontend)
• haproxy (proxies)
• Servidores mysql (backend)

37. Backend
• O backend está half-baked: o script ansible
instala a mariadb, mas não instala os dados
• Após instalar, devemos nomear um dos servers
o maestre. Os outros vão ser escravos daquele.

38. Executando os scripts
• Backend: ansible-playbook -i ec2.py db-
servers.yml -e host=endereço
• Frontend: ansible-playbook -i ec2.py drupal-
servers.yml -e host=endereço
• Proxy: ansible-playbook -i ec2.py proxy-
servers.yml -e host=endereço

39. Backend
• Maestre: executar o script drupal.sql.gz:
• mysql -u root -e ‘CREATE DATABASE drupal’
• zcat drupal.sql.gz | mysql -u root drupal
• Escravos:
• CHANGE MASTER TO
MASTER_HOST=‘endereço_master’,
MASTER_USER=‘fisl’;

40. Conclusões
E perguntas