Buenas prácticas de despliegue
DevStudio permite empaquetar los artefactos en un fichero CAR (Composite Application aRchive) y desplegarlos en los distintos servidores WSO2 (AS, ESB, DSS, ...), sin importar si dichos servidores esten on-premise o en Cloud.
Las tres principales maneras de desplegar los artefactos son:
- Usando un fichero "*.car" para desplegarlo en el servidor (el fichero puede ser fruto de la exportación desde DevStudio o usando Maven)
- Desplegando desde la vista de servidores de WSO2 DevStudio.
- Desplegando desde el plugin Maven (mi favorito porque se integra muy bien con Jenkins)
Todas las opciones antes mencionadas necesitan de un proyecto "composite application" para generar el fichero "*.car".
Existen ciertos puntos importantes:
- Desplegar con el plugin Maven o con el fichero CAR puede ser la mejor forma para desplegar en entornos productivos.
- Desplegar con el plugin de Maven nos da la habilidad de desplegar el fichero CAR en múltiples servidores. Lo único que hay que hacer es configurar las direcciones de los servidores con sus credenciales en el plugin Maven.
- La C-App puede ser desplegada en cualquier servidor Carbon, pero sólo los artefactos relevantes pueden ser desplegados en servidores específicos dependiendo de los roles de servidor (por ejemplo un artefacto DSS no puede ser desplegado en un servidor IS).
Despliegue en múltiples entornos
Los siguientes son algunos aspectos importantes.
Cuando se trata con múltiples entornos (DEV, QA, PROD) se necesita tener diferentes proyectos C-App para agrupar los artefactos dinámicos para los diferentes entornos (endpoints, WSDLs y polices). También se necesita otro proyecto para almacenar los artefactos comunes(independientes del entorno) y poder desplegarlo en cualquier entorno sin sufrir modificaciones.
Debemos intentar colocar artefactos como recursos del registro para diferentes entornos, para que sea fácil de gestionar en los entornos. Consulte este artículo para obtener más información.
Por ejemplo, si consideramos los entornos DEV y QA, el proyecto 'Integration_Parent_Project' mencionado en el post anterior, debería tener la siguiente estructura:
Integration_Parent_Project
|___ AppServerProject
|___ ESBConfigProject
|___ RegistryProject
|___ DEV
|___ QA
|___ CappProject_Common
|___ CappProject_DEV
|___ CappProject_QA
En esta estructura "RegistryProject" tiene dos carpetas para los recursos necesarios para DEV y QA. Digamos que para el mismo servicio que tenemos dos endpoints, uno para desarrollo(DEV) y otro para calidad (QA); estos endpoints se pueden crear en sus respectivas carpetas. Esta técnica nos permite crear recursos(endpoints) con el mismo nombre y diferentes nombres de artefactos, quedando de la siguiente manera:
|___ RegistryProject
|___DEV
|__ backendEP.xml //dev backend, http://dev.wso2as.com/9763
|___QA
|__ backendEP.xml //qa backend, http://qa.wso2as.com/9763
La finalidad de "CappProject_Common" es mantener los recursos independientes del entorno, de tal manera que el fichero CAR generado de este pueda ser desplegado en todos los entornos.
"CappProject_DEV" será usado para empaquetar los recursos de desarrollo.
"CappProject_QA" será usado para empaquetar los recursos del entorno de pruebas.
Todo esto facilita el movimiento de DEV a QA y lo único que se necesita es desplegar el fichro .car adecuado.
Despliegues remotos
Como se dijo al principio, cuando tenemos múltiples proyectos hay que agruparlos en un "parent project" (como buena práctica). Cuando se construye este, obtenemos el fichero "*.car" dentro del directorio target del proyecto C-App, el cual, simplemente se puede desplegar usando la consola de administración.
Sin embargo, cuando se trata de automatizació y pruebas, podemos usar el "Maven CAR deploy plugin" para hacer este proceso más fácil.
Despliegues remotos con el plugin Maven CAR
El plugin de maven proporcinado por WSO2 necesita que se configure con los datos del servidor donde desplegar, sus credenciales de conexión y el truststore con los certificados públicos de dicho servidor (accesibles desde el plugin), el siguiente es un ejemplo de configuración:
<plugin>
<groupid>org.wso2.maven</groupid>
<artifactid>maven-car-deploy-plugin</artifactid>
<version>1.0.9</version>
<extensions>true</extensions>
<configuration>
<carbonservers>
<carbonserver>
<truststorepath>/.../repository/resources/security/wso2carbon.jks</truststorepath>
<truststorepassword>wso2carbon</truststorepassword>
<truststoretype>JKS</truststoretype>
<serverurl>https://localhost:9443</serverurl>
<username>admin</username>
<password>admin</password>
<operation>deploy</operation>
</carbonserver>
</carbonservers>
</configuration>
</plugin>
De este ejemplo, notese que la etiqueta "carbonserver", puede repertirse varias veces dado que esta contenida dentro de otra llamada "carbonservers".
Una vez que el plugin ha sido configurado, se puede efectuar el despliegue remoto con una simple instrucción maven, como por ejemplo:
mvn clean deploy -Dmaven.deploy.skip=true -Dmaven.car.deploy.skip=false
Un aspecto evidente de seguridad es que el plugin usa passwords en texto plano. Actualmente no hay ninguna opción para encriptar los passwords, sin embargo el plugin se puede configurar para que obtenga los passwords de variables de entorno pasadas por linea de comandos, modificandose la configuración de la siguiente manera:
<carbonserver>
...
<serverurl>https://localhost:9443</serverurl>
<username>${username}</username>
<password>${password}</password>
...
</carbonserver>
Así la ejecución desde linea de comandos quedaría de la siguiente manera:
mvn clean deploy -Dusername=admin -Dpassword=admin -Dmaven.deploy.skip=true -Dmaven.car.deploy.skip=false
Este artículo es una interpretación de un artículo publicado por Susinda Perera, uno de los ingenieros de WSO2, el cual trata sobre el IDE oficial y las buenas prácticas de desarrollo de proyectos SOA.
Enlaces relacionados:
- FIN -
No comments:
Post a Comment