Migre su aplicación Linux a la nube de Amazon, Parte 1: Migración inicial

Cómo migrar su aplicación a la nube

La computación en nube y la Infrastructure as a Service (IaaS) han sido bien documentadas. Sin embargo, por lo general no se habla de cómo hacer funcionar una aplicación en un entorno de nube. En esta serie, descubra cómo trasladar una aplicación a la nube y aprovechar las características que esta configuración tiene para ofrecerle. En la Parte 1, vea la migración directa de un servidor físico a un servidor nube.

Sean A. Walberg, Senior Network Engineer

Author photoSean Walberg ha trabajado con los sistemas Linux y UNIX desde 1994 en entornos académicos, corporativos, y de proveedores de servicios de Internet. Ha escrito bastante sobre la administración de sistemas en los últimos años. Usted puede contactarse con el en sean@ertw.com.



13-07-2010

Sobre esta serie

Esta serie de artículos sigue la migración de una aplicación web desde un servidor físico único hasta Amazon Elastic Compute Cloud (Amazon EC2). Durante el proceso, usted aprender cómo adaptar su aplicación al entorno de nube y cómo aprovechar las características que la nube tiene para ofrecerle.

Infrastructure as a Service (IaaS) es un concepto amplio: si usted utiliza recursos de la nube, paga por ellos. Si desea mayor capacidad informática, paga más. La desventaja de este modelo es que usted trabaja con computadoras que nunca verá o sobre las que no sabrá mucho al respecto. Una vez que supera esto, sin embargo, hay mucho que ganar con IaaS.

Dado que el modelo IaaS es tan diferente al modelo tradicional de compra de servidores, la forma de administrar sus computadoras virtuales cambia. El modo de ejecución de su aplicación en la nube también se modifica. Aquello que alguna vez dio por sentado, como la latencia insignificante entre servidores, ya no es un hecho.

Trabajando con Amazon EC2

Amazon EC2 le permite a cualquier persona que posea una tarjeta de crédito pagar el uso de servidores por hora, encendiéndolos y apagándolos mediante una application programming interface (API). Se puede elegir entre una gran variedad de servidores,—según le preocupen más la memoria, el disco, o la capacidad de la CPU, —junto con conjunto de discos residentes para balanceadores de carga. Usted paga sólo por lo que usa.

Además del ofrecimiento Amazon EC2 existen otros que le proporcionan, entre otras cosas, el procesamiento de pagos, bases de datos, y procesamiento de las colas de mensajes. En esta serie de artículos, usted utilizará Amazon Simple Storage Service (Amazon S3), el cual le dará acceso al espacio en disco, y pagará sólo por lo que use.


La aplicación de ejemplo

La aplicación web que se utiliza en los ejemplos de esta serie es un servicio de pago de salarios denominado SmallPayroll.ca, escrito con la estructura Ruby on Rails y un back end de PostgreSQL. Es común en muchas aplicaciones: tiene un nivel de base de datos, un nivel de aplicación, y un conjunto de archivos estáticos como los archivos cascading style sheet (CSS) y JavaScript. Los usuarios prueban diferentes formas de ingresar y administrar datos, y estos generan informes.

Los diferentes componentes en uso son:

  • Nginx. El servidor web front-end para archivos estáticos y balanceador al nivel medio.
  • Mongrel. El propio servidor de la aplicación.
  • Ruby. El lenguage que usted utiliza al escribir la aplicación.
  • Gems. Conectores y bibliotecas de terceros para todo, desde el encriptamiento de la base de datos hasta el monitoreo a nivel de la aplicación.
  • PostgreSQL. El motor de la base de datos de lenguage de consulta estructurado.

El uso del sitio ha excedido la capacidad del único servidor que ahora lo aloja. Por lo tanto, la migración a un nuevo entorno se encuentra en orden, y esta es una excelente oportunidad para moverse hacia la nube.

Las mejoras deseadas

Sin embargo, si sólo se moviera de un servidor a algunos servidores basados en la nube no se aprovecharía todo lo que permite hacer la nube, ni se lograría una lectura emocionante. Así que durante el traslado usted alcanzará mejoras, algunas de las cuales solamente son posibles en un entorno de nube:

  • Mayor confiabilidad. Porque usted puede elegir el tamaño del servidor que desea utilizar en la nube, puede ejecutar múltiples servidores pequeños para la redundancia.
  • Capacidad tanto para escalar en forma vertical como hacia abajo. A medida que el servicio aumenta, hay un incremento en el número de servidores que se agregan al grupo. Sin embargo, la cantidad de servidores puede también aumentarse para soportar los picos de tráfico en el corto plazo o disminuir durante los periódicos momentos de calma.
  • Almacenamiento en la nube. Los backups de los datos de la aplicación se harán a Amazon S3, eliminando la necesidad del almacenamiento en cinta.
  • Automatización. Todo en el entorno Amazon, —desde los servidores hasta el almacenamiento y los balanceadores de carga —pueden automatizarse. Menos tiempo de administración de una aplicación significa más tiempo para otras cosas más productivas.

Usted logrará estas mejoras progresivamente a lo largo de esta serie de artículos.


Estrategias de verificación y migración

Al desplegar una aplicación por primera vez, por lo general usted puede darse el lujo de verificar y hacer pequeños ajustes sin tener que cargar con el tráfico de producción. Por el contrario, al migrar una aplicación, usted tiene el desafío de los usuarios que están depositando carga en el sitio. Una vez que el nuevo entorno toma el tráfico de producción, los usuarios estarán esperando que todo funcione correctamente.

Que haya una migración no necesariamente significa que no habrá tiempo de espera. Es mucho más fácil si usted puede desconectar el servicio por un período de tiempo determinado. Puede usar esta ventana de interrupción para realizar las sincronizaciones finales de los datos y dar lugar a la estabilización de cualquier cambio en la red. La ventana no debería utilizarse para hacer el despliegue inicial al nuevo entorno,—osea que el nuevo entorno debería encontrarse en funcionamiento antes de que comience la migración de la aplicación. Teniendo esto en cuenta, la sincronización de los datos entre los entornos y los cambios en la red resulta fundamental.

La planificación de la estrategia de migración ayuda a comenzar el recorrido por el entorno actual. Responda las siguientes preguntas:

  • ¿Qué software utilizo en mis servidores para ejecutar la aplicación?
  • ¿Que software utilizo en mis servidores para administrar y monitorear los recursos de la aplicación y del servidor?
  • ¿Dónde se encuentran todos los datos de los usuarios que se guardaron? ¿En las bases de datos? ¿En los archivos?
  • ¿Se guardan los activos estáticos, como las imágenes, los CSS, y los archivos JavaScript en algún otro lugar?
  • ¿Qué puntos de contacto con otros sistemas requiere la aplicación?
  • ¿He realizado el backup de todo últimamente?

Las notificaciones a los usuarios

Por lo general, las notificaciones a los usuarios son positivas, aunque estas no anticipen los tiempos de inactividad. En el caso de la aplicación SmallPayroll.ca, los usuarios tienden a usar el sitio durante periodos constantes, que corresponden al ciclo de pago de salarios de dos semanas. Por lo tanto, un aviso con un período de dos semanas de anticipación sería razonable. Los sitios como Google AdWords, interfaz administrativa de la plataforma publicitaria de Google, brinda los avisos con una semana de anticipación aproximadamente. Si su sitio web es sólo un sitio de noticias donde los usuarios no se verían tan afectados si estuvieran desconectados durante una hora, usted puede optar por dar la notificación el mismo día de la interrupción.

La forma de la notificación también varía dependiendo de la naturaleza de su sitio y del modo en el cual actualmente se comunica con los usuarios. Para SmallPayroll.ca, un mensaje destacado cuando el usuario se conecta es suficiente. Por ejemplo, un mensaje como "El sistema no estará disponible entre las 12:01 a.m. y la 1 a.m. hora de Oriente, el 24 de junio de 2010. Todo lo ingresado antes de esta fecha será guardado. Si desea más información haga clic aquí." Este mensaje suministra tres datos claves que los usuarios deben conocer:

  • Cuándo será la interrupción, incluyendo la zona horaria
  • La confirmación de que los datos estarán a salvo
  • El indicador de más información

De ser posible, evite el uso de los horarios 12:00 a.m. y 12:00 p.m., y también del término media noche. Estos tienden a confundir a la gente, ya que muchos no están seguros de si la medianoche del 17 de junio es muy temprano (12:01 a.m.) o muy tarde (11:59 p.m.). De modo similar, muchos no están seguros de si mediodía significa 12 a.m. o 12 p.m. Es mucho más fácil agregar un minuto y determinar una hora inequívoca.

Los detalles pueden ser diferentes, especialmente si usted anticipa que el servicio funcionará parcialmente durante la interrupción. Si usted decide colocar la noticia durante la interrupción (por ejemplo en el caso de un sitio de noticias), esta información también le será útil. Mi pantalla preferida de interrupción de sitio fue la siguiente "El sitio no se encuentra disponible por razones de mantenimiento; vuelva alrededor de las 3 p.m. EST. ¡Mientras espera juegue Asteroids!"

No desatienda a sus usuarios internos tampoco. Si usted tiene representantes de cuentas, querrá darles la noticia por si sus clientes le hacen alguna pregunta.

Reflexiones sobre DNS

El domain name system (DNS) se encarga de la traducción de un nombre, como www.example.com a una dirección IP, como 192.0.32.10. Su computadora se conecta a esas direcciones, así que esta traducción es importante. Al migrar de un entorno a otro, es casi seguro que esté utilizando una dirección IP diferente (excepto que usted se encuentre en el mismo edificio físico).

Las computadoras guardan en la memoria caché la asociación de los nombres a las direcciones IP durante un período de tiempo determinado, que se conoce como el time to live (TTL), para reducir el tiempo total de respuesta. Al cambiar de un entorno a otro—osea de una dirección IP a otra—las personas cuya entrada DNS ha sido guardada en la memoria caché seguirán tratando de usar el viejo entorno. La entrada DNS para la aplicación y su TTL asociado deben ser administrados con cuidado.

Los TTLs llevan por lo general entre una hora y un día. Al preparar una migración, sin embargo, desearía que el TTL llevara menos de 5 minutos. Este cambio debe realizarse por lo menos un período TTL antes de intentar cambiar la dirección, porque las computadoras obtienen el TTL junto con la asociación del nombre a la dirección IP. Por ejemplo, si el TTL para www.example.com se fijara en 86,400 segundos (un día), usted debería resetear el TTL a 5 minutos por lo menos un día antes de la migración.

Desacoplamiento del entorno viejo y el nuevo

Es fundamental probar todo el entorno antes de realizar la migración. Todas las pruebas deberían realizarse aisladas del entorno de producción, preferiblemente con una copia instantánea del volumen de los datos de la producción para poder poner en práctica mejor el nuevo entorno.

La realización de una prueba completa con una copia instantánea del volumen de los datos de la producción tiene dos motivos. El primero es que es más probable ver los errores al utilizar datos del mundo real, porque son más impredecibles que los datos de prueba utilizados durante el desarrollo. Los Datos del mundo real pueden referirse a archivos que usted olvida copiar o que requieren una configuración particular que olvidó realizar en el camino.

La segunda razón para utilizar datos de producción es que usted puede practicar la migración al mismo tiempo que carga los datos. Usted debería poder probar más aspectos del plan de migración, excepto el cambio de entorno propiamente dicho.

Aunque usted estará simulando que su nuevo entorno es de producción, sólo un entorno puede asociarse con el nombre del host de la aplicación. La forma más sencilla para evitar este requisito es realizar la anulación del DNS en sus archivos hosts. En UNIX®, este archivo reside en /etc/hosts; en Windows®, reside en C:\windows\system32\drivers\etc\hosts. Simplemente siga el formato de las líneas existentes, y agregue una entrada señalando al nombre del host de su aplicación su futura dirección IP. No olvide hacer lo mismo para cualquier servidor de imágenes o cualquier otro elemento que traslade. Probablemente tenga que reiniciar su navegador, pero después de esto, podrá ingresar la URL de producción y en vez de ser conducido allí será guiado a su nuevo entorno.


Un manual básico de Amazon EC2

El servicio de EC2 le permite pagar por el uso de una virtual machine (VM) por hora. Amazon ofrece varios tipos de máquinas y las clasifica según los perfiles de su CPU, memoria, y disco. Amazon mide la memoria y el disco en gigabytes y la CPU en EC2 Compute Units (ECU) de Amazon, donde 1 ECU equivale aproximadamente a 1.0 - 1.2GHz AMD Opteron o Intel® Xeon® processor (2007 era). Por ejemplo, la instancia pequeña normal le ofrece una memoria de 1.7GB, 160GB de espacio en disco, y 1 ECU de CPU. Al momento de escribir este artículo, la máquina más grande es la High-memory Quadruple Extra Large, que tiene una memoria de 68.4GB, un espacio en disco de 1.7TB, y 26 ECUs dividido en ocho núcleos virtuales. Los precios van desde 8.5 centavos de dólar por hora por el uso de la más pequeña hasta US$2.40 por hora por la más grande.

La vida de una instancia Amazon EC2 comienza como la de una Amazon Machine Image (AMI), se trata de una plantilla que usted puede utilizar para crear cualquier cantidad de VMs. Amazon publica algunas AMIs, y usted puede crear las suyas y compartirlas con los demás. Algunas de estas AMIs creadas por el usuario pueden adquirirse de forma gratuita; algunas tienen un costo superior al que cobra Amazon por hora. Por ejemplo, IBM publica varias AMIs pagas que le permiten pagar por licencias por horas.

Cuando usted desea iniciar una VM, elige el tipo de máquina y una AMI. La AMI es almacenada en Amazon S3 y copiada a la partición raíz de su VM al abrir la instancia. La partición raíz es siempre de 10GB. El espacio de almacenamiento asociado con el tipo de máquina se denomina almacenamiento de la instancia o almacenamiento efímero y se presenta ante su VM como un driver independiente. El almacenamiento se denomina efímero porque al cerrar la instancia, la información se pierde para siempre. Es necesario que realice un back up de sus datos en forma regular para evitar la pérdida de los mismos. Esto significa además que si el host físico se está ejecutando, su instancia se bloquea y se cierra, y el disco efímero se pierde.

La Amazon Machine Image

Todas las AMIs son asignadas como identificadoras por Amazon, como por ejemplo ami-0bbd5462. Amazon proporciona algunas AMIs públicas, y otras personas han además publicado sus propias AMIs. Usted puede elegir empezar con una AMI pública y realizarle modificaciones, o comenzar de cero. Cada vez que usted realiza cambios en el sistema de archivos raíz de una AMI, puede guardar la AMI como si fuera una nueva, que se denominará re-bundling.

En esta serie, usted comienza con una imagen CentOS disponible al público, aunque puede elegir otra diferente. Es inteligente dedicar algún tiempo a la observación de la imagen que utiliza para asegurarse de que no haya cuentas adicionales y de que los paquetes se actualicen. Es posible además poner en movimiento su AMI desde el inicio, pero en este artículo no tratamos ese tema.

La API de Amazon

Toda la funcionalidad necesaria para iniciar, detener, y utilizar la nube de Amazon EC2 se puede alcanzar usando un servicio web. Amazon publica las especificaciones para los servicios web y además suministra un conjunto de herramientas de línea de comando. Usted debería descargar estas herramientas antes de proceder (vea Resources). También lo invito a dar una rápida mirada a la guía de inicio (vea Resources) para configurar su entorno, lo cual le ahorrará mucho tipeo.

Usted se identifica en la API usando las credenciales de seguridad. Estas credenciales se encuentran en el enlace Account que se encuentra dentro de la consola de administración de Amazon Web Services (AWS) (vea Resources). Usted necesitará los archivos de identificación X.509 y las claves de acceso. ¡Cuide estas claves! Cualquiera que las tenga podría acceder a los recursos de AWS y realizar gastos a su nombre.

Antes de abrir su primera instancia

Antes de abrir su primer instancia, debe generar las claves Secure Shell (SSH) para identificarse en su nueva instancia y configurar el firewall virtual para proteger su instancia. El listado 1 muestra el uso del comando ec2-add-keypair para generar un par de claves SSH.

Listado 1. Generación de un par de claves SSH
[sean@sergeant:~]$ ec2-add-keypair main
KEYPAIR main    40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAu8cTsq84bHLVhDG3n/fe9FGz0fs0j/FwZiDDovwfpxA/lijaedg6lA7KBzvn
...
-----END RSA PRIVATE KEY-----
[sean@sergeant:~]$ ec2-describe-keypairs
KEYPAIR main    40:88:59:b1:c5:bc:05:a1:5e:7c:61:23:5f:bc:dd:fe:75:f0:48:01

El primer comando le indica a Amazon generar un par de claves con el nombre main. La primera línea de resultados brinda el hash de la clave. El resto del resultado consiste en una clave privada encriptada PEM. Usted deber guardar estas claves en algún lugar—por ejemplo, ~/.ssh/main.pem. Amazon conserva la parte pública de la clave, que probablemente estarán disponibles para las VMs que usted inicie.

El segundo comando, ec2-describe-keypairs, le solicita a Amazon la lista actual de pares de claves. El resultado es el nombre del par de claves, seguido de la hash.

Cada instancia es protegida por un firewall virtual que inicialmente no permite que nada entre. Amazon EC2 llama a estas instancias grupos de seguridad y tiene llamadas API y comandos para administrarlas. Usted verá esto en mayor profundidad cuando llegue el momento. Mientras tanto, en el listado 2 puede observar una vista de sus grupos actuales.

Listado 2. Despliegue de los grupos de seguridad actuales
[sean@sergeant:~]$ ec2-describe-group
GROUP   223110335193    default default group

El Listado 2 muestra un grupo denominado default con la descripción "default group." La ID de usuario relacionada con el grupo es 223110335193. No hay reglas en este grupo. Si las hubiera, serían descriptas debajo del grupo con la palabra PERMISSION en la columna izquierda.


Preparación del entorno de la nube

El primer paso es preparar el entorno de la nube para probar la aplicación. El nuevo entorno imitará al entorno de producción actual.

Comience iniciando la AMI que tiene la ID ami-10b55379. En el Listado 3 se observa el inicio de la AMI y la comprobación del estado.

Listado 3. Inicio de la AMI CentOS
[sean@sergeant:~]$ ec2-run-instances ami-10b55379 -k main
RESERVATION  r-750fff1e  223110335193  default
INSTANCE  i-75aaf41e  ami-10b55379  pending  main  0  m1.small
2010-05-15T02:02:57+0000 us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
instance-store  
[sean@sergeant:~]$ ec2-describe-instances i-75aaf41e
RESERVATION  r-750fff1e  223110335193  default
i-75aaf41e  ami-10b55379  pending  main  0  E3D48CEE  m1.small
2010-05-15T02:02:57+0000 us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
instance-store  
[sean@sergeant:~]$ ec2-describe-instances i-75aaf41e
RESERVATION  r-750fff1e  223110335193  default
INSTANCE  i-75aaf41e  ami-10b55379  ec2-184-73-43-141.compute-1.amazonaws.com
domU-12-31-39-00-64-71.compute-1.internal  running  main  0  E3D48CEE  m1.small
2010-05-15T02:02:57+0000  us-east-1a  aki-3038da59  ari-3238da5b  monitoring-disabled
184.73.43.141  10.254.107.127  instance-store

El primer comando inicia la instancia usando la AMI ami-10b55379 y especifica que el par de claves generado en elListado 1 será utilizado para identificarse en la máquina. El comando devuelve bastante información, de lo cual lo más importante es el identificador de la instancia (i-750fff1e), el cual constituye la identidad de la máquina en la nube de Amazon EC2. El segundo comando usa el comando ec2-describe-instances, el cual hace una lista de todas las instancias que se están ejecutando. En el Listado 3, el identificador de la instancia ha sido ingresado a la línea de comando para mostrar sólo la información sobre la instancia. El estado de la instancia se indica en la lista como pending, lo que significa que la instancia todavía está siendo iniciada. La IBM AMI es grande, por lo cual generalmente le lleva 5-10 minutos solamente iniciarse. Al ejecutar el mismo comando más tarde se puede ver que el estado de la misma es running y que la dirección IP externa 184.73.43.141 ha sido suministrada. La dirección IP interna que comienza con 10 sirve para dialogar con la nube de Amazon EC2, pero no ahora.

Usted puede usar entonces SSH para conectarse al servidor usando la clave que generó anteriormente. Pero primero debe dejar ingresar al SSH (22/TCP). En el Listado 4 se puede observar cómo autorizar la conexión y conectarse a su nuevo servidor.

Comprensión de las claves SSH

Si no está familiarizado con las claves SSH, le será útil saber que SSH puede identificar a los usuarios con claves en vez de contraseñas. Usted genera un par de claves, compuesto por una clave pública y una privada. Usted se guarda la clave privada y sube la clave pública a un archivo denominado authorized_keys, que se encuentra dentro del directorio $HOME/.ssh . Al conectarse al servidor con SSH, el cliente puede tratar de identificarse con la clave. Si tiene éxito, se conecta.

Una característica del par de claves es que los mensajes encriptados con una de las claves puede ser desencriptado solamente con la otra clave. Al conectarse al servidor, éste puede encriptar un mensaje con la clave pública guardada en el archivo authorized_keys. Si usted puede desencriptar el mensaje usando su clave pública, el servidor sabe que usted está autorizado para conectarse sin necesidad de una contraseña.

La siguiente pregunta lógica es, "¿Cómo colocar en el archivo authorized_keys la clave pública que se encuentra almacenada en Amazon?" Cada instancia Amazon EC2 puede dialogar con un servidor web que se encuentra en la nube Amazon EC2 en http://169.254.169.254 y recuperar metadatos sobre la instancia. Una de las URLs es http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key, la cual devuelve la clave pública asociada con la imagen.

En el arranque, la AMI recupera la clave pública y la almacena en authorized_keys. Esto se puede ver en la AMI de ejemplo en /etc/init.d/getssh. Esto podría suceder con esta misma facilidad en rc.local.

Otro uso de los metadatos de la instancia es el paso de información a la imagen. Usted podría tener una AMI genérica que podría ser un servidor web o un servidor de trabajo de fondo y hacer que la instancia decida cuál de los servicios iniciar en base a los parámetros que usted ingresa al iniciar la imagen.

Listado 4. Conexión con la instancia
[sean@sergeant:~]$ ec2-authorize default -p 22 -s $MYIP/32
...
[sean@sergeant:~]$ ssh -i ~/.ssh/main.pem root@184.73.43.141
The authenticity of host '184.73.43.141 (184.73.43.141)' can't be established.
RSA key fingerprint is af:c2:1e:93:3c:16:76:6b:c1:be:47:d5:81:82:89:80.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '184.73.43.141' (RSA) to the list of known hosts.
...

El primer comando acepta el puerto 22 (TCP es la opción por omisión) de una fuente de su dirección IP. El /32 significa que sólo el host tiene permitido entrar, no toda la red. El comando ssh se conecta al servidor usando la clave privada.

Instalación de Ruby

CentOS trae incorporada una versión fechada de Ruby, de modo que usted instalará Ruby Enterprise Edition (REE), que es un interpretador de Ruby de alta performance compatible con la versión actual 1.8.7 de Ruby. A pesar de que el nombre lo hace parecer caro, se trata de un software de fuente abierta. El Listado 5 muestra cómo instalar REE.

Listado 5. Instalación de REE
# rpm -e ruby ruby-libs
# yum -y install gcc-c++ zlib-devel openssl-devel readline-devel
...
Complete!
# wget http://rubyforge.org/frs/download.php/71096/ruby-enterprise-1.8.7-2010.02.tar.gz
...
# tar -xzf ruby-enterprise-1.8.7-2010.02.tar.gz
# ruby-enterprise-1.8.7-2010.02/installer -a /opt/ree

Los primeros dos comandos del Listado 5 borran la instalación de Ruby por omisión e instalan un compilador C y algunos paquetes necesarios para el desarrollo. wget descarga el tarball actual de REE, el cual luego es descomprimido por tar. Finalmente, el último comando ejecuta el instalador con una alternativa para aceptar todas las opciones por omisión y coloca los resultados en /opt/ree. El instalador es lo suficientemente inteligente como para indicarle qué comandos ejecutar si se está olvidando de algunos paquetes, así que esté atento al resultado si la instalación no funciona.

Después de la instalación de Ruby, agregue el directorio bin a su ruta con export PATH="/opt/ree/bin:$PATH", que puede colocar en el directorio system-wide /etc/bashrc o .bashrc dentro de su directorio principal.

Instalación de PostgreSQL

El servidor PostgreSQL forma parte de la distribución CentOS, de modo que lo único que debe hacer es instalarlo con el programa utilitario yum. El listado 6 muestra cómo instalar PostgreSQL y asegurarse de que todavía se inicie en el arranque.

Listado 6. Instalación de PostgreSQL
# yum -y install postgresql-server postgresql-devel
...
Installed: postgresql-devel.i386 0:8.1.21-1.el5_5.1 
   postgresql-server.i386 0:8.1.21-1.el5_5.1
Dependency Installed: postgresql.i386 0:8.1.21-1.el5_5.1 
   postgresql-libs.i386 0:8.1.21-1.el5_5.1
Complete!
# chkconfig postgresql on

El comando yum instala paquetes de un depósito. En el Listado 7, usted instala el componente del servidor y las bibliotecas de desarrollo de PostgreSQL. De esta forma automáticamente incorpora los programas utilitarios de la base de datos central y cualquier otro paquete que necesite. Usted no necesita todavía el paquete de desarrollo, pero cuando llegue el momento de integrar Rails y PostgreSQL, necesitará las bibliotecas que se encuentran en postgresql-devel.

Por omisión, la base de datos almacena sus archivos en /var/lib/pgsql/data, que forma parte del sistema de archivos raíz. Usted translada este directorio al almacenamiento de la instancia en /mnt, tal como se observa en el Listado 7.

Listado 7. Translado del almacén de datos de PostgreSQL a /mnt
# mv /var/lib/pgsql/data /mnt
# ln -s /mnt/data /var/lib/pgsql/data
# service postgresql start

Después de ingresar los comandos en el Listado 7, PostgreSQL es ejecutado desde /mnt.

Luego, usted debe habilitar los accesos por contraseña para la base de datos payroll_prod (que usted creará en el siguiente paso). Por omisión, PostgreSQL no utiliza contraseñas: usa un sistema de identificación interno. Simplemente agregue:

host    "payroll_prod" all  127.0.0.1/32   md5

antes de /var/lib/pgsql/data/pg_hba.conf, y luego ejecute:

su - postgres -c 'pg_ctl reload'

para lograr que la modificación surja efecto. Con esta configuración, las claves comunes para PostgreSQL no requieren contraseña (motivo por el cual el comando reload no necesita contraseña), pero sí será necesario para cualquier acceso a la nómina de pagos de la base de datos.

El último paso es establecer la base de datos Rails desde la línea de comando. Ejecute su - postgres -c psql, y siga los pasos del Listado 8.

Listado 8. Creación del usuario y la base de datos
postgres=# create user payroll with password 'secret';
CREATE ROLE
postgres=# create database payroll_prod;
CREATE DATABASE
postgres=# grant all privileges on database payroll_prod to payroll;
GRANT

Y así, habrá creado la base de datos.

Migración de los datos

Para probar, debería tomar una copia de respaldo de la base de datos de su entorno de producción desde un momento determinado para tener algo que verificar. La aplicación SmallPayroll almacena tanto los datos de la base de datos como el sistema de archivos. La base de datos será copiada usando el comando pg_dump que viene con PostgreSQL; los datos del sistema de archivos utilizarán rsync. La base de datos tendrá que ser borrada y trasladada nuevamente para la migración debido a la naturaleza de las copias de seguridad de la base de datos, pero los datos del sistema de archivos sólo necesitan los archivos nuevos y modificados, porque rsync puede detectar cuando un archivo no ha sido modificado. De este modo, la parte que se está verificando del plan ayuda a acelerar la migración, ya que la mayoría de los datos ya se encontrarán allí.

La forma más rápida de copiar la base de datos es ejecutando:

pg_dump payroll_prod | gzip -c > /tmp/dbbackup.gz

en su máquina de producción, copie dbbackup.gz al servidor de la nube, y luego ejecute:

zcat dbbackup.gz | psql payroll_prod

Este comando simplemente crea una copia de seguridad comprimida de la base de datos desde el servidor, y luego repite todas las transacciones en el otro servidor.

rsync es así de simple. Desde el servidor de producción ejecute:

rsync -avz -e "ssh -i .ssh/main.pem" /var/uploads/ root@174.129.138.83:/var/uploads/

Este comando copia todo desde /var/uploads del servidor de producción actual al nuevo servidor. Si usted lo ejecuta nuevamente, sólo los archivos modificados serán copiados, ahorrándole tiempo luego en las sincronizaciones.

Dado que usted está copiando sobre la base de datos, no es necesario aplicar sus migraciones de Rails primero. Rails considerará que la base de datos está actualizada, porque usted ya ha copiado sobre la tabla schema_migrations.

Despliegue de la aplicación Rails

A esta altura, el servidor base ya ha sido configurado, pero no la aplicación. Usted debe instalar algunas gemas básicas, junto con algunas gemas que requiere su aplicación, antes de que se ejecute la aplicación. El Listado 9 muestra los comandos para actualizar las gemas. Tenga en cuenta que debe encontrarse en la raíz de su aplicación Rails, así que copie todo en su servidor primero.

Listado 9. Actualización de RubyGems e instalación de sus gemas
# gem update --system
Updating RubyGems
Nothing to update
# gem install rails mongrel mongrel-cluster postgres
Successfully installed rails-2.3.8
Building native extensions.  This could take a while...
Successfully installed gem_plugin-0.2.3
Successfully installed daemons-1.1.0
Successfully installed cgi_multipart_eof_fix-2.5.0
Successfully installed mongrel-1.1.5
Successfully installed mongrel_cluster-1.0.5
Building native extensions.  This could take a while...
Successfully installed postgres-0.7.9.2008.01.28
7 gems installed
...
# rake gems:install
(in /home/payroll)
gem install haml
Successfully installed haml-3.0.12
1 gem installed
Installing ri documentation for haml-3.0.12...
Installing RDoc documentation for haml-3.0.12...
gem install money
...

El primer comando se asegura de que RubyGems esté actualizado. El segundo comando instala algunas gemas útiles:

  • rails. La estructura de Ruby on Rails
  • postgres. El driver de la base de datos que le permite utilizar PostgreSQL con ActiveRecord
  • mongrel. Un servidor de aplicación usado para alojar la aplicación Rails
  • mongrel_cluster. Programas utilitarios que le permiten iniciar y detener grupos de mongrels al mismo tiempo

El último comando ejecuta una tarea de Rails para instalar todas las gemas adicionales que requiere la aplicación. Si usted no utilizó la orden config.gem en su archivo config/environment.rb, entonces tiene que instalar las gemas adicionales manualmente usando el comando gem install nombre de la gema.

Trate de iniciar su aplicación con el comando RAILS_ENV=production script/console . Si este comando tiene éxito, deténgalo y luego inicie el paquete de mongrels con:

mongrel_rails cluster::start -C /home/payroll/current/config/mongrel_cluster.yml

Si el primer comando no tiene éxito, recibirá varios mensajes de error para ayudarlo a localizar el problema, que por lo general se debe a la falta de una gema o de un archivo. Aproveche esta oportunidad para retroceder y colocar las órdenes config.gem que faltan de manera que no olvide otra gema en el futuro.

Instalación de un servidor front-end

Nginx es el servidor web elegido en muchos entornos virtuales. Los gastos fijos del mismo son bajos y es bueno en la autorización de conexiones a servicios back-end como mongrel. En el Listado 10 se observa cómo instalar nginx.

Listado 10. Instalación de nginx
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
...
# yum install nginx
...
Running Transaction
Installing     : nginx                                             [1/1]
Installed: nginx.i386 0:0.6.39-4.el5
Complete!
# chkconfig nginx on

En el Listado 11 se instalan los paquetes adicionales para el depósito de Enterprise Linux® (EPEL), luego se instala nginx y se verifica que aparezca al inicio.

Listado 11. Una configuración nginx para una aplicación rails
# Two mongrels, balanced based on least connections
upstream mongrel-payroll {
	fair;
	server 127.0.0.1:8100;
	server 127.0.0.1:8101;
}

server {
	listen 80;
	server_name  app.smallpayroll.ca;

	root   /home/payroll/current/public;
	gzip_static on;

	access_log  /var/log/nginx/app.smallpayroll.ca_log  main;
	error_page  404       /404.html;

	location / {
		# Because we're proxying, set some environment variables indicating this
		proxy_set_header X-Real-IP  $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_redirect false;
		proxy_max_temp_file_size 0;


		# Serve static files out of Root (eg public)
		if (-f $request_filename) {
			break;
		}

		# Handle page cached actions by looking for the appropriately named file
		if (-f $request_filename.html) {
			rewrite (.*) $1.html;
			break;
		}

		# Send all other requests to mongrel
		if (!-f $request_filename) {
			proxy_pass http://mongrel-payroll;
			break;
		}
	}
	error_page   500 502 503 504  /500.html;
	location = /500.html {
		root   /home/payroll/current/public;
	}
}

En el Listado 11 se observa una configuración bastante común de nginx con la inclusión de algunos elementos para administrar el almacenamiento de la página de Rails en la memoria caché y el envío de solicitudes dinámicas a un mongrel ascendente. Usted aquí podría asociar otras URLs a los nombres de archivos, si fuera necesario.

Con la configuración como corresponde, service nginx start inicia el servidor web.

Verificación

Para realizar la verificación, sería útil poder referirse a la instancia de la nube usando el nombre de dominio habitual de su aplicación, porque usted querrá asegurarse de que está utilizando el sitio de prueba y no el sitio de producción. Esto se logra a través de una invalidación del DNS local. En Windows, edite C:\windows\system32\drivers\etc\hosts; en UNIX, edite /etc/hosts. Agregue una línea como esta:

x.x.x.x  app.smallpayroll.ca

donde x.x.x.x es la dirección IP de su servidor de la nube y app.smallpayroll.ca es el nombre de su aplicación. Reinicie el navegador y diríjase a su sitio web. Ahora estará usando la versión de la nube de su aplicación. (¡No olvide quitar la línea que ha agregado al querer volver a la versión de producción!)

A esta altura, debería poder verificar que la versión nube de su aplicación trabaja igual de bien que la versión de producción; corrija todos los problemas que encuentre. Tome nota detallada de lo que encuentre, ya que quizá desee programarlo en caso de incorporar un segundo servidor. Dado que está utilizando la versión nube de su aplicación, usted puede borrar y restablecer su base de datos sin recibir quejas de ningún usuario.

Empaquetado de la nueva AMI

Por último, debe volver a empaquetar la AMI. Cada vez que inicie una nueva instancia, pierde todo en /mnt, y la partición raíz se resetea según el contenido de la AMI. No puede hacer nada aún para resolver el problema de /mnt pero al volver a empaquetar la AMI se asegura de que la misma quede en el mismo estado en el cual la dejó.

Si la AMI que está iniciando no tiene herramientas AMI, usted puede instalarlas con el siguiente comando:

rpm -i --nodeps http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm

El proceso de empaquetado de una AMI consiste en tres pasos:

  1. La creación de la imagen de la instancia.
  2. La carga de la imagen a Amazon S3.
  3. El registro de la AMI.

Antes de continuar, cierre su mongrel y las instancias PostgreSQL, para asegurarse simplemente de que los archivos abiertos son administrados correctamente. Debe además copiar sus claves X.509 , que se encuentran en la consola de Amazon, a /mnt que se encuentra en su servidor. El Listado 12 muestra los dos primeros pasos del proceso de empaquetado, los cuales se realizan en la misma VM.

Listado 12. Empaquetado de la AMI
# ec2-bundle-vol -d /mnt -e /mnt --privatekey /mnt/pk-mykey.pem  \
--cert /mnt/cert-mycert.pem --user 223110335193 -p centos-ertw
Please specify a value for arch [i386]:
Copying / into the image file /mnt/centos-ertw...
...
Generating digests for each part...
Digests generated.
Creating bundle manifest...
ec2-bundle-vol complete.
# ec2-upload-bundle -b ertw.com -m /mnt/centos-ertw.manifest.xml \
--secret-key MYSECRETKEY --access-key MYACCESSKEY
Creating bucket...
Uploading bundled image parts to the S3 bucket ertw.com ...
...
Uploaded centos-ertw.part.37
Uploading manifest ...
Uploaded manifest.
Bundle upload completed.

El primer comando genera el paquete, especificando que /mnt será ignorado y el paquete irá a /mnt (las opciones -e y -d, respectivamente). Las opciones -k, --cert, y --user se refieren a sus credenciales de seguridad y a la ID de usuario de AWS, las cuales se encuentran en las configuraciones de la cuenta en la consola de administración de AWS. La última opción, -p, le permite nombrar esta AMI para diferenciarla de las demás.

El primer comando será ejecutado durante 10 minutos aproximadamente, dependiendo de cuán llena esté la partición raíz. El segundo comando carga el paqueta a Amazon S3. La opción -b especifica un nombre del registro provisional, el cual será creado si es que no existe ya. La opción -m se refiere al archivo de referencia creado en el último paso. Las últimas dos opciones son las credenciales de Amazon S3, las cuales se encuentran justo al lado de sus credenciales X.509 en la consola de administración de AWS. Simplemente recuerde que las credenciales X.509 se utilizan para las operaciones de Amazon EC2, mientras que Amazon S3 usa claves de texto.

Finalmente, ejecute el comando:

ec2-register ertw.com/centos-ertw.manifest.xml

para registrar la AMI, y verá el identificador de la AMI que utilizará de aquí en adelante. Tenga en cuenta que el comando ec2-register no se distribuye junto con la AMI, así que es más fácil ejecutarlo desde el servidor en el que inició la AMI original. Debería poder instalar además las herramientas de Amazon EC2 en su instancia de Amazon EC2.


Realización de la migración

Ahora que su entorno nube se está ejecutando, la migración debería ser bastante sencilla. Ha verificado que todo funciona: sólo queda volver a sincronizar los datos y transferirlos correctamente.

Tareas previas a la migración

Poco antes de la migración, asegúrese de bajar el TTL de los registros de nombre de dominio a 5 minutos. Debería además desarrollar un listado para verificar los pasos a seguir para poder avanzar, las pruebas que desea realizar para verificar que todo funciona, si fuerea necesario, el procedimiento para deshacer el cambio.

¡Asegúrese de que los usuarios sean notificados sobre la migración!

Justo antes del momento de la migración vuelva a observar el entorno de la nube para asegurarse de que está listo para la sincronización y para aceptar el tráfico de producción.

Migración de la aplicación

Para migrar la aplicación siga los siguientes pasos:

  1. Deshabilite el sitio de producción actual o colóquelo en modo de sólo lectura, dependiendo de la naturaleza del sitio.

    Ya que la mayoría de las solicitudes de SmallPayroll requieren la escritura en la base de datos o en el sistema de archivos, el sitio estará inhabilitado. La gema del despliegue de Capistrano incluye una tarea, cap deploy:web:disable, que coloca una página de mantenimiento en el sitio informando a los usuarios que el sitio se encuentra en mantenimiento.

  2. Detenga los servicios de la aplicación en el entorno nube para prepararse para la migración de los datos terminando con los procesos mongrel.
  3. Copie la base de datos de la misma forma en la cual lo hizo en las pruebas.
  4. Vuelva a ejecutar rsync, si fuera necesario.
  5. Reinicie los servidores de la aplicación con el comando:
    mongrel_rails cluster::start -C /home/payroll/current/config/mongrel_cluster.yml
  6. Asegúrese de que el archivo host está indicando el entorno nube, y realice algunas pruebas de humo. Asegúrese de que los usuarios puedan conectarse al sitio y navegar.

Actualización del DNS

Si la prueba de humo es positiva, entonces puede cambiar sus registros DNS para señalar el entorno de nube. A esta altura, me parece útil dejar un tail -f ejecutándose en el archivo de registro del servidor web para esperar a que la gente entre al sitio.

Hay probabilidades de que su servidor DNS local todavía contenga la información anterior guardada en la memoria caché durante los siguientes 5 minutos. Usted puede verificar esto con el comando dig, tal como se puede ver en el Listado 13.

Listado 13. Verificación de que el servidor DNS está guardando la consulta en la memoria caché
# dig  app.smallpayroll.ca @172.16.0.23

; <<>> DiG 9.3.4 <<>> app.smallpayroll.ca @172.16.0.23
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38838
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;app.smallpayroll.ca.           IN      A

;; ANSWER SECTION:
app.smallpayroll.ca.    251     IN      A       69.164.205.185
...

En la sección ANSWER, usted puede observar que cuenta con 251 segundos hasta que la entrada expire. Es importante que utilice una herramienta como dig, host, o nslookup para verificar el DNS, ya que su archivo hosts está anulando el DNS por el momento. El uso de ping implicará el uso de todo lo que se encuentra dentro de los hosts.

Realice la prueba final de aceptación mientras espera que el DNS se propague.


Conclusión

¡Ha logrado migrar una aplicación a la nube con éxito! El proceso básicamente fue el siguiente:

  1. Configuración del nuevo entorno.
  2. Prueba con una copia de los datos de producción.
  3. Desactivación el viejo entorno.
  4. Copia de los datos de producción en el nuevo entorno.
  5. Modificación del DNS para que señale al nuevo entorno.

A pesar de estar ahora "en la nube," la aplicación probablemente esté peor que antes. Analice los siguientes puntos:

  • La aplicación se encuentra todavía ejecutándose en un servidor.
  • Si el servidor se interrumpe, todos los datos se pierden.
  • Tiene menor control sobre la performance que el que tendría sobre un servidor físico.
  • La máquina y la aplicación no se encuentran bloqueadas.

En el próximo artículo, aprenderá a superar estos problemas y comenzará a crear un entorno más sólido para su aplicación.

Recursos

Aprender

Obtener los productos y tecnologías

  • Ruby Enterprise Edition es una implementación Ruby de alta performance que puede utilizarse sola o junto con Phusion Passenger para incorporarse a Apache o nginx. De cualquier modo, usted accede a la administración veloz de la memoria y a una recolección mejorada de la basura.
  • Regístrese en IBM Industry Application Platform AMI for Development Use para enterarse de la gran variedad de productos de IBM en la nube. Recuerde que tiene que pasar por el proceso de registro de salida, pero no se le cobrará nada que no haya usado. Usted puede además utilizar ami-90ed0ff9.
  • Las Amazon EC2 API tools se utilizan para comunicarse con Amazon API para abrir y cerrar instancias y para reempaquetar las nuevas. Estas herramientas son actualizadas regularmente a medida que aparecen nuevas características en Amazon EC2, así que vale la pena volver a esta página para buscar las actualizaciones en los anuncios de los productos. Necesitará al menos la actualización del 15-5-2009, porque utilizará algunas de las características de balanceo de carga más adelante.
  • Evaluate IBM products en la forma que mejor le convenga: descarga de versiones de prueba de productos, pruebas de productos en línea, uso de productos en entornos de nube, o pase algunas horas en la SOA Sandbox aprendiendo cómo implementar de manera eficaz la arquitectura orientada al servicio.

Comentar

  • Participe en la My developerWorks community. Conéctese con otros usuarios de developerWorks mientras explora los blogs administrados por los desarrolladores, los foros, los grupos y los wikis.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux, Cloud computing, WebSphere
ArticleID=549060
ArticleTitle=Migre su aplicación Linux a la nube de Amazon, Parte 1: Migración inicial
publish-date=07132010