linux_tasks/module2/08_docker_containerization_advanced/tasks.md

Задания

1. Многоступенчатая сборка образов

В полученной вами директории todo_app находятся исходные коды Enterprise Quality™® системы для менеджмента напоминаний.

Она состоит из следующих частей:

• TodoApi - API-сервис, на платформе .NET 7,
• todo_ui - веб-интерфейс к этому сервису, Single-Page JavaScript приложение(SPA), написанное с использованием Vue.js 3,
• PostgreSQL - API-сервис использует PostgreSQL для хранения данных.

Необходимо будет контейнеризировать эту систему.

В этот раз, к сожалению, программисты не оставили никаких скриптов, но вы можете написать их сами, по ходу работы. Некоторые команды и их аргументы будут довольно длинные.

1.1 Контейнеризация приложения

1.1.1 Подготовка образа для TodoApi и todo_ui

Используя подход к многоступенчатой сборке образов, напишите Dockerfile, из которого можно было бы создать образ, и который отвечал бы следующим требованиям:

• Фаза сборки API-сервиса должна использовать образ mcr.microsoft.com/dotnet/sdk:7.0
• Фаза сборки JavaScript приложения должна использовать образ node:21
• Результирующий образ должен основываться на mcr.microsoft.com/dotnet/aspnet:7.0
• Готовое приложение API-сервиса вместе с зависимостями должно находиться в директории /app
• JavaScript приложение должно находиться в директории /app/wwwroot
• При старте контейнера из такого образа, должно запускаться приложение API-сервиса.

Документация по многоступенчатой сборке образов находится тут: https://docs.docker.com/build/building/multi-stage/.

Фаза сборки сервиса TodoApi состоит из следующих шагов:

• Во-первых, для его сборки необходим .NET 7 SDK
• Далее, из директории, в которой находятся исходные коды сервиса(см. todo_app/TodoApi), нужно сделать dotnet restore TodoApi.csproj - эта команда скачает зависимости сервиса.
• Следующим шагом идет непосредственно сборка сервиса.
  Она производится командой dotnet build TodoApi.csproj -c Release -o <output_directory>,
  в которой вместо <output_directory> необходимо подставить имя директории, которое будет содержать бинарные файлы сервиса, например /app/build
• Последняя вещь, которую необходимо сделать - это вызывать команду
  dotnet publish TodoApi.csproj -c Release -o <publish_directory>,
  которая опубликует результирующие бинарные файлы, а также зависимости сервиса в <publish_directory>(например в /app/publish).

Для запуска процесса сервиса SDK не нужен, достаточно лишь соответствующего фреймворка ASP.NET - в данном случае версии 7.0. Запуск осуществляется вызовом исполняемого файла ./TodoApi из директории, которая хранит опубликованные бинарные файлы сервиса и его зависимостей.

Фаза сборки JavaScript приложения состоит из следующих шагов:

• Прежде всего, необходим NodeJS - в данном случае подойдет версия 21.
• Далее, из директории, в которой находятся исходные коды приложения(см. todo_app/todo_ui), нужно вызывать npm install - это команда скачает зависимости приложения.
• После этого, в этой же директории необходимо выполнить команду npm run build, в результате чего, в этой директории появится директория wwwroot, содержащая файл index.html, результирующий код на JS, а также его ресурсы, такие как картинки и файлы стилей(css).
  Перед выполнением этой команды, также можно установить переменную среды BASE_PATH, в значение,
  являющееся префиксом в пути URL, по которому приложение будет находится. По умолчанию, BASE_PATH
  трактуется как имеющее значение /, таким образом приложение должно раздаваться веб-сервером из корня сайта.
  Если же вы хотите, чтобы приложение находилось например по адресу http://<домен>/todo/, тогда необходимо
  установить BASE_PATH в значение /todo/ соответственно. Для установки переменной среды, доступной во время
  сборки образа, используйте директиву ARG внутри докер-файла(и соответственно опцию --build-arg при вызове docker build).

Для запуска JavaScript приложения NodeJS не нужен, достаточно лишь любого веб-сервера, и в нашем случае, в API-сервисе такой имеется(он называется Kestrel). Для хостинга JS-приложения в API-сервисе, необходимо всего лишь скопировать упомянутую выше директорию wwwroot внутрь результирующей директории API-сервиса(которая получается после выполнения dotnet publish ...).

Создайте образ из полученного Dockerfile и назовите его todo-bundle.

1.1.2 Подготовка образа PostgreSQL

Перед запуском самого приложения, необходимо запустить и подготовить PostgreSQL в сети todo.

Создайте именованную сеть типа bridge, в которой будет работать вся система, назовите ее todo.

Создайте том данных, в котором PostgreSQL будет хранить БД. Назовите его todo_pgdata.

Запустите именованный контейнер todo_postgres из образа postgres:16.

При этом:

• При запуске установите следующие переменные окружения контейнера в значение todo:
  • POSTGRES_DB - имя базы данных, к которой будет обращаться API-сервис
  • POSTGRES_USER - пользователь БД, через которого будет работать сервис
  • POSTGRES_PASSWORD - пароль для пользователя
• Установите значение переменной среды PGDATA в значение /var/lib/postgresql/data - здесь PostgreSQL будет хранить данные.
• Примонтируйте том данных todo_pgdata в качестве директории /var/lib/postgresql/data.
• Примонтируйте директорию initdb из todo_app в качестве директории /docker-entrypoint-initdb.d внутри контейнера. Там находится скрипт init_db.sql, который используется для инициализации базы данных при первом старте контейнера.

1.1.3 Проверка работоспособности контейнеризованного приложения

Запустите контейнер todo_bundle в сети todo из созданного вами образа todo-bundle, при этом:

• Установите значение переменной среды ConnectionStrings__PostgreSQL в контейнере равной Host=todo_postgres;Port=5432;Database=todo;Username=todo;Password=todo. Можете выбрать другой Host в этой строке, если вы назвали контейнер с PostgreSQL по-другому. Аналогично - и другие параметры.
• Пробросьте порт 80 на хост-систему(например на порт 8080). API-сервис работает на 80м порту по умолчанию, но это можно изменить, установив значение переменной
  ASPNETCORE_URLS например в http://*:5000 - тогда внутри контейнера сервис будет слушать порт 5000.

Убедитесь, что приложение работает и доступно на выбранном вами порту на локальной машине.

При возникновении сложностей и необходимости отладки, вы можете также установить значение переменной ASPNETCORE_ENVIRONMENT в Development - таким образом сервис будет выдавать больше логов.

1.2 Рефакторинг контейнеризованного приложения

1.2.1 Декомпозиция образа todo-bundle

Несмотря на то что API-сервис поддерживает хостинг JavaScript приложения, в реальном(или скорее, идеальном) мире никто так не делает. Над интерфейсом и API часто работают разные команды, у них может быть разный график работы, разное версионирование приложений, и тем более разные репозитарии, и разный подход к разработке.

Кроме того, хотя Kestrel - хороший веб-сервер, все же раздача статических файлов - не основная его специализация.

Поэтому, руководствуясь принципом разделения ответственности, вам необходимо разделить контейнеризацию API-сервиса и JavaScript приложения.

Остановите контейнер todo_bundle, удалите его и образ todo-bundle

Модифицируйте Dockerfile для API-сервиса, таким образом, чтобы убрать из него все упоминание JavaScript приложения и его этапов сборки.

Создайте образ todo-api на основе нового докер-файла.

Напишите конфигурацию Nginx для использования его как в качестве обратного прокси для API-сервиса, так и для раздачи файлов из wwwroot, получаемой после сборки JavaScript приложения. При этом:

• Учтите, что все методы API-сервера имеют префикс /api
• Не забудьте о том, что приложение на JS является SPA, и веб-сервер должен перенаправлять все нераспознанные пути на index.html (используйте директиву try_files)
• Содержимое wwwroot должно лежать в /var/www/todo

Напишите Dockerfile для JavaScript приложения, взяв за основу образ nginx. При сборке образа копируйте написанную вами конфигурацию Nginx в /etc/nginx/nginx.conf, а результат сборки JavaScript приложения в /var/www/todo.

Создайте образ todo-ui из этого докер-файла.

1.2.2 Проверка работоспособности контейнеризованного приложения

Запустите в сети todo контейнер todo_api из образа todo-api, при этом:

• Не забудьте про переменную среды ConnectionStrings__PostgreSQL.
• Убедитесь что контейнер недоступен из внешней сети.

Запустите в сети todo контейнер todo_ui из образа todo-ui, при этом:

• Пробросьте порт контейнера 80(или любой другой, который вы использовали при написании конфигурации Nginx) на локальную машину(например, опять же на порт 8080)

Убедитесь что приложение доступно извне и работает.

1.2.3 Рефакторинг образа todo-api

Платформа .NET, на самом деле, позволяет собирать приложения, отвязанные от "внешней" предустановленной среды выполнения.

Хотя рекомендованный способ докеризации приложений на .NET - отталкиваться от образа с mcr.microsoft.com, иногда возникает необходимость именно в self-contained приложениях.

Модифицируйте Dockerfile для todo-api, следующим образом:

• Поменяйте образ SDK для сборки на mcr.microsoft.com/dotnet/sdk:7.0-bullseye-slim
• Замените команду публикации приложения на
  dotnet publish TodoApi.csproj --self-contained -r linux-x64 -c Release -o /app/publish
  (замените /app/publish на директорию которую использовали вы, если она у вас отличается)
• Поменяйте результирующий исходный образ на debian:bullseye-slim
• В образе debian:bullseye-slim не хватает ICU, необходимого для запуска полноценного .NET приложения.
  Установите libicu в этом образе при сборке: apt-get update && apt-get install libicu67

1.2.4 Проверка работоспособности контейнеризованного приложения

Пересоберите образ todo-api, и перезапустите контейнер todo_api на его основе, проверьте что всё работает.

2. Политики перезапуска и базовый мониторинг

1. Запустите todo_ui, todo_api и todo_postgres так, чтобы они перезапускались при ошибке или же при перезапуске демона Docker.

   Перезапустите демон Docker, или же вообще, сделайте перезагрузку машины, и проверьте что контейнеры запустились при старте Docker.

2. Перезапустите контейнер todo_postges, так чтобы healthcheck:

   • Запускался командой pg_isready -U todo -d todo
   • Имел интервал 10 секунд
   • Имел timeout 5 секунд
   • Проверка имела бы до 5 попыток старта в случае неудачи
   • Начиналась бы после 10 секунд после старта контейнера

3. Ограничение ресурсов

1. Перезапустите контейнеры todo_ui, todo_api и todo_postgres, так они имели ограничение по памяти в 300, 500 и 800 мегабайт соответственно.
   Поэкспериментируйте с ограничениями и посмотрите что выходит, в случае их превышения.

2. Перезапустите контейнеры todo_ui, todo_api и todo_postgres, так они имели ограничение по ресурсам процессора в 1, 1 и 2 соответственно

4. Docker Compose

1. Убедитесь что docker compose установлен, проверьте версию.

2. Напишите docker-compose.yml для контейнера на основе busybox, который бы печатал Hello, World при запуске. Запустите.

3. Напишите конфигурацию compose для приложения cats_app. Сделайте так, чтобы образ cats_app собирался, если его еще не существует. Запустите приложение через docker compose, используя эту конфигурацию. Убедитесь в том, что приложение работает.

4. Напишите конфигурацию compose для вышеописанной системы todo. При этом:

   • Добавьте туда как healthcheck, так и ограничения ресурсов описанные выше
   • Сделайте так чтобы контейнер todo_api зависел от todo_postgres, а todo_ui - от todo_api.
   • Сделайте так, чтобы образы todo-ui и todo-api собирались, если они еще не существуют. Запустите систему через docker compose, и убедитесь что все работает.

5. Добавьте контейнер из образа dpage/pgadmin4:7 в compose файл к вышеописанной системе, так чтобы он подключался к PostgreSQL и позволял смотреть данные приложения todo. При этом установите следующие переменные среды в контейнере в соответствующие значения:

   • PGADMIN_DEFAULT_EMAIL = todo@example.com
   • PGADMIN_DEFAULT_PASSWORD = todo
   • PGADMIN_CONFIG_SERVER_MODE = False

   Убедитесь что консоль администрирования недоступна из интернета, и чтобы проверить ее работоспособность, можно, например,
   прокинуть SSH-туннель от вашей машины, до машины с Docker, например таким образом:
   ssh -L 5051:localhost:5050 stud@studN.myoffice.ru.
   где вместо 5050 - подставьте порт, на котором pgadmin доступен изнутри машины studN.myoffice.ru.
   После выполнения этой команды, pgadmin будет доступен на вашей машине, на http://localhost:5051

   Про SSH туннели подробнее можете почитать здесь:
   https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot

5. Docker Swarm

1. Инициализируйте Docker в режим Swarm

2. Выведите на экран список нод Docker Swarm

3. Выведите токен для присоединения к Swarm в качестве worker

4. Создайте сеть Docker типа overlay с именем todo_swarm

5. Создайте том данных todo_swarm_pgdata так, чтобы в него мог писать только 1 сервис одновременно

6. Запустите образ postgres:16 как сервис Swarm с именем todo_postgres, подключенный к сети todo_swarm, с количеством реплик равному 1, при этом:

   • При запуске установите следующие переменные окружения контейнера в значение todo:
     • POSTGRES_DB - имя базы данных, к которой будет обращаться API-сервис
     • POSTGRES_USER - пользователь БД, через которого будет работать сервис
     • POSTGRES_PASSWORD - пароль для пользователя
   • Установите значение переменной среды PGDATA в значение /var/lib/postgresql/data - здесь PostgreSQL будет хранить данные.
   • Примонтируйте том данных todo_swarm_pgdata в качестве директории /var/lib/postgresql/data.
   • Примонтируйте директорию initdb из todo_app в качестве директории /docker-entrypoint-initdb.d внутри контейнера.
     Там находится скрипт init_db.sql, который используется для инициализации базы данных при первом старте контейнера.

7. Запустите образ todo-api как сервис Swarm с именем todo_api, подключенный к сети todo_swarm, с количеством реплик равному 1, при этом:

   • Установите переменную окружения ConnectionStrings__PostgreSQL
     в значение Host=todo_postgres;Port=5432;Database=todo;Username=todo;Password=todo
   • Установите переменную окружения ASPNETCORE_URLS в http://*:80

8. Запустите образ todo-ui как сервис Swarm с именем todo_ui, подключенный к сети todo_swarm, с количеством реплик равному 1, при этом:

   • Пробросьте порт 80 на внешний порт 8080

9. Убедитесь, что приложение доступно на порту 8080

10. Увеличьте количество реплик каждого из сервисов todo_ui и todo_api до 3. Убедитесь что приложение работает.

11. Выведите листинг реплик сервисов todo_api и todo_ui

12. Просмотрите логи сервиса todo_api. Убедитесь что запросы подхватываются разными репликами.

13. Удалите все три сервиса

14. Напишите compose-файл для этих сервисов, который бы также запускал по 3 реплики todo_ui и todo_api и 1 реплику todo_postgres

    • Отталкивайтесь от ранее вами написанного файла для docker compose

15. Запустите docker stack, исходя из написанной вами конфигурации, и убедитесь в работоспособности системы