cds
0.54.1
CDS es una plataforma de automatización continua de entrega continua y DevOps de grado empresarial escrita en GO (Lang).
Este proyecto está bajo desarrollo activo
Documentación
CDS proporciona una interfaz de usuario intuitiva que le permite construir flujos de trabajo complejos, ejecutarlos y cavar en los registros cuando sea necesario.
Crear y ejecutar flujo de trabajo con CDS UI.
CDSCTL es la línea de comandos CDS: puede escribir todo con ella, CDSCTL también proporciona algunos comandos interesantes, como cdsctl shell para navegar por sus proyectos y flujos de trabajo sin la necesidad de abrir un navegador.
Ver todos los comandos CDSCTL
Cree flujo de trabajo como código con la línea de comandos CDS.
Docker-composa es tu amigo, vea los tutoriales listos para ejecutar
La mayoría de las herramientas de CI/CD se reproducen con trabajos dentro de una tubería. CDS introduce un nuevo concepto llamado CDS Workflows . Un flujo de trabajo CDS le permite encadenar tuberías con desencadenantes. Una tubería está estructurada en etapas secuenciales que contienen uno o múltiples trabajos concurrentes.
¡Sí! CDS se usa en producción desde 2015 @OVH y lanza más de 7 millones de trabajadores de CDS por año. Puede instalar la versión oficial disponible en https://github.com/ovh/cds/releases
CDS proporciona todo lo necesario para monitorear y medir la actividad de producción (registros, métricas, monitoreo)
Todos los datos se almacenan en la base de datos, nada en el sistema de archivos. Simplemente haga una copia de seguridad de su base de datos regularmente y estará a salvo.
Core Team está disponible en Github
Capacidad para ejecutar múltiples trabajos simultáneamente mientras mantiene un aislamiento entre ellos. Vea el documento sobre etapas y trabajos dentro de una tubería. Se inicia una tubería con un contexto: 0 o 1 aplicación, entorno 0 o 1.
Un flujo de trabajo permite encadenar las tuberías. Esta es una característica clave de los CD. Puede crear flujos de trabajo utilizando una o más tuberías, tuberías que se pueden vincular junto con uniones o horquillas.
Puede imaginar tener solo un constructor de flujo de trabajo e implementar toda su pila de microservicios. La misma tubería se puede usar varias veces en un flujo de trabajo, puede asociar una aplicación o un entorno. Solo tendrá una tubería de implementación y una tubería de compilación para mantener, incluso si tiene cientos de aplicaciones.
Una plantilla de flujo de trabajo le permite compartir y reutilizar flujos de trabajo en varios equipos. Cualquier usuario puede crear una plantilla de flujo de trabajo, mantenerla como código o desde UI, y actualizar a granel un conjunto de flujos de trabajo con una sola acción.
Como empresa, puede ofrecer un catálogo predefinido de flujos de trabajo que le permite estandarizar las prácticas de prueba y implementación en todos sus equipos.
Esto también reduce los esfuerzos de mantenimiento, ya que las plantillas permiten una gestión centralizada escalable.
Puede configurar todo con la interfaz de usuario web. Incluso si tiene casos de uso complejos, generalmente es más fácil crear sus flujos de trabajo gráficamente.
Pipeline como código es un concepto bien conocido de herramientas de CI / CD. CDS va un paso más y ofrece flujo de trabajo como código. Esto se realiza mediante el complemento de Git utilizando archivos de configuración YAML de su flujo de trabajo ( + Pipeline, + Aplicaciones, + entorno). Esto es particularmente útil ya que puede probar su nuevo flujo de trabajo en una rama de desarrollo, antes de fusionar los cambios en la rama maestra.
Puede modificar su flujo de trabajo con la interfaz de usuario, también puede modificar la configuración editando el archivo YAML directamente en la interfaz de usuario si lo desea. Esta es una excelente manera de aprender a usar la función de flujo de trabajo como código.
Capacidad para lanzar compilaciones basadas en un patrón de rama. Esto permite, por ejemplo, implementar ramas dev/* en "puesta en escena" e implementar la rama maestra en "prod".
Tenga en cuenta que el comportamiento predeterminado de CDS es lanzar todo el flujo de trabajo en cada confirmación de GIT. Este comportamiento se puede alterar utilizando "condiciones de ejecución".
Integración de 2 vías con productos más populares basados en GIT.
CDS es compatible con GitHub, GitLab, Bitbucket Server y Gerrit. El enlace entre su repositorio GIT y CDS es a través de una aplicación CDS: 1 repositorio de git == una aplicación CDS. A través de esta integración, los CD presionarán el estado de construcción de sus compromisos: construcción, éxito o fallido.
CDS le brinda la posibilidad de clonar de diferentes repositorios GIT dentro de un solo flujo de trabajo. Un flujo de trabajo CDS puede involucrar varias aplicaciones diferentes, o ninguna si no desea tener una conexión con un repositorio GIT.
Capacidad para iniciar servicios efímeros (una base de datos, un servidor web, etc.) para admitir su trabajo. Esto es particularmente útil al probar su código.
En CDS, estos servicios se denominan requisitos previos del servicio. Solo necesita especificar la imagen de Docker correspondiente y ejecutar Params.
Tome un ejemplo simple: tiene una tubería que crea una imagen de Docker que contiene su aplicación. Su aplicación necesita un Redis y un PostgreSQL para funcionar. Puede, en un trabajo de CDS, poner tres servicios de requisitos previos: un Redis, un PostgreSQL y su aplicación. Los CD se encargarán de hacer una red privada entre sus servicios para que puedan comunicarse entre sí. Su trabajo de CDS puede realizar pruebas de integración en su aplicación, comenzando con una base de datos real y un caché real.
Lea: https://ovh.github.io/cds/docs/concepts/requirement/requirement_service/
Un equipo de desarrolladores y/o un sistema de integración continua (IC) utiliza un caché remoto para compartir salidas de compilación. Si su compilación es reproducible, las salidas de una máquina se pueden reutilizar de manera segura en otra máquina, lo que puede hacer que las compilaciones sean significativamente más rápidas
Doc: https://ovh.github.io/cds/docs/components/worker/cache/
Como plataforma de grado empresarial, los CD pueden enviar una amplia gama de sus eventos internos (por ejemplo, construir) en un bus de eventos. Este flujo de eventos puede alimentar otros servicios (informes, notificaciones, etc.).
Capacidad para lanzar un flujo de trabajo manualmente o con Git Pushes o a través de un programador o a través de un webhook. Además de lo anterior, los CD también se pueden activar utilizando un bus de eventos (Kafka o RabbitMQ).
Capacidad para administrar múltiples entornos (por ejemplo, dev/prod/puesta en escena) de manera segura con los derechos de acceso segregados. En la práctica, un entorno es un conjunto de variables que puede usar dentro de sus flujos de trabajo.
Con CDS, puede usar una tubería de implementación en su entorno de preproducción y usar esa misma tubería de implementación en su entorno de producción. La capacidad de implementar a la producción puede limitarse a un grupo de usuarios preestablecido.
Los usuarios son libres de crear grupos y administrar usuarios en sus grupos. Un grupo puede tener derecho a leer, escribir y ejecutar sus proyectos y sus flujos de trabajo. También puede restringir la ejecución de algunas tuberías a algunos grupos si lo desea.
Si usa CD como una herramienta CI / CD, probablemente tendrá artefactos construidos. Los trabajos de CDS están aislados entre sí, pero puede pasar artefactos de un trabajo a otro utilizando las acciones de carga y descarga de artefactos de artefactos. Al final de un trabajo de CDS, todos los archivos se eliminan de los trabajadores. Para persistir artefactos, los CD pueden usar un almacenamiento Swift o un sistema de archivos determinado (aunque no se recomienda).
CDS muestra claramente los resultados de las pruebas unitarias y las vulnerabilidades detectadas durante las compilaciones.
Un proyecto de CDS es como un inquilino. Todos los usuarios pueden crear un proyecto CDS, este proyecto reunirá aplicaciones, entornos, tuberías y, por supuesto, flujos de trabajo.
Los proyectos de CDS están aislados entre sí, pero el mismo grupo puede tener derechos de acceso a múltiples proyectos si lo desea.
Un modelo de trabajador es un contexto de ejecución de trabajadores. Digamos que debe ejecutar un trabajo que requiera Golang V1.11.5. En CDS, solo necesita crear un modelo de trabajadores Go, que contiene una GO en la versión 1.11.5. Un modelo de trabajador puede ser una imagen Docker, una imagen OpenStack o una imagen vSphere. Aunque los administradores de CDS pueden ofrecer modelos de trabajadores compartidos, los usuarios pueden crear sus propios trabajadores de plantillas si lo desean.
En un proyecto CDS, puede agregar integraciones como OpenStack, Kubernetes, etc. Esto le ofrecerá características dentro de sus flujos de trabajo. Por ejemplo, con la integración de Kubernetes, puede agregar su propio clúster a su proyecto CDS y, por lo tanto, poder utilizar la acción de implementación de la aplicación para implementar su aplicación recién construida en su clúster, en formato de timón si lo desea. Por supuesto, puede desarrollar sus propias integraciones.
Después de leer los puntos anteriores, has entendido: el autoservicio está en todas partes. Todos los usuarios pueden crear su proyecto/flujo de trabajo/modelos de trabajadores/plantillas/acciones de flujo de trabajo ... y ejecutar trabajos en un entorno totalmente aislado. Los proyectos de CDS son constructores, en los que puede agregar integraciones. Todo esto le permite tener solo una instancia de CD para toda su empresa.
Todo lo que puede hacer con la interfaz de usuario está disponible a través de la interfaz de línea de comandos (CLI), llamada "CDSCTL". CDSCTL está disponible en todo el sistema operativo: Darwin, FreeBSD, Linux, OpenBSD ... CDSCTL le permitirá crear, lanzar, exportar, importar sus flujos de trabajo, monitorear sus CD y navegar a través de sus proyectos y flujos de trabajo. No es necesario ir a la interfaz de usuario de CDS o su administrador de repositorio para verificar el estado de su confirmación, git push && cdsctl workflow --track mostrará su flujo de trabajo en su línea de comando.
¿Tiene necesidades de automatización aún más avanzadas o el deseo de desarrollar una aplicación que consulte CD? La API REST y el SDK le permitirán desarrollar fácilmente su software.
CDS ha sido de código abierto desde octubre de 2016. Puede instalarlo libremente en su empresa o en el hogar. Algunos tutoriales están disponibles para ayudarlo a iniciar un CDS, Docker-Compose, instalar con binarios.
La alta disponibilidad es un punto muy importante para una herramienta CI / CD. CDS no tiene estado, no se almacena nada en el sistema de archivos. Esto permite lanzar varias API CDS detrás de un equilibrador de carga. Por lo tanto, puede escalar la API de CD a sus necesidades. También permite actualizaciones de CD en un día completo sin impacto en los usuarios. En producción @OVH, los CD se pueden actualizar varias veces al día, sin afectar a los usuarios o detener a los trabajadores de CDS. Pedirle a sus usuarios que dejen de trabajar mientras actualizan la herramienta de entrega continua sería irónico, ¿no? ;-)
CDS expone de manera nativa los datos de monitoreo. Podrá alimentar a su instancia Prometheus o Warp10 usando Beamium.
Un trabajo de CDS consiste en pasos. Cada paso es una acción de tipo incorporada (script, checkoutapplication, artefactos cargas/descarga ...). Puede crear sus acciones, usar acciones existentes, o desarrollar su acción como complemento. Todos los idiomas son compatibles, siempre que el idioma admite GRPC.
CDS es agnóstico para idiomas y plataformas. Los usuarios pueden iniciar trabajos en Linux, Windows, FreeBSD, OS X, Raspberry ... en una máquina virtual engendra a pedido, en un contenedor Docker, en un host dedicado.
Entonces, si su empresa usa múltiples tecnologías, los CD no serán un bloqueador para construir e implementar su software interno.
Uno de los objetivos iniciales de CD en OVH: construir e implementar 150 aplicaciones como contenedor en menos de 7 minutos. Esto se ha convertido en realidad desde 2015. ¿Cuál es la clave secreta? Auto a escala a pedido!
Por lo tanto, puede tener cientos de modelos de trabajadores y cuando sea necesario, los CD comenzarán a los trabajadores utilizando los criaderos.
Un criadero es como una incubadora, da a luz a los trabajadores de CDS y el derecho a la vida y la muerte sobre ellos.
Hay varios tipos de criadero disponibles:
Entonces, sí, palabras de moda o no, un Ondemand a escala automática de múltiples nubes es una realidad con CD :-)
3 cláusula BSD
