Отделите пробные бронирования от основных

Введение

STILL STUDIO проводит небольшие мастер-классы по керамике. Гости выбирают занятие, бронируют место и видят своё имя в списке. Команда хочет опробовать занятие в Garden Room, не занимая места в настоящем списке Riverside Room. Вы создадите для того же приложения собственную среду staging: явно обозначенный тестовый сайт с отдельными данными бронирования.

Достаточно базового знакомства с терминалом. Docker Compose, конфигурация, пути, порты и тома объясняются здесь. Приложение и его образ предоставлены; писать код и устанавливать инструменты не нужно. Все бронирования вымышлены. Почта, платежи, внешние аккаунты и настоящие персональные данные не используются.

Используйте Live Bookings для подготовленного сайта на порту 8081, Preview Bookings для своего тестового сайта на порту 8082 и Workstation для команд. Preview Bookings недоступен до запуска на шаге 2. Этот раздел начинается независимо.

Познакомьтесь с сервисом и настройте тестовую среду

На этом шаге вы пройдёте обычный путь бронирования, затем подготовите отдельный набор параметров. Начните в Live Bookings.

Забронируйте место в обычном сервисе

Главная страница представляет мастер-класс и показывает LIVE BOOKINGS, Riverside Room и 4 of 6 places left. Выберите Explore the clay workshop. Страница описывает занятие и содержит поле Guest name. Введите вымышленное имя Live guest, затем выберите Reserve a place.

Браузер откроет Guest list с Maria, Jun и Live guest. Теперь остаётся 3 of 6 places left. Это настоящая запись в базу данных, а не декоративное сообщение об успехе. Выберите STILL STUDIO, чтобы вернуться на главную. Сохраните все три бронирования.

При случайной повторной отправке того же имени сайт сообщит, что оно уже забронировано, и не добавит вторую запись. Если вы ошиблись в своём имени, откройте Guest list, нажмите Cancel только возле собственной ошибочной брони и забронируйте снова как Live guest. Никогда не отменяйте Maria или Jun и не очищайте весь список ради одной опечатки.

Разберитесь в границе конфигурации

Перейдите в Workstation, уже открытый в /home/labex/project/booking. Путь обозначает файл или каталог. pwd выводит текущий каталог, а ls — его содержимое:

pwd

/home/labex/project/booking

ls

Вы должны увидеть compose.yaml и live.env. cat выводит текстовый файл:

cat live.env

PORT=8081
APP_ENV=live
VENUE=Riverside Room
CAPACITY=6
DATA_VOLUME=still-live-data

Конфигурация задаёт варианты поведения приложения без изменения кода. Строки KEY=value выбирают опубликованный порт, обозначение среды, площадку, вместимость и том данных. VENUE меняет реальную площадку, отображаемую по всему сайту. CAPACITY ограничивает число принимаемых бронирований, а не просто меняет подпись.

Docker запускает приложение в контейнере, созданном из сохранённого образа. Оба сайта будут использовать предоставленный образ still-booking:1. При создании каждый контейнер получает собственные переменные окружения. Именованный том хранит базу данных вне заменяемого контейнера. Разные контейнеры могут использовать один том, поэтому разные имена контейнеров сами по себе не разделяют записи.

Подготовлены следующие ресурсы:

Имя тома выбирает реальное хранилище. Никогда не выбирайте основной том для пробных бронирований.

Изучите небольшой файл Compose

Docker Compose описывает связанные контейнеры в YAML-файле. YAML группирует настройки отступами; сохраняйте предоставленные отступы и используйте пробелы, а не табуляцию. Прочитайте файл:

cat compose.yaml

В services сервис booking использует still-booking:1. Раздел environment передаёт значения приложению. ${VENUE} означает, что Compose подставляет значение с именем VENUE перед созданием контейнера. Файл окружения служит входом для подстановки; он не меняет автоматически уже работающий процесс.

ports задаёт ${PORT}:8000: перед двоеточием указан опубликованный порт экземпляра лаборатории; 8000 — порт приложения внутри контейнера. Двум сайтам нужны разные опубликованные порты.

Сервис подключает booking-data к /data, где приложение хранит базу. Запись тома верхнего уровня разрешает этот псевдоним в ${DATA_VOLUME}. external: true означает, что том существует и Compose должен использовать именно этот ресурс. Имя проекта группирует контейнеры Compose, но не переименовывает явно выбранный внешний том.

Запишите и разрешите тестовые параметры

Не меняйте live.env. Создайте preview.env со значениями ниже. cat > preview.env заменяет файл. ENV в кавычках начинает here-document: вставьте весь блок, включая завершающий ENV в отдельной строке. Кавычки сохраняют текст буквально.

cat > preview.env <<'ENV'
PORT=8082
APP_ENV=staging
VENUE=Garden Room
CAPACITY=3
DATA_VOLUME=still-trial-data
ENV

Порт обозначает сетевой сервис. Здесь 8082 относится к Preview Bookings, а 8081 остаётся Live Bookings. APP_ENV=staging включает заметную тестовую метку. Само по себе это не выбирает отдельное хранилище: за него отвечает DATA_VOLUME.

--env-file preview.env указывает Compose значения для подстановки. -p still-preview выбирает проект. config выводит разрешённую конфигурацию, не запуская и не меняя контейнеры:

docker compose --env-file preview.env -p still-preview config

Найдите APP_ENV: staging, VENUE: Garden Room, вместимость 3, опубликованный порт 8082 и том still-trial-data. Формат зависит от версии Compose. Доказательством служат разрешённые значения, а не только успешное завершение команды.

Если Compose сообщает об отсутствующей переменной или файле, проверьте pwd и cat preview.env, исправьте написание, повторив весь here-document, затем снова выполните config. Если оболочка уже экспортировала переменную вроде VENUE, её значение может перекрыть файл. unset VENUE удаляет это переопределение оболочки; применяйте способ только к конфликтующему ключу, который вы намеренно экспортировали. Не запускайте тестовую среду, пока разрешённые значения не станут правильными.

Запустите тестовую среду и проверьте реальную вместимость

На этом шаге вы запустите копию staging и докажете, что её бронирования используют отдельный список. Начните в Workstation.

Запустите настроенное приложение

up создаёт или обновляет контейнеры проекта. -d оставляет их работать в фоне, сохраняя доступность терминала:

docker compose --env-file preview.env -p still-preview up -d

Вывод называет созданный контейнер. ps показывает фактическое состояние проекта и опубликованный порт:

docker compose --env-file preview.env -p still-preview ps

Найдите работающий сервис booking и порт 8082, соединённый с 8000. При ошибке запуска logs выводит сообщения приложения:

docker compose --env-file preview.env -p still-preview logs

Недоступный внешний том обычно означает опечатку в имени ресурса. Исправьте preview.env, повторите config, затем up -d. Не создавайте подменный том, скрывая ошибочную цель. Конфликт порта часто означает выбор основного порта: сохраните 8081 и используйте 8082 для этой тестовой среды.

Создайте пробное бронирование

Перейдите в Preview Bookings, при необходимости обновите страницу. Главная должна показывать STAGING · TEST BOOKINGS ONLY, Garden Room и 3 of 3 places left. Выберите Explore the clay workshop, введите Trial guest, затем Reserve a place. В Guest list теперь только Trial guest, а свободных мест 2 of 3 places left.

Перейдите в Live Bookings, выберите Guest list и обновите. Здесь по-прежнему должны быть Maria, Jun и Live guest, со значением 3 of 6 places left. Если появились пробные данные, прекратите новые пробные бронирования. В Workstation исправьте тестовый том, примените up -d, затем отмените только свою однозначно узнаваемую пробную запись в основном списке. Сохраните все законные основные бронирования. После исправления изоляции откройте Preview Bookings и создайте там Trial guest.

Такое сравнение важнее метки. Надпись staging при общей базе всё равно расходовала бы настоящие места.

Проверьте меньшую вместимость

Оставайтесь в Preview Bookings. Нажмите Back to the workshop и забронируйте Capacity A. Снова вернитесь к занятию и забронируйте Capacity B. Теперь в списке три гостя и 0 of 3 places left.

Попробуйте ещё одно бронирование — Overflow guest. Страница должна показать Every place is taken. и No booking was added. Перейдите по View the guest list: Overflow guest должен отсутствовать. Меньшая вместимость действительно изменила поведение приложения.

Отмените только Capacity A и Capacity B, сохранив Trial guest. Тестовая среда вернётся к 2 of 3 places left. При опечатке отмените конкретную пробную запись и повторите её; очищать базу не требуется. Вернитесь в Live Bookings и подтвердите, что основной список и свободные места не изменились.

Сравните машиночитаемые результаты

Перейдите в Workstation. HTTP — протокол запросов и ответов браузера. curl отправляет запрос; -sS скрывает прогресс, но показывает ошибки соединения. В Workstation адрес 127.0.0.1 обозначает этот экземпляр лаборатории. URL объединяет протокол, адрес, порт и путь ресурса. /api/info возвращает фактическую конфигурацию и список базы в JSON — структурированном текстовом формате. Язык запросов к базе не нужен.

curl -sS http://127.0.0.1:8081/api/info

Прочитайте live, Riverside Room, вместимость 6, остаток 3 и три основных имени. Идентификаторы могут отличаться.

curl -sS http://127.0.0.1:8082/api/info

Прочитайте staging, Garden Room, вместимость 3, остаток 2 и только Trial guest. Это разные конечные точки, а не две подписи одного списка.

Замените тестовый контейнер без потери бронирований

На этом шаге вы замените тестовый контейнер и подтвердите сохранность его отдельных данных. Начните в Workstation.

Проверьте фактическое подключение хранилища

ps -q выводит только идентификатор контейнера проекта. docker inspect читает реальные настройки контейнера. --format выбирает поле; шаблон в кавычках преобразует список подключений в JSON. Выражение оболочки $(...) выполняет внутреннюю команду и подставляет её вывод как аргумент контейнера:

docker inspect $(docker compose --env-file preview.env -p still-preview ps -q booking) --format '{{json .Mounts}}'

Найдите подключение типа volume, с именем still-trial-data и назначением /data. Другое имя проекта не защитило бы основные данные, если бы подключение называлось still-live-data.

Пересоздайте только тестовый контейнер

--force-recreate указывает up заменить контейнер даже без изменения конфигурации. Подключённые именованные тома сохраняются. Это также показывает, как конфигурация попадает в новый процесс: редактирование одного файла окружения не обновляет работающий контейнер.

docker compose --env-file preview.env -p still-preview up -d --force-recreate

Дождитесь, пока ps покажет работающий сервис:

docker compose --env-file preview.env -p still-preview ps

Перейдите в Preview Bookings и обновите Guest list. Trial guest должен остаться в Garden Room со значением 2 of 3 places left. Перейдите в Live Bookings и обновите список. Maria, Jun и Live guest должны остаться в Riverside Room со значением 3 of 6 places left. Ни замена контейнера, ни пробная бронь не должны очищать другую среду.

Не используйте удаление томов или down -v для восстановления. Если тестовая среда не запускается, используйте logs того же проекта, исправьте значения и снова примените up -d. Подготовленная основная среда находится вне области ваших изменений.

Проверяйте страницы вместе с ответами

В Preview Bookings выберите STILL STUDIO, откройте занятие, затем Guest list. Локальная иллюстрация, подробности и навигация должны работать. Одна исправная главная страница — ещё не весь сервис бронирования.

Перейдите в Workstation. Статус HTTP 200 означает успешный ответ; 404 — отсутствие запрошенного пути. -o /dev/null отбрасывает тело ответа; -w выводит формат в кавычках. %{http_code} — статус HTTP, а \n завершает строку:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8082/bookings

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

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/workshop

Ожидается 200: основной мастер-класс остаётся доступен. Ошибка соединения отличается от ошибочного HTTP-ответа; при отсутствии ответа проверьте ps и logs. Теперь у вас один образ приложения, два независимо настроенных процесса и два отдельных устойчивых списка гостей. Это учебная изоляция на одном экземпляре, а не граница безопасности против администратора с доступом к Docker.

Резюме

Вы настроили и запустили копию staging того же приложения, выбрали отдельный именованный том, проверили реальную вместимость и сравнили списки. Пересоздание тестового контейнера сохранило бронь, а основной сервис сохранил исходных гостей. Другая метка или проект Compose помогают организации; изоляцию установила фактическая цель хранения данных.