intDataBlog
← ЖурналМаршруты обучения ↗

Доставка приложения: образ, проверка, релиз

Различайте сборку, доставку и работающий сценарий; спроектируйте учебный конвейер.

Практика рассчитана на отдельную учебную среду и вымышленные данные.

Docker

Образ — воспроизводимый шаблон, контейнер — его запущенный экземпляр. Данные и публикацию порта нужно задавать явно.

Образ — подготовленный шаблон файлов и настроек, контейнер — запущенный из него процесс в изолированной среде. Один образ можно использовать для нескольких контейнеров. Данные в изменяемом слое не должны быть единственным местом хранения важного состояния. Переносимость образа не отменяет требований к архитектуре, сети и конфигурации.

  • Образ и контейнер
  • Порты и тома
  • Логи и жизненный цикл

Попробуйте

  1. Выполните официальный начальный Docker tutorial в отдельной учебной среде.
  2. Найдите образ, контейнер и опубликованный порт приложения.
  3. Объясните, какие данные исчезнут при пересоздании контейнера без тома.

Приложение отвечает на учебном порту; судьба данных при пересоздании описана.

Почему localhost внутри контейнера отличается от хоста?

Это разные сетевые пространства; адрес localhost указывает на сам контейнер, если сеть специально не изменена.

Продолжить на русском и английском
  • Docker: Run an application EN ↗

    Запустите учебное приложение локально. Нужны Docker, Git и предусмотренный руководством аккаунт.

  • Linux Labs RU ↗

    Первый практикум раздела «Первые шаги». Браузерные VM; для запуска нужен вход через Google.

CI/CD

Pipeline превращает изменение в последовательность проверок и доставки. Зелёная сборка сама по себе не доказывает, что новая версия обслуживает пользователей.

Конвейер связывает отдельные проверки и действия. Тесты отвечают на вопрос о выбранных сценариях, сборка создаёт артефакт, доставка переносит его в среду. Если deploy пропущен, успешная сборка не означает публикацию. После доставки проверьте версию и основной пользовательский путь, а не только активный процесс.

  • Порядок этапов
  • Артефакт и версия
  • Проверка после доставки

Попробуйте

  1. Разберите pipeline: tests PASS, build PASS, deploy SKIPPED.
  2. Определите, что проверено и что ещё не опубликовано.
  3. Добавьте критерии smoke check и условие остановки для учебного релиза.

Проверка не смешивается с доставкой; указано, какой артефакт и какой адрес проверяются.

Нужно ли пересобирать артефакт при переходе staging → release?

Обычно продвигают тот же проверенный неизменяемый артефакт; повторная сборка может дать другой результат.

Продолжить на русском и английском
  • Introduction to DevOps and SRE EN ↗

    Прочитайте вводную часть после общей базы. Бесплатный курс; сначала основы Linux, сетей и скриптов.

  • Pro Git RU ↗

    Главы 1–3: фиксация изменений и ветки. Онлайн-книга открыта; для локальных упражнений нужен Git.

  • Docker: Run an application EN ↗

    Запустите учебное приложение локально. Нужны Docker, Git и предусмотренный руководством аккаунт.

Инфраструктура как код

Описание желаемого состояния позволяет обсуждать изменения до применения. План, фактическое состояние и повторный запуск — разные проверки.

Описание инфраструктуры должно позволять увидеть желаемое состояние и сравнить его с текущим. Перед применением прочитайте план, границы ресурсов и возможные удаления. Автоматизация повторяет инструкцию быстрее человека, поэтому ошибка в области действия тоже масштабируется. Начните с вымышленного конфига и объяснимой разницы.

  • Декларативное состояние
  • Plan и apply
  • Идемпотентность и drift

Попробуйте

  1. Откройте локальный Docker-путь в Terraform tutorials или учебный inventory Ansible.
  2. До запуска выпишите ресурсы и адреса, которые затрагиваются; внешние аккаунты не подключайте.
  3. Сравните первый и повторный план для неизменённого описания.

Указана изолированная цель; повторный план не обещает изменений без причины.

Значит ли успешный plan, что изменение уже применено?

Нет. Plan описывает предполагаемые действия, apply — отдельная операция с отдельным результатом.

Продолжить на русском и английском
  • Terraform tutorials EN ↗

    Read plan before apply; начните с локальной учебной среды. Упражнения могут требовать установки или облачного аккаунта; выбирайте локальный Docker-путь.

  • Getting started with Ansible EN ↗

    Inventory, первый playbook, идемпотентность. Нужны отдельная учебная среда и установка; не запускайте на рабочем хосте.

  • Introduction to DevOps and SRE EN ↗

    Прочитайте вводную часть после общей базы. Бесплатный курс; сначала основы Linux, сетей и скриптов.

Kubernetes

Deployment задаёт желаемое число экземпляров, Pod запускает контейнеры, Service даёт стабильный способ обращения. Начинайте после освоения образа и контейнера.

Kubernetes сопоставляет желаемое состояние с наблюдаемым. Deployment управляет экземплярами приложения, Service даёт стабильную точку обращения к выбранным Pod. Готовность принимать трафик и факт запуска процесса различаются. Для первого упражнения достаточно схемы этих отношений и разбора статуса; собственный кластер не обязателен.

  • Pod/Deployment/Service
  • Readiness и replicas
  • Rollout и наблюдение

Попробуйте

  1. Пройдите официальный Kubernetes Basics в отдельном учебном кластере.
  2. Сопоставьте Deployment с его Pod и Service.
  3. Измените только учебный Deployment и сравните desired и ready replicas.

По именам объектов видно, какие Pod принадлежат Deployment; ready отличается от desired при неготовом приложении.

Почему Running не равно Ready?

Контейнер может быть запущен, но ещё не проходить проверку готовности и не обслуживать трафик.

Продолжить на русском и английском
  • Основы Kubernetes RU ↗

    Сначала Pod, Deployment и Service. Руководство, не действующий встроенный терминал; нужен учебный кластер.

  • Kubernetes Basics EN ↗

    Deploy an app, затем Explore your app. Нужен учебный кластер; прежние интерактивные уроки закрыты.

Релиз, которого не было

Проверьте путь изменения от тестов до пользовательского запроса. Это вымышленный учебный сценарий.

1. Прочитайте результат

tests: PASS
build: PASS
deploy: SKIPPED
production version: v12

Можно ли считать v13 опубликованной?

2. Найдите первую проверку

v13 развёрнута в учебной среде.
process: active
GET /health: 503
log: missing CONFIG_MODE

Что проверить следующим?

3. Подтвердите результат

CONFIG_MODE задана; новая версия перезапущена.
process: active
GET /health: 200

Чего ещё не хватает перед выводом об успехе?