Cómo implementar su aplicación Cloud Foundry con (casi) cero miedo usando Travis CI

Las implementaciones de aplicaciones en la nube deberían ser sencillas. Deberíamos poder implementar nuevo código de forma continua, con la frecuencia que queramos, sin miedo. El modelo de implementación azul-verde nos permite hacer esto.

Recientemente me uní a un nuevo equipo en el trabajo que estaba implementando aplicaciones de node.js Cloud Foundry en IBM Cloud usando Travis con el proveedor de implementación de Bluemix CloudFoundry. Esto funciona muy bien para configurar rápida y fácilmente su implementación con solo unos pocos parámetros.

Desafortunadamente, cada implementación significa una interrupción de su aplicación ya que la versión existente se detiene y se inicia la nueva versión. Además, no hay verificación de que el nuevo código sea bueno antes de que el código anterior desaparezca.

Con la técnica de implementación azul-verde, su aplicación actual (Azul) continúa ejecutándose y recibiendo tráfico de red. Mientras su nuevo código de aplicación (verde) se implementa en una ruta temporal. La nueva aplicación Green se puede validar en la ruta temporal. Si hay algún problema, la implementación se detiene. La aplicación Blue sigue ofreciendo tráfico ininterrumpido. Una vez que se examina la aplicación verde, el enrutador se actualiza para apuntar a la aplicación verde. El azul se puede detener.

De esta manera, siempre hay una versión de la aplicación disponible para tomar tráfico. Cualquier problema en la implementación o tiempo de ejecución del nuevo código no afectará la disponibilidad de su aplicación.

Inmediatamente comencé a buscar una forma de implementar nuestras aplicaciones en azul-verde. Con el interés de escribir la menor cantidad de código personalizado posible, decidí aprovechar el complemento cf-blue-green-deploy para la interfaz de línea de comandos (CLI) de Cloud Foundry. Compartiré cómo hice esto aquí.

Voy a suponer que si aterrizaste aquí, probablemente hayas pasado el punto de simplemente "empezar" con Travis. No cubriré esos detalles aquí.

Si no está interesado en seguir adelante y solo quiere ir directamente a los productos, puede clonar mi muestra de trabajo de GitHub.

Instalación de CF CLI y el complemento azul-verde

Dado que no estamos utilizando el proveedor de implementación de Cloud Foundry, tenemos que instalar la CLI de Cloud Foundry nosotros mismos, así como el complemento de implementación azul-verde. Podemos hacer esto en la before_deployfase del ciclo de vida de la construcción de Travis.

Tenga en cuenta que la before_deployfase se ejecuta antes de cada proveedor de implementación. Si está haciendo cosas adicionales en su fase de implementación, es posible que desee mover estos pasos a la after_successfase (que se ejecuta solo una vez después de una compilación exitosa) para evitar instalaciones adicionales innecesarias. También puede mover estos pasos al propio script de implementación, que escribiremos a continuación.

Independientemente de dónde lo ponga, aquí está el guión:

- echo "Installing cf cli"- test x$TRAVIS_OS_NAME = "xlinux" && rel="linux64-binary" || rel="macosx64"; wget "//cli.run.pivotal.io/stable?release=${rel}&source=github" -qO cf.tgz && tar -zxvf cf.tgz && rm cf.tgz- export PATH="$PATH:."- cf --version
- echo "Installing cf blue-green deploy plugin"- cf add-plugin-repo CF-Community //plugins.cloudfoundry.org- cf install-plugin blue-green-deploy -r CF-Community -f

El comando para instalar la CLI proviene directamente de la fuente DPL de CloudFoundry. Los comandos para instalar el complemento de implementación azul-verde provienen del archivo README del complemento.

Invocando el despliegue azul-verde

Para invocar la implementación azul-verde, usaremos el proveedor de implementación de secuencias de comandos, que ejecuta un comando proporcionado y verifica el estado cero como indicación de éxito.

deploy:# on update to master branch we deploy to Cloud Foundry- provider: script skip_cleanup: true script: ./scripts/cf-blue-green-deploy.sh blue-green-cf-travis manifest.yml prod on: branch: master

Tenga en cuenta que skip_cleanupestá configurado en true. Sin esto, la CLI de cf y el complemento de implementación azul-verde que acaba de instalar se eliminarían antes de que se ejecute la implementación.

El script cf-blue-green-deploy.sh inicia sesión en la API de Cloud Foundry e invoca el complemento de implementación azul-verde. Además de especificar un nombre de aplicación y un archivo de manifiesto, también puede pasar un script de prueba de humo al complemento de implementación azul-verde. El complemento llamará al script de prueba de humo después de que se haya implementado el nuevo código de la aplicación, pero antes de que la ruta de la aplicación se cambie a la nueva aplicación. Esto le permite ejecutar cualquier número de pruebas con el nuevo código antes de que el tráfico real acceda a él.

El guión de la prueba de humo se pasa con un solo argumento. El argumento es la URL temporal de la aplicación recién implementada. Si el script de prueba de humo sale con éxito, la implementación azul-verde se completará cambiando la ruta a la nueva aplicación. Si el script de prueba de humo sale con un error, el tráfico continúa fluyendo a la versión anterior de la aplicación. La nueva versión permanece disponible para solucionar problemas.

En mi proyecto de ejemplo, el script de prueba de humo invoca una API / versión y verifica que regrese con un código de estado 200.

En nuestros proyectos reales en el trabajo, ejecutamos una colección de Postman contra la aplicación recién implementada. Desea que su conjunto de pruebas de humo sea lo suficientemente grande como para sentirse seguro en su nuevo código, pero no tan grande como para que lleve mucho tiempo completar una implementación o las pruebas inestables le impiden completar una implementación exitosa.

Opcionalmente, puede ejecutar un conjunto más completo de pruebas de regresión como un after_deploypaso, después de que su nuevo código esté activo.

Efectos secundarios de una implementación azul-verde en IBM Cloud

Hay algunos matices de este enfoque que debe tener en cuenta si está implementando en IBM Cloud. Debido a que está creando una nueva instancia de aplicación CF cada vez que realiza una implementación azul-verde, la guía de su aplicación cambiará. Si utiliza el servicio de supervisión de disponibilidad, sus pruebas configuradas se perderán cuando cambie su guid.

Para solucionar este problema, coloque una aplicación ficticia permanente. Escriba sus pruebas para su aplicación implementada azul-verde en la configuración de esta aplicación ficticia. Puede especificar cualquier URL al escribir sus pruebas de supervisión de disponibilidad.

Del mismo modo, si utiliza el servicio de análisis de registros, verá que cuando haga clic en el enlace "Ver en Kibana" en la pestaña Registros del panel de su aplicación, se le iniciará una búsqueda de Kibana en la cadena de guid de la aplicación. No se mostrarán los registros de aplicaciones anteriores a su implementación más reciente. Para solucionar esto, simplemente puede filtrar por el nombre de la aplicación en lugar del guid de la aplicación.

Otro servicio que tiene el mismo problema es Auto-Scaling. Cada vez que se coloca una nueva aplicación como parte de la implementación azul-verde, es necesario que se reconfigure su política de Auto-Scaling. Hay una interfaz de línea de comandos disponible que presumiblemente podría usar para escribir esto, pero todavía no he tenido la necesidad de probar esto.

Si alguno de estos problemas no es un problema para usted, siempre tiene la opción de escribir un script de implementación azul-verde personalizado que aproveche dos aplicaciones CF permanentes, una azul y una verde. Estas dos aplicaciones se turnarían para estar activas e inactivas. Puede configurar ambas aplicaciones con una política de escalado automático, por ejemplo.

Por supuesto, este enfoque significa que no puede aprovechar el complemento de implementación azul-verde que se describe en esta publicación, y debe mantener su propio script personalizado.

Terminando

En esta publicación, hemos examinado cómo podemos lograr una implementación de bajo riesgo y sin tiempo de inactividad utilizando Travis y el complemento de implementación cf blue-green.

In a real project, we would have even greater assurances, as we would have a suite of unit tests in place, and errors there would fail the Travis build before the deployment had a chance to run. We would also potentially have dev and staging branches configured to deploy to their own respective spaces in our Cloud Foundry organization, allowing us to validate and stabilize the application as necessary before promoting changes to production.

Thanks for reading! This is my first Medium story, and I hope you found it useful.