Desplegar una aplicación en Kubernetes
Continuous Delivery dejará de utilizarse en las siguientes regiones el 12 de febrero de 2027: au-syd, ca-mon, ca-tor, us-east. Code Risk Analyzer y DevOps Insights también quedarán obsoletos en todas las regiones en esa fecha. Sin embargo, si una región no tiene un uso activo de estas funciones, es posible que las funciones de esa región se suspendan antes y dejen de aceptar nuevas instancias. Más información
En esta guía de aprendizaje, descubrirá cómo crear una cadena de herramientas abierta utilizando distintas estrategias de despliegue. También aprenderá cómo implementar las cadenas de herramientas en el servicio IBM Cloud® Continuous Delivery y cómo desarrollar y desplegar una aplicación web simple (app) utilizando las cadenas de herramientas.
Esta guía de aprendizaje está basada en navegador. También puede crear una cadena de herramientas abierta similar en Terraform, tal y como se muestra en el ejemplo IBM Cloud del proveedor de Terraform ibm-cd-toolchain-simple-helm.
En esta guía de aprendizaje, se utilizan estrategias de despliegue que tienen Kubernetes como destino de despliegue. La cadena de herramientas que se utiliza en esta guía de aprendizaje implementa prácticas de DevOps estándar, como la exploración de código, las pruebas de aceptación, los repositorios de Git y las funciones de integración continua y entrega continua. Después de crear una clúster de Kubernetes y una cadena de herramientas, cambie el código de la aplicación y envíe el cambio al repositorio de Git Repos and Issue Tracking. Cuando se envían cambios al repositorio, la interconexión de entrega basada en Tekton compila y despliega el código automáticamente.
Tekton es un framework de código abierto, independiente del proveedor y nativo de Kubernetes que puede utilizar para crear, probar y desplegar aplicaciones. Tekton proporciona un conjunto de componentes compartidos para construir sistemas de integración continua y entrega continua. Como proyecto de código abierto, Tekton está gestionado por la Fundación Continuous Delivery. El objetivo es modernizar la entrega continua proporcionando especificaciones del sector para interconexiones, flujos de trabajo y otros bloques de construcción. Con Tekton, puede efectuar compilaciones, pruebas y despliegues en distintos proveedores o en sistemas locales abstrayendo los detalles de implementación subyacentes. Las interconexiones de Tekton se crean en Continuous Delivery.
La plantilla que se utiliza en esta guía de aprendizaje funciona con los planes Estándar o Lite de Kubernetes. Con el plan Estándar, puede acceder a la aplicación por medio del nombre DNS. En el plan Lite, puede acceder a la aplicación utilizando nodeport.
Puede utilizar una estrategia de despliegue para actualizar, de forma controlada, una aplicación en un entorno de producción. La utilización de una estrategia de despliegue puede proporcionar las ventajas siguientes:
- Evitar el tiempo de inactividad de la aplicación.
- Habilitar la prueba de producción de nuevas funciones sin afectar a los clientes.
- Limitar el impacto de los problemas de producción a un subconjunto de usuarios.
- Habilitar la retrotracción rápida a la versión anterior si surgen problemas.
Hay muchas estrategias de despliegue posibles disponibles. En general, dependen de la ejecución de varias instancias de la aplicación y la gestión de la actualización de las distintas instancias. Puede configurar previamente las siguientes estrategias comunes de despliegue en Continuous Delivery:
- Básico
- Despliega el nuevo release deteniendo y actualizando todas las instancias en ejecución simultáneamente, lo que deriva en tiempo de inactividad. Para la reversión, debe desplegar de nuevo la versión anterior, lo que provoca un tiempo de inactividad adicional. Si bien esta estrategia es simple, rápida y sus requisitos de recursos de tiempo de ejecución no son exigentes, se trata de la más arriesgada y conlleva un tiempo de inactividad. No se recomienda utilizar la estrategia de despliegue básica en aplicaciones críticas que necesitan una alta disponibilidad.
- Actualización continua
- Del mismo modo que la estrategia básica, esta estrategia de despliegue es rápida, sencilla y poco exigente en lo relativo a requisitos de recursos de tiempo de ejecución. Sin embargo, dado que cada una de las instancias en ejecución se desactiva y se actualiza individualmente, de manera que se evita el tiempo de inactividad, la retrotracción requiere que se vuelva a desplegar el release anterior. Este método puede, por lo tanto, ocupar mucho tiempo y provocar problemas si la versión actual de la aplicación en producción está dañada.
- Despliegue azul-verde
- Crea dos entornos de producción independientes permanentes (azul y verde) y solo uno de los entornos recibe tráfico cada vez, nunca los dos al mismo tiempo. El release actual siempre se despliega en el entorno desocupado y el tráfico pasa a este una vez completado el despliegue, sin tiempo de inactividad. Dado que solo es necesario pasar el tráfico al entorno sin modificaciones, la retrotracción no genera ningún tiempo de inactividad. Al requerir esta estrategia dos entornos de producción completos, los requisitos de recursos son también mayores. Sin embargo, se trata de una estrategia que habilita unos potentes flujos de desarrollador, como la capacidad de probar nuevas versiones de aplicaciones en el entorno de producción antes de permitir el tráfico de clientes. El despliegue azul-verde también facilita la retrotracción rápida.
- Release Canary
- Despliega un nuevo release en paralelo con el entorno de producción original (parecido al azul-verde), sin tiempo de inactividad. La cantidad de tráfico que se envía a las instancias actualizadas y las originales se gestiona de tal forma que la nueva versión pasa a estar disponible para un subconjunto controlado de usuarios mientras se realiza el despliegue. Con el tiempo, el tráfico que se envía a la nueva versión aumenta hasta que todo el tráfico se envía allí, momento en el que se puede detener el entorno de producción anterior. Para realizar una retrotracción rápida mientras el despliegue está en curso, puede direccionar todo el tráfico al entorno de producción original. Dado que esta estrategia sólo requiere dos entornos de producción completos durante la implantación, el uso total de recursos es menor que en el caso de la implantación Azul-Verde. La estrategia de despliegue del release Canary es la más lenta para pasar de un release anterior a un release actual del software que se está desplegando. Los despliegues de Canary permiten a las empresas probar dos versiones de software diferentes en paralelo en el entorno de producción.
Antes de empezar
Antes de iniciar esta guía de aprendizaje, asegúrese de que dispone de los recursos siguientes:
-
Una cuenta de IBM Cloud. En función del tipo de cuenta de IBM Cloud, es posible que se limite el acceso a determinados recursos. En función de los límites del plan de cuenta, es posible que algunas prestaciones necesarias para algunas estrategias de despliegue no estén disponibles. Para obtener más información sobre las cuentas de IBM Cloud, consulte Configuración de la cuenta de IBM Cloud y Actualización de la cuenta.
-
Un clúster de Kubernetes y una clave de API. Puede crear estos recursos utilizando la interfaz de usuario o la CLI. El clúster puede tardar algún tiempo en llevar a cabo la provisión. A medida que se crea el clúster, se va avanzando por las etapas de Despliegue, Pendiente y Preparado. Para obtener más información sobre los clústeres de Kubernetes, consulte Clústeres de Kubernetes. Aunque puede utilizar el despliegue continuo y el despliegue azul-verde para planes Lite, debe crear un clúster de Kubernetes para los planes Estándar.
-
Una instancia del servicio Continuous Delivery.
-
Opcional. Secretos almacenados en una caja fuerte de gestión de secretos y administrados de forma centralizada desde una única ubicación. Para obtener más información sobre cómo seleccionar una oferta de gestión de secretos y protección de datos entre todas las que se ofrecen, consulte Gestión de secretos de IBM Cloud. Si todavía no se ha decidido por una instancia del proveedor de cajas fuertes de gestión de secretos, cree una.
-
Opcional. Un espacio de nombres que se crea utilizando la línea de mandatos del registro de contenedor. Para crear un espacio de nombres, escriba el siguiente comando :
ibmcloud cr namespace-add <my namespace>Si lo prefiere, puede crear un espacio de nombres en la página Container Registry. Para obtener más información sobre cómo crear un espacio de nombres en esta ubicación, consulte el servicio IBM Cloud Container Registry.
Creación de la cadena de herramientas
En este paso, creará una cadena de herramientas Desarrollar una app de Kubernetes. El clúster de Kubernetes de destino se configura al mismo tiempo que la cadena de herramientas utilizando la clave de API de IBM Cloud y el nombre del clúster de Kubernetes. Puede cambiar estos valores más adelante actualizando la configuración de Delivery Pipeline. Cualquier código fusionado en la rama de repositorios Git de destino se compila, se valida y se despliega automáticamente en el clúster de Kubernetes.
Para crear una cadena de herramientas Desarrollar una app de Kubernetes, pulse
Como alternativa, desde la IBM Cloud consola, haga clic en el icono de menú (
) > Automatización de plataformas > Cadenas de herramientas.
En la página Cadenas de herramientas, pulse Crear una cadena de herramientas. En la página Crear una cadena de herramientas, haga clic en Desarrollar una aplicación Kubernetes.
Configurar el nombre y la región de la cadena de herramientas
Revise la información predeterminada para la configuración de la cadena de herramientas. El nombre de la cadena de herramientas la identifica en IBM Cloud. Asegúrese de que el nombre de la cadena de herramientas sea exclusivo dentro de las cadenas de herramientas de la misma región y grupo de recursos en IBM Cloud.
La región de la cadena de herramientas puede diferir del clúster y de la región de registro.
Seleccione la estrategia de despliegue
La cadena de herramientas crea una interconexión de despliegue continuo para desplegar la imagen de Docker de la aplicación en IBM Cloud® Kubernetes Service. Seleccione la estrategia de despliegue que quiera utilizar. Deberá proporcionar más detalles, que dependerán de la estrategia de despliegue elegida (continua, azul-verde o Canary).
-
Pulse la estrategia de despliegue que quiera utilizar para la cadena de herramientas.
Estrategias seguras para la implementación de aplicacionesEstrategias de implementación -
Pulse Continuar.
Configurar el repositorio de código fuente de aplicación
De forma predeterminada, en el paso Aplicación, se muestran las opciones recomendadas para el repositorio del código fuente de aplicación. Para ver todas las opciones disponibles para la integración de Git subyacente, pulse Opciones avanzadas. De forma predeterminada, la cadena de herramientas utiliza el ejemplo predeterminado que clona la aplicación de ejemplo como un repositorio de Git Repos and Issue Tracking alojado en IBM.
Puede cambiar el nombre del repositorio de aplicaciones. La región del repositorio sigue siendo la misma que la región de la cadena de herramientas.
La plantilla de cadena de herramientas proporciona una aplicación NodeJS de ejemplo. Si quiere enlazar un repositorio de aplicaciones existente para la cadena de herramientas, seleccione Traer su propia aplicación y especifique el URL del repositorio. La cadena de herramientas solo admite la creación de enlaces con repositorios existentes de Git Repos and Issue Tracking.
De forma predeterminada, la plantilla del repositorio de aplicaciones se clona en la organización Git Repos and Issue Tracking. Para cambiar la organización, habilite las Opciones avanzadas y especifique el propietario del repositorio.
Configurar el repositorio de inventario
El repositorio de inventario registra los detalles de los artefactos creados por las cadenas de herramientas de integración continua. Puede crear un nuevo repositorio de inventario que sea un clon de la plantilla de repositorio de inventario o utilizar un repositorio de inventario existente que comparta entre cadenas de herramientas.
De forma predeterminada, la plantilla del repositorio de inventario se clona en la organización Git Repos and Issue Tracking. Para cambiar la organización, seleccione Opciones avanzadas y especifique el propietario del repositorio.
Almacenar secretos de forma segura
Hay varias herramientas de esta cadena de herramientas que requieren secretos, como una clave de API de IBM Cloud. Es necesario almacenar de forma segura todos los secretos en una caja fuerte de secretos y hacer referencia a ellos siempre que lo requiera la cadena de herramientas.
Con IBM Cloud, puede elegir entre varias ofertas de gestión de secretos y protección de datos que le ayudan a proteger los datos confidenciales y a centralizar los secretos. En el paso Secretos, puede especificar qué integraciones de la caja fuerte de secretos se deben añadir o eliminar de la cadena de herramientas. Para obtener más información sobre cómo añadir y eliminar integraciones de la caja fuerte, así como los requisitos previos y el uso de sugerencias, consulte Gestión de secretos de IBM Cloud.
Cuando se utilizan sugerencias en una plantilla, la cadena de herramientas se rellena automáticamente con secretos configurados previamente; no es necesario seleccionar secretos de forma manual en las integraciones de cajas fuertes conectadas a la cadena de herramientas.
En esta guía de aprendizaje, se utiliza IBM Secrets Manager como caja fuerte de secretos.
IBM Secrets Manager almacena y aplica de forma segura secretos como las claves de API, la firma de imágenes o las credenciales de HashiCorp que forman parte de la cadena de herramientas.
Para más información sobre la gestión de sus secretos en IBM Key Protect o HashiCorp, consulte Secretos.
Configurar el destino de despliegue
Configure el clúster de Kubernetes de destino en el que desplegar la aplicación. Una vez que la aplicación pasa la fase de compilación, prueba y exploración, la interconexión despliega la imagen de la aplicación compilada en el clúster de Kubernetes de destino. En ese momento, el despliegue está listo para la prueba de aceptación o la prueba de integración.
Si la clave de API dispone del acceso necesario, los campos siguientes se cargan automáticamente utilizando la clave de API creada, recuperada de una caja fuerte o especificada de forma manual. Si la clave de API es válida, se rellenan automáticamente los valores de espacio de nombres y región del registro de contenedores, el espacio de nombres, el nombre y la región del clúster, y el grupo de recursos. Puede actualizar cualquiera de estos campos para adecuarlos a la configuración.
-
Nombre de app: nombre de la aplicación. El nombre de aplicación predeterminado es
hello-containers. -
Clave de API de IBM Cloud: clave de API que se utiliza para interactuar con la herramienta de CLI de
ibmclouden distintas tareas. Utilice uno de estos métodos para especificar la clave de API que quiera utilizar:- Pulse el icono de llave para importar una clave de API existente desde la caja fuerte de secretos que quiera.
- Copie y pegue una clave de API existente.
- Pulse Nuevo para crear una clave de API.
- Genere un nuevo valor
api-keysi no tiene una clave de API existente.
Puede guardar de inmediato la clave de API generada en una caja de fuerte de secretos existente de su elección.
La aplicación se despliega utilizando la estrategia de despliegue especificada. El ejemplo siguiente muestra los detalles de un despliegue continuo o azul-verde.
Si ha seleccionado la estrategia de despliegue Canary, debe especificar detalles adicionales del destino de despliegue.
-
Tamaño del paso de Canary: define la cantidad de tráfico que se va a redirigir al nuevo release del despliegue Canary.
-
Intervalo del paso de Canary: define el intervalo de tiempo entre cada prueba Canary para pasar al nuevo release del despliegue Canary.
Añadir integraciones de herramientas opcionales
Puede añadir la integración de herramientas de IBM Cloud® DevOps Insights a la cadena de herramientas sin ninguna configuración adicional.
DevOps Insights se incluye en la cadena de herramientas creada. No se necesita ningún paso de configuración para DevOps Insights. La interconexión de integración continua utiliza automáticamente la instancia de DevOps Insights incluida en la cadena de herramientas. DevOps Insights agrega datos de despliegue, compilación, prueba y código para proporcionar visibilidad sobre la velocidad y la calidad de todos los equipos y releases.
Pulse Continuar.
Complete la configuración de la cadena de herramientas
En la página Resumen, pulse Crear. Para configurar la cadena de herramientas, se ejecutan varios pasos automáticamente.
Puede configurar las integraciones de cadenas de herramientas individuales después de crear la interconexión.
Exploración de su nueva cadena de herramientas
Después de crear la cadena de herramientas, muestra cada una de las integraciones de herramientas que forman parte de la cadena de herramientas en un diagrama.
Exploración de los conductos
Puede explorar los conductos para comprender el flujo de la cadena de herramientas y las distintas operaciones que se ejecutan dentro de cada conducto. La cadena de herramientas que acaba de crear contiene tres interconexiones:
- Interconexión de solicitud de extracción: se ejecuta cuando un desarrollador fusiona cambios de la rama de desarrollo con la rama maestra o con cualquier otra rama del repositorio. El conducto de la solicitud de extracción ejecuta la prueba unitaria y las exploraciones estáticas sobre el código fuente de la aplicación.
- Interconexión de integración continua: se ejecuta cuando se fusiona un cambio en la rama maestra del repositorio de código fuente de aplicación. La interconexión de integración continua ejecuta la prueba de unidad, la cobertura de código, las exploraciones estáticas en el código fuente de aplicación, la comprobación de CIS y la comprobación de la lista de materiales (BOM). La interconexión de entrega continua genera también los artefactos de compilación binarios y los carga en IBM Cloud® Kubernetes Service, tal y como se ha configurado en la cadena de herramientas. Además, la interconexión de integración continua genera los metadatos de los artefactos de compilación y los almacena en el repositorio de inventario.
- Interconexión de despliegue continuo: despliega artefactos de compilación en el entorno de despliegue. La interconexión verifica el despliegue correcto de la aplicación ejecutando la comprobación de estado. Una vez completada la interconexión de integración continua, debe activar de forma manual esta interconexión. En función de la estrategia de despliegue seleccionada, se añadirán más desencadenantes a la interconexión de entrega continua.
Ejecutar las interconexiones de integración continua y solicitud de extracción
Para iniciar la interconexión de solicitud de extracción, cree una solicitud de fusión en el repositorio de aplicaciones:
- En la página Visión general de la cadena de herramientas, en la tarjeta Repositorios, pulse el repositorio de la aplicación
compliance-app-<timestamp>. - Desde el repositorio maestro, cree una rama.
- Actualice parte del código de la aplicación del nodo de ejemplo o el archivo readme y guarde los cambios.
- Envíe la solicitud de fusión.
- En la página Visión general de la cadena de herramientas, en la tarjeta Repositorios, pulse el repositorio de
pr-pipelinepara iniciar la interconexión de la solicitud de extracción. La solicitud de fusión correspondiente en el repositorio de aplicaciones permanece en estado pendiente hasta que todas las etapas de la interconexión de la solicitud de extracción se completan correctamente. - Si la ejecución de la interconexión de solicitud de extracción se realiza correctamente, puede seleccionarla para explorar los pasos completados.
{: caption="
Para iniciar la interconexión de integración continua, fusione la solicitud de fusión de integración continua en el repositorio de aplicaciones:
- Vaya a la solicitud de fusión.
- Fusione la solicitud para que los cambios se copien en la rama maestra del repositorio de aplicaciones. La interconexión de integración continua se desencadena automáticamente.
- En la página Visión general de la cadena de herramientas de integración continua, en la tarjeta Repositorios, pulse el repositorio de
ci-pipelinepara iniciar la interconexión de integración continua. - Después de la correcta ejecución de la interconexión de integración continua, puede pulsar la ejecución de la interconexión para explorar los pasos completados.
{: caption="
Práctica del cambio a la izquierda
En el mundo del desarrollo de aplicaciones seguras, el shift-left es una práctica que previene y detecta problemas como defectos y vulnerabilidades de seguridad, y realiza comprobaciones de conformidad en una fase temprana del proceso de entrega del software. Esta práctica de adelantar los controles de calidad en el ciclo de desarrollo incluye las siguientes prácticas:
- La ejecución, en la fase más temprana posible, de comprobaciones, en el código o en el propio repositorio, que no necesitan la imagen compilada. Estas comprobaciones impiden que el código que no respeta la conformidad se fusione en la rama maestra del repositorio. Dado que las pruebas no se recogen del pull request pipeline, su objetivo es desplazar las comprobaciones de conformidad a una fase más temprana del proceso de desarrollo.
- Todas las comprobaciones se ejecutan en cada una de las ejecuciones de interconexión. Si falla una comprobación, la interconexión continúa con la siguiente comprobación. Para evaluar si hay alguna anomalía en la ejecución, compruebe el paso final de la interconexión, que tiene un evaluador de interconexiones.
Los resultados de las pruebas de unidad y las exploraciones de vulnerabilidad se publican en la instancia de DevOps Insights de la cadena de herramientas. Para revisar estos resultados, pulse el mosaico DevOps Insights en la cadena de herramientas y vaya a la página Panel de control de calidad.
{: caption="de herramientas*
Para evaluar si hay alguna anomalía en la ejecución de la interconexión, compruebe el paso final de la interconexión, que tiene un evaluador de interconexiones.
Explorar la interconexión de entrega continua
Las interconexiones de integración continua y solicitud de extracción son comunes en todas las estrategias de despliegue. Los cambios en la implementación y el diseño de la interconexión de entrega continua se basan en la estrategia de despliegue seleccionada previamente en esta guía de aprendizaje.
Esta guía de aprendizaje muestra cómo funciona la estrategia de despliegue continuo mediante la aplicación de ejemplo.
Explorar el despliegue continuo
La estrategia de despliegue continuo que se utiliza en esta guía de aprendizaje muestra cómo se puede utilizar una estrategia de despliegue con el servicio Continuous Delivery para ejecutar las cargas de trabajo de producción en Kubernetes. La interconexión de entrega continua proporciona dos desencadenantes para el despliegue continuo. Puede iniciar una interconexión de entrega continua de cualquiera de las maneras siguientes:
- Desencadene manualmente la interconexión de entrega continua.
- Desencadene automáticamente la interconexión de entrega continua después de cada acción de
Mergeen el repositorio de inventario. Después de la fusión, debe desencadenar manualmente la ejecución de la interconexión de entrega continua.
Hay un desencadenante Git Repos and Issue Tracking configurado para desencadenar una interconexión de entrega continua automática, pero está inhabilitado de forma predeterminada. Cuando haya promocionado un cambio, podrá habilitar este desencadenante.
Debido a que la estrategia de despliegue continuo actualiza de forma incremental todas las instancias de producción con la nueva versión de software, no se produce ningún tiempo de inactividad. Sin embargo, la estrategia de despliegue de retrotracción requiere que vuelva a desplegar el release anterior, lo que puede tardar algún tiempo en completarse.
Después de la correcta ejecución de la interconexión de entrega continua, puede localizar el URL de la aplicación en el paso perform deployment de la interconexión de entrega continua.
Próximos pasos
Si quiere eliminar la aplicación de ejemplo que se ejecuta en Kubernetes, debe limpiar el clúster de Kubernetes:
-
Vaya a la página de inicio de Kubernetes Cluster.
-
Seleccione el clúster en el que se ejecuta la aplicación de ejemplo.
-
Pulse Panel de control de Kubernetes.
-
Desde la ubicación en la que se ejecuta la aplicación de ejemplo, seleccione espacio de nombres.
Kubernetes espacio de nombres -
Suprima los despliegues, servicios e ingresos relacionados recogidos en el espacio de nombres seleccionado.
¿Está buscando ayuda?
IBM Cloud watsonx, que funciona con la tecnología de IBM, está diseñado para ayudarle a aprender a trabajar en IBM Cloud y a crear soluciones con el catálogo de productos y servicios disponibles. Consulte Cómo obtener ayuda del asistente de IA.
Para obtener más opciones de soporte, consulte Obtención de ayuda y soporte para Continuous Delivery.