DevOps — це культура та практики, які об’єднують розробку і експлуатацію для швидкої та надійної доставки змін.

Коротко:

• Спільна відповідальність Dev + Ops.
• Автоматизація і швидкий фідбек.
• Стабільні релізи з меншим ризиком.

DevOps інженер будує CI/CD, IaC, моніторинг, керує середовищами і покращує процеси доставки.

Коротко:

• Автоматизує шлях від коду до production.
• Зменшує ручну роботу і помилки.
• Працює на стику dev, ops і security.

Ключові принципи: collaboration, automation, continuous improvement, observability, security by design.

Коротко:

• Часті невеликі зміни.
• Вимірюваність через метрики.
• Безперервне покращення процесу.

DevOps прискорює релізи через CI/CD, автоматичні тести, стандартизацію і моніторинг після деплою.

Коротко:

• Коротший release cycle.
• Вища якість і стабільність.
• Швидше відновлення після збоїв.

Типово: Plan -> Code -> Build -> Test -> Release -> Deploy -> Operate -> Monitor.

Коротко:

• Це безперервний цикл.
• Дані з Monitor повертаються в Plan.
• Автоматизація на кожному етапі.

Переваги: швидші релізи, менше інцидентів, краща взаємодія команд, нижчий MTTR.

Коротко:

• Швидкість + надійність.
• Прозорість процесів.
• Кращий time-to-market.

Почав би з цілей і KPI, далі Git workflow, CI/CD, IaC, observability, security checks, регулярні ретроспективи.

Коротко:

• Спочатку процес, потім інструменти.
• Pipeline as code + IaC.
• Постійне вимірювання результатів.

Agile — про гнучку розробку продукту, DevOps — про доставку й експлуатацію змін у production.

Коротко:

• Agile і DevOps доповнюють одне одного.
• Agile: що і як розробляти.
• DevOps: як стабільно постачати і підтримувати.

Найчастіше — DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.

Коротко:

• Міряємо швидкість і надійність одночасно.
• KPI мають бути прив’язані до бізнес-цілей.
• Метрики потрібні для покращень, не для формальності.

Через потребу бізнесу швидко випускати зміни без втрати якості, плюс розвиток cloud, containers, IaC і CI/CD інструментів.

Коротко:

• Ринок вимагає швидкості.
• Технології зробили automation доступною.
• DevOps став стандартом delivery.

Анти-патерни: ручні деплої, слабкі тести, відсутність ownership, DevOps як «окремий відділ», відкладена безпека.

Коротко:

• Інструменти без культури не працюють.
• Ручні кроки = ризик помилок.
• Security має бути в процесі з початку.

Shift Left — перенос перевірок якості й безпеки на ранні етапи розробки.

Коротко:

• Раніше знайдена помилка дешевша.
• Тести і скани запускаються в CI.
• Менше дефектів у production.

Continuous Testing — автоматичні перевірки на всіх етапах pipeline, а не лише перед релізом.

Коротко:

• Постійний фідбек про якість.
• Швидке виявлення регресій.
• База для стабільного CI/CD.

Test Automation — автоматизація запуску та перевірки тестів (unit, integration, e2e тощо).

Коротко:

• Менше ручної роботи.
• Повторювані результати.
• Безпечні часті релізи.

ChatOps — виконання операційних дій через чат-ботів та інтеграції в командних чатах.

Коротко:

• Швидка координація під час інцидентів.
• Прозорий журнал дій.
• Зручний командний інтерфейс.

Впевнений advanced рівень: адміністрування, troubleshooting, процеси, мережа, systemd, shell automation.

Коротко:

• Сильний production-досвід.
• Орієнтація на root cause.
• Автоматизація типових операцій.

ls, find, grep, awk, sed, tail, journalctl, systemctl, ss, ps, top/htop, df, du, chmod, chown.

Коротко:

• Файли, логи, процеси, мережа.
• Базовий набір для щоденної роботи.
• Комбінації команд для швидкої діагностики.

top/htop, mpstat, ps --sort=-%cpu, sar -u, uptime для load average.

Коротко:

• Швидкий старт: top.
• Деталізація: mpstat, sar.
• Дивимось і %CPU, і контекст навантаження.

df -h для файлових систем, du -sh і find -size для пошуку великих файлів, df -i для inode.

Коротко:

• df показує де проблема.
• du/find показують причину.
• Перевіряйте також inode.

last, lastlog, w, who.

Коротко:

• last для історії входів.
• w/who для активних сесій.
• Корисно для аудиту і розслідувань.

Для systemd: journalctl; для файлів: tail -f, less, grep.

Коротко:

• journalctl -u <service> -f для live-аналізу.
• Фільтруйте за часом/рівнем/помилками.
• Централізований логінг обов’язковий у production.

chmod, chown, chgrp, umask; за потреби ACL (setfacl/getfacl).

Коротко:

• Права + власник + група.
• Принцип least privilege.
• ACL для тонкої грануляції доступу.

start запускає сервіс зараз, enable вмикає автозапуск при boot.

Коротко:

• start = негайний запуск.
• enable = запуск після перезавантаження.
• Часто використовують enable --now.

CPU, RAM, disk I/O, network: top, vmstat, iostat, ss, sar, плюс логи і алерти у централізованій системі.

Коротко:

• Локальні утиліти для діагностики.
• Централізований моніторинг для масштабу.
• Метрики + логи + алерти.

VCS зберігає історію змін коду, авторів змін і дозволяє повертатися до попередніх станів.

Коротко:

• Історія змін і аудит.
• Командна робота без втрат.
• Основа сучасної розробки.

Rollback, branching, code review, traceability, інтеграція з CI/CD.

Коротко:

• Безпечна командна робота.
• Прозора історія змін.
• Швидші і керовані релізи.

Централізовані мають один сервер істини; розподілені (Git) дають повну локальну копію історії кожному розробнику.

Коротко:

• Centralized: сильна залежність від сервера.
• Distributed: офлайн-робота і вища гнучкість.
• Git — стандарт distributed підходу.

Git — розподілена система контролю версій для швидкого branching, merging і спільної розробки.

Коротко:

• De facto стандарт VCS.
• Потужна робота з історією.
• База для PR-процесу.

Копіює віддалений репозиторій локально разом із історією та налаштовує origin.

Коротко:

• Створює локальну копію repo.
• Завантажує коміти і гілки.
• Готово до подальшої роботи.

git add -> git commit -> git push origin <branch>; далі відкривається PR.

Коротко:

• Commit в локальній гілці.
• Push у remote гілку.
• Merge через review.

Bare repo — Git-репозиторій без робочої директорії, використовується як серверний remote.

Коротко:

• Без working tree.
• Для push/pull, не для редагування.
• Типовий формат центрального repo.

Тимчасово зберігає незакомічені зміни, щоб переключитися на іншу задачу.

Коротко:

• «Відкласти» поточні зміни.
• Повернути через stash pop/apply.
• Корисно для швидкого контекст-switch.

Branching — ізольована лінія розробки для фіч/фіксів без впливу на основну гілку.

Коротко:

• Паралельна робота команди.
• Безпечно для main.
• Feature branch -> PR -> merge.

merge зберігає історію злиття, rebase переписує історію в лінійний вигляд.

Коротко:

• merge безпечніший для shared history.
• rebase робить історію чистішою.
• Не rebasing публічні гілки.

Конфлікт виникає, коли Git не може автооб’єднати зміни. Треба вручну обрати правильний варіант, прибрати маркери і завершити merge/rebase.

Коротко:

• Конфлікт = неоднозначність змін.
• Вирішення вручну + git add.
• Часті синхронізації зменшують конфлікти.

Інструмент binary search для пошуку коміту, що спричинив регресію.

Коротко:

• Швидкий пошук «поганого» коміту.
• Добре для складних багів.
• Працює вручну або зі скриптами.

fetch тільки завантажує зміни з remote, pull робить fetch і одразу інтегрує у поточну гілку.

Коротко:

• fetch безпечний попередній крок.
• pull одразу змінює локальну гілку.
• Для контролю часто спочатку fetch.

git show --name-only <sha> або git diff-tree --name-only -r <sha>.

Коротко:

• Найпростіше через git show.
• Підходить для аудиту комітів.
• SHA гарантує точність.

init, clone, status, add, commit, branch, switch/checkout, merge, rebase, fetch, pull, push, log, diff, show, stash, tag, revert.

Коротко:

• Повний щоденний Git-набір.
• Впевнена робота з історією.
• Акцент на безпечні операції.

Trunk-Based, GitFlow, release branches — залежно від частоти релізів і вимог до стабільності.

Коротко:

• Швидкі продукти: Trunk-Based.
• Формальні релізи: GitFlow.
• Вибір під контекст команди і продукту.

CI/CD — автоматизація інтеграції, тестування і доставки змін до середовищ.

Коротко:

• Менше ручних кроків.
• Швидші релізи.
• Вища стабільність delivery.

Source -> Build -> Test -> Package -> Deploy -> Verify -> Promote/Rollback.

Коротко:

• Кожен етап має quality gate.
• Pipeline має бути repeatable.
• Один шлях для всіх змін.

Зміни автоматично готуються до релізу, але production-деплой зазвичай затверджується вручну.

Коротко:

• Завжди release-ready стан.
• Контрольований випуск у production.
• Менший ризик великих релізів.

Кожна зміна, що пройшла всі перевірки, автоматично деплоїться у production.

Коротко:

• Максимальна швидкість delivery.
• Потребує сильних тестів.
• Критичні моніторинг і rollback.

Два однакові середовища: активне і нове. Після перевірки трафік перемикається на нове.

Коротко:

• Безпечне перемикання релізу.
• Мінімальний downtime.
• Швидкий rollback на попереднє середовище.

Нова версія поступово отримує частину трафіку; при стабільних метриках rollout розширюється.

Коротко:

• Поетапний реліз.
• Менший blast radius.
• Рішення на основі метрик.

Pipeline as code, швидкі тести, immutable artifacts, security scanning, захищені гілки, environment parity, чіткі quality gates.

Коротко:

• Швидко, прозоро, відтворювано.
• Якість і security вбудовані.
• Маленькі зміни — краща стабільність.

Flaky тести, довгі pipeline, різниця середовищ, слабка культура review, некеровані секрети, відсутність ownership.

Коротко:

• Технічні й культурні проблеми пов’язані.
• Без стабільних тестів довіри до pipeline не буде.
• Впроваджувати краще поетапно.

Least privilege, vault для секретів, SAST/SCA/скан образів, підпис артефактів, захист гілок, ізоляція runner-ів, аудит.

Коротко:

• Security на кожному етапі pipeline.
• Контроль доступів і секретів — пріоритет.
• Supply chain security обов’язкова.

Зупинити rollout, повернути трафік/версію на last known good release, перевірити health, провести RCA.

Коротко:

• Rollback має бути автоматизований.
• Потрібні immutable артефакти.
• Після відкату — аналіз причини.

docker build -> тести/скани -> docker login -> docker push з versioned tag (краще SHA), далі deploy цим тегом.

Коротко:

• Build, verify, push, deploy.
• Не покладатися лише на latest.
• Версіонування і перевірка образів критичні.

Jenkins — це open-source automation server для CI/CD: збірка, тестування і деплой застосунків через pipeline.

Коротко:

• Один із найпоширеніших CI/CD інструментів.
• Підтримує плагіни та інтеграції з VCS/Cloud.
• Дозволяє автоматизувати повний delivery цикл.

У Jenkins контролер (раніше master) керує job-ами і розподіляє виконання на агенти (workers/nodes), де реально запускаються build/test/deploy задачі.

Коротко:

• Controller керує оркестрацією.
• Agents виконують навантаження.
• Дає масштабованість і ізоляцію середовищ.

Jenkinsfile — файл у репозиторії, де pipeline описаний як код (Pipeline as Code), зазвичай на Groovy DSL.

Коротко:

• Пайплайн зберігається поруч із кодом.
• Є version control і code review для CI/CD логіки.
• Спрощує відтворюваність і стандартизацію.

• stage — логічний етап пайплайну (Build, Test, Deploy).
• step — конкретна дія всередині stage (sh, checkout, archiveArtifacts).
• node — агент/виконавець, де запускаються steps.

Коротко:

• stage = блок етапу.
• step = команда/операція.
• node = середовище виконання.

Scripted pipeline — гнучкий Groovy-скрипт із програмною логікою. Declarative pipeline — більш структурований синтаксис із чіткими секціями (pipeline, stages, post), простіший для підтримки.

Коротко:

• Scripted: максимум гнучкості.
• Declarative: краща читабельність і стандартизація.
• У більшості команд базово обирають Declarative.

Через Build Triggers у job: Build periodically з cron-виразом Jenkins (наприклад, H/15 * * * *), або через webhook події з Git.

Коротко:

• Розклад задається cron-форматом Jenkins.
• Можна запускати і по подіях (push/PR/webhook).
• Часто комбінують schedule і event-trigger.

У Jenkins UI: New Item -> вибрати тип (Freestyle, Pipeline, Multibranch Pipeline) -> налаштувати source, triggers, stages/steps -> Save.

Коротко:

• Створення починається з New Item.
• Для CI/CD зазвичай використовують Pipeline.
• Краще одразу налаштувати через Jenkinsfile.

Типові способи:

• через systemd: sudo systemctl restart jenkins;
• безпечний перезапуск після завершення job: /safeRestart;
• миттєвий перезапуск: /restart (залежить від налаштувань і прав).

Коротко:

• Найчастіше: systemctl restart jenkins.
• Для production бажано safeRestart.
• Потрібні admin-права.

Бекаплять каталог JENKINS_HOME (jobs, config, plugins, credentials) через snapshot/архівацію або спеціальні backup-плагіни; перед відновленням важлива сумісність версій Jenkins і плагінів.

Коротко:

• Основа бекапу: JENKINS_HOME.
• Робіть регулярні автоматичні backup + тест restore.
• Версії Jenkins/плагінів мають збігатися при відновленні.

Jenkins підтримує локальні акаунти, LDAP/Active Directory, SSO через SAML/OIDC (через плагіни), матричні моделі авторизації та інтеграцію з role-based access control.

Коротко:

• Є локальна, directory-based і SSO автентифікація.
• Для enterprise типово LDAP/AD або OIDC/SAML.
• Безпека залежить від правильної авторизації (RBAC/roles).

Найчастіше використовував: EC2, VPC, ALB/NLB, Auto Scaling, S3, RDS, IAM, CloudWatch, CloudTrail, Lambda, API Gateway, ECR, ECS/EKS, CodePipeline, CodeBuild, Systems Manager, Route 53, Secrets Manager.

Коротко:

• Використовую core AWS сервіси для compute, network, storage і CI/CD.
• Вибір сервісу залежить від вимог до вартості, масштабу й надійності.
• Основний фокус: automation, security, observability.

Базові стани EC2: pending, running, stopping, stopped, shutting-down, terminated.

Коротко:

• running — інстанс активний.
• stopped — зупинений, але може бути знову запущений.
• terminated — остаточно видалений стан.

VPC (Virtual Private Cloud) — логічно ізольована віртуальна мережа в AWS, де ви керуєте CIDR, підмережами, маршрутизацією, доступом і мережевою безпекою.

Коротко:

• VPC — мережевий фундамент в AWS.
• Дозволяє сегментувати середовище на public/private subnet.
• Керує трафіком і ізоляцією ресурсів.

VPC Peering — приватне мережеве з’єднання між двома VPC для прямого обміну трафіком через AWS backbone без використання Internet Gateway.

Коротко:

• Прямий приватний зв’язок між VPC.
• Потрібне налаштування route tables в обох VPC.
• Транзитивність через peering не підтримується.

Типові варіанти: через Bastion Host, AWS Systems Manager Session Manager, через VPN/Direct Connect або через AWS Client VPN.

Найбезпечніший сучасний підхід часто — Session Manager без відкриття SSH-порту.

Коротко:

• Bastion або Session Manager — базові методи доступу.
• Приватна subnet зазвичай без прямого інтернет-доступу.
• Перевага за SSM: менше attack surface.

Security Group — stateful firewall на рівні ENI/інстансу (дозволяючі правила). NACL — stateless firewall на рівні subnet (allow/deny правила для inbound і outbound).

Коротко:

• SG: stateful, instance-level.
• NACL: stateless, subnet-level.
• Зазвичай SG — основний контроль, NACL — додатковий периметр.

AWS відповідає за безпеку "of the cloud" (фізична інфраструктура, базові сервіси), а клієнт — за безпеку "in the cloud" (дані, IAM, конфігурації, мережеві правила, ОС/застосунки залежно від сервісу).

Коротко:

• Відповідальність ділиться між AWS і клієнтом.
• Чим ближче до IaaS, тим більше відповідальності у клієнта.
• Неправильна конфігурація клієнта залишається ризиком клієнта.

S3 Versioning зберігає кілька версій одного об’єкта в бакеті, що допомагає відновлювати дані після випадкового перезапису або видалення.

Коротко:

• Кожна зміна об’єкта отримує нову версію.
• Спрощує recovery і аудит змін.
• Важливо враховувати вплив на вартість зберігання.

S3 Object Lock запобігає видаленню або зміні об’єктів протягом заданого періоду (retention), підтримує режими Governance і Compliance, що корисно для регуляторних вимог і immutable backups.

Коротко:

• Захист від модифікації/видалення до кінця retention.
• Підтримує WORM-підхід.
• Важливий для комплаєнсу та ransomware-захисту.

CloudWatch збирає метрики, логи та події з AWS сервісів і застосунків, дозволяє будувати дашборди, створювати алерти та автоматичні реакції (наприклад через EventBridge/Lambda).

Коротко:

• Централізований моніторинг і алертинг в AWS.
• Метрики + логи + події в одному контурі.
• Основа операційної видимості та реагування.

Використовують стандартні метрики EC2 (CPU, network, status checks), CloudWatch Agent для memory/disk, CloudWatch Alarms для порогів, dashboards і Logs для системних журналів.

Коротко:

• Базово: CPU, network, status checks.
• Через Agent додаються memory/disk метрики.
• Алерти мають бути прив’язані до SLO і runbooks.

Основні: CodeCommit, CodeBuild, CodeDeploy, CodePipeline, CloudFormation, Systems Manager, CloudWatch, X-Ray, ECR/ECS/EKS, Lambda, SAM/CDK.

Також активно використовують інтеграцію з Terraform, GitHub Actions, Jenkins.

Коротко:

• AWS має повний набір для build/test/deploy/operate.
• IaC інструменти: CloudFormation і CDK.
• Легко комбінується з зовнішніми DevOps-платформами.

Створюєте Lambda-функцію, далі API Gateway (HTTP/REST API), додаєте маршрут, вказуєте Lambda integration, налаштовуєте permissions (invoke), deploy stage, після чого endpoint API викликає Lambda.

Коротко:

• API Gateway виступає HTTP-фронтом для Lambda.
• Потрібні коректні IAM permissions і stage deployment.
• Патерн часто використовується для serverless API.

Infrastructure as Code (IaC) — підхід, за якого інфраструктура описується кодом і керується так само, як застосунок: через VCS, review, CI/CD і автоматичні деплої.

Коротко:

• Інфраструктура створюється та змінюється кодом.
• Дає відтворюваність і контроль змін.
• Основа масштабованого DevOps-процесу.

Переваги: швидкість розгортання, repeatability, менше ручних помилок, versioning, audit trail, простіший disaster recovery, стандартизація середовищ.

Коротко:

• Швидше і стабільніше керування інфраструктурою.
• Прозора історія змін і rollback можливості.
• Менше configuration drift між середовищами.

Terraform — open-source IaC-інструмент від HashiCorp, який декларативно описує ресурси в HCL і керує ними через plan/apply та state-файл.

Коротко:

• Універсальний IaC для multi-cloud.
• Декларативний підхід і багата екосистема провайдерів.
• Критично важливе коректне управління state.

CloudFormation — нативний AWS IaC-сервіс для опису та керування ресурсами через JSON/YAML шаблони і stack-модель.

Коротко:

• AWS-native підхід до IaC.
• Керує ресурсами через stacks.
• Добра інтеграція з AWS екосистемою.

Declarative IaC описує бажаний кінцевий стан, а інструмент сам вирішує, як до нього дійти. Imperative IaC описує конкретні кроки виконання.

Коротко:

• Declarative: "що має бути".
• Imperative: "як це зробити".
• Для масштабування частіше використовують declarative підхід.

Terraform module — повторно використовуваний набір ресурсів/логіки (файли main.tf, variables.tf, outputs.tf) для стандартизації типових шаблонів інфраструктури.

Коротко:

• Module = reusable building block.
• Зменшує дублювання конфігурацій.
• Спрощує підтримку й governance.

Configuration drift — розбіжність між фактичним станом інфраструктури і тим, що описано в IaC, зазвичай через ручні зміни поза кодом.

Коротко:

• Drift порушує передбачуваність середовища.
• Ускладнює деплоя і troubleshooting.
• Лікується IaC discipline, policy і регулярною валідацією.

Idempotence означає, що повторний запуск однієї й тієї ж конфігурації приводить до того самого стану без небажаних побічних ефектів.

Коротко:

• Повторний apply не ламає інфраструктуру.
• Ключова властивість надійної автоматизації.
• Знижує ризики у CI/CD для IaC.

Базовий підхід: linting/format (terraform fmt, terraform validate), static analysis/security scanning (tflint, tfsec, checkov), unit/integration тести, plan review, ephemeral env для перевірки застосування.

Коротко:

• Тестувати треба синтаксис, політики й поведінку.
• plan + automated checks перед apply.
• Окремі середовища для безпечної перевірки змін.

Мінімальний приклад:

provider "aws" {
  region = "eu-central-1"
}

resource "aws_instance" "web" {
  ami           = "ami-xxxxxxxx"
  instance_type = "t3.micro"

  tags = {
    Name = "web-01"
  }
}

Далі: terraform init -> terraform plan -> terraform apply.

Коротко:

• Потрібні provider + resource блоки.
• Перед застосуванням обов’язково перевіряти plan.
• Для production додають VPC/SG/IAM/variables/modules.

Docker — платформа контейнеризації, яка дозволяє пакувати застосунок з усіма залежностями в ізольований переносимий контейнер.

Коротко:

• Єдиний формат запуску в будь-якому середовищі.
• Швидший старт порівняно з VM.
• Стандарт для modern DevOps workflow.

Ключові компоненти: Docker Client, Docker Engine (daemon), Images, Containers, Networks, Volumes, Registry (Docker Hub/приватні реєстри).

Коротко:

• Client надсилає команди daemon-у.
• Daemon керує образами і контейнерами.
• Registry зберігає й розповсюджує образи.

Dockerfile — текстовий файл з інструкціями для побудови Docker-образу (FROM, RUN, COPY, CMD, тощо).

Коротко:

• Описує, як зібрати образ.
• Дозволяє версіонувати процес збірки.
• Основа repeatable container build.

Docker image — шаблон (read-only layers), з якого створюються контейнери. Містить ОС-базу, runtime, код і залежності.

Коротко:

• Image = незмінний артефакт.
• Може бути версіонований тегами.
• Використовується для запуску контейнерів.

Container — запущений екземпляр image з ізольованими процесами, файловою системою, мережею і обмеженнями ресурсів.

Коротко:

• Container = runtime-стан образу.
• Легковаговий та швидкий у старті.
• Підходить для мікросервісної архітектури.

Image — статичний шаблон, container — запущений процес на основі цього шаблону. Один image може запускати багато контейнерів.

Коротко:

• Image: build-time артефакт.
• Container: run-time інстанс.
• Аналогія: клас і об’єкт.

VM віртуалізують цілу ОС з окремим kernel, Docker-контейнери ділять kernel хоста і віртуалізують рівень процесів, тому значно легші.

Коротко:

• Контейнери швидші та компактніші.
• VM дають сильнішу ізоляцію ОС-рівня.
• Часто використовують обидва підходи разом.

Multi-stage build дозволяє мати кілька FROM етапів: збірка в одному stage, а фінальний runtime-образ — мінімальний, лише з потрібними артефактами.

Коротко:

• Менший розмір фінального образу.
• Краща безпека (менше зайвих залежностей).
• Оптимально для production.

Типовий підхід: взяти базовий образ nginx, скопіювати статичні файли в /usr/share/nginx/html, додати конфіг (за потреби), відкрити порт 80.

Коротко:

• База: FROM nginx:alpine.
• COPY контент у web root.
• Запуск з пробросом порту -p 80:80.

Базовий патерн: FROM node:alpine, копіювати package*.json, виконати npm ci, скопіювати код, задати CMD ["npm","start"]; для production краще multi-stage.

Коротко:

• Кешуйте залежності через окремий крок COPY package*.json.
• Використовуйте npm ci для стабільних білдів.
• Для продакшну робіть мінімальний runtime-образ.

Зазвичай: build stage на Node (npm ci && npm run build), потім runtime stage на Nginx, де віддається папка build.

Коротко:

• Рекомендований multi-stage підхід.
• Build у Node, serve у Nginx.
• Дає легкий і швидкий production-образ.

Docker Compose — інструмент для опису й запуску multi-container застосунків через docker-compose.yml (services, networks, volumes, env).

Коротко:

• Один файл для локального/інтеграційного оточення.
• Швидкий запуск стеку командою docker compose up.
• Зручний для dev і тестових середовищ.

Docker Swarm — вбудований оркестратор Docker для керування кластером вузлів, реплікацією сервісів, rolling updates і service discovery.

Коротко:

• Оркестрація контейнерів нативно в Docker.
• Простіший за Kubernetes, але менш гнучкий.
• Підходить для невеликих/середніх кластерів.

Registry — сервіс зберігання образів (Docker Hub, ECR, GHCR). Repository — логічна колекція версій одного образу в реєстрі.

Коротко:

• Registry = сховище образів.
• Repository = простір для конкретного образу.
• Теги в repository представляють версії.

EXPOSE у Dockerfile лише документує/декларує порт контейнера. publish (-p host:container) під час запуску реально публікує порт на хості.

Коротко:

• EXPOSE не відкриває порт зовні сам по собі.
• -p робить порт доступним ззовні.
• Часто потрібні обидва для зрозумілого конфігу.

Kubernetes (K8s) — платформа оркестрації контейнерів для автоматичного розгортання, масштабування і керування containerized застосунками.

Коротко:

• Декларативне керування контейнерними workload.
• Автоматизує scaling, self-healing і rollout.
• De facto стандарт container orchestration.

Kubernetes вирішує: оркестрацію контейнерів у кластері, service discovery, автовідновлення pod-ів, балансування трафіку, rolling updates/rollback, горизонтальне масштабування.

Коротко:

• Знімає ручне керування контейнерами в масштабі.
• Покращує надійність і repeatability релізів.
• Спрощує операції для мікросервісної архітектури.

Pod — найменша deployable одиниця в Kubernetes, яка містить один або кілька контейнерів зі спільними network namespace і volumes.

Коротко:

• Pod = runtime-обгортка для контейнерів.
• Контейнери в pod ділять IP/port space.
• Зазвичай один основний контейнер на pod.

Deployment — контролер Kubernetes для декларативного керування stateless застосунками: створення/оновлення pod-ів, rollout, rollback і desired state.

Коротко:

• Керує життєвим циклом pod-ів через ReplicaSet.
• Підтримує rolling update і rollback.
• Основний об’єкт для app deployment.

ReplicaSet гарантує, що задана кількість однакових pod-ів постійно працює. Зазвичай створюється і керується Deployment-ом.

Коротко:

• Підтримує потрібну кількість реплік.
• Автоматично відновлює втрачені pod-и.
• Рідко керується напряму у production.

Основні типи Service: ClusterIP, NodePort, LoadBalancer, ExternalName. Також використовується headless service (clusterIP: None).

Коротко:

• ClusterIP — внутрішній доступ у кластері.
• NodePort/LoadBalancer — зовнішній доступ.
• ExternalName — DNS-аліас на зовнішній сервіс.

Headless Service — service без віртуального ClusterIP (clusterIP: None), який повертає DNS-записи напряму на pod-и (часто для stateful workload).

Коротко:

• Немає єдиного service IP.
• DNS резолвиться в IP конкретних pod-ів.
• Часто використовується з StatefulSet.

Через Service типу LoadBalancer/NodePort, Ingress Controller, API Gateway, або service mesh/egress rules для вихідного трафіку.

Коротко:

• Вхід: Ingress або LoadBalancer service.
• Вихід: egress через CNI/мережеві політики/NAT.
• Безпечність забезпечують TLS, auth, network policies.

Ingress — Kubernetes-ресурс для L7-маршрутизації HTTP/HTTPS трафіку до service (за host/path правилами), який працює через Ingress Controller.

Коротко:

• Єдина точка входу для веб-трафіку.
• Підтримує host/path routing і TLS termination.
• Потребує встановленого Ingress Controller.

Основні підходи: ручне масштабування (kubectl scale), Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), Cluster Autoscaler для вузлів.

Коротко:

• HPA масштабує pod-и за метриками.
• Cluster Autoscaler додає/прибирає nodes.
• Потрібні коректні requests/limits і метрики.

Helm — пакетний менеджер Kubernetes, який використовує charts (шаблони) для параметризованого і повторюваного розгортання застосунків.

Коротко:

• Helm chart = шаблон інфраструктури/додатку для K8s.
• Спрощує release management і rollback.
• Добре підходить для стандартизації deployment-ів.

Базовий алгоритм: kubectl describe pod, kubectl logs --previous, перевірка readiness/liveness probes, env vars/secrets/config, ресурсних лімітів, залежностей (DB, DNS, мережа), exit code контейнера.

Коротко:

• Починайте з describe і логів попереднього рестарту.
• Часті причини: помилка старту, probes, конфіг, ресурси.
• Далі виправлення і контрольний rollout.

APM — це підхід і набір інструментів для відстеження продуктивності застосунку: latency, throughput, error rate, traces, залежності та вузькі місця.

Коротко:

• Дає видимість продуктивності на app-рівні.
• Прискорює пошук root cause інцидентів.
• Критично для SLO/SLA-контролю.

Типові інструменти: Prometheus, Grafana, Alertmanager, ELK/OpenSearch, Loki, Datadog, New Relic, Dynatrace, CloudWatch, Azure Monitor, Nagios, Zabbix.

Коротко:

• Використовують стек метрик, логів, трасувань.
• Вибір залежить від масштабу і платформи.
• Моніторинг має бути інтегрований з alerting.

Nagios — класична система моніторингу інфраструктури і сервісів із моделлю перевірок (checks), алертів і плагінів.

Коротко:

• Моніторить доступність хостів/сервісів.
• Працює через плагіни і перевірки.
• Підходить для legacy та hybrid середовищ.

Active checks запускаються самим Nagios за розкладом. Passive checks надсилаються зовнішніми агентами/системами в Nagios.

Коротко:

• Active: ініціює Nagios.
• Passive: результат пушиться ззовні.
• Часто комбінують обидва типи.

NRPE (Nagios Remote Plugin Executor) — агент/протокол для віддаленого запуску Nagios-плагінів на цільових Linux/Unix хостах.

Коротко:

• Дає змогу виконувати remote checks.
• Використовується для глибшого host monitoring.
• Потребує безпечного налаштування доступу.

Continuous monitoring — безперервний збір і аналіз метрик, логів, подій та сигналів безпеки для швидкого виявлення проблем і деградацій.

Коротко:

• Моніторинг працює постійно, а не періодично вручну.
• Дає раннє виявлення інцидентів.
• Основа для reliability і security operations.

Dashboards візуалізують ключові метрики (SLI/SLO, latency, errors, utilization), щоб швидко оцінювати стан системи, тренди і вплив релізів.

Коротко:

• Єдина точка операційної видимості.
• Допомагають у troubleshooting і capacity planning.
• Полегшують комунікацію під час інцидентів.

Configuration management — керування конфігураціями серверів/сервісів у стандартизований і відтворюваний спосіб через код і автоматизацію.

Коротко:

• Зменшує ручні налаштування і drift.
• Забезпечує єдині стандарти середовищ.
• Важлива частина IaC/DevOps практик.

Chef — інструмент configuration management, який описує desired state системи через recipes/cookbooks і застосовує його через агентну модель.

Коротко:

• Потужний DSL для складної автоматизації.
• Орієнтований на великі керовані середовища.
• Часто використовується в enterprise-інфраструктурі.

Puppet — декларативний CM-інструмент із власним DSL і зазвичай agent-based архітектурою для керування конфігураціями вузлів.

Коротко:

• Declarative підхід до стану системи.
• Сильні можливості для централізованого керування.
• Поширений у великих інфраструктурах.

Ansible — agentless інструмент автоматизації й configuration management, який використовує YAML playbooks і підключення переважно через SSH/WinRM.

Коротко:

• Простий старт і читабельні playbooks.
• Не потребує агентів на керованих хостах.
• Широко використовується для ops automation.

Ansible — agentless, процедурно-декларативний підхід через playbooks. Puppet — переважно agent-based і більш жорстко декларативна модель через маніфести.

Коротко:

• Ansible простіший для швидкого впровадження.
• Puppet сильний у централізованому керуванні на великому масштабі.
• Вибір залежить від вимог і зрілості команди.

Ansible role — структурована одиниця повторного використання (tasks, handlers, vars, templates, files, defaults) для модульної автоматизації.

Коротко:

• Role = reusable automation component.
• Спрощує підтримку і масштабування playbooks.
• Допомагає стандартизувати конфігурації.

Test Kitchen — інструмент для тестування infrastructure/configuration code (часто в екосистемі Chef) у тимчасових інстансах/контейнерах.

Коротко:

• Автоматизує перевірку CM-коду.
• Запускає тестові середовища для валідації.
• Підвищує надійність інфраструктурних змін.

Virtualization — технологія абстракції апаратних ресурсів, що дозволяє запускати кілька ізольованих віртуальних середовищ на одному фізичному хості.

Коротко:

• Підвищує ефективність використання ресурсів.
• Дозволяє ізолювати workload-и.
• Основа для сучасних датацентрів і cloud.

Hypervisor — програмний шар, який створює і керує віртуальними машинами, розподіляючи CPU, RAM, storage і network між ними.

Коротко:

• Керує життєвим циклом VM.
• Буває Type 1 (bare-metal) і Type 2 (hosted).
• Ключовий компонент віртуалізації.

Основні типи: server virtualization, OS-level/container virtualization, storage virtualization, network virtualization, desktop virtualization.

Коротко:

• Різні типи закривають різні інфраструктурні задачі.
• Найпоширеніші в DevOps: server + container virtualization.
• Часто застосовуються у поєднанні.

Переваги: краща утилізація ресурсів, ізоляція, масштабованість, швидке провізіонування, зниження CAPEX/OPEX, спрощення DR/backup.

Коротко:

• Економія і гнучкість інфраструктури.
• Швидше створення та міграція середовищ.
• Краща операційна керованість.

VM мають власну гостьову ОС і kernel поверх hypervisor. Containers ділять kernel хоста і ізолюють процеси на рівні ОС.

Коротко:

• VM: сильніша ізоляція, більші накладні витрати.
• Containers: легші, швидший старт, вища щільність.
• Обирають залежно від вимог безпеки і продуктивності.