DevOps no es una herramienta, es una reacción en cadena

Bueno. Comencemos. Este artículo está destinado a dar a un principiante una introducción a algunos de los componentes clave en DevOps y cómo se ajustan juntos en el proceso de desarrollo moderno. Hay innumerables artículos web que describen el mismo tema, y no tengo la intención de proporcionar algo innovador aquí. En cambio, quiero centrarme en las señales principales - lo que se destaca como importante - para que las cosas esenciales vengan a través claramente en medio de todo el ruido. +------------------------------------------------+ | THE DEVOPS PROCESS FLOW | +==================+=============================+ | STAGE | KEY ACTION | +==================+=============================+ | 1. Code | Write and commit changes | +------------------+-----------------------------+ | 2. Build | Compile and package code | +------------------+-----------------------------+ | 3. Test | Run automated tests | +------------------+-----------------------------+ | 4. Deploy | Release to production | +------------------+-----------------------------+ | 5. Feedback | Monitor and inform new code | +------------------+-----------------------------+ | (Repeat) | The loop continues... | +------------------+-----------------------------+ Diagrama 1: Flujo de procesos de DevOps Diagrama 1: Flujo de procesos de DevOps +======================================================+ | Process Transformation: DevOps | +======================+===============================+ | STAGE | MANUAL (BEFORE) | +======================+===============================+ | Code Integration | Manual merges, "merge hell" | | Build | Run on local machine | | Test | Manual testing, slow | | Deploy | Manual scripts, risky | |----------------------+-------------------------------| | **Result** | Slow, Error-Prone, Stressful | +======================+===============================+ | STAGE | AUTOMATED (AFTER) | +======================+===============================+ | Code Integration | Auto-merge via CI server | | Build | Automated build on push | | Test | Automated tests run in pipe | | Deploy | Automated CD to production | |----------------------+-------------------------------| | **Result** | Fast, Reliable, Repeatable | +======================+===============================+ Diagrama 2: Beneficios de DevOps Diagrama 2: Beneficios de DevOps De la simple evolución a la compleja realidad Cuando pensamos en el desarrollo, generalmente lo imaginamos en términos muy simples. Un programador escribe el código, y eso se implementa en el sitio web. Pero en la práctica, el proceso puede complicarse considerablemente en un corto período de tiempo. Varios programadores podrían estar trabajando en la misma base de código. Cambios de código hechos por una persona pueden afectar lo que otra ya ha construido. Es importante rastrear quién cambió lo que y cuándo, para que sea más fácil volver a rodar si algo va mal. Es ahí donde entra un sistema de gestión de código fuente como Git - que mantiene un seguimiento de cada cambio, cada versión, y permite a varios desarrolladores colaborar de manera eficiente y sin problemas. ╔═══════════════════════════════════════════════════╗ ║ THE ILLUSION VS REALITY OF DEVELOPMENT ║ ╚═══════════════════════════════════════════════════╝ WHAT WE IMAGINE WHAT ACTUALLY HAPPENS ┌──────────────┐ ┌──────────────┐ │ Programmer │ │ Programmer A │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Code │ │ Code v1 │◄─┐ └──────┬───────┘ └──────────────┘ │ │ │ │ ▼ │ CONFLICT! ┌──────────────┐ │ │ │ Website │ ▼ │ └──────────────┘ ┌──────────────┐ │ │ Code v2 │──┘ SIMPLE └──────────────┘ ▲ │ ┌──────┴───────┐ │ Programmer B │ └──────────────┘ COMPLEX Diagrama 3: Explica la realidad del desarrollo de software Diagrama 3: Explica la realidad del desarrollo de software ╔═════════════════════════════════════════════╗ ║ THE CHANGE TRACKING CHALLENGE ║ ╚═════════════════════════════════════════════╝ BEFORE GIT (CHAOS) Week 1 Week 2 Week 3 │ │ │ ▼ ▼ ▼ Change Change Something Made Made Broke! │ │ │ └───────────┴───────────┘ │ ▼ ┌───────────────┐ │ Who did it? │ │ When? │ │ Why? │ │ How to undo? │ └───────────────┘ │ ▼ [ MYSTERY ] NEED: TRACKING SYSTEM Diagrama 4: Desarrollo de software sin Git (sistema de control de versiones) Diagrama 4: Desarrollo de software sin Git (sistema de control de versiones) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Diagrama 5: Desarrollo de software con Git (sistema de control de versiones) Diagrama 5: Desarrollo de software con Git (sistema de control de versiones) ╔═══════════════════════════════════════════════╗ ║ THE ROLLBACK SAFETY NET CONCEPT ║ ╚═══════════════════════════════════════════════╝ WITHOUT GIT Past ──────────────► Present │ ▼ ┌────────┐ │ BROKEN │ └────────┘ │ ▼ [ NO WAY BACK ] WITH GIT ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ v1 │───►│ v2 │───►│ v3 │───►│ v4 │ └────┘ └────┘ └────┘ └────┘ ▲ │ │ │ │ SOMETHING BROKE │ │ ▼ │ │ ┌────────┐ │ │ │ROLLBACK│ │ └─────────┤ TO v1 │◄──────────┘ └────────┘ SAFETY GUARANTEED Diagrama 6: Concepto de Rollback en Git Diagrama 6: Concepto de Rollback en Git El problema de la implantación manual Una vez que el código está seguro en Git, todavía tienes que llevarlo a un servidor. Antes, en los primeros días, alguien sacaría manualmente ese código, ejecutaría algunas pruebas en su propia máquina, lo empaquetaría y lo desplegaría en la producción. Los errores se escapan – desde la falta de un paso de prueba hasta la implementación en el entorno equivocado. +===================================================+ | The Manual Bottleneck Effect | +===================================================+ LOW SCALE (1x/Month) -------------------- [Commit] ---> ( 👤 ) ---> [Deploy OK] (No pressure) HIGH SCALE (10x/Week) --------------------- [Commit] --\ [Commit] -- \ [Commit] --- > ( 👤 ) --- > [ERROR] [Commit] -- / (Pressure) [CONFLICT] [Commit] --/ (Overwhelmed) [FAILURE] CONCLUSION: A human 👤 cannot process high volume. SOLUTION: Need an automated CI/CD pipeline. Diagrama 7: Implementación manual Diagrama 7: Implementación manual Automatización del proceso de construcción y prueba Una tubería CI/CD automatiza los pasos entre la escritura del código y su implementación en la producción.Cuando el código es empujado al repositorio, la tubería toma el control.Pacta el código en una compilación, luego ejecuta pruebas automatizadas: pruebas de unidades para comprobar las funciones individuales, pruebas de integración para asegurar que las diferentes partes funcionen juntas, pruebas de seguridad para detectar vulnerabilidades y pruebas de rendimiento para comprobar la salud general. Todo esto sucede sin que nadie tenga que recordar cada tarea, y se puede dar más énfasis al desarrollo de características más recientes. ╔═══════════════════════════════════════════════╗ ║ THE CI/CD PIPELINE ANATOMY ║ ╚═══════════════════════════════════════════════╝ ┌─────────────┐ │ CODE PUSHED │ │ TO REPO │ └──────┬──────┘ │ ▼ ╔══════════════════════╗ ║ CI/CD PIPELINE ║ ║ ║ ║ ┌────────────────┐ ║ ║ │ 1. PACKAGE │ ║ ║ │ (Build) │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 2. TEST │ ║ ║ │ - Unit │ ║ ║ │ - Integration│ ║ ║ │ - Security │ ║ ║ │ - Performance│ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 3. DEPLOY │ ║ ║ │ Test/Dev Env │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 4. DEPLOY │ ║ ║ │ Production │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ Gráfico 8: Pipeline CI/CD Gráfico 8: Pipeline CI/CD ╔═════════════════════════════════════════════╗ ║ THE CI/CD AUTOMATION ENGINE ║ ╚═════════════════════════════════════════════╝ DEVELOPER CI/CD DOES ALL: │ │ ┌──────────┐ │ │ Package │ ▼ └────┬─────┘ ┌────────────┐ │ │ PUSH CODE │ │ └────────────┘ ▼ │ ┌──────────┐ │ │Unit Test │ │ └────┬─────┘ │ │ │ ▼ Developer's ┌──────────┐ Job Done! │Integrate │ │ │ Test │ │ └────┬─────┘ │ │ ▼ ▼ ┌────────────┐ ┌──────────┐ │ FOCUS ON │ │ Security │ │ NEXT │ │ Scan │ │ FEATURE │ └────┬─────┘ └────────────┘ │ ▼ ┌──────────┐ │Performnce│ │ Test │ └────┬─────┘ │ ▼ ┌──────────┐ │ Deploy │ └──────────┘ Diagrama 9: Mejora de la eficiencia del desarrollador Diagrama 9: Mejora de la eficiencia del desarrollador Si todo pasa, la construcción va a un entorno de prueba o desarrollo, donde se prueba el nuevo código junto con lo que ya está en producción.Cuando las cosas parecen buenas, se implementa en vivo.Jenkins, GitHub Actions, Azure DevOps y Harness son algunos ejemplos de herramientas CI/CD populares. ╔═══════════════════════════════════════════════╗ ║ THE ENVIRONMENT PROMOTION LADDER ║ ╚═══════════════════════════════════════════════╝ ┌──────────────┐ │ CODE PUSHED │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ CI/CD RUNS │ │ TESTS │ └──────┬───────┘ │ TESTS PASS │ ▼ ╔════════════════════════╗ ║ TEST/DEV ENVIRON ║ ◄── Try Here First ║ ║ ║ New Code + Old Code ║ ║ Working Together? ║ ╚════════════╤═══════════╝ │ LOOKS GOOD │ ▼ ╔════════════════════════╗ ║ PRODUCTION ENVIRON ║ ◄── Deploy Live ║ ║ ║ Users Get Update ║ ╚════════════════════════╝ SAFE PROGRESSION TEST → PRODUCTION Diagrama 10: Entorno de ensayo/desarrollo al entorno de producción Diagrama 10: Entorno de ensayo/desarrollo al entorno de producción El problema de la coherencia ambiental Después de avanzar hasta aquí, naturalmente nos encontraremos con otro inconveniente: a veces el código funciona en el portátil de un desarrollador, pero cae en la producción porque los entornos subyacentes son diferentes.La forma en que una pieza de software interactúa con su sistema operativo, bibliotecas o versiones específicas de dependencias puede cambiar fácilmente de una máquina a otra. ╔═══════════════════════════════════════════════╗ ║ "IT WORKS ON MY MACHINE" SYNDROME ║ ╚═══════════════════════════════════════════════╝ DEVELOPER'S LAPTOP PRODUCTION SERVER ┌──────────┐ ┌──────────┐ │ CODE │ │ CODE │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Python │ │ Python │ │ 3.9 │ │ 3.7 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Library │ │ Library │ │ v2.0 │ │ v1.5 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ OS │ │ OS │ │ Ubuntu22 │ │ Ubuntu20 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ [ ✓ WORKS ] [ ✗ CRASHES ] THE ENVIRONMENT MISMATCH PROBLEM Diagrama 11: El problema de la incompatibilidad ambiental Diagrama 11: El problema de la incompatibilidad ambiental ╔═══════════════════════════════════════════════╗ ║ THE ISOLATION LAYER VISUALIZATION ║ ╚═══════════════════════════════════════════════╝ WITHOUT CONTAINERS ┌───────────────────────────┐ │ Operating System │ │ │ │ App1 App2 App3 App4 │ │ │ │ │ │ │ │ └─────┴─────┴─────┘ │ │ │ │ │ Shared Resources │ │ (Conflicts!) │ └───────────────────────────┘ WITH CONTAINERS ┌───────────────────────────┐ │ Operating System │ ├───────────────────────────┤ │ ╔═══╗ ╔═══╗ ╔═══╗ ╔═══╗ │ │ ║App║ ║App║ ║App║ ║App║ │ │ ║ 1 ║ ║ 2 ║ ║ 3 ║ ║ 4 ║ │ │ ╚═══╝ ╚═══╝ ╚═══╝ ╚═══╝ │ │ │ │ Each Isolated & Protected │ └───────────────────────────┘ Diagrama 12 : Beneficios del aislamiento Diagrama 12 : Beneficios del aislamiento Es por eso que se introdujeron los contenedores.Un contenedor actúa como un pequeño paquete: envuelve todo lo que necesita una aplicación - su código, tiempo de ejecución, herramientas del sistema, bibliotecas - para que pueda funcionar de la misma manera independientemente de dónde se despliega.Los contenedores aíslan la aplicación del entorno subyacente, haciendo que "funcione en mi máquina" sea algo del pasado. De las diversas tecnologías de contenedores, Docker es una de las más populares. Docker hace que sea fácil crear, implementar, probar y administrar contenedores. Como resultado, tu aplicación se ejecuta de la misma manera en todas partes, desde máquinas locales hasta servidores de producción. ╔══════════════════════════════════════════════╗ ║ THE DEPENDENCY ISOLATION SHIELD ║ ╚══════════════════════════════════════════════╝ HOST MACHINE (ANY OS) ┌────────────────────────────────────┐ │ │ │ ╔═══════════════════════════════╗ │ │ ║ CONTAINER SHIELD ║ │ │ ║ ║ │ │ ║ ┌─────────────────────────┐ ║ │ │ ║ │ YOUR APPLICATION │ ║ │ │ ║ │ │ ║ │ │ ║ │ • Code │ ║ │ │ ║ │ • Runtime │ ║ │ │ ║ │ • System Tools │ ║ │ │ ║ │ • Libraries │ ║ │ │ ║ │ • Dependencies │ ║ │ │ ║ │ │ ║ │ │ ║ └─────────────────────────┘ ║ │ │ ║ ║ │ │ ║ ISOLATED FROM HOST ║ │ │ ╚═══════════════════════════════╝ │ │ │ │ Host Changes Don't Affect App! │ └────────────────────────────────────┘ Diagrama 13: Diseño de contenedores Diagrama 13: Diseño de contenedores ╔═══════════════════════════════════════════════╗ ║ FROM LOCAL DEVELOPMENT TO PRODUCTION ║ ╚═══════════════════════════════════════════════╝ SINGLE CONTAINER ╔═════════════╗ ║ Docker ║ ║ Container ║ ╚══════╤══════╝ │ │ DEPLOY JOURNEY │ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ LOCAL │ │ STAGING │ │ PROD │ │ DEV │ │ SERVER │ │ SERVER │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ [IDENTICAL] [IDENTICAL] [IDENTICAL] NO CONFIGURATION DRIFT! NO ENVIRONMENT SURPRISES! PREDICTABLE DEPLOYMENTS! Diagrama 14: Las aplicaciones en los contenedores de Docker funcionan de manera idéntica en todos los entornos Diagrama 14: Las aplicaciones en los contenedores de Docker funcionan de manera idéntica en todos los entornos El reto de la orquestación Docker es perfecto para empaquetar aplicaciones de forma consistente, pero cuando tienes muchos contenedores en producción para cosas como servidores web, bases de datos, cachés y microservicios, la gestión manual no puede seguir adelante. ╔═════════════════════════════════════════════╗ ║ THE ORCHESTRATION REQUIREMENT ║ ╚═════════════════════════════════════════════╝ PRODUCTION REALITY Web Server Database Cache APIs Containers Containers Containers Containers │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐┌────┐ ┌────┐┌────┐ ┌────┐ ┌────┐ │ W1 ││ W2 │ │ D1 ││ D2 │ │ C1 │ │ A1 │ └────┘└────┘ └────┘└────┘ └────┘ └────┘ ┌────┐┌────┐ ┌────┐ │ W3 ││ W4 │ │ A2 │ └────┘└────┘ └────┘ MANUAL QUESTIONS: • Which container crashed? • How to reroute traffic? • When to scale up/down? • How to connect them? ▼ NEED ORCHESTRATOR ▼ KUBERNETES! Diagrama 15: Necesidad de orquestación de contenedores Diagrama 15: Necesidad de orquestación de contenedores Kubernetes es una capa de orquestación en la parte superior de Docker. Gestiona automáticamente los contenedores - reiniciar los fallidos, escalar o bajar, equilibrar el tráfico y conectar los contenedores. Docker gestiona la containerización; Kubernetes gestiona la orquestación a través de su infraestructura, ya sea en la nube (AWS, Azure, Google Cloud) o en el lugar. ╔═════════════════════════════════════════════╗ ║ THE AUTOMATIC MANAGEMENT LOOP ║ ╚═════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ CONTROL PLANE ║ ╚═════════╤═════════════╝ │ Constantly Monitors │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ A │ │ B │ │ C │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────┼─────────────┘ │ Reports Status │ ▼ ╔═══════════════════╗ ║ AUTO ACTIONS: ║ ║ • Restart ║ ║ • Scale ║ ║ • Balance ║ ║ • Link ║ ╚═══════════════════╝ CONTINUOUS AUTOMATION Capítulo 16: Gestión automática Capítulo 16: Gestión automática ╔══════════════════════════════════════════════╗ ║ THE FAILED CONTAINER AUTO-RECOVERY ║ ╚══════════════════════════════════════════════╝ TIME LINE t=0 t=1 t=2 t=3 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌─────────┐ │Running │ │Crashed!│ │Detected│ │Restarted│ └────────┘ └───╳────┘ └────────┘ └─────────┘ │ │ │ │ ▼ │ │ ╔═══════════════╗ │ │ ║ KUBERNETES ║ │ └───►║ Monitors ║ │ ║ & Acts ║───┘ ╚═══════════════╝ AUTOMATIC HEALING NO MANUAL INTERVENTION Diagrama 17: Recuperación automática Diagrama 17: Recuperación automática ╔═══════════════════════════════════════════════╗ ║ THE SCALING AUTOMATION ENGINE ║ ╚═══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Watches Metrics ║ ╚═══════╤═══════════════╝ │ ┌───────────┴───────────┐ │ │ LOW DEMAND HIGH DEMAND │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Scale │ │ Scale │ │ DOWN │ │ UP │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌────┐ ┌────┐┌────┐ │ C1 │ │ C1 ││ C2 │ └────┘ └────┘└────┘ ┌────┐┌────┐ 1 Container │ C3 ││ C4 │ Enough └────┘└────┘ 4 Containers Needed ELASTIC SCALING Diagrama 18: Escalado elástico Diagrama 18: Escalado elástico ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD Diagrama 19: Balance de carga Diagrama 19: Balance de carga ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS Diagrama 20: Enlace de contenedores Diagrama 20: Enlace de contenedores ╔═════════════════════════════════════════════╗ ║ THE DIVISION OF RESPONSIBILITIES ║ ╚═════════════════════════════════════════════╝ DOCKER'S JOB KUBERNETES' JOB ┌─────────────┐ ┌─────────────┐ │ CREATE │ │ DEPLOY │ │ Containers │ │ Where? │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ PACKAGE │ │ MONITOR │ │ Application │ │ Health │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ RUN │ │ SCALE │ │ Containers │ │ Count │ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ │ MANAGE │ │ Lifecycle │ └─────────────┘ CONTAINERIZATION ORCHESTRATION Diagrama 21: Modelo de responsabilidad compartida Diagrama 21: Modelo de responsabilidad compartida Observar lo que sucede en la producción La tarea no se completa después de la implementación. Es esencial observar cómo la aplicación realmente se ejecuta en la producción. ¿se acumulan errores? ¿es lenta la aplicación? Herramientas de monitoreo rastrean métricas como la utilización de la CPU, la utilización de la memoria, los tiempos de respuesta y las tasas de error. El registro captura lo que la aplicación está haciendo y los errores que ocurren. Cuando algo va mal, esta infraestructura le ayuda a encontrar y corregir rápidamente los problemas antes de que los usuarios finales lo notifiquen. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ Diagrama 22: Monitorización, registro y respuesta a incidentes Diagrama 22: Monitorización, registro y respuesta a incidentes ╔══════════════════════════════════════════════╗ ║ DETECTING ISSUES BEFORE USERS ║ ╚══════════════════════════════════════════════╝ WITHOUT MONITORING Error Occurs ──► User Complains ──► Fix │ │ └───────────────────┘ Hours/Days Later! WITH MONITORING Error Occurs │ ▼ ╔═════════════╗ ║ MONITORING ║ ║ Detects ║ ──► Alerts Team ║ Instantly ║ ╚═════╤═══════╝ │ ▼ Team Fixes Issue │ ▼ Users Never Know! PROACTIVE > REACTIVE Diagrama 23: Respuesta Proactiva Diagrama 23: Respuesta Proactiva Lo que uno debe tener en cuenta Cualquiera que quiera obtener más experiencia en DevOps también debe centrarse en comprender los diferentes tipos de pruebas automatizadas que se escriben. ╔══════════════════════════════════════════════╗ ║ THINKING THROUGH USE & MISUSE ║ ╚══════════════════════════════════════════════╝ ┌─────────────────┐ │ FEATURE TO │ │ BE TESTED │ └────────┬────────┘ │ Think About: │ ┌────────────┴────────────┐ │ │ ▼ ▼ ┌───────────┐ ┌───────────┐ │ NORMAL │ │ ABNORMAL │ │ USE │ │ USE │ │ │ │ │ │• Expected │ │• Wrong │ │ Inputs │ │ Inputs │ │• Happy │ │• Edge │ │ Path │ │ Cases │ │• Valid │ │• Malicious│ │ Flow │ │ Intent │ └─────┬─────┘ └─────┬─────┘ │ │ └────────────┬────────────┘ │ ▼ [ COMPREHENSIVE TEST COVERAGE ] Diagrama 24: Consideraciones de la prueba Diagrama 24: Consideraciones de la prueba Las opciones aquí deben trabajar con el resto de su ecosistema DevOps - proveedor de nube, herramienta CI / CD, plataforma de automatización. Por ejemplo, Jenkins (una herramienta CI / CD) se integra con varios idiomas, incluyendo Python y marcos como pytest, por lo que es crucial saber qué herramientas funcionan bien juntos. ╔═════════════════════════════════════════════╗ ║ THE DEVOPS ECOSYSTEM COMPATIBILITY ║ ╚═════════════════════════════════════════════╝ ┌─────────────────┐ │ TEST CHOICE │ └────────┬────────┘ │ Must Work With: │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Cloud │ │ CI/CD │ │Automation│ │ Provider │ │ Tool │ │ Platform │ │ │ │ │ │ │ │AWS/Azure │ │ Jenkins │ │ Etc. │ │ /GCP │ │ GitHub │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ INTEGRATION ║ ║ IS CRITICAL ║ ╚═══════════════╝ Gráfico 25: Compatibilidad con los ecosistemas Gráfico 25: Compatibilidad con los ecosistemas envuelve Este es un punto de partida para hacer sentido de DevOps, conectando los pasos desde el código y la colaboración a la automatización e infraestructura hasta el monitoreo y el feedback. Cada capa aparece para abordar un problema que no se podía resolver con el anterior solo. Como este paisaje continúa evolucionando, notar esas transiciones clave es lo que ayuda a convertir las implementaciones complicadas en algo que realmente funciona. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ Capítulo 26: Resumen Capítulo 26: Resumen Más que nada, DevOps se trata de entender cómo se ajustan las piezas y por qué cada una de ellas es necesaria, en lugar de simplemente aprender herramientas aisladas. Si tienes alguna pregunta, no dudes en enviarme un correo electrónico.También puedes ponerte en contacto conmigo a través de LinkedIn.También puedes seguirme en X. El email El email Linkedin Linkedin . X X Puedes leer mi artículo en system design . Aquí Aquí Si desea que escriba sobre cualquier otro tema, por favor déjame saber en los comentarios. Enlace a mi . Perfil de hacker