Na primeira parte deste artigo, você pode conferir como segue a
migração de um aplicativo de web a partir de um
único servidor físico para o Amazon Elastic Compute
Cloud (Amazon EC2). Agora durante esta parte do trajeto, você
vai aprender como adaptar seu aplicativo ao ambiente de
nuvem e como tirar vantagem dos recursos que a nuvem
tem a oferecer. Confira abaixo o passo a passo para a migração.
A API da Amazon
Todas as funcionalidades necessárias para iniciar, parar e
usar a nuvem do Amazon EC2 estão disponíveis usando um
serviço da web. O Amazon publica as especificações
para os serviços da web e fornece um conjunto de
ferramentas de linha de comandos.
É preciso fazer o
download dessas ferramentas em Recursos antes de continuar. Também
recomendo que veja o guia de início rápido, localizado também ao final do artigo na seção Recursos, para configurar
seu ambiente, o que economizará muito tempo de
digitação.
Você autentica na API usando credenciais de segurança. Essas
credenciais podem ser encontradas no link
Account dentro do console de
gerenciamento do Amazon Web Services (AWS). Você precisará
de seus arquivos do certificado X.509 e chaves de
acesso. Mantenha-os seguros! Qualquer pessoa que os
tenha poderá usar recursos do AWS e incorrer em
cobranças em seu nome.
Antes de iniciar sua primeira instância
É preciso gerar as
chaves de Secure Shell (SSH) para se autenticar na
nova instância e configurar o firewall virtual para
protegê-la. A Listagem 1 mostra o uso do comando
ec2-add-keypair para
gerar um par de chaves SSH.
Listagem 1. Gerando o par de chaves SSH
[sean@sergeant:~]$ ec2-add-keypair main KEYPAIR main<br />40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01<br />-----BEGIN RSA PRIVATE KEY-----<br />MIIEpAIBAAKCAQEAu8cTsq84bHLVhDG3n/fe9FGz0fs0j/FwZiDDovwfpxA/lijaedg6lA7KBzvn<br />... -----END RSA PRIVATE KEY----- [sean@sergeant:~]$<br />ec2-describe-keypairs KEYPAIR main<br />40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01 O primeiro comando diz ao Amazon para gerar um par de chaves
com o nome main. A primeira linha do
resultado dá o hash da chave. O restante da saída é
uma chave primada PEM não criptografada. É preciso
armazenar essa chave em algum lugar por
exemplo, ~/.ssh/main.pem. O Amazon retém a porção
pública da chave, que ficará disponível para as VMs
que você iniciar.
O segundo comando, ec2-describe-keypairs, pede ao Amazon a
lista atual de pares de chaves. O resultado é o nome
do par de chaves, seguido pelo hash.
Cada instância é protegida por um firewall virtual que,
inicialmente, não permite nada. O Amazon EC2 chama
essas instâncias de grupos de segurança e
tem chamadas de API e comandos para manipulá-los.
Você os verá mais de perto na hora certa. Enquanto
isso, a Listagem 2 mostra como visualizar seus
grupos atuais.
Listagem 2. Exibindo os grupos de segurança atuais
[sean@sergeant:~]$ ec2-describe-group GROUP<br />223110335193 default default group A Listagem 2 mostra um grupo chamado default, com a
descrição “default group.” O ID de usuário associado
ao grupo é 223110335193. Não existem regras nesse
grupo. Se houvesse, elas seriam descritas abaixo do
grupo com a palavra PERMISSION na coluna
esquerda.
Preparando o ambiente da nuvem
O primeiro passo é preparar o ambiente da nuvem para testar o
aplicativo. O novo ambiente imitará o ambiente atual
de produção.
Comece iniciando a AMI, que tem um ID de
ami-10b55379. A Listagem 3 mostra a AMI
sendo iniciada e o status sendo verificado.
Listagem 3. Iniciando a AMI do CentOS
[sean@sergeant:~]$ ec2-run-instances ami-10b55379 -k<br />main RESERVATION r-750fff1e 223110335193 default<br />INSTANCE i-75aaf41e ami-10b55379 pending main 0<br />m1.small 2010-05-15T02:02:57+0000 us-east-1a<br />aki-3038da59 ari-3238da5b monitoring-disabled<br />instance-store [sean@sergeant:~]$<br />ec2-describe-instances i-75aaf41e RESERVATION<br />r-750fff1e 223110335193 default i-75aaf41e<br />ami-10b55379 pending main 0 E3D48CEE m1.small<br />2010-05-15T02:02:57+0000 us-east-1a aki-3038da59<br />ari-3238da5b monitoring-disabled instance-store<br />[sean@sergeant:~]$ ec2-describe-instances i-75aaf41e<br />RESERVATION r-750fff1e 223110335193 default INSTANCE<br />i-75aaf41e ami-10b55379<br />ec2-184-73-43-141.compute-1.amazonaws.com<br />domU-12-31-39-00-64-71.compute-1.internal running<br />main 0 E3D48CEE m1.small 2010-05-15T02:02:57+0000<br />us-east-1a aki-3038da59 ari-3238da5b<br />monitoring-disabled 184.73.43.141 10.254.107.127<br />instance-store O primeiro comando inicia a instância usando a AMI ami-10b55379 e especifica que o par de chaves gerado na Listagem 1 será usado para autenticar a máquina. O comando retorna várias informações, a mais importante delas sendo o identificador da instância (i-750fff1e), que é a identidade da máquina na nuvem do Amazon EC2. O segundo comando usa ec2-describe-instances, que lista todas as instâncias em execução.
Na Listagem 3, o identificador da instância foi passado na linha de comandos para exibir somente informações sobre aquela instância. O estado da instância é listado como pending, o que significa que a instância ainda está sendo iniciada. A AMI da IBM é grande, portanto leva, tipicamente, 5 a 10 minutos para iniciar. Executar o mesmo comando algum tempo mais tarde mostrará que o estado é running e que o endereço IP externo 184.73.43.141 foi dado. O endereço IP interno que começa com 10 é útil para falar dentro da nuvem do Amazon EC2, mas não agora.
É possível, então, usar SSH para se conectar ao servidor usando a chave que foi gerada anteriormente. Mas, primeiro, é preciso permitir o SSH (22/TCP). A Listagem 4 mostra como autorizar a conexão e efetuar login em seu novo servidor.
Entendendo chaves SSH
Se não estiver familiarizado com chaves SSH, é útil saber que
o SSH pode autenticar usuários com chaves, em vez de
senhas. Você gera um par de chaves, que é composto
de uma chave pública e uma chave privada. Você
mantém a chave privada e carrega a chave pública em
um arquivo chamado authorized_keys, que
está dentro do diretório $HOME/.ssh. Ao conectar a
um servidor com SSH, o cliente poderá tentar a
autenticação com a chave. Se tiver sucesso, você
terá efetuado o login.
Uma propriedade do par de chaves é que mensagens
criptografadas com uma das chaves só pode ser
descriptografada com a outra. Ao conectar a um
servidor, ele poderá criptografar uma mensagem com a
chave pública armazenada no arquivo authorized_keys.
Se você descriptografar a mensagem usando sua chave
pública, o servidor saberá que você está autorizado
a efetuar o login sem uma senha.
A próxima pergunta lógica é “Como o arquivo authorized_keys é
preenchido com a chave pública que está armazenada
no Amazon?” Cada instância do Amazon EC2 pode falar
com um servidor da web na nuvem do Amazon EC2 em
http://169.254.169.254 e recuperar metadados sobre a
instância. Uma das URLs é
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key,
que retorna a chave pública associada com a imagem.
Ao inicializar, a AMI recupera a chave pública e a armazena
em authorized_keys. Isto é feito em
/etc/init.d/getssh no exemplo de AMI. Poderia
também, facilmente, ocorrer em rc.local.
Outro uso dos metadados de instância é passar informações
para a imagem. É possível ter uma AMI genérica que
poderia ser um servidor da web ou servidor de
tarefas em segundo plano e fazer com que a instância
decidisse que serviços iniciar, com base nos
parâmetros passados ao iniciar a imagem.
Listagem 4. Conectando à instância
[sean@sergeant:~]$ ec2-authorize default -p 22 -s<br />$MYIP/32 ... [sean@sergeant:~]$ ssh -i<br />~/.ssh/main.pem root@184.73.43.141 The authenticity<br />of host '184.73.43.141 (184.73.43.141)' can't be<br />established. RSA key fingerprint is<br />af:c2:1e:93:3c:16:76:6b:c1:be:47:d5:81:82:89:80. Are<br />you sure you want to continue connecting (yes/no)?<br />yes Warning: Permanently added '184.73.43.141' (RSA)<br />to the list of known hosts. ... O primeiro comando permite a porta 22 (TCP é a opção padrão)
a partir de uma fonte de seu endereço IP. O /32 significa que somente o
host tem permissão, não a rede inteira. O comando ssh se conecta ao
servidor usando a chave privada.
Instalando o Ruby
O CentOS vem com uma versão limitada do Ruby, portanto você
instalará o Ruby Enterprise Edition (REE), que é um
interpretador Ruby de alto desempenho compatível com
a ramificação 1.8.7 atual do Ruby. Apesar do nome
parecer caro, o software é livre. A Listagem 5
mostra como instalar o REE.
Listagem 5. Instalando o REE
# rpm -e ruby ruby-libs<br /># yum -y install gcc-c++ zlib-devel openssl-devel<br />readline-devel ... Complete! # wget<br />http://rubyforge.org/frs/download.php/71096/ruby-enterprise-1.8.7-2010.02.tar.gz<br />... # tar -xzf ruby-enterprise-1.8.7-2010.02.tar.gz<br /># ruby-enterprise-1.8.7-2010.02/installer -a<br />/opt/ree Os primeiros dois comandos da Listagem 5 removem a instalação
padrão do Ruby e instalam um compilador C e alguns pacotes de
desenvolvimento necessários. O wget efetua o download do tarball atual do
REE, que é, a seguir, descomprimido pelo tar.
Finalmente, o último
comando executa o instalador com uma opção para
aceitar todos os padrões e colocar os resultados em
/opt/ree. O instalador é inteligente o suficiente
para lhe dizer os comandos que deverão ser
executados se alguns pacotes estiverem ausentes,
portanto observe cuidadosamente a saída, se a
instalação não funcionar.
Depois que o Ruby for instalado, adicione o diretório bin a
seu caminho com export
PATH=”/opt/ree/bin:$PATH”, que poderá ser
colocado no diretório disponível para todo o sistema
/etc/bashrc ou no diretório .bashrc dentro de seu
diretório inicial.
Instalando o PostgreSQL
O servidor PostgreSQL é parte da distribuição do CentOS,
portanto tudo o que você precisa fazer é instalá-lo
com o utilitário yum. A
Listagem 6 mostra como instalar o PostgreSQL e
assegurar-se de que ele será executado na
inicialização.
Listagem 6. Instalando o PostgreSQL
# yum -y install<br />postgresql-server postgresql-devel ... Installed:<br />postgresql-devel.i386 0:8.1.21-1.el5_5.1<br />postgresql-server.i386 0:8.1.21-1.el5_5.1 Dependency<br />Installed: postgresql.i386 0:8.1.21-1.el5_5.1<br />postgresql-libs.i386 0:8.1.21-1.el5_5.1 Complete! #<br />chkconfig postgresql on O comando yum instala pacotes a
partir de um repositório. Na Listagem 7, você está
instalando o componente do servidor PostgreSQL e as
bibliotecas de desenvolvimento. Isso automaticamente
puxa os utilitários principais de banco de dados e
quaisquer outros pacotes de que precisar.
Você não
precisará ainda do pacote de desenvolvimento, mas,
quando precisar integrar o Rails e o PostgreSQL,
precisará das bibliotecas dentro de
postgresql-devel.
Por padrão, o banco de dados armazena seus arquivos em
/var/lib/pgsql/data, que é parte do sistema de
arquivos raiz. Você moverá esse diretório para o
armazenamento da instância em on /mnt, como mostra a
Listagem 7.
Listagem 7. Movendo o armazenamento de dados do PostgreSQL para /mnt
# mv /var/lib/pgsql/data /mnt<br /># ln -s /mnt/data /var/lib/pgsql/data # service<br />postgresql start Depois de inserir os comandos na Listagem 7, o /mnt do
PostgreSQL estará no fim.
A seguir, é preciso ativar logins com senha para o banco de
dados payroll_prod (que será criado na próxima
etapa). Por padrão, o PostgreSQL não usa senhas: ele
usa um sistema interno de identificação.
Simplesmente adicione:
host "payroll_prod" all 127.0.0.1/32 md5 na parte superior de /var/lib/pgsql/data/pg_hba.conf e, a
seguir, execute:
su - postgres -c 'pg_ctl reload' para que a alteração entre em vigor. Com essa configuração,
logins normais ao PostgreSQL não precisarão de uma
senha (que é motivo pelo qual o comando reload não precisou de uma
senha), mas qualquer acesso ao banco de dados
payroll precisará.
A etapa final é configurar o banco de dados Rails a partir da
linha de comandos. Execute su –
postgres -c psql e acompanhe na Listagem 8.
Listagem 8. Criando o usuário e o banco de dados
postgres=# create user payroll with password<br />'secret'; CREATE ROLE postgres=# create database<br />payroll_prod; CREATE DATABASE postgres=# grant all<br />privileges on database payroll_prod to payroll;E, com isso, seu banco de dados está criado.
Migrando os dados
Para testar, você deveria obter um dump de seu banco de dados
do ambiente de produção em um certo momento, para
que tenha algo com que testar. O aplicativo
SmallPayroll armazena dados tanto no banco de dados
quanto no sistema de arquivos. O dump do banco de
dados será feito usando o comando pg_dump que acompanha o
PostgreSQL; os dados do sistema de arquivo usarão
rsync.
O banco de dados
deverá ser apagado e transferido novamente para a
migração por causa da natureza dos dumps de bancos
de dados, mas os dados do sistema de arquivo só
precisam transferir arquivos novos e alterados, pois
o rsync consegue detectar
quando um arquivo não sofreu modificações. Portanto,
a parte de teste do plano ajuda a acelerar a
migração, pois a maioria dos dados já estará lá.
A maneira mais rápida de copiar o banco de dados é
executando:
pg_dump payroll_prod | gzip -c ><br /> /tmp/dbbackup.gz em sua máquina da produção, copiando dbbackup.gz para o
servidor da nuvem e, a seguir, executando:
zcat dbbackup.gz | psql payroll_prod Esse comando simplesmente cria um dump compactado do banco de
dados em um servidor e, a seguir, reexecuta todas as
transações no outro servidor. O rsync é simples assim. Em seu
servidor de produção, execute:
rsync -avz -e "ssh -i .ssh/main.pem"<br />/var/uploads/ root@174.129.138.83:/var/uploads/ Esse comando copia tudo de /var/uploads do servidor de
produção atual para o novo servidor. Se executá-lo
novamente, somente os arquivos alterados são
copiados, economizando tempo mais tarde em
sincronizações.
Como você está copiando o banco de dados, não é preciso
aplicar primeiro suas migrações do Rails. O Rails
acreditará que o banco de dados está atualizado,
pois você já copiou a tabela schema_migrations.
Implementando o aplicativo Rails
Neste momento, você tem um servidor base configurado, mas não
seu aplicativo. É preciso instalar alguns gems
básicos, juntamente com quaisquer gems que seu
aplicativo precisar, antes que ele possa ser
executado. A Listagem 9 mostra os comandos
necessários para atualizar seus gems. Note que é
preciso estar na raiz de seu aplicativo Rails,
portanto copie-o primeiro para seu servidor.
Listagem 9. Atualizando o RubyGems e instalando seus gems
# gem update --system Updating<br />RubyGems Nothing to update # gem install rails<br />mongrel mongrel-cluster postgres Successfully<br />installed rails-2.3.8 Building native extensions.<br />This could take a while... Successfully installed<br />gem_plugin-0.2.3 Successfully installed<br />daemons-1.1.0 Successfully installed<br />cgi_multipart_eof_fix-2.5.0 Successfully installed<br />mongrel-1.1.5 Successfully installed<br />mongrel_cluster-1.0.5 Building native extensions.<br />This could take a while... Successfully installed<br />postgres-0.7.9.2008.01.28 7 gems installed ... #<br />rake gems:install (in /home/payroll) gem install<br />haml Successfully installed haml-3.0.12 1 gem<br />installed Installing ri documentation for<br />haml-3.0.12... Installing RDoc documentation for<br />haml-3.0.12... gem install money ... O primeiro comando assegura que o RubyGems propriamente dito
esteja atualizado. O segundo comando instala alguns
gems úteis:
- rails. A
estrutura Ruby on Rails - postgres. O
driver do banco de dados que permite usar o
PostgreSQL com ActiveRecord - mongrel. Um
servidor de aplicativos usados para armazenar o
aplicativo Rails - mongrel_cluster. Utilitários que
permitem iniciar e parar grupos de mongrels ao
mesmo tempo
O último comando executa uma tarefa do Rails para instalar
todos os gems extras que o aplicativo requer. Se
você não usou a diretiva config.gem em seu arquivo
config/environment.rb, então poderá ser preciso
instalar os gems extras manualmente, usando o comando
gem install gemname.
Tente iniciar seu aplicativo com o comando RAILS_ENV=production
script/console. Se esse comando for bem
sucedido, pare-o e, a seguir, inicie seu pacote de
mongrels com:
mongrel_rails cluster::start -C<br />/home/payroll/current/config/mongrel_cluster.ymlSe o primeiro comando não for bem sucedido, você receberá
várias mensagens de erro para ajudá-lo a encontrar o
problema, que geralmente é um gem ou arquivo
ausente. Aproveite essa oportunidade para voltar e
colocar quaisquer diretivas config.gem ausentes, para que não esqueça
o gem no futuro.
Instalando um servidor web front-end
Nginx é o servidor web de escolha para muitos ambientes
virtuais. Ele tem baixo custo adicional e é bom para
realizar conexões de proxy para um serviço de
backend, como mongrel. A Listagem 10 mostra como
instalar o nginx.
Listagem 10. Instalando nginx
# rpm -Uvh<br />http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm<br />... # yum install nginx ... Running Transaction<br />Installing : nginx [1/1] Installed: nginx.i386<br />0:0.6.39-4.el5 Complete! # chkconfig nginx on A Listagem 11 instala o repositório Extra Packages for
Enterprise Linux® (EPEL) e, a seguir, instala o
nginx e assegura que ele será executado na
inicialização.
Listagem 11. Uma configuração do nginx para um aplicativo rails
# Two mongrels, balanced based on least<br />connections upstream mongrel-payroll { fair; server<br />127.0.0.1:8100; server 127.0.0.1:8101; } server {<br />listen 80; server_name app.smallpayroll.ca; root<br />/home/payroll/current/public; gzip_static on;<br />access_log /var/log/nginx/app.smallpayroll.ca_log<br />main; error_page 404 /404.html; location / { #<br />Because we're proxying, set some environment<br />variables indicating this proxy_set_header X-Real-IP<br />$remote_addr; proxy_set_header X-Forwarded-For<br />$proxy_add_x_forwarded_for; proxy_set_header Host<br />$http_host; proxy_redirect false;<br />proxy_max_temp_file_size 0; # Serve static files out<br />of Root (eg public) if (-f $request_filename) {<br />break; } # Handle page cached actions by looking for<br />the appropriately named file if (-f<br />$request_filename.html) { rewrite (.*) $1.html;<br />break; } # Send all other requests to mongrel if<br />(!-f $request_filename) { proxy_pass<br />http://mongrel-payroll; break; } } error_page 500<br />502 503 504 /500.html; location = /500.html { root<br />/home/payroll/current/public; } } A Listagem 11 mostra uma configuração relativamente típica do
nginx, com alguns elementos inseridos para manipular
o armazenamento em cache de páginas do Rails e
enviar solicitações dinâmicas para um mongrel de
saída. Você poderia mapear outras URLs para nomes de
arquivo aqui, se necessário.
Com a configuração no lugar, service
nginx start inicia o servidor da web.
Testes
Para os testes, seria útil ser capaz de referenciar sua
instância na nuvem usando o nome regular de domínio
do aplicativo, pois você deseja garantir que esteja
usando o site de teste, e não o site de produção.
Isso é feito por meio de uma substituição do DNS
local. No Windows, edite
C:\windows\system32\drivers\etc\hosts; no UNIX,
edite /etc/hosts. Adicione uma linha como:
x.x.x.x app.smallpayroll.ca onde x.x.x.x é o endereço IP de seu servidor da
nuvem e app.smallpayroll.ca é o nome do
aplicativo. Reinicie seu navegador e acesse seu site
da web. Você estará agora usando a versão de seu
aplicativo na nuvem. (Não se esqueça de comentar a
linha que acabou de adicionar quando desejar
retornar à versão de produção!)
Neste momento, você deverá ser capaz de testar que a versão
da nuvem de seu aplicativo funciona da mesma forma
que a versão de produção; corrija quaisquer
problemas que encontrar. Anote cuidadosamente o que
encontrar, pois será bom criar um script caso inicie
um segundo servidor. Como você está usando a versão
da nuvem de seu aplicativo, é possível excluir e
restaurar o banco de dados sem que os usuários
reclamem.
Empacotando a nova AMI
A última coisa a fazer é reempacotar sua AMI. A qualquer
momento que iniciar uma nova instância, você perderá
tudo que está em /mnt e sua partição raiz será
redefinida para o que estiver na AMI. Ainda não há
nada que possa fazer sobre o problema com o /mnt,
mas o reempacotamento assegura que sua AMI continue
da maneira como a deixou.
Se a AMI que estiver iniciando não tiver as ferramentas de
AMI, é possível instalá-las com o seguinte comando:
rpm -i --nodeps<br />http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm Empacotar uma AMI é um processo em três etapas:
- Criar a imagem da instância propriamente
dita. - Carregar a imagem para o Amazon S3.
- Registrar a AMI.
Antes de prosseguir, interrompa suas instâncias do mongrel e
do PostgreSQL, para garantir que quaisquer arquivos
abertos sejam tratados corretamente. É preciso
também copiar suas chaves X.509, que se encontram no
Amazon Console, para o /mnt em seu servidor. A
Listagem 12 mostra as primeiras duas etapas do
empacotamento, que são realizadas na VM propriamente
dita.
Listagem 12. Empacotando a AMI
# ec2-bundle-vol -d<br />/mnt -e /mnt --privatekey /mnt/pk-mykey.pem \ --cert<br />/mnt/cert-mycert.pem --user 223110335193 -p<br />centos-ertw Please specify a value for arch [i386]:<br />Copying / into the image file /mnt/centos-ertw...<br />... Generating digests for each part... Digests<br />generated. Creating bundle manifest...<br />ec2-bundle-vol complete. # ec2-upload-bundle -b<br />ertw.com -m /mnt/centos-ertw.manifest.xml \<br />--secret-key MYSECRETKEY --access-key MYACCESSKEY<br />Creating bucket... Uploading bundled image parts to<br />the S3 bucket ertw.com ... ... Uploaded<br />centos-ertw.part.37 Uploading manifest ... Uploaded<br />manifest. Bundle upload completed. O primeiro comando gera o pacote, especificando que /mnt
deverá ser ignorado e que ele irá para /mnt (as
opções -e e -d, respectivamente). As
opções -k, –cert e –user apontam para suas credenciais de
segurança e ID de usuário do AWS, que podem ser
encontradas nas configurações de conta de seu
console de gerenciamento do AWS. A última opção,
-p, permite nomear esta
AMI para diferenciá-la das outras.
O primeiro comando executará por cerca de 10 minutos,
dependendo do quanto sua partição raiz estiver
cheia. O segundo comando carrega o pacote no Amazon
S3. A opção -b especifica
um nome de depósito, que será criado se ainda não
existir. A opção -m
aponta para o arquivo de manifesto criado na última
etapa. As duas últimas opções são suas credenciais
do Amazon S3, que podem ser encontradas junto a suas
credenciais X.509 no console de gerenciamento do
AWS. Mas lembre-se de que suas credenciais X.509 são
usadas para operações do Amazon EC2, enquanto que o
Amazon S3 usa chaves de texto.
Finalmente, execute o comando:
ec2-register<br /> ertw.com/centos-ertw.manifest.xml para registrar a AMI e verá o identificador da AMI para usar
de agora em diante. Note que o comando ec2-register não é
distribuído com a AMI, portanto é mais fácil
executá-lo a partir do servidor onde a AMI original
foi iniciada. Também é possível instalar as
ferramentas do Amazon EC2 em sua instância do Amazon
EC2.
Realizando a migração
Agora que seu ambiente em nuvem está funcionando, a migração
em si deverá ser bem simples. Você verificou que
tudo está funcionando: tudo o que resta é
sincronizar os dados e transferir o serviço de forma
ordenada.
Tarefas pré-migração
Algum tempo antes da migração, assegure-se de diminuir o TTL
dos registros de nome do seu domínio para 5 minutos.
Você também deverá desenvolver uma lista de
verificação das etapas necessárias para mover tudo,
os testes que deseja realizar para verificar se tudo
está funcionando e o procedimento para reverter a
mudança, se necessário.
Assegure-se de que seus usuários sejam notificados da
migração!
Imediatamente antes do horário da migração, verifique
novamente o ambiente da nuvem para se assegurar de
que ele esteja pronto para ser sincronizado e
aceitar tráfego de produção.
Migrando o aplicativo
Para migrar o aplicativo, realize as seguintes etapas:
-
Desative o site atual de produção ou coloque-o
em modo somente leitura, dependendo da natureza do
site. Como a maioria das solicitações de
SmallPayroll envolve gravação no banco de dados ou
sistema de arquivos, o site será desativado. O gem
de implementação Capistrano inclui uma tarefa,
cap deploy:web:disable,
que coloca uma página de manutenção no site
informando aos usuários que o site está fora do ar
para manutenção. - Pare os serviços do aplicativo no ambiente da
nuvem em preparação para a migração dos dados
interrompendo seus processos mongrel. - Copie o banco de dados da mesma forma como fez
para testar. - Execute novamente o rsync, se necessário.
- Reinicie os servidores de aplicativo com o
comando:
mongrel_rails<br /> cluster::start -C<br /> /home/payroll/current/config/mongrel_cluster.yml06. Assegure-se de que seu arquivo hosts aponta para
o ambiente da nuvem e realize alguns testes.
Assegure-se de que os usuários conseguem efetuar o
login e navegar pelo site.
Atualizando o DNS
Se seus testes forem bem-sucedidos, então você poderá alterar
seus registros de DNS para apontar para o ambiente
da nuvem. Neste ponto, acho útil manter um tail -f em execução no
arquivo de log do servidor web para observar se as
pessoas estão acessando o site.
Há chances de que seu servidor DNS local ainda tenha
informações antigas armazenadas em cache pelos
próximos 5 minutos. É possível verificar isto com o
comando dig, conforme
mostra a Listagem 13.
Listagem 13. Verificando se o servidor DNS está armazenando a consulta em cache
# dig<br />app.smallpayroll.ca @172.16.0.23 ;<br /><<>> DiG 9.3.4<br /><<>> app.smallpayroll.ca<br />@172.16.0.23 ; (1 server found) ;; global options:<br />printcmd ;; Got answer: ;;<br />->>HEADER<<- opcode:<br />QUERY, status: NOERROR, id: 38838 ;; flags: qr rd<br />ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL:<br />0 ;; QUESTION SECTION: ;app.smallpayroll.ca. IN A ;;<br />ANSWER SECTION: app.smallpayroll.ca. 251 IN A<br />69.164.205.185 ... Na seção ANSWER, você pode ver que faltam 251 segundos para
que a entrada expire. É importante usar uma
ferramenta como dig,
host ou nslookup para verificar o
DNS, pois seu arquivo hosts está substituindo o DNS
por enquanto. Usar ping
usaria o que estiver dentro do arquivo hosts.
Realize seu teste final de aceitação enquanto espera que o
DNS seja propagado.
Conclusão
Você migrou com sucesso um aplicativo para a nuvem! O
procedimento básico foi:
- Configurar o novo ambiente.
- Testar com uma cópia dos dados de produção.
- Desligar o ambiente antigo.
- Copiar os dados de produção para o novo
ambiente. - Alterar o DNS para apontar para o novo
ambiente.
Apesar de agora estar “na nuvem”, o aplicativo provavelmente
está em pior situação do que antes. Considere os
seguintes pontos:
- O aplicativo ainda está em execução em um
servidor. - Se o servidor travar, todos os dados serão
perdidos. - Você tem menos controle sobre o desempenho do
que tinha em seu servidor físico. - A máquina e o aplicativo não estão
trancados.
No próximo artigo, você aprenderá como resolver estes
problemas e começar a construir um ambiente mais
robusto para seu aplicativo.
Recursos
Aprender
- No Cloud Computing zone do developerWorks,
obtenha os recursos necessários para desenvolver e
implementar aplicativos na nuvem e manter-se
atualizado sobre os recentes desenvolvimentos na
nuvem. - Solicite os metadados da instância de sua instância do
Amazon EC2 para obter informações sobre a instância,
desde as chaves SSH que deverá usar até informações
especificadas pelo usuário. - Inicie sua aventura na
nuvem navegando pelo console de gerenciamento do AWS. - Se for trabalhar com o
Amazon EC2, você deverá se familiarizar com os vários guias que o Amazon fornece. - Aprenda sobre as AMIs da
IBM da
perspectiva do Amazon e da perspectiva da IBM. - Pesquise todos os artigos do Sean no
developerWorks. - Na zona Linux do developerWorks, encontre
centenas de artigos e tutoriais, bem como downloads,
fóruns de discussão e muitos outros recursos para
desenvolvedores e administradores Linux. - Mantenha-se atualizado com
os eventos técnicos e webcasts do developerWorks
focados em uma variedade de produtos IBM e assuntos
da indústria de TI. - Participe de uma orientação gratuita do developerWorks Live!
para atualizar-se rapidamente sobre produtos e
ferramentas da IBM, assim como tendências da
indústria de TI. - Assista às demos on demand do developerWorks que
abrangem da instalação do produto e demos de
configuração para iniciantes à funcionalidade
avançada para desenvolvedores experientes. - Siga o developerWorks no Twitter, ou inscreva-se em
um feed dos
Obter produtos e tecnologias
- O
Ruby Enterprise Edition é uma implementação
de alto desempenho do Ruby que pode ser usado por si
só ou em conjunto com o Phusion
Passenger para integrar com Apache ou nginx.
De qualquer forma, você obtém acesso a gerenciamento
mais rápido de memória e melhor coleta de lixo. -
Registre-se em IBM Industry Application Platform AMI for
Development Use para obter uma introdução aos
vários produtos da IBM na nuvem. Lembre-se de que
terá que passar por um processo de registro de
saída, mas não será cobrado por nada até que o use.
Você pode usar também a ami-90ed0ff9. - As
ferramentas da API do Amazon EC2 são usadas
para comunicar com a API do Amazon para iniciar e
terminar instâncias e reempacotar novas instâncias.
Estas ferramentas são periodicamente atualizadas à
medida que novos recursos são introduzidos no EC2,
portanto é bom verificar anúncios de atualização de
produtos nesta página. Você precisará pelo menos da
atualização 2009-05-15, pois usará alguns dos
recursos de balanceamento de carga posteriormente. -
Avalie os produtos da IBM da forma que melhor
lhe convém: Faça o download de uma versão de teste
de produto, experimente um produto on-line, use um
produto em um ambiente de nuvem ou passe algumas
horas no SOA Sandbox aprendendo como implementar
Arquitetura Orientada a Serviço de forma eficiente.
Discutir
Envolva-se na comunidade My developerWorks. Entre em
contato com outros usuários do developerWorks
enquanto explora os blogs, fóruns, grupos e wikis
dos desenvolvedores.
Artigo publicado originalmente no developerWorks Brasil, por Sean Walberg.
Sean Walberg trabalha com Linux e UNIX desde 1994 em ambientes
acadêmicos, corporativos e de provedores de serviço de Internet.
Escreveu muito sobre administração de sistemas nos últimos anos. É
possível entrar em contato com ele pelo e-mail sean@ertw.com.







