Rodando sua aplicação na Amazon do Brasil
Postado em 20. dez, 2011 por Guilherme Silveira em Arquitetura, Inovação
Desde o início de nosso trabalho com o cloud em 2009 temos investido tempo e pesquisa na utilização do cloud como plataforma para diminuir custos (e trabalho!) e potencializar produtos, através de diversos vendors.
Com a Amazon não é diferente: nosso sistema de ensino online está deployado lá. Com o lançamento de grande parte da sua plataforma no Brasil, a Amazon se torna uma opção ainda mais interessante de onde ter sua aplicação. Vamos ver passo a passo como fazer um deploy e aproveitar das novas vantagens da Amazon por aqui.
Primeiro nos logamos no painel AWS Manager, e escolhemos a região da América do Sul:
Depois escolhemos a imagem que usaremos para a máquina, no nosso caso uma instalação linux limpa, mantida pela própria Amazon. Existem centenas de instalações possíveis (de linux e windows) que podem ser buscadas no market da amazon.
Escolhemos então a potência da máquina e em qual availability zone ela ficará. Comecemos com “sa-east-1a“, que indica América do Sul:
Vale lembrar que uma aplicação realmente com alta disponibilidade precisaria ser deploiada em duas ou mais avaliability zones, mesmo sendo pequena a chance de uma zona cair.
Nas duas próximas telas escolhemos detalhes do Kernel e do RAM, além de possíveis tags que queremos dar para a máquina (em geral para trabalhar através dos web services). No nosso caso deixaremos os defaults.
Quando uma nova máquina é criada, precisamos nos logar nela e, para isso, precisamos de uma chave privada de acesso. A amazon pergunta qual o nome que devemos dar a chave, criando e permitindo que baixemos o arquivo. Note que a chave contida nesse arquivo é importantíssima e qualquer um de sua posse poderá ter acesso a máquina.
Por fim, escolhemos quais portas desejamos deixar abertas. No caso de uma aplicação Java com Jetty ou Tomcat, adicionamos a porta padrão 8080:
Isso mesmo, nada de complicados usuários e senhas. Nada de gerenciá-los através de ferramentas de webadmin desatualizadas. Nada de complicadas regras e configuração de firewalls. A Amazon então permite confirmar todas as opções, e o resultado é a máquina rodando:
A máquina possui um IP interno (para ser acessado de dentro da Amazon) e um DNS público, através do qual acessaremos a mesma de fora da Amazon. O DNS público pode ser visto ao clicar no nome da máquina:
Vamos acessar a máquina via ssh:
chmod 700 caelum-exemplo.pem ssh -i caelum-exemplo.pem ec2-user@ec2-177-71-153-49.sa-east-1.compute.amazonaws.com
Resultando em:
The authenticity of host 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com (177.71.153.49)' can't be established.
RSA key fingerprint is 34:a6:de:34:88:fd:a1:73:ae:c5:03:f1:ed:8e:2f:96.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com,177.71.153.49' (RSA) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
See /usr/share/doc/system-release/ for latest release notes.
There are 16 security update(s) out of 24 total update(s) available
Agora fazemos download do jetty, descompactamos e rodamos o servidor (se preferir, utilize o Tomcat):
wget http://download.eclipse.org/jetty/8.1.0.RC1/dist/jetty-distribution-8.1.0.RC1.tar.gz tar zxf jetty-distribution-8.1.0.RC1.tar.gz jetty-distribution-8.1.0.RC1/bin/jetty.sh start
O servidor irá inicializar e você logo receberá a mensagem de que ele está ouvindo a porta 8080.
2011-12-15 17:54:27.682:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8080 STARTING
Pronto, acesse seu jetty:
E se desejarmos atualizar a imagem da máquina, com atualizações de seguranca? Se sua máquina não armazena o banco, mas sim somente arquivos voláteis (de fácil reinstalação), basta terminá-la e criar uma nova. Sistema operacional atualizado! Para manter dados voláteis, você pode usar o RDS da Amazon para seu banco Mysql ou Oracle (ou outras máquinas para bancos não relacionais) e manter um script de configuração (usar técnicas de configuration management).
Mais: com apenas alguns cliques é muito fácil de adicionar um load balancer através de sticky sessions, configurar ips fixos, etc.
O que você está esperando para fazer seu primeiro deploy por lá?
Guilherme Silveira (Google+)
30 Respostas para “Rodando sua aplicação na Amazon do Brasil”
Trackbacks/Pingbacks
-
-
agosto 14, 2012
[...] relativamente simples colocar sua aplicação no cloud da Amazon. Um dos serviços oferecidos e bastante utilizados é o Amazon Simple Storage Service (S3), para [...]
ASSINE NOSSO RSS
Gabriel Novaes
20. dez, 2011
E o preço? Tem algo a falar ?
Guilherme Silveira
20. dez, 2011
Oi Gabriel!
O preço é mais salgado do que o preço dela fora do Brasil, infelizmente. Uma das *grandes* vantagens está no uso temporário de maquinas. Quando precisamos escalar, posso alugar uma maquina por algumas horas e depois desativa-la, pagando somente o tempo desejado. Para o aluguel de uma maquina full time durante um ano, outros concorrentes podem ser mais baratos.
Mas mesmo assim ainda ganhamos em alguns quesitos de infra: o load balancing, por exemplo, é trivial.
Abraço!
Renato Sardinha
20. dez, 2011
Tenho uma dúvida.
Eu posso usar o Jboss invés do Jetty?
Guilherme Silveira
20. dez, 2011
Com certeza Renato!
Você pode instalar o que quiser… (seguindo os termos da Amazon). É uma máquina linux (ou windows) como outra qualquer. No exemplo utilizamos o jetty pois foram só três comandos para baixar, descompactar, rodar. O jboss também seria nesse caso.
Abraço!
Marcelo Tozzi
20. dez, 2011
Renato, nas “Community AMIs” tem uma porrada de máquinas que já vem com o JBoss pra tentar facilitar ainda mais!
Guilherme Silveira
20. dez, 2011
Oi Marcelo! Isso mesmo, mas lembre-se que você pode escolher uma instalação minimal que tenha só aquilo que você precisa ou com mais coisas.
Tenho gostado da abordagem de pegar uma instalação zerada, instalar o mínimo, tirar um snapshot e usar esse snapshot a vontade para novas atualizações… a replicação fica muito barata.
Julian Monteiro
20. dez, 2011
Criar o snapshot é uma solução prática, mas o que fazer com os arquivos de configuração que por vezes são alterados?… é fácil esquecer de refazer o snapshot.
Tapajos
20. dez, 2011
Guilherme,
Eu acho que a ideia de usar uma AMI e snapshots é a mais utilizada.
Você chegou a avaliar sempre subir a maquina do zero (imagem mínima) e sempre usar o “user data” para subir a maquina?
Aqui nós optamos por sempre subir a maquina do zero. O nosso deploy na verdade é subir maquinas novas com um novo código e matar as antigas.
Desvantagem:
* – demora mais
* – o “user data” é limitado. (a solução usada é ele fazer é um download de outros scripts que são maiores)
Vantagem:
* – Não preciso me preocupar com atualizações, já que ao subir uma maquina nova ela instava o que tem de mais novo. Isso é crucial para atualizações de segurança.
Opiniões?
Paulo Silveira
20. dez, 2011
Vale lembrar nosso outro uso do EC2 que está cada vez mais em voga: colocar o servidor de integração contínua lá. Fica fácil de paralelizar os testes com o auxílio dos plugins que as ferramentas já possuem para a Amazon.
Guilherme Silveira
20. dez, 2011
Oi Julian!
Como o Tapajos disse, uma boa sacada é usar o server limpo (que é o foco desse post, inclusive! ). Deixando o script de receita de deploy da máquina em um servidor, você consegue replicar isso N vezes, onde N é o quanto deseja. E desliga suas outras máquinas antigas.
Nesse processo é importante que sua homologação também use esse processo para não acabar usando versões diferentes de “qualquer coisa” que acabem causando efeitos surpresa. Mas se a arquitetura é limpa como a de exemplo aqui (jetty + apache + RDS pra banco) a chance de uma surpresa é muito pequena e o custo de stop start são os descritos pelo Tapajos.
otimo comment!
Abraço
Daniel Serodio
20. dez, 2011
Muito interessante o post. Fiquei curioso com o “[...] load balancing, por exemplo, é trivial”, vocês vão fazer um post sobre isso?
José Papo
21. dez, 2011
Olá! Sou o evangelista técnico da Amazon Web Services no Brasil. Para entender as questões de preço, vide minha resposta no fórum em portugues da AWS: https://forums.aws.amazon.com/thread.jspa?threadID=83141&tstart=0
Guilherme Silveira
22. dez, 2011
Oi Daniel!
Atualizei o post com um link na seção onde você comentou. Basta ler “Utilizando o Elastic Load Balancing” e lá está!
Abraço
André
27. dez, 2011
Muito bacana, mas será que é possível vocês compartilharem também a experiência que tem com os preços cobrados? Que produto exatamente vocês já usaram? Eu vi uma tal de Instância Reservada que custa $473 por 3 anos de uso em São Paulo. Mas daí do lado tem $0.04 por hora de Linux. É cobrado a soma dos 2 valores? Ou você tem que optar por contratar anualmente ou por hora? Eu andava muito desanimado com o suporte a Java dos provedores de hospedagem. Mas agora fiquei empolgado, se eu realmente puder ter a minha máquina virtual, eu posso instalar a versão Java que eu quiser, com o servidor Web da minha preferência. Abraços!
André
27. dez, 2011
Elaborando mais a minha pergunta: existe alguma taxa a mais a ser paga? Por exemplo: é necessário pagar por byte transferido? Ou essa anualidade já inclui tudo?
Guilherme Silveira
27. dez, 2011
Boa tarde André. Voce esta certo, são os dois preços juntos. Por pegar uma instancia reservada, a idéia é que o preço por hora baixe bastante, mas você paga um valor mais alto para dizer meio que “eu me comprometo em usar mais essa máquina”. Por outro lado, o cúmulo do “descomprometimento” seria comprar uma spot instance, onde você paga muito mais barato mas não precisa de um horário específico.
Você está certo. A liberdade é total, é uma máquina tua. Enquanto a vantagem é essa liberadade, o chato é ter que se preocupar com a infra (que, como disse, em alguns casos é bem simples de cuidar, como no load balancing).
Abraço!
Gilvan Marques
03. fev, 2012
Maior roubada. Utilizei o site somente 1 dia, criei um server de testes e agora, um mês depois me vem um email informando que devo $ 105 do mes de janeiro e já em fevereiro, tá $31,00…
Não achei em lugar nenhum do site os valores da tabela de preços.
Nas faqs informa que o valor é pré-pago… bla bla bla.
Em suma, uma cilada para quem é de pequenas empresas ou só deseja testar o serviço.
Julio Monteiro
01. mar, 2012
Gilvan,
Com certeza não é uma roubada. Os preços são bem claros e disponíveis em http://aws.amazon.com/pt/ec2/pricing/, além de você achar diversas calculadores para estimar o valor cobrado ao final do mês.
E durante o percurso, você pode fazer uso dos relatórios deles para saber exatamente quanto que vai pagar pelos serviços utilizados. Se o valor cobrado foi um susto, foi por falta de acompanhamento, e não por problemas com a AWS.
Emannuel Silveira
07. mar, 2012
Guilherme Silveira,
Você saberia informar se o “Free Tier” deles é realmente free? Tem como realmente utilizar gratuitamente um conjunto de serviços da amazon para rodar uma aplicação em java, por exemplo?
Estou com vontade de fazer o cadastro para testar esse free tier, mas tenho medo de que eu suba sem querer algum serviço pago (e caro) e tenha uma surpresa desagradável na fatura do cartão. Você teria algum conselho quanto a isso?
Abraço!
Erick Melo
20. mar, 2012
O free tier é FREE mesmo.. Eu utilizei o serviço free por um bom tempo. Só preste atenção pro tipo de instância que vc vai rodar (MICRO INSTANCE).. Só esse tipo que é free de verdade…
O único custo que vc teria seria banda se o teu site for muito acessado.. Mas pra testes sai de graça mesmo!!
Eduardo Souza
08. mai, 2012
Pessoal, somente como informação, tenho implementado diversos projetos em Cloud na Amazon e percebi que os clientes estão contratando as instâncias EC2 “por demanda” que não tem preço de instalação cobrado no primeiro mês, e não contratam as instâncias “reservadas” de 1 ou 3 anos, porque dizem que não vão utilizar 100% do tempo, lembre-se que na hora de contratar vocÊ dizer a % de tempo de você vai usar da máquina, diminuindo o custo, o preço das instâncias reservada é quase 50% mais barato que as instâncias por demanda, em 6 meses o valor de implementação já se paga, lembrem-se disso.
Eduardo Souza
eduardo.souza@dominit.com.br
Dominit Soluções em TI.
Guilherme Silveira
08. mai, 2012
Otimo Eduardo!
No curso da amazon online da Caelum mencionamos justamente isso em um capitulo, quando vale a pena reservar/nao reservar etc. Como o Fabio Kung comentou em outro post, as vezes tambem vale tomar cuidado com a possivel queda de preco de infraestrutura, que pode fazer com que reservas mais curtas sejam positivas (como a de 1 ano)
Abraçø
Alex
06. set, 2012
Bacana o passo-a-passo! Exceto pelo tecniquês inventado e “deploiado” rss
Anderson de Sousa
24. out, 2012
Olá pessoal,
De acordo com os eventos que acompanho sobre cloud, palestras de Jose Papo sobre a WAS, fala-se muito sobre sucesso em seu uso e diminuição de custos. Para mim, ainda é nebuloso. Quando diminui custos, ninguém diz quanto diminuiu ou quanto custou uma solução de cloud. E quando diz que é barato, é barato quanto comparado ao custo de máquina e infra.
Por exemplo: A Caelum tem uma plataforma fantástica de curso on-line, aquilo funciona 24h todos os dias, qual é custo em média deste sistema?
Recentemente fiz uma projeção com a micro-instância, usando sempre o mínimo em tudo, ficou em torno de $ 66 dólares. Será que é isso mesmo?
Guilherme Silveira
25. out, 2012
Oi Anderson tudo bem?
Você está certo! No caso da plataforma online de cursos ela roda (hoje) em uma máquina medium com capacidade de 5 processadores 100% do tempo e com instancia reservada em high usage o que dá um belo desconto. Mas com certeza você está certo, a vantagem grotesca surge quando você tem boosts de necessidade de utilização e descarte de uma máquina – é a capacidade de poder escalar tua demanda que torna a solução barata. Se a demanda e o custo é fixo, talvez saia mais caro do que outra alternativa, tem que sempre por aconta no papel.
Abraço!
Jefferson
21. jan, 2013
Olá Pessoal!
Tenho a seguinte dúvida: possuo uma aplicação construída em 2007 usando J2EE com Tomcat. Nesta aplicação foi usado o recurso de sessão de usuário conforme as necessidades do sistema. Posso eu agora simplesmente fazer um deploy em Cloud? Tudo funcionará como antes?
Desde já, agradeço
Guilherme Silveira
21. jan, 2013
Faz sentido sim Jefferson. Basta voce tomar os mesmos cuidados de replicacao de sessao que voce ja estava tomando antes – ou passar a tomar caso queira a replicacao.
Abraço
Jefferson
22. jan, 2013
Certo Guilherme!
Mas configurando manualmente a replicação de sessão fará necessário conhecer alguns detalhes do ambiente de infra como IP das máquinas usadas no cluster e ainda terei que configurar os tomcats em cada máquina para configurar a repicacao… Isto é possível por exemplo na Amazon? Terei todo esse controle?
Eu nunca coloquei um aplicação grande em Cloud, talvez esse seja o problema de minhas dúvidas… Apenas fiz uns testes com Heroku
Guilherme Silveira
23. jan, 2013
Oi Jefferson.
Você está certo. Isto é possivel na Amazon pois voce tem acesso ssh a maquina e controle total sobre ela
Abraço