Si están apurados y solo necesitan una receta, vayan directamente a la parte práctica del articulo, pero quiero comentar un poco mi experiencia ya que puede que solo estén decidiendo si Platform es para ustedes.

Yo llegué a probar Platform por que un amigo necesitaba un sitio, y yo prefería mantenerlo fuera de mi server personal. Pero tampoco quería mantener un server para el, hacer actualizaciones de seguridad, etc...

Así que empecé a pensar en opciones para sitios chicos:

• Acquia: USD 134 por mes
• Pantheon: USD 25 por mes (bastante limitado en tráfico), siguiente opción USD 100
• Platform: USD 50 por mes (buen balance de recursos/costo sin limitación de tráfico)
• Aberdeen Cloud: USD 49 por mes
• Red Hat Openshift: USD 20 por mes

La lista no es pareja en termino de lo que los proveedores ofrecen, pero los he usado a casi todos antes para diferentes proyectos. El único que me quedaba probar era Platform.

Viendo cada uno un poco mas en detalle:

• Dejé RH Openshift de lado por que le faltan servicios, adicionales. En mi experiencia Drupal funciona lento sin caché, y las opciones dentro de RH OpenShift o combinarlo con otras cosas complicaba a la solución.
• Aberdeen: Lo he usado, funciona bien, pero está muy enfocado en Europa.
• Acquia es fácil de usar y había una opción de dentro de los costos, pero estaba por encima de todas las otras opciones.
• Pantheon: Lo he usado y me gusta, pero el esquema de precios era arriesgado. La opción de 25USD tenía limitaciones de tráfico, y el riesgo de tener que pasar a la opción de 100USD era probable.

He estado escuchando cosas muy buenas de Platform, y la comparación de precios y prestaciones es buena. Como soy propenso a probar cosas, terminé inclinándome por intentar usarlo.

La Experiencia

Platform no tiene una opción gratis, la única forma de usarlo/probarlo es pagar por un sitio. Esto hizo que la experiencia fuera algo así como un salto al vacío. Incluso tuve un par de momentos difíciles tratando de hacerlo andar y poner el sitio en linea, lo que me hizo pensar que quizás no era la mejor opción. Debo decir que estoy mas acostumbrado a soluciones orientadas a resolver las cosas lo mas sencillo posible, Platform esta orientado a programadores y configuración por archivos. En cualquier caso una vez que uno entiende la lógica y aprende los detalles de implementación, las cosas funcionan y uno gana mas de lo que pierde. No tener que hacer el mantenimiento del sitio y poder evitar cobrar por el es una gran cosa y permite enfocarnos solo en Drupal. Ellos proveen mucha documentación, pero no pude hacer el sitio solo con eso. Gracias a que el soporte es muy bueno, y los tiempos de respuestas son razonables, logré sacarlo andando.

Debo decir que la plataforma me hace mucho acordar a RH Openshift. El precio es un poco mas alto, pero el servicio final es mejor para Drupal. Tener los servicios de búsqueda Solr, Redis cache y la solución de caché para navegación anónima mejora (y mucho) el rendimiento de un sitio Drupal. Lo que lo transforma en una solución PaaS mas que en un servicio de hosting de aplicaciones. Debo decir que solo he corrido sitios Drupal de desarrollo RH Openshift, pero en base a mi experiencia no me arriesgaría a correr Drupal sin una solución de caché adecuada.

Debo decir que me son mas familiares las soluciones de Acquia o Pantheon, y me molestó un poco el tiempo que debemos esperar luego de cada git push... Esto es por que cada vez que uno hace push la aplicación debe ser empacada, configurada y puesta en linea. Y terminamos teniendo una demora entre que uno hace el cambio y lo ve en producción. Esto también pasa en las otras plataformas, pero me pareció mas lento en Platform. Para mi es un producto pensado para programadores que usen un ambiente local.

En general la experiencia fue positiva, pero me llevo mas de lo que esperaba. Definitivamente no la recomendaría para gente buscando algo fácil de usar.

Todavía no puse el sitio en producción, así que me falta ver cuan bien ande. Teniendo en cuenta que entre otros servicios proveen caché, dudo que tenga problemas de rendimiento/velocidad.

La receta

Creo que si uno no tiene nada y sigue 100% el procedimiento de Platform, puede ser mas sencillo el proceso... Pero como tenía experiencia previa decidí armar el sitio en mi ambiente local primero y luego subirlo a Platform. Cuan dificil puede ser no? Bueno, not tanto... Pero tiene sus idiosincrasias.

Estos son los pasos a seguir si queremos llevar nuestro sitio local Drupal 7 a Platform:

1. Lo primero que debemos hacer es agregar nuestra key y crear un GIT repo (o subir nuestro repositorio actual). Hay mas sobre el repositorio en los pasos finales, pero debemos agregar nuestra key a Platform.sh como primer paso para poder usar GIT, SSH, etc...
2. Luego debemos escribir nuestro archivo ".platform.app.yaml", acá tienen un ejemplo:

   
   name: drupal
   type: php:5.6
   build:
       flavor: drupal
   relationships:
       database: "database:mysql"
       solr: "search:solr"
       redis: "cache:redis"
   web:
       document_root: "/"
       passthru: "/index.php"
       whitelist:
         # robots.txt.
         - /robots\.txt$    
         # CSS and Javascript.
         - \.css$
         - \.js$
         # image/* types.
         - \.gif$
         - \.jpe?g$
         - \.png$
         - \.ico$
         - \.bmp$
         # fonts types.
         - \.ttf$  
   disk: 2048
   mounts:
       "/public/sites/default/files": "shared:files/files"
       "/tmp": "shared:files/tmp"
       "/private": "shared:files/private"
   hooks:
       # We run deploy hook after your application has been deployed and started.
       deploy: |
           cd public
           drush -y updatedb
   crons:
       drupal:
           spec: "*/20 * * * *"
           cmd: "cd public ; drush core-cron"
       

3. Ahora debemos agregar el servicio de MySQL (entre otros) para nuestra aplicación. Para esto debemos agregar otro archivo a nuestro repositorio: ".platform/services.yaml":

   
   database:
     type: mysql:5.5
     disk: 512
   
   search:
       type: solr:4.10
       disk: 512
   
   cache:
       type: redis:2.8
       

   Esta es una de las ventajas de usar Platform.sh, por el mismo costo tenemos SOLR+Redis para que nuestro sitio. Si van a usar la función de búsqueda de Drupal, SOLR es un gran aliado. Y si se toman el trabajo de configurar Drupal para que use Redis, el tiempo de crear las páginas de usuarios registrados (no anónimos) mejorará mucho. Este servicio es muy similar a Memcache, cumplen la misma función.

4. También debemos agregar nuestro dominio a la configuración de la aplicación, esto lo hacemos agregando el archivo ".platform/routes.yaml":

   
   "http://www.{default}/":
       type: upstream
       upstream: "drupal:php"
   
   "http://{default}/":
       type: redirect
       to: "http://www.{default}/"
       

5. Ahora debemos configurar Drupal para que use el servicio de base de datos de Platform. Esto lo hacemos cambiando nuestro settings.php, Platform toma nuestro archivo y automáticamente crea el archivo "settings.local.php" que nos conectará con la base de datos. Así que reemplacemos nuestro "settings.php" con:

   
   <?php
   $update_free_access = FALSE;
   
   $local_settings = dirname(__FILE__) . '/settings.local.php';
   if (file_exists($local_settings)) {
     require_once($local_settings);
   }
       

6. Y estamos listos para empezar a copiar archivos. Comenzaremos por hacer una copia de la base de datos . Hay otras formas de hacerlo, pero yo lo voy a explicar usando un conexión SSH:

   
   scp mysitesdb.dump.gz [PROJECT-ID]-[ENV]@ssh.[REGION].platform.sh:/app/tmp
   ssh [PROJECT-ID]-[ENV]@ssh.[REGION].platform.sh
   zcat tmp/mysitesdb.dump.gz | mysql -h database.internal main
   rm tmp/mysitesdb.dump.gz
       

7. Para llevar nuestro código al repositorio git de Platform debemos hacer en nuestro repositorio local:

   
   cd mysite/code
   git init
   git remote add platform [PROJECT-ID]@git.[REGION].platform.sh:[PROJECT-ID].git
   git add --all
   git commit -m "Initial commit of My Project"
   git push
       

   Es importante saber que cada vez que hacemos un "git push" Platform empaca, configura, y distribuye nuestra aplicación. Así que por cada "git push" deberemos esperar un poco mas de lo que estamos acostumbrados.

8. Para importar nuestro archivos podermos usar rsync:

   
   rsync -r my/local/files/. [PROJECT-ID]-[ENV]@ssh.[REGION].platform.sh:public/sites/default/files/
       

9. Y finalmente debemos reconstruir la "registry" del sitio:

   
   ssh [PROJECT-ID]-[ENV]@ssh.[REGION].platform.sh
   drush dl registry_rebuild --destination=/app/tmp
   sed -i 's/, define_drupal_root()/, '"'"'\/app\/public'"'"'/' /app/tmp/registry_rebuild/registry_rebuild.php
   cd /app/public
   php ../tmp/registry_rebuild/registry_rebuild.php
       

Siguiendo estos pasos logré finalmente llevar mi copia local del sitio a Platform. Si usamos Drupal 8 el proceso es muy similar, pero podemos evitar el último paso que limpia la registry. Lo intenté y recuerdo que también pude evitar el settings.php que tuve que crear para Drupal 7.

Los problemas con que yo me encontré fueron no darme cuenta que necesitaba agregar a la sección de "whitelist" los archivos CSS, JS, images y otros. Tampoco me dí cuenta que debía crear el setting.php a medida para Drupal 7. Llevó un poco de tiempo, pero en ambas ocaciones el soporte me ayudo a darme cuenta que faltaba.

Hay mucha documentación, pero si llegaron a mi articulo supongo que el que mas les interese sea "Getting started for the impatient", por supuesto está en inglés. No pudo resolver mis problemas, pero es un muy buen resumen del proceso.

Cuando me encontré con los problemas que mencioné no encontré muchas experiencias previas, solo los documentos de Platform y el soporte. Así que espero que esto ayude a alguién mas.