¡La versión 2.0 de Play ya está lista! Ayúdanos a traducir la documentación de la útlima versión y sigue nuestro progreso.

Manuales, tutoriales & referencias

Consulte

Contenidos

Elija la versión

Buscar

Busque con google

Libros

Poniendo su aplicación en producción

Aquí le damos algunos consejos para optimizar su aplicación para que corra en un ambiente productivo.

application.conf

Antes que nada, la mejor forma de configurar la aplicación para modo productivo es dar un ID específico para el framework de producción. Tomemos production como un ejemplo. Visite administración del archivo application.conf en diferentes ambientes para ver cómo puede hacerlo.

Configure el framework en modo de producción

%production.application.mode=prod

En este modo, el framework pre-compilará todos los archivos fuente java y las plantillas. Si un error es encontrado en este paso, la aplicación no iniciará. Además, los cambios en los archivos fuente no serán recompilados automáticamente como ocure en modo desarrollo, sino que tendrá que reiniciar el framework para tomar los cambios hechos al código fuente.

Defina una base de datos real

Si usó una base de datos de desarrollo (ya sea db=mem o db=fs), debería configurar un motor de base de datos más robusto:

%production.db.url=jdbc:mysql://localhost/prod
%production.db.driver=com.mysql.jdbc.Driver
%production.db.user=root
%production.db.pass=1515312

Deshabilite la actualización automática del esquema en JPA

Si usó la actualización automática del esquema de base de datos que proveé Hibernate, debe deshabilitar esta característica en el ambiente de producción.

En el servidor de producción, generalmente es mala idea dejar que Hibernate ejecute automáticamente ALTER’s en la base de datos, tanto en el esquema como en los datos…

El despliegue inicial puede ser es una excepción. Si desea que Hibernate genere una base de datos límpia en el ambiente productivo tan sólo especifique:

%production.jpa.ddl=create

Defina una clave secreta segura

La clave secreta de Play es usada por las funciones criptográficas, como la firma de la sesión. Su aplicación debe conservar esta clave muy bien guardada.

%production.application.secret=c12d1c59af499d20f4955d07255ed8ea333

Puede usar el comando play secret para generar una nueva clave aleatoria segura (por lo menos en un Sistema Operativo ‘de verdad’). Si tiene pensado distribuir la aplicación en muchos servidores recuerde que debes usar la misma clave para todas las instancinas de la aplicación.

Configuración del Log de auditoría

Para el ambiente productivo, es una buena idea usar archivos de log continuos. No direccione el log a la consola, ya que esta salida será dirigida al archivo logs/system.out y crecerá sin límite.

Cree un archivo log4j.properties personalizado en el directorio conf/:

log4j.rootLogger=ERROR, Rolling
 
log4j.logger.play=INFO
 
# Archivos continuos
log4j.appender.Rolling=org.apache.log4j.RollingFileAppender
log4j.appender.Rolling.File=application.log
log4j.appender.Rolling.MaxFileSize=1MB
log4j.appender.Rolling.MaxBackupIndex=100
log4j.appender.Rolling.layout=org.apache.log4j.PatternLayout
log4j.appender.Rolling.layout.ConversionPattern=%d{ABSOLUTE} %-5p ~ %m%n

Servidor HTTP frontal

Puede poner en producción fácilmente su aplicación como un servidor independiente configurando el puerto HTTP 80:

%production.http.port=80

Pero si planea desplegar distintas aplicaciones en el mismo servidor o balancear la carga de distintas instancias de la aplicacion para mayor escalabilidad y tolerancia a errores, entonces puedes usar un servidor HTTP frontal.

Nota: Un servidor HTTP frontal nunca le dará mejor desempeño que usando el servidor HTTP de Play directamente

Configuración de lighttpd

Este ejemplo muestra cómo configurar lighttpd como servidor web frontal. Tenga en cuenta que puede hacer lo mismo con Apache, pero si sólo necesita alojamiento virtual o balanceo de cargas, lighttpd es una muy buena elección y mucho más fácil de configurar.

En el archivo /etc/lighttpd/lighttpd.conf debería definir parámetros como los siguientes:

server.modules = (
      "mod_access",
      "mod_proxy",
      "mod_accesslog" 
)
…
$HTTP["host"] =~ "www.myapp.com" {
    proxy.balance = "round-robin" proxy.server = ( "/" =>
        ( ( "host" => "127.0.0.1", "port" => 9000 ) ) )
}
 
$HTTP["host"] =~ "www.loadbalancedapp.com" {
    proxy.balance = "round-robin" proxy.server = ( "/" => ( 
          ( "host" => "127.0.0.1", "port" => 9000 ), 
          ( "host" => "127.0.0.1", "port" => 9001 ) ) 
    )
}

Configuración de Apache

El siguiente ejemplo muestra una configuración simple usando el servidor httpd de Apache como servidor frontal de una configuración de Play estándar.

LoadModule proxy_module modules/mod_proxy.so
…
<VirtualHost *:80>
  ProxyPreserveHost On
  ServerName www.loadbalancedapp.com
  ProxyPass / http://127.0.0.1:9000/
  ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>

Apache como proxy frontal que permite actualizar de manera transparente su aplicación

La idea básica es correr dos instancias de Play dentro de la aplicación web y de manera que el proxy frontal pueda balancear la carga entre ellos. En caso de que alguno no esté disponible, todas las solicitudes HTTP serán dirigidas a la instancia disponible.

Ahora iniciemos la misma aplicación de Play dos veces, una en el puerto 9999 y otra en el puerto 9998.

Haga una copia de la aplicación y edite el archivo application.conf dentro del directorio conf para cambiar los números de puerto.

Para cada directorio de la aplicación web:

play start mysuperwebapp

Ahora vamos a examinar la configuración de nuestro servidor web de Apache para tener un balanceador de carga:

En Apache, debe tener la siguiente configuración:

<VirtualHost mysuperwebapp.com:80>
  ServerName mysuperwebapp.com
  <Location /balancer-manager>
    SetHandler balancer-manager
    Order Deny,Allow
    Deny from all
    Allow from .mysuperwebapp.com
  </Location>
  <Proxy balancer://mycluster>
    BalancerMember http://localhost:9999
    BalancerMember http://localhost:9998 status=+H
  </Proxy>
  <Proxy *>
    Order Allow,Deny
    Allow From All
  </Proxy>
  ProxyPreserveHost On
  ProxyPass /balancer-manager !
  ProxyPass / balancer://mycluster/
  ProxyPassReverse / http://localhost:9999/
  ProxyPassReverse / http://localhost:9998/
</VirtualHost>

La parte importante es balancer://mycluster. Esto define un balanceador de carga. El parámetro +H significa que la segunda aplicación de Play está en modo de espera, pero también puede configurarlo para balanceo de cargas.

Cada vez que quiera actualizar mysuperwebapp, esto es lo que necesita hacer:

play stop mysuperwebapp1

El balanceador de cargas dirige todo el tráfico a mysuperwebapp2 mientras actualizas mysuperwebapp1. Una vez que estés listo:

play start mysuperwebapp1

Ahora puedes actualizar mysuperwebapp2 con seguridad.

Apache además provee una forma de ver el estado de su cluster. Simplemente dirija su navegador a /balancer-manager para ver el estado actual de su cluster.

Dado que Play usa un modelo sin estado no necesita administrar las sesiones entre las aplicaciones. Así puede fácilmente esclar mas de dos instancias de Play.

Configuración avanzada del proxy

Cuando usa un servidor frontal HTTP las direcciones del request son vistas como vienen del servidor HTTP. En una configuración usual donde tiene aplicaciones de Play y el proxy corriendo en la misma máquina, la aplicación de Play ve los request que vienen de 127.0.0.1.

Los servidores proxy también pueden agregar un encabezado HTTP específico al request para decirle a la aplicación que ha pasado a través del proxy de dónde vino el request. La mayoría de los servidores web van a agregar un encabezado X-Forwarded-For con la dirección IP del cliente remoto en el primer argumento. Si habilita la opción de direccionamiento en Configuración de XForwardedSupport, Play cambiará el parámetro request.remoteAddress de la dirección IP del proxy a la dirección IP del cliente remoto. Para que funcione esta opción, debe listar las direcciones IP de sus servidores proxy.

Sin embargo, el encabezado del host permanece intacto, sigue estando configurado por el proxy. Si usas Apach 2.x puedes agregar esta directiva de la siguiente forma:

ProxyPreserveHost on

El encabezado host será el mismo encabezado que mandó el cliente. Combinando estas dos técnicas, tu aplicación se comportará como si estuviera directamente expuesta en internet.

Configuración HTTPS

El servidor HTTP interno provisto por Play soporta el protocolo HTTPS, que también puede ser utilizado en producción. Trae soporte para administración de certificados ya sea de la forma clásica de Java keystore o simplemente configurando los archivos cert y key. Para iniciar el conector HTTPS para su aplicación solo tiene que configurar la opción https.port en su archivo application.conf:

http.port=9000
https.port=9443

Debe colocar los certificados en el directorio conf. Play soporta certificados X509 y de tipo keystore. Los certificados X509 deben ser llamados de la siguiente forma:
host.cert para el certificado y host.key para la llave. Si está usando keystore entonces, por defecto debe ser llamado certificate.jks.

Si está usando certificados X509, entonces puede configurar los siguientes parámetros en su archivo application.conf:

# X509 certificates
certificate.key.file=conf/host.key
certificate.file=conf/host.cert
# En caso de que su archivo llave esté protegido por password:
certificate.password=secret
trustmanager.algorithm=JKS

Si está usando un keystore:

keystore.algorithm=JKS
keystore.password=secret
keystore.file=conf/certificate.jks

Tenga en cuenta que la configuración mencionada son los valores por defecto.

Puede generar certificados auto firmados usando la herramienta openssl:

openssl genrsa 1024 > host.key
openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert

Si está usando el mecanismo de keystore de Java, entonces las siguientes propiedades pueden ser configuradas en su archivo application.conf:

# Keystore 
ssl.KeyManagerFactory.algorithm=SunX509
trustmanager.algorithm=JKS
keystore.password=secret
keystore.file=certificate.jks

Los valores mencionados también corresponden a la configuración por defecto.

Poniendo en producción sin usar Python

Python viene instalado por defecto en la mayoría de los equipos Unix, y Play incluye una versión de Windows. Sin embargo puede haber casos en los que necesita desplegar la aplicación en un servidor que no tiene ningún ejecutable de Python.

Para eso, Las aplicaciones de Play proveen un archivo build.xml de Ant con funcionalidad limitada.

Desde el directorio de la aplicación, puedes iniciar el servidor usando:

ant start -Dplay.path=/path/to/playdirectory

Precaución: Usando el comando play la salida se direcciona a System.out; sin embargo si se usa Ant la salida estándar no estará disponible. Es necesario proveer un archivo de configuración Log4j donde se especifique una salida a archivo.

Para detener el servidor:

ant stop -Dplay.path=/path/to/playdirectory

También puede especificar la ruta al framework de Play en una variable de entorno o directamente en el archivo build.xml de la aplicación.

Próximos pasos

Siguiente: Opciones de puesta en producción.