Operadores de Kubernetes: automatizar el proceso de lanzamiento

Snyk ayuda a nuestros clientes a integrar la seguridad en sus pipelines de CI/CD, por lo que dedicamos mucho tiempo a pensar en la automatización. Al lanzar nuestro propio software, siempre buscamos adoptar las mejores prácticas de pruebas y lanzamiento.

En este blog, hablaré del proceso de lanzamiento de nuestro Kubernetes Operator y mostraré cómo automatizamos su implementación en varios repositorios.

¿Qué es un Kubernetes Operator?

Un Operator es un «... método para empaquetar, implementar y administrar una aplicación de Kubernetes...». Básicamente, los Operators encapsulan en código las acciones del ciclo de vida de una aplicación, lo que nos permite controlarlas mediante la API nativa de Kubernetes.

¿Por qué son importantes los Kubernetes Operators?

El patrón de Operator nos permite controlar las aplicaciones una vez que están en ejecución mediante las API de Kubernetes. Si nuestras aplicaciones necesitan hacer algo más que iniciarse o detenerse, podemos controlarlas durante su funcionamiento de la misma manera declarativa en que administramos el resto de nuestros recursos de Kubernetes.

¿Qué es la automatización del lanzamiento de aplicaciones?

Con el auge de los catálogos en línea donde implementamos nuestro software para que los usuarios lo consuman, el proceso de distribución de una versión lanzada puede volverse muy complejo. Es posible que debamos completar muchos pasos para distribuir nuestros artefactos en distintos repositorios y proporcionar diferentes tipos de metadatos para que nuestra aplicación pueda consumirse de distintas maneras. Automatizar estos procesos es fundamental para garantizar que cada lanzamiento se distribuya sin errores y para que nuestros usuarios puedan acceder a las nuevas versiones en cuanto estén disponibles.

Veámoslo en detalle

Hace unos meses, el equipo detrás de Container Scanning lanzó Snyk Operator, un Operator para Snyk Controller que facilita su implementación tanto en clústeres nativos de Kubernetes como de OpenShift.

Snyk Controller es una aplicación de Snyk que se implementa en el clúster del usuario y analiza las imágenes de los contenedores que se ejecutan en él. Puedes obtener más información sobre esta increíble herramienta aquí y descubrir aquí cómo puede ayudarte a detectar vulnerabilidades en tus imágenes y aplicaciones.

Hay muchas formas distintas de crear Operators para Kubernetes. Una de las más comunes es Operator Framework, que se originó en CoreOS y ahora es un proyecto de CNCF. Además de ofrecer un SDK para desarrollar Operators, Operator Framework también proporciona un repositorio de Operators creados por la comunidad.

Snyk Operator se creó con este framework y distribuimos cada versión en los repositorios upstream. Cuando lanzamos una nueva versión de Operator, debemos completar muchos pasos que podrían dar lugar a errores si se hicieran manualmente.

Primero, veamos cómo es el proceso de lanzamiento de Snyk Controller y cómo incluimos en él la compilación del Operator.

Cuando se integra un pull request de cualquiera de los colaboradores en nuestro repositorio de Snyk Controller, se inicia nuestro pipeline de integración continua e implementación continua. Este compila el Operator y su imagen, y ejecuta las pruebas unitarias, las pruebas del sistema y todas las pruebas de integración para probar el Operator en distintos entornos.

Debemos probarlo en una gran variedad de entornos, con distintas versiones de OpenShift y distintas versiones de Kubernetes upstream. En todos estos entornos, hacemos pruebas con Operator Lifecycle Manager, que forma parte de Operator Framework y amplía Kubernetes para ofrecer una forma declarativa de instalar, administrar y actualizar Operators y sus dependencias en un clúster.

Una vez que probamos una versión de Snyk Operator, debemos distribuir la versión final. Actualmente, lanzamos Snyk Operator en Operator Hub, que permite a los usuarios instalarlo en cualquier clúster de Kubernetes que ejecute Operator Lifecycle Manager. También lo lanzamos en el catálogo de OpenShift.

Este proceso de lanzamiento incluye dos pull requests distintos, lo que generaría mucho trabajo adicional si lo hiciéramos manualmente: uno para incluir Snyk Operator en la carpeta community-operators y otro para incluirlo en la carpeta upstream-community-operators. El primero lanza Snyk Operator en OperatorHub.io y el segundo lo lanza en el catálogo de OpenShift.

Para eliminar el trabajo adicional que implican estos pasos, queremos automatizar por completo el proceso de lanzamiento en ambos repositorios, así que lo programamos todo en nuestro pipeline de CircleCI.

Primero, copiamos todos los archivos que necesitamos a la carpeta snyk-operator y reemplazamos la versión de la aplicación por la más reciente. Descargamos la herramienta operator-sdk y la usamos para compilar la imagen de Snyk Operator. Una vez que termina este proceso, subimos la imagen a nuestro registro público en Docker Hubs.

Fuente: GitHub

Esta imagen nos permite ejecutar las pruebas de integración en el pipeline y asegurarnos de que lanzamos una versión que funciona en clústeres de OpenShift 3.x y 4.x, y en clústeres de Kubernetes con OLM. Para ejecutar las pruebas de integración, usamos un truco: subimos la imagen del Operator al registro de Quay, creamos un operator-source.yaml y luego lo instalamos en el clúster aplicando este install.yaml.

La intención es imitar el mismo proceso que ocurre cuando los usuarios instalan el Operator mediante la interfaz de usuario. Lo tratamos como una caja negra y seguimos algunos de los pasos que OpenShift ejecutaría cuando el usuario hace clic en «instalar» en la interfaz.

Fuente: GitHub

Fuente: GitHub

Fuente: GitHub

Por último, cuando todas las pruebas dan luz verde, podemos lanzar Snyk Operator. Para ello, debemos crear algunos metadatos adicionales. Estos agregan ClusterServiceVersion y CustomerResource Definitions, que se usan para completar la página de Snyk Controller en Operator Hub y permitir la integración con Operator Lifecycle Manager. OLM permite que los usuarios se suscriban a un Operator y unifica la instalación y las actualizaciones en un solo paso.

Como estos metadatos no cambian con frecuencia, usamos plantillas y solo cambiamos la versión para que coincida con la más reciente de Snyk Operator.

Fuente: GitHub

Una vez que completamos todos estos pasos, por fin podemos crear nuestros commits: uno para incluir los nuevos metadatos de Operator en la carpeta community-operators y otro para la carpeta upstream-community-operators. Para cada commit, abriremos un pull request en el repositorio de Operators de la comunidad e incluiremos el mensaje solicitado.

Fuente: GitHub

Puedes ver ejemplos de estos pull requests automatizados aquí y aquí.

Una vez creados los pull requests, se ejecutan pruebas automatizadas en OperatorHub y OpenShift y, finalmente, los encargados de mantener esos repositorios integran nuestra nueva versión.

En resumen

Al automatizar por completo el proceso de lanzamiento de nuestro Operator, ahorramos mucho tiempo y recursos del equipo de ingeniería y podemos seguir ofreciendo nuevas versiones de nuestro software de la manera más rápida y eficiente posible.

Snyk Controller integra el análisis de Snyk en tus clústeres de Kubernetes, lo que te permite importar y probar tus cargas de trabajo en ejecución e identificar vulnerabilidades en las imágenes y configuraciones asociadas que podrían reducir su seguridad. Obtén más información aquí y empieza a usar Snyk registrándote para obtener una cuenta gratuita.