Transferir como PDF, PPTX
Carregado porIgnacio Nin
Datacenter na nuvem
Este documento descreve um workshop sobre datacenters na nuvem. O workshop inclui introduções sobre conceitos-chave, administração de datacenters, AWS EC2, VPN, automação e privacidade. Os participantes terão experiência prática criando um datacenter completo na AWS com subredes, VPN e implantação de uma aplicação web usando Ansible.
Datacenter na nuvem
- 1.
- 2. O workshop • Começaremoscom 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 oparticipante 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 • Parala 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.
- 6. Algumas desvantagens • Colocationsgeralmente 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 • Mudasen 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çãoa 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 Quandoun 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 implementadoen 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 implementadoen 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.
- 19. Hands on • Criarum 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: AWSVPC • 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 routingtables • 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 • Todasubrede 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 servidorOpenVPN 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 certificadodo 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çãodas 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ânciaEC2 • 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 • Umavez 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: Setup (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 backendestá 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: executaro 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.