DevOps – это не инструмент, это цепная реакция

Давайте начнем. Эта статья предназначена для того, чтобы дать начинающему представление о некоторых ключевых компонентах DevOps и о том, как они сочетаются в современном процессе разработки. Существуют бесчисленные веб-статьи, описывающие одну и ту же тему, и я не собираюсь предоставлять здесь что-то новаторское. +------------------------------------------------+ | 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... | +------------------+-----------------------------+ Диаграмма 1: Поток процессов DevOps Диаграмма 1: Поток процессов 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 | +======================+===============================+ Диаграмма 2: Преимущества DevOps Диаграмма 2: Преимущества DevOps От простого развития к сложной реальности Когда мы думаем о разработке, мы обычно представляем это в очень простых терминах. Программист пишет код, и он реализуется на веб-сайте. Но на практике процесс может быть значительно сложнее за короткий промежуток времени. Многочисленные программисты могут работать на одной кодовой базе. Изменения кода, сделанные одним человеком, могут повлиять на то, что уже построил другой. Именно здесь входит система управления исходным кодом, такая как Git - она отслеживает каждое изменение, каждую версию и позволяет нескольким разработчикам эффективно и беспрепятственно сотрудничать. ╔═══════════════════════════════════════════════════╗ ║ 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 Диаграмма 3: объясняет реальность разработки программного обеспечения Диаграмма 3: объясняет реальность разработки программного обеспечения ╔═════════════════════════════════════════════╗ ║ 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 Диаграмма 4: Разработка программного обеспечения без Git (система управления версиями) Диаграмма 4: Разработка программного обеспечения без Git (система управления версиями) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Диаграмма 5: Разработка программного обеспечения с помощью Git (система управления версиями) Диаграмма 5: Разработка программного обеспечения с помощью Git (система управления версиями) ╔═══════════════════════════════════════════════╗ ║ 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 Диаграмма 6: Концепция Rollback в Git Диаграмма 6: Концепция Rollback в Git Проблема ручного развертывания Как только код будет безопасным в Git, вы все еще должны получить его на сервер. Раньше, в первые дни, кто-то вручную вытащил этот код, запустил некоторые тесты на своей машине, упаковал его и развернул в производство. Ошибки пропускаются — от пропущенного испытательного шага до развертывания в неправильной среде. +===================================================+ | 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. Диаграмма 7: Ручное развертывание Диаграмма 7: Ручное развертывание Автоматизация процесса построения и тестирования Трубопровод CI/CD автоматизирует шаги между написанием кода и его развертыванием в производстве.Когда код выталкивается в хранилище, трубопровод берет на себя ответственность.Он упаковывает код в конструкцию, а затем запускает автоматизированные тесты - единичные тесты для проверки отдельных функций, тесты интеграции для обеспечения совместной работы различных частей, сканирование безопасности для обнаружения уязвимостей и тесты производительности для проверки общего состояния здоровья. Все это происходит без необходимости запоминать каждую задачу, и больше внимания можно уделить разработке новых функций. ╔═══════════════════════════════════════════════╗ ║ 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 │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ Диаграмма 8: трубопровод CI/CD Диаграмма 8: трубопровод 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 │ └──────────┘ Диаграмма 9: Улучшение эффективности разработчиков Диаграмма 9: Улучшение эффективности разработчиков Если все пройдет, build перейдет в среду тестирования или разработки, где новый код будет опробован наряду с тем, что уже в производстве.Когда все хорошо выглядит, он будет развернут в реальном времени.Jenkins, GitHub Actions, Azure DevOps и Harness являются некоторыми примерами популярных инструментов CI/CD. ╔═══════════════════════════════════════════════╗ ║ 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 Диаграмма 10: Окружающая среда испытаний/деве до производственной среды Диаграмма 10: Окружающая среда испытаний/деве до производственной среды Проблема экологической последовательности После прогресса до этого мы, естественно, столкнемся с еще одним неудобством: иногда код работает на ноутбуке разработчика, но сбои в производстве, потому что основные среды отличаются. ╔═══════════════════════════════════════════════╗ ║ "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 Диаграмма 11: Проблема экологического несоответствия Диаграмма 11: Проблема экологического несоответствия ╔═══════════════════════════════════════════════╗ ║ 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 │ └───────────────────────────┘ Диаграмма 12 : Преимущества изоляции Диаграмма 12 : Преимущества изоляции Вот почему контейнеры были введены.Контейнер действует как небольшой пакет: он включает в себя все, что требуется приложению - его код, время запуска, системные инструменты, библиотеки - так что он может работать одинаково независимо от того, где он развернут.Контейнеры изолируют приложение от основной среды, делая «это работает на моей машине» вещью прошлого. Из различных контейнерных технологий Docker является одной из самых популярных. Docker облегчает создание, развертывание, тестирование и управление контейнерами. В результате, ваше приложение работает одинаково везде - от локальных машин до производственных серверов. ╔══════════════════════════════════════════════╗ ║ 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! │ └────────────────────────────────────┘ Диаграмма 13: Контейнерный дизайн Диаграмма 13: Контейнерный дизайн ╔═══════════════════════════════════════════════╗ ║ 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! Диаграмма 14 : Приложения в контейнерах Docker работают одинаково во всех средах Диаграмма 14 : Приложения в контейнерах Docker работают одинаково во всех средах Вызов оркестрации Docker идеально подходит для последовательного упаковки приложений, но когда у вас много контейнеров в производстве для вещей, таких как веб-серверы, базы данных, кэши и микросервисы, ручное управление не может идти в ногу. ╔═════════════════════════════════════════════╗ ║ 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! Диаграмма 15: Необходимость оркестрации контейнеров Диаграмма 15: Необходимость оркестрации контейнеров Kubernetes - это слой оркестрации на вершине Docker. Он автоматически управляет контейнерами - перезагружая неудачные, масштабируя или понижая, балансируя трафик и связывая контейнеры. Docker обрабатывает контейнеризацию; Kubernetes обрабатывает оркестрацию по всей вашей инфраструктуре, будь то в облаке (AWS, Azure, Google Cloud) или на месте. ╔═════════════════════════════════════════════╗ ║ 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 Диаграмма 16: Автоматическое управление Диаграмма 16: Автоматическое управление ╔══════════════════════════════════════════════╗ ║ 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 Диаграмма 17: Автовосстановление Диаграмма 17: Автовосстановление ╔═══════════════════════════════════════════════╗ ║ 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 Диаграмма 18: Эластичное масштабирование Диаграмма 18: Эластичное масштабирование ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD Диаграмма 19: Балансирование нагрузки Диаграмма 19: Балансирование нагрузки ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS Диаграмма 20: Подключение контейнеров Диаграмма 20: Подключение контейнеров ╔═════════════════════════════════════════════╗ ║ 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 Диаграмма 21: Модель совместной ответственности Диаграмма 21: Модель совместной ответственности Смотреть что происходит в производстве Задача не завершается после развертывания. Важно наблюдать, как приложение на самом деле работает в производстве. Набираются ли ошибки? является ли приложение медленным? Инструменты мониторинга отслеживают показатели, такие как использование процессора, использование памяти, время отклика и скорость ошибок. Логирование записывает то, что делает приложение, и ошибки, которые происходят. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ Диаграмма 22: Мониторинг, регистрация и реагирование на инциденты Диаграмма 22: Мониторинг, регистрация и реагирование на инциденты ╔══════════════════════════════════════════════╗ ║ 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 Диаграмма 23: Проактивный ответ Диаграмма 23: Проактивный ответ Что нужно иметь в виду Любой, кто хочет получить больше опыта в DevOps, должен также сосредоточиться на понимании различных типов автоматизированных тестов, которые пишутся. ╔══════════════════════════════════════════════╗ ║ 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 ] Диаграмма 24: Тестирование рассмотрения Диаграмма 24: Тестирование рассмотрения Опыт языков программирования, знание API, знания домена и осведомленность о тестировании рамок помогают.Выбор здесь должен работать с остальной частью экосистемы DevOps - облачным поставщиком, инструментом CI/CD, платформой автоматизации. Например, Jenkins (инструмент CI/CD) интегрируется с различными языками, включая Python и рамки, такие как pytest, поэтому важно знать, какие инструменты хорошо работают вместе. ╔═════════════════════════════════════════════╗ ║ 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 ║ ╚═══════════════╝ Диаграмма 25: Совместимость экосистем Диаграмма 25: Совместимость экосистем Вверх Вверх Это отправной пункт для создания смысла DevOps, соединения шагов от кода и сотрудничества до автоматизации и инфраструктуры до мониторинга и обратной связи. Каждый слой появляется, чтобы решить проблему, которую нельзя было решить только с предыдущим. Поскольку этот ландшафт продолжает развиваться, заметив эти ключевые переходы, помогает превратить сложные развертывания в нечто, что действительно работает. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ Диаграмма 26: Резюме Диаграмма 26: Резюме Более того, DevOps - это понимание того, как части сочетаются друг с другом и почему каждая из них необходима, а не просто обучение инструментам в изоляции. Если у вас есть какие-либо вопросы, пожалуйста, не стесняйтесь отправлять мне электронное письмо. Вы также можете связаться со мной через LinkedIn. Вы также можете следить за мной на X. Электронная Электронная Линкейн Линкейн . X X Вы можете прочитать нашу статью на system design . here здесь Если вы хотите, чтобы я писал по любой другой теме, пожалуйста, сообщите мне в комментариях. Линк к моему . Профиль хакера