Interesante presentación donde nos muestran todas las posibilidades de AWS S3
Interesante presentación donde nos muestran todas las posibilidades de AWS S3
Si alguna vez necesitáis hacer una redirección de un dominio que no tenga un hosting ya creado lo podéis hacer con Amazon S3 fácilmente. Para este ejemplo voy a redireccionar el subdominio aws.rastreador.com.es a la categoría aws de este blog.
Lo primero es crear un bucket en S3 con el nombre del dominio o subdominio, este detalle es importante, no vale cualquier bucket, tiene que tener el mismo nombre del dominio que se va a redireccionar, en este caso aws.rastreador.com.es
Una vez creado el bucket vamos a propiedades y seleccionamos la opción de Static Website Hosting. Una vez ahí seleccionamos la tercera opción Redirect all requests to another host name e introducimos la url a la que queremos que se haga la redirección.
Finalmente sólo nos queda generar un registro cname en nuestro DNS que apunte al endpoint que he señalado en rojo en la imagen anterior.
Y con esto ya hemos terminado la redirección, para comprobarlo sólo hay que hacer un curl -I aws.rastreador.com.es y vemos que hace una redirección 301 a la url que le hemos indicado.
Para eliminar la limitación de envío de emails de Amazon Web Service sólo tenemos que ir a la url:
https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request
En esta misma pantalla también podemos solicitar al mismo tiempo la resolución inversa de dns asignando un nombre de host a la ip elástica que hemos asignado a esa instancia. Es muy recomendable hacer este paso para evitar problemas de spam.
A veces puede ser muy útil asignar a un bucket o a unos ficheros en concreto dentro de un bucket una fecha de caducidad para tener controlado el espacio ocupado, especialmente si hablamos de backups o similar.
Desde la consola web de Amazon S3 se puede asignar esa caducidad muy fácilmente seleccionando el bucket sobre el que queremos trabajar -> propiedades y seleccionando la pestaña lifecycle.
Como podéis ver el funcionamiento es muy intuitivo. Se pulsa en «Add rule» y sencillamente indicamos si lo queremos activo, el nombre de la regla (opcional), el prefijo y la caducidad en días. El dato del prefijo es importante ya que indica sobre qué contenidos se va a aplicar esta regla, si no se indica nada, como en el ejemplo, se aplicará sobre todos los objetos del bucket. Si quisieramos que se aplicara sólo sobre los que están en la carpeta backup se pondría «backup/», tened cuidado si no ponéis el slash «/» por que si tuvierais algún fichero que contuviera la palabra backup tambien se le aplicaría la regla, p.e.: backup_fotos_importantisimas.zip.
El borrado es diario y totalmente automático así que una vez grabadas las reglas nos podemos olvidar completamente de ese tema.
Si queréis profundizar un poco más en este tema os recomiendo leer la documentación de Amazon: http://docs.amazonwebservices.com/AmazonS3/latest/dev/ObjectExpiration.html
Esta semana he tenido que migrar un servidor con plesk de un hosting normal (OVH en este caso) a una instancia de Amazon EC2.
Para la instalación inicialmente utilice una AMI de centos 6.2 y la última versión de plesk (10.4.4). Hice la migración del servidor antiguo al nuevo con la herramienta de migraciones del plesk y, con la excepción de unos errores sin importancia de la migración, parecía que todo estaba bien.
Normalmente suelo probar los dominios migrados modificando el fichero hosts de mi equipo antes de modificar las dns, por si algo no ha funcionado correctamente. En este caso fue muy buena idea ya que cuando accedías al dominio se veía la página por defecto de plesk, la del servidor, no la del dominio.
Evidentemente eso sonaba a que apache no tenía bien configurados los virtualhosts pero por más que miraba me daba la impresión de que todo era correcto.
Después de mucho probar y revolver, incluida una reinstalación completa de otra instancia y otra migración, esta vez con ubuntu server por si había algún problema con centos, di con la solución: el problema está en las ips del servidor y en como configura plesk los virtualhost.
Cuando se crea una instancia en Amazon se le asigna automáticamente una dirección ip privada del tipo 10.x.x.x y después tu le tienes que asignar una ip pública (elastic ip).
Cuando configuras las ips en plesk tienes que añadir a mano la ip pública al servidor y poner como compartida tanto la pública como la privada (10.x.x.x). En mi caso lo que estaba haciendo mal era que durante la migración seleccionaba como ip destino de la migración la pública y lo que debería de hacer era seleccionar la ip privada para que la configuración del virtualhost llevara esa ip. Debería de quedar algo así:
En vez de la fórmula habitual
Si ya has realizado la migración y no puedes/quieres volver a hacerla tienes dos opciones, o cambias a mano todas las ips o ejecutas un script como este para que lo haga por ti.
mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -Ns -e «select name from domains;» | awk ‘{print «/usr/local/psa/bin/domain –update «$1″ -ip IP_PRIVADA_DE_AMAZON»}’ | sh
por su puesto que a mi me gusta mucho más la opción del script. =;-)
Tened en cuenta que si alguna vez paráis la instancia cuando la volváis a encender casi seguro que os habrá cambiado la ip privada y tendréis que volver a realizar todo este proceso. Es un problema que plesk no ha tenido en cuenta y que espero que solucione en próximas actualizaciones.
Otra de las incidencias que tuvimos en esta migración es que por alguna extraña razón el apache no hacía caso de la directiva DirectoryIndex y cogía siempre como fichero por defecto el index.html en vez del index.php, así que decisión salomónica: fuera todos los index.html,
mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -Ns -e «select name from domains;» | awk ‘{print «rm /var/www/vhosts/»$1″/httpdocs/index.html»}’ | sh
Si utilizáis ubuntu server para la instalación lo mejor es que desinstaléis apparmor antes de empezar la instalación y si preferís dejarlo o no os acordáis hay que añadir a su fichero de configuración la siguiente línea para que bind os funcione correctamente.
vim /etc/apparmor.d/usr.sbin.named
y añadir
/var/named/run-root/** rw,
al final del fichero
Aunque no tiene nada que ver con Amazon si quieres cambiar el idioma del panel de control y la licencia que has contratado no lo permite lo puedes hacer directamente modificando un par de valores en mysql:
mysql -uadmin -p`cat /etc/psa/.psa.shadow`
use psa
update misc set val=’es-ES’ where param=’def_locale’;
update misc set val=’es-ES’ where param=’admin_locale’;
Si se me ocurre algún otro truco, o conocéis algún otro truco interesante, decídmelo y lo añadiré aquí para tener como referencia futura.
Prestashop es uno de los CMS de comercio electrónico que más auge está teniendo últimamente. La documentación es bastante buena pero hay algunas cosas que sólo tratan de pasada y creo que son muy importantes para mejorar el funcionamiento de Prestashop.
Concretamente os quería enseñar la forma de mejorar el rendimiento de prestashop utilizando Amazon CloudFront para servir contenidos estáticos.
Amazon CloudFront es el servicio de Amazon AWS que permite distribuir contenidos más rápido y con menor latencia que si lo hicieras desde tu propio servidor. Amazon CloudFront tiene distribuidos a través del mundo varios puntos de salida de forma que entrega los archivos al usuario desde el punto más cercano a su ubicación. Otra ventaja de Amazon CloudFront es que liberas a tu servidor de la entrega de esos ficheros con lo que consigues liberar recursos que podrás utilizar para otras cosas.
Para crear tu distribución lo único que tienes que hacer es ir a tu consola de Amazon y en la pestaña de CloudFront pulsar en «Create Distribution».
Debes de seleccionar la opción de Custom Origin y en Origin DNS Name poner la página de tu tienda
En la siguiente pantalla debes de indicar un subdominio del dominio de tu tienda, aunque no es obligatorio. En mi caso lo suelo poner siempre por estética ya que si no cuando carga la página los clientes podrían ver que se cargan contenidos de otros sitios con nombres tan extraños como dlskfhxxxis3dhflk23shf.cloudfront.net. En el ejemplo he utilizado ccc1.mitiendac.com
En el último paso podréis ver como queda la distribución que acabáis de crear.
Una vez creada la distribución podréis ver en el panel de control que hay una nueva distribución y que su estado es «InProgress». En mi caso permaneció en ese estado unos 10 minutos hasta que pasó al estado «Deployed» que es cuando ya se puedo empezar a utilizar.
En esta imagen tenéis un ejemplo de como quedaría.
Si habéis decidido utilizar un subdominio de vuestra tienda, mientras que finaliza la creación, podeís ir al servidor dns de vuestro dominio y añadir el subdominio a los dns. Para ello hay que crear una entrada cname con el nombre ccc1.mitienda.com. que apunte al nombre de la distribución que acabamos de crear, por ejemplo xxxxxxxx.cloudfront.net
El último paso es ir al administrador de prestashop y configurar el apartado de CCC (). Para eso hay que ir a Preferencias -> Rendimiento. y activar CCC. añadiendo la distribución. Si habéis utilizado el subdominio hay que poner ccc1.mitienda.com y si no, introducir directamente la distribución, p.e. xxxxxxxx.cloudfront.net en el apartado Servidores de media.
Como veis en la imagen se pueden añadir hasta 3 servidores de media. Para poner otros dos sólo hay que repetir lo anterior otras dos veces.
Por último os quería comentar algo sobre el coste de este servicio pero es difícil ya que es muy variable por que se factura en función del uso así que lo mejor es que vosotros mismos echéis mano de la calculadora y revisando los precios de la página de amazon lo calculéis o que utilicéis la calculadora de Amazon.
Si no os aclaráis con los precios lo que os recomiendo es que lo hagáis y que diariamente reviséis lo que lleváis gastado. Probablemente con el gasto de un par de días «normales» os será mas que suficiente para poder calcular el coste mensual.
s3cmd es una pequeña aplicación que sirve para interactuar con el servicio de almacenamiento de Amazon, S3. Hace un tiempo ya os había contado cómo realizar backups con s3cmd.
Si utilizas ubuntu o debian, s3cmd está en los repositorios oficiales, pero una versión bastante antigua con muchos fallos. En mi caso el fallo que más me estaba afectando es cuando se se producía timeout hacía que la aplicación se cerrara sin finalizar las tareas, cosa que últimamente se estaba convirtiendo un algo demasiado habitual.
Por suerte el desarrollador de la aplicación ha creado un repositorio donde mantiene actualizadas las versiones estables para debian 5 y 6 y ubuntu 10.04 LTS y superiores. Para actualizar sólo hay que ejecutar los siguientes comandos.
wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | sudo apt-key add - sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.list sudo apt-get update && sudo apt-get install s3cmd |
Fuente: s3tools.org
Antes de empezar 2 conceptos sobre Amazon Web Sevices (aws):
Instancia: es el equivalente a un servidor
Grupo de seguridad: reglas predeterminadas de un firewall
Durante el proceso de creación de una instancia en Amazon EC2 uno de los pasos es asignarle un grupo de seguridad.
Lo normal es dejar abiertos sólo aquellos puertos que realmente necesitas para minimizar los riesgos de accesos y ataques no deseados.
Yo tengo predefinidos tres grupos, uno super básico con sólo el puerto 80, 443 (los usados por las páginas web) y el 22 (ssh), otro más abierto con mas puertos para otro tipo de servidor y el «vivalavirgen» con todo abierto, que en principio no debería de utilizarse para nada excepto algunas pruebas.
En mi caso el problema surgió al crear una nueva instancia para un servidor que tiene servicios en puertos que hasta ahora no había utilizado y sin darme cuenta le asigné un grupo de seguridad que no tenía esos puertos contemplados.
Evidentemente al intentar acceder a esos servicios no podía,así que intenté cambiar el grupo de seguridad de esa instancia pero me llevé una buena sorpresa al comprobar que no era posible por el tipo de servidor que había seleccionado.
La única solución que encontré fue ir al menú de la instancia y seleccionar la opción «Launch more like this» y en el proceso de creación de la nueva instancia asignarle el grupo correcto. Es una forma de hacer esto un poco «de andar por casa» pero funciona y soluciona la papeleta al que lo necesite.
Amazon S3 es un servicio de almacenamiento masivo de información con unos costes bastante aceptables. Para poder manejarlo hay varias herramientas pero para mi la más cómoda es s3cmd, un sencillo programa en línea de comandos que nos permite manejar nuestra cuenta en S3.
Lo primero es instalarlo, desde debian o ubuntu con un simple
[shell]apt-get install s3cmd[/shell]
lo tenemos listo y si no podéis ir a http://s3tools.org/download y descargarlo desde allí.
Inmediatamente deberíamos configurarlo, para ello hay que ejecutarlo con el parámetro –configure
s3cmd –configure
Lo primero que nos va a pedir el «Access Key» y el «Secret Key» de nuestra cuenta de Amazon. Para obtenerlos debemos ir a la página de Amazon, menú «cuenta» -> «Credenciales de Seguridad»
Después nos pedirá una clave que se utilizará para cifrar todo lo que se suba a Amazon y algunos datos más como la ruta del gpg y datos si estuvieramos detrás de un firewall. Al final del proceso nos crea un fichero .s3cfg en nuestro directorio de usuario.
Los comandos de s3cmd son:
Los comandos básicos con ficheros son put para subir todo el contenido al bucket, get para descargarlo y sync para sincronizar los contenidos.
P.E.:
[shell]s3cmd sync –delete-remove –recursive /mi-directorio/datos/ s3://BUCKET/datos-de-mi-directorio/[/shell]