О следующем шаге вы уже догадались. Нужно новый сервис "упаковать" в docker-контейнер.

Поехали

Как всегда, код тут.

Первым делом мы создадим docker-файл (Dockerfile.ads) с инструкцией по сборке контейнера, он не будет сольно отличаться от docker-файла для основного приложения:

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build

# Copy everything
COPY . ./


# Build and publish a release
RUN dotnet publish DeployToProduction.Ads.WebApi --configuration Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:7.0
EXPOSE 80

COPY --from=build /out .

# Start App
ENTRYPOINT ["dotnet", "DeployToProduction.Ads.WebApi.dll"]

Далее у нас несколько вариантов.

Первый - это собрать образ отдельной командой:

docker build -t weather-forecast-ads-img -f Dockerfile.ads .

Второй вариант - обновить файлы docker-compose и пересобрать все образы.

Как вы помните, у нас был один файл docker-compose для конфигурации Development - docker-compose.app.dev.yml:

version: "3.9"

services:
  ads:
    container_name: "weather-forecast-ads"
    image: "weather-forecast-ads-img"
    build:
      context: .
      dockerfile: Dockerfile.ads
    networks:
      - weather-forecast-net
    ports:
      - "5298:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Development
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
  app:
    container_name: "weather-forecast-app"
    image: "weather-forecast-app-img"
    build:
      context: .
      dockerfile: Dockerfile.app
    networks:
      - weather-forecast-net
    ports:
      - "5022:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Development
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=weather-forecast-postgres;User Id=postgres;Password=postgres;Database=postgres
       ConnectionStrings__Redis: weather-forecast-redis:6379
       ConnectionStrings__AdsServerUrl: http://weather-forecast-ads
    depends_on:
      postgres:
        condition: service_started
      redis:
        condition: service_started
      ads:
        condition: service_started

Второй - для конфигурации Production - docker-compose.app.prd.yml:

version: "3.9"

services:
  ads:
    container_name: "weather-forecast-ads"
    image: "weather-forecast-ads-img"
    build:
      context: .
      dockerfile: Dockerfile.ads
    networks:
      - weather-forecast-net
    ports:
      - "5298:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Production
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
  setup:
    container_name: "weather-forecast-setup"
    image: "weather-forecast-setup-img"
    build:
      context: .
      dockerfile: Dockerfile.setup
    networks:
      - weather-forecast-net
    environment:
       ConnectionStrings__Postgres: Host=weather-forecast-postgres;User Id=postgres;Password=postgres;Database=postgres
    depends_on:
      postgres:
        condition: service_started
      redis:
        condition: service_started
  app:
    container_name: "weather-forecast-app"
    image: "weather-forecast-app-img"
    build:
      context: .
      dockerfile: Dockerfile.app
    networks:
      - weather-forecast-net
    ports:
      - "5022:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Production
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=weather-forecast-postgres;User Id=webapp;Password=webapppwd;Database=postgres
       ConnectionStrings__Redis: weather-forecast-redis:6379
       ConnectionStrings__AdsServerUrl: http://weather-forecast-ads
    depends_on:
      setup:
        condition: service_completed_successfully

Обращу ваше внимание на один момент. В Dockerfile.ads мы указываем инструкцией EXPOSE 80, что контейнер из этого образа "выставляет" порт 80, то есть слушает и принимает запросы по этому порту. В docker-compose файле при описании сервиса ads в параметре ports мы указываем какой порт "хоста" будет использоваться для обращения к 80-му порту контейнера. НО в переменной окружения ConnectionStrings__AdsServerUrl для сервиса app мы указываем адрес сервиса http://weather-forecast-ads, где weather-forecast-ads - это имя контейнера, порт мы не указываем, так как используется 80-ый порт по умолчанию. Акцентирую, не правильными вариантами будут: http://localhost:5298, http://weather-forecast-ads:5298.

Собрать образы и запустить все сервисы вы можете одной из команд:

docker compose -f docker-compose.db.yml -f docker-compose.app.dev.yml up --build

docker compose -f docker-compose.db.yml -f docker-compose.app.prd.yml up --build

Проверим что все образы на месте в Docker Desktop:

Протестируем работу нашего приложения:

Освежим в памяти, как загрузить образ в Container Registry, на примере нового образа для ads. Для этого нужно сначала добавить тэг:

docker tag weather-forecast-ads-img cr.selcloud.ru/deploy2production/weather-forecast-ads-img:v1.0

А потом отправить образ в Container Registry:

 docker push cr.selcloud.ru/deploy2production/weather-forecast-ads-img:v1.0

Проверяем список образов в интерфейсе Selectel:

Текущий вариант приложения мы не будем разворачивать в Selectel. Вы можете потренироваться самостоятельно, но для этого не забудьте обновить образ приложения app в Container Registry с новой версией кода. Далее мы добавим в сервис Ads базу данных.

З.Ы.

Традиционное заключение - автоматизированные тесты. Добавляем сборку для интеграционного тестирования сервиса Ads:

Сервис запускается в контейнере с помощью библиотеки Testcontainers:

Я выделил интересный момент - это ожидание, когда сервис запустится и будет готов отвечать на наши запросы. Для этого в сам сервис Ads я добавил контроллер, который называют health check:

Так же мы добавляем в UI-тест приложения проверку блока с рекламой:

Мы начали с простенького веб-приложения и разобрали базовые шаги в его публикации. Теперь пришло время немного усложнить наш учебный пример. В наши дни реальные проекты редко (читай "никогда") состоят только из одного сервиса, тем более когда так модны "микросервисы". Поэтому дальше мы разберемся как разрабатывать и публиковать много-модульные/сервисные проекты.

Поехали

Как всегда, код тут.

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

Я для удобства создам новый проект в том же solution, но представляя себе, что это два разных "микросервиса", сделаю их код не зависимым друг от друга. Так бы и произошло, если бы реальный большой проект разрабатывался несколькими команда, каждая из которых отвечала за определенные микросервисы (или только один). Для наглядности я разложу проекты по папочкам Ads и WeatherForecast:

Для сервиса Ads мне понадобятся два проекта:

DeployToProduction.Ads.Core - Library проект, в котором у нас будет код моделек

AdPost и AdRequest - простые Data Transfer Object (DTO) классы сериализуемые в JSON.

DeployToProduction.Ads.WebApi - ASP.NET Core Web API проект, который предоставит end-point для получения объектов AdPost по запросу с аргументом AdRequest.

Данные для сервиса пока для простоты мы "захардкодим". Контроллер для обработки запроса:

Уберем лишнее из настроек запуска и отключим открывание браузера при старте проекта:

И точка входа:

Вот такой простой сервис.

Нужно запустить и протестировать новый сервис. Делаем его в панели отладки активным

Запускаем:

Для тестирования "апишек" сегодня есть много инструментов, один из самый популярных - Postman.

Я предпочитаю использовать расширение для VS Code под названием REST Client из-за его простоты. Достаточно создать файл с расширением http и простым синтаксисом описать запросы. В редакторе появятся "кнопочки" Send Request, и теперь можно вручную выполнить проверку:

Файл web-api.http лежит в каталоге Test.

Теперь модифицируем приложение WeatherForecast. Помним, что проекты сервисов по нашей задумке должны быть независимыми, поэтому нам нужны копии моделек:

Создадим сервис, который будет отправлять запрос:

Остановлюсь на паре моментов.

Первое, timeout запроса должен быть. Практически всегда его выносят в настройки (конфигурационные файлы), чтобы настраивать под конкретные условия (скорость сети, нагрузка). Дефолтные 180 секунд не годятся. Пользователь не будет ждать. Если сервис не критичен для приложения, то есть он не отвечает, тогда "идем" дальше без него. Такие моменты нужно изначально продумывать в архитектуре приложения.

Второе, обработка ошибок. Ловим, оборачиваем в "свои" специфичные классы ошибок, добавляем контекста, информации, которая потом поможет при диагностике проблем. Это очень сложная тема, которая требует опыта, понимания и интуиции, что, где, как пойдет не так, и какая информация пригодится.

Добавляем свойство AdPost в модель страницы и делаем запрос к нашему сервису:

Выводим на страницу рекламу:

Нам понадобится добавить в настройки url сервиса Ads:

Настроим контейнер внедрения зависимостей:

Visual Studio позволяет нам во время разработки запускать и отлаживать несколько проектов, для этого нужно открыть свойства Solution:

Открываем раздел Common Properties -> Startup Project:

Выбераем Multiple startup projects, установливаем Action в значение Start для проектов DeployToProduction.Ads.WebApi и DeployToProduction.WeatherForecast.App, жмем ОК:

В панели отладки видим:

Помним, что для работы нашего приложения нужны баз данных, поэтому запускаем контейнеры:

docker run --name weather-forecast-postgres -p 5432:5432 -e POSTGRES_PASSWORD=postgres -d postgres
docker run --name weather-forecast-redis -p 6379:6379 -d redis

Теперь запускаем наши сервисы:

Проверяем:

Работает!

З.Ы.

Конечно же вы помните, что "тру" разработчики проверяют свой код автоматическими тестами. Пока вы в творческом цикле пишу-пробую инструменты ручного тестирования могут быть вам удобней, но готовый код - это код покрытый авто-тестами. Поэтому к тестированию сервиса Ads мы ещё вернемся. ;)

Замечательно, когда у вашего любимого провайдера есть готовые образы виртуальных машин с установленными docker-ом и docker compose-ом. Но если нет, то ничего страшного. Docker устанавливается по инструкции с официального сайта (сразу даю ссылочку на вариант установки из репозитория "Install using the apt repository"):

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

Заводите виртуальную машину (описание тут), только выберите конфигурацию "пожирнее", я для теста взял 2 vCPU, 4RAM, 15 ГБ HDD. Настраивайте подключение по ssh и устанавливайте docker, опыта копирования команд из инструкции вам должно хватить.

И так виртуальная машина готова. Docker установлен.

Поехали

Начнем с решения проблем. Если вы успешно установили docker под root-ом и потом создали своего пользователя, настроили ssh и подключились к виртуальной машине (как это сделал я), то использованием docker-а возникнут проблемы:

Для решения нам нужно добавить своего пользователя в группу "docker". Кстати посмотреть список всех групп в системе можно командой:

 cat /etc/group

А проверить список групп, в которые входит ваш пользователь:

groups

Добавляемся в группу "docker" командой:

sudo usermod -aG docker ${USER}

Для того, чтобы изменения применились, нужно разлогиниться и залогиниться, после проверяем:

Работает. Теперь логинимся в наш Container Registry командой:

docker login cr.selcloud.ru

Для проверки скачаем образ нашего приложения и утилиты:

docker pull cr.selcloud.ru/deploy2production/weather-forecast-app-img:v2.0

docker pull cr.selcloud.ru/deploy2production/weather-forecast-setup-img:v2.0

УПС

Посыплю голову пеплом. В пролом посте я накосячил с копированием команд, и собрал один и тот же образ под разными именами (хотя в тексте поста все корректно), и "залил" так в Container Registry. Будь я зорким как орел, я бы заметил одинаковый хэш образов. Но нет. Поэтому я пересобрал опубликовал образы с новым тегом-версией v2.0. Учимся на ошибках - дважды проверяем, хэши нам в помощь.

Продолжим. Давайте для разминки запустим наше приложение в "dev" варианте, как мы это делаем локально, с базами данных в контейнерах.

 mkdir dev
 cd dev
 nano ./docker-compose.yml

Нам понадобится docker-compose файл с некоторыми изменениями:

name: "weather-forecast"

networks:
  weather-forecast-net:

services:
  postgres:
    image: "postgres"
    container_name: "weather-forecast-postgres"
    networks:
      - weather-forecast-net
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
  redis:
    image: "redis"
    container_name: "weather-forecast-redis"
    networks:
      - weather-forecast-net
    ports:
      - "6379:6379"
  app:
    image: "cr.selcloud.ru/deploy2production/weather-forecast-app-img:v2.0"
    container_name: "weather-forecast-app"
    networks:
      - weather-forecast-net
    ports:
      - "80:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Development
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=weather-forecast-postgres;User Id=postgres;Password=postgres;Database=postgres
       ConnectionStrings__Redis: weather-forecast-redis:6379
    depends_on:
      postgres:
        condition: service_started
      redis:
        condition: service_started

Теперь сервис app использует образ из Container Registry вместо сборки из docker-файл. Ещё мы используем порт хота 80.

Поднимаем наши контейнеры:

docker compose up -d

Без удобного клиента Docker Desktop проверить какие контейнеры запущены можно командой:

docker ps

Фаервол на виртуальной машине мы ещё не настраивали, поэтому мы должны увидеть наш сайт снаружи:

И убедившись в том, что всё работает, останавливаем и удаляем контейнеры:

docker compose down

Теперь попробуем запустить наше приложение с базами данных от Selectel. Как создать базы данных в Selectel, вы уже знаете. Я прошлые базы данных удалил, поэтому создаю новые пользуясь своей же инструкцией, удобно =)

cd ~
mkdir dev-db
cd dev-db
nano ./docker-compose.yml

Содержимое файла docker-compose.yml:

name: "weather-forecast"

networks:
  weather-forecast-net:

services:
  app:
    image: "cr.selcloud.ru/deploy2production/weather-forecast-app-img:v2.0"
    container_name: "weather-forecast-app"
    networks:
      - weather-forecast-net
    ports:
      - "80:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Development
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=192.168.0.107;User Id=delilah;Password=*******;Database=weatherforecast
       ConnectionStrings__Redis: 192.168.0.222:6379,password==*********

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

docker compose up

И мы видим, что приложение успешно запускается и работает, но происходит ошибка при выполнении второго sql-скрипта, который настраивает схему базы данных, создает пользователя для приложения. Вот такой вот сюрприз, пользователь, которого мы создали через интерфейс личного кабинет (а это единственный доступный вариант), просто не имеет необходимых прав. Такое вот ограничение облачной базы данных Postgres в Selectel, связано это с реализацией на стороне Selectel. Но не унываем, значит нам нужно будет учесть этот момент и внести изменения в свой код ;)

Останавливаем приложение, Ctrl+C. Удаляем:

docker compose down

Давайте, для полноты картины создадим compose файлы для приложения и утилиты настройки базы данных так, как бы мы делали в "бою".

cd ~
mkdir prod
cd prod
mkdir setup
cd setup
nano ./docker-compose.yml

services:
  setup:
    image: "cr.selcloud.ru/deploy2production/weather-forecast-setup-img:v2.0"
    container_name: "weather-forecast-setup"
    environment:
       ConnectionStrings__Postgres: Host=192.168.0.107;User Id=delilah;Password=pwd;Database=weatherforecast

docker compose up

cd ~/prod
mkdir app
cd app
nano ./docker-compose.yml

name: "weather-forecast"

networks:
  weather-forecast-net:

services:
  app:
    image: "cr.selcloud.ru/deploy2production/weather-forecast-app-img:v2.0"
    container_name: "weather-forecast-app"
    networks:
      - weather-forecast-net
    ports:
      - "80:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Production
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=192.168.0.107;User Id=delilah;Password=pwd;Database=weatherforecast
       ConnectionStrings__Redis: 192.168.0.222:6379,password==pwd

docker compose up -d

docker compose ps

Подведем итоги. Мы разобрались на базовом уровне как разрабатывать, упаковывать и распространять приложение с помощью docker-а, и запускать его потом на виртуальной машине. Теперь дальше мы будем двигаться глубже =)

И так, мы с вами разобрались как "заворачивать" приложение в docker, как организовывать удобную работу с контейнерами с помощью docker compose (раз, два). Теперь пришло время попробовать эти знания в запуске приложения на виртуальном сервере.

Поехали

Исходники к этому посту такие же как на предыдущем шаге.

Начнем с чистого листа, запустим Docker Desktop и удалим ранее собранные образы нашего приложения.

Собираем docker-образ приложения:

docker build -t weather-forecast-app-img -f Dockerfile.app .

Собираем docker-образ утилиты setup:

docker build -t weather-forecast-setup-img -f Dockerfile.setup .

Образы собраны, но они находятся на диске нашего компьютера. Как же они попадут на виртуальный сервер, чтобы мы могли уже на нем запустить контейнеры из этих образов?

Хранилище для образов называется Container Registry.

Когда мы запускали контейнеры баз данных или собирали образ для нашего приложения, docker скачивал на наш диск базовые образы из хранилища Docker Hub. Docker Hub предоставляет какой-то объем для бесплатного размещения публичных образов и платные услуги для приватного использования. Но нам будет удобнее и дешевле создать Container Registry в Selectel.

Открываем панель управления Selectel, выбираем Облачные платформы -> Container Registry:

Жмем "Начать работу", вводим имя реестра и жмем "Создать":

Видим с писке созданное хранилище, кликаем по нему:

Жмем на кнопку с тремя точками, выбираем пункт "Получить токен":

Сохраняем к себе в надежное место логи и пароль:

Открываем терминал и логинимся в наш Container Registry:

docker login cr.selcloud.ru

Теперь нужно присвоить образу тэг:

docker tag weather-forecast-app-img cr.selcloud.ru/deploy2production/weather-forecast-app-img:v1.0

И загрузить образ в Container Registry:

docker push cr.selcloud.ru/deploy2production/weather-forecast-app-img:v1.0

Аналогично для утилиты setup:

docker tag weather-forecast-setup-img cr.selcloud.ru/deploy2production/weather-forecast-setup-img:v1.0

docker push cr.selcloud.ru/deploy2production/weather-forecast-setup-img:v1.0

И так, образы загружены:

Следующий шаг - настройка виртуальной машины.

Мы начали разбираться с Docker Compose на предыдущем шаге. Теперь хочется охватить чуть больше полезных фич этого инструмента, которые сильно помогут в разработке. Реальные проекты состоят нескольких приложений, программ, сервисов. В нашем случае мы рассмотрим следующий момент. Сервис при запуске ожидает настроенную схему базы данных Postgres. В режиме разработки мы при старте выполняли скрипты sql для создании таблиц. Но в "бою" такой подход не подойдет, так как у нас может одновременно запускаться несколько копий приложения или само приложение может состоять из нескольких сервисов. Обычно процедуру миграции (обновления) схемы базы данных выносят в отдельное приложение или используют для этого сторонний инструмент. На пример, если вы используете Entity Framework, то выполняете команду 'dotnet ef database update'. Мы создадим консольную программу, которая будет выполнять обновление схемы базы данных.

Поехали

Исходники к этому посту находятся тут.

Создадим консольный проект, добавим необходимые зависимости:

Добавим кофигурационные файлы и код:

Для демонстрации тут всё максимально просто: считываем настройки подключения, вызываем уже знакомый метод Setup класса Db.

Позвольте уделить внимание ещё одному важному моменту. Ранее наше приложение подключалось к postgres пользователем с "админскими" правами. Что не есть хорошо и не безопасно. Приложение должно иметь минимально необходимый уровень доступа к базе данных. Давайте это исправим. В проект "DeployToProduction.WeatherForecast.Data.Psql" нужно добавить новый sql-скрипт, который будет создавать пользователя для нашего приложения:

Не забудьте в настройках нового скрипта установить свойство "Build Action":

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

В 31-ой строке я меняю логин/пароль в строке подключения на нового пользователя.

В коде самого приложения мы убираем обновление схемы базы данных под условие с проверкой среды выполнения, таким образом при разработке нам будет удобно - схема обновляется, а в "бою" приложение будет ожидать подготовленной базы данных:

Перейдем к docker-у.

Удалим ранее созданные образы контейнера нашего приложения.

У нас теперь будет два docker-файла, один "Dockerfile.app" для сборки приложения, второй "Dockerfile.setup" для сборки нашей утилиты setup:

Обратите внимание, что при сборке консольного проекта на linux, расширение файла будет "dll", и его также нужно запускать через dotnet.

Веб приложение использует Postgres и Redis, для консольной утилиты setup нужен только Postgres, но нам лень (ладно, мне лень) и не хочется усложнять пример, поэтому мы создадим один файл docker compose "docker-compose.db.yml" для запуска баз данных, который далее будем переиспользовать:

Добавим "docker-compose.setup.yml" для запуска setup:

Запускаем setup в контейнере командой:

docker compose -f docker-compose.db.yml -f docker-compose.setup.yml up

Обратите внимание, я указываю оба файла.

В выводе в консоль мы видим, что два наших sql-скрипты были выполнены:

Ctrl+C - остановить, удалить остановленные контейнеры:

docker compose -f docker-compose.db.yml -f docker-compose.setup.yml down

Теперь docker compose для приложения. У нас будет два файла, один "docker-compose.app.dev.yml" для запуска при разработке, второй "docker-compose.app.prd.yml" - "боевой":

Тут у нас и Environment=Development и логин в Postgres админский. А, вот, второй будет интереснее:

Мы добавили в services нашу утилиту setup, которая будет выполнена перед запуском app, так как app зависит от setup, смотри depends_on. И логин/пароль в строке подключения Postgres используется пользователь, которого мы создали в новом sql-скрипте.

Запустим "боевой" compose:

docker compose -f docker-compose.db.yml -f docker-compose.app.prd.yml up

Запустилось. Видим работающие контейнеры баз данных и приложения, а контейнер setup выполнил свое дело и остановился:

Проверяем в браузере:

Работает!

Ctrl+C - остановить. Удалить контейнеры:

docker compose -f docker-compose.db.yml -f docker-compose.app.prd.yml down

Таким образом вы можете упростить себе процесс разработки, создавая переиспользуемые части инфраструктуры вашего приложения или организуя специфичные режимы работы.

З.Ы.

Ну, вы уже догадались... нет нам покоя пока тесты не будут полностью автоматизированы, поэтому вот код UI теста, который запускает все базы данных и приложение в контейнерах и "прокликивает" с помощью Selenium:

На предыдущих шагах (dev, Docker-изация) мы запускали контейнеры баз данных руками. Да, это полезно для понимания и тренировки, но не удобно в повседневной работе. Для сборки необходимого окружения одной командой есть Docker Compose - один файл описывает всё необходимое. Попробуем запустить всё наше приложение одни легким движением руки.

Поехали

Исходники к этому посту находятся тут.

Как всегда сначала почистим запущенные контейнеры и ранее созданные образы.

Добавим в проект файл docker-compose.yml:

version: "3.9"

name: "weather-forecast"

networks:
  weather-forecast-net:

services:
  postgres:
    image: "postgres"
    container_name: "weather-forecast-postgres"
    networks:
      - weather-forecast-net
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
  redis:
    image: "redis"
    container_name: "weather-forecast-redis"
    networks:
      - weather-forecast-net
    ports:
      - "6379:6379"
  app:
    container_name: "weather-forecast-app"
    image: "weather-forecast-app-img"
    build:
      context: .
      dockerfile: Dockerfile
    networks:
      - weather-forecast-net
    ports:
      - "5022:80"
    environment:
       ASPNETCORE_ENVIRONMENT: Production
       DOTNET_PRINT_TELEMETRY_MESSAGE: false
       ConnectionStrings__Postgres: Host=weather-forecast-postgres;Username=postgres;Password=postgres;Database=postgres
       ConnectionStrings__Redis: weather-forecast-redis:6379
    depends_on:
      postgres:
        condition: service_started
      redis:
        condition: service_started

Пройдемся по этому файлу.

networks - определяем сеть в которой будут работать наши контейнеры.

services - перечисляем нужные нам контейнеры.

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

Аналогично redis.

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

Подредактируем Dockerfile, нам уже не нужно указывать в нем переменные окружения:

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build

# Copy everything
COPY . ./

# Build and publish a release
RUN dotnet publish DeployToProduction.WeatherForecast.App --configuration Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:7.0
EXPOSE 80

COPY --from=build /out .

# Start App
ENTRYPOINT ["dotnet", "DeployToProduction.WeatherForecast.App.dll"]

Дл запуска открываем терминал в каталоге проекта и выполняем команду:

docker compose up

Команда "docker compose up" запускает все контейнеры перечисленные в файле docker-compose.yml и выводит в консоль их логи. Чтобы остановить контейнеры нажмите Ctrl+C. Для запуска в фоновом режиме используйте параметр -d:

docker compose up -d

Удалить все контейнеры можно командой:

docker compose down

Если вы внесли изменения в проект или Dockerfile, то пересобрать образ можно командой

docker compose build

Есть маленький нюанс. Наше приложение при старте выполняет обновление схемы базы данных Postgres. Хоть мы и указали, что контейнер приложения зависит от контейнера postgres, в момент выполнения запуска приложения база данных postgres может быть ещё не готова принимать запросы. Способов решения этой проблемы несколько, один из них - воспользоваться фичей docker compose - healthcheck. Но, так как я не хочу сильно закапывать вас в эти тонкости (при том что первый результат поиска из гугла и SO не сработает), я сделаю более простую и понятную проверку в коде Db.cs:

И так, проверяем:

Работает!

Пару слов в сторону. Мы ручками создавали простейший проект и настраивали работу с docker, чтобы вся эта кухня не казалась магией. Сегодня Visual Studio из коробки поддерживает интегрированную работу с Docker. Вы просто создаете новый проект и ставити галочку "Enable Docker". VS создаст для вас Dockerfile и настроит запуск и отладку приложения в контейнере. Более того, вы просто сможете добавить docker-compose.yml для инфраструктуры приложения.

З.Ы.

Хотелось бы тут добавить "вишенку на торте", как мы можем автоматизировать UI тест и запускать не просто контейнер из образа нашего приложения, а запускать docker compose, чтобы не приходилось руками поднимать контейнеры базы данных. Но, Testcontainers для Java имеет фичу по работе с docker compose (DockerComposeContainer), а вот в .NET её ещё не завезли. Хотя всё, что делает docker compose, вы можете воспроизвести в коде теста: создать сеть, создать контейнеры базы данных.

И так, у нас есть проект, подопытный кролик, который мы опубликовали нашими умелыми ручками на виртуальную машину с "настоящими" базами данных Postgres и Redis. В очевидной простоте (скачать исходники на виртуальную машину, собрать, настроить демона) есть и такие же очевидные недостатки:

• ручная работа (= ошибки), которую можно автоматизировать скриптами. Но главное достоинство хорошего программиста - это лень. Если можно что-то не делать, лучше этого не делать.
• сложности с обновлением приложения. Вот вы запустили первую версию. Прошло время и у вас готова новая версия приложения, а денег вы ещё не заработали на новые сервера. Вам придется производить работы на "горячем" сервере. Огромная доза адреналина вам обеспечена. Сервер будет обслуживать клиентов и в это же время собирать новую версию. А ещё нужно внести изменения в настройки системы и NGINX. Страшно! Логично остановить работу приложения на время работ. И скорее всего вам придется это сделать, так как новая версия потребует обновление схемы баз данных. А делать миграции баз данных так, чтобы не требовалось останавливать приложение нужно уметь ещё. И это пол беды. А что если в новой версии обнаружились баги?! o_0 Нужно откатываться на предыдущую версию (вы же не удалили ветку в git с предыдущей версией o_0). Опять останов. Куча адреналина!
• и самое волшебное, что может с вами случиться - проект просто не соберется на сервере. Да, да. Такое может случиться. Например, вы забили закомитить какой-то файл. Или GitHub или какой-то другой репозиторий прилег, или забанен. Или сервер NuGet решил взять выходной. Или...

Тут-то и приходит нам на помощь Docker. Но давайте по порядку. Сначала нам нужно поместить наше приложение в контейнер и научиться работать с ним локально.

Поехали

Исходники к этому посту находятся тут.

Начнем мы с того, что удалим контейнеры Postgres и Redis, который ранее создавали. Наше приложение будет запускаться в контейнере и подключаться оно будет к базам данных, который тоже находятся в контейнерах. Настройка сети Docker-а, которая используется по-умолчанию, сеть bridge, позволяет адресовать контейнеры только через IP, что не удобно (нужно будет после запуска контейнера узнавать его IP). Подробности тут. По этому мы сначала создадим свою сеть в Docker командой:

docker network create weather-forecast-net

Команды для создания контейнеров баз данных теперь будут выглядеть так (мы добавили параметр --net):

docker run --name weather-forecast-postgres --net weather-forecast-net -p 5432:5432 -e POSTGRES_PASSWORD=postgres -d postgres

docker run --name weather-forecast-redis --net weather-forecast-net -p 6379:6379 -d redis

Для создания образа контейнера нашего приложения нужно создать в проекте файл Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build

# Copy everything
COPY . ./

# Build and publish a release
RUN dotnet publish DeployToProduction.WeatherForecast.App --configuration Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:7.0
EXPOSE 80

COPY --from=build /out .

# Set Environment Variables for the App
ENV ASPNETCORE_ENVIRONMENT=Production
ENV DOTNET_PRINT_TELEMETRY_MESSAGE=false
ENV ConnectionStrings__Postgres="Host=weather-forecast-postgres;Username=postgres;Password=postgres;Database=postgres"
ENV ConnectionStrings__Redis="weather-forecast-redis:6379"

# Start App
ENTRYPOINT ["dotnet", "DeployToProduction.WeatherForecast.App.dll"]

В чем тут суть.

Сначала мы используем образ "mcr.microsoft.com/dotnet/sdk:7.0" для сборки и публикации проекта: копируем исходники инструкцией COPY, запускаем сборку dotnet инструкцией RUN.

Берем второй образ "mcr.microsoft.com/dotnet/aspnet:7.0", в котором есть только run-time dotnet-а и apt.net, копируем в него результат сборки-публикации, то есть наше приложение, задаем переменные окружения инструкцией ENV, и указываем какую команду должен выполнить контейнер при старте инструкцией ENTRYPOINT.

Обратите внимание, как мы задаем строки подключения, имена серверов баз данных - это имена контейнеров (для этого мы и создавали свою сеть в Docker).

Дополнительно, чтобы в образы не копировались "ненужные" файлы, радом с Dockerfile лежит файл .dockerignore - это список файлов и каталогов, который нужно проигнорировать при сборке образа.

Теперь открываем терминал в каталоге где лежит Dockerfile и выполняем команду сборки образа:

docker build -t weather-forecast-app-img -f Dockerfile .

Новый образ вы увидите в приложении Docker Desktop:

Осталось запустить контейнер из этого образа (образы баз данных должны быть запущены):

docker run --name weather-forecast-app --net weather-forecast-net -p 5022:80 -d weather-forecast-app-img

Проверяем в браузере:

Работает!

Подытожим. Теперь мы можем оперировать Docker-образами как единицами деплоймента. Один раз собрали образ контейнера - теперь он запускается и работает везде одинаково. "Развернуть" приложение теперь - это одна команда запуска Docker-контейнера. Образы хранятся и версионируются в специальных репозиториях.

З.Ы.

А теперь самое вкусненькое =) Помните, ранее для UI теста мы сначала запускали само приложение, а потом запускали тест. Теперь мы можем убрать это неудобство предоставив работу по запуску приложения библиотеке Testcontainers (у нас же теперь есть образ нашего приложения).

Создаем виртуальную машину. Только в этот раз в настройках сети выбираем "Приватная подсеть + 1 публичный IP". Наш сервер будет доступен по публичному IP, а базы данных будут находиться в приватной сети, и будут доступны только внутри неё. По соображениям безопасности лучше избегать выставления баз данных наружу.

В этот раз нам понадобится размер диска побольше, потому что 5 ГБ не хватит, я увеличил размер диска до 7ГБ.

После создания сервера мы видим в консоли 2 IP адреса: первый - публичный, второй - внутри приватной сети.

Далее настраиваете подключение по SSH.

Затем устанавливаете ПО: NGINX и ufw, dotnet

Ещё нам понадобится программа Git, чтобы скачать исходники с GitHub. Устанавливаете командой:

sudo apt install git -y

Теперь скачиваем исходники проекта, я качаю только ветку dev, последний коммит:

git clone --depth 1 -b dev https://github.com/deploy2production/weather-forecast.git

Переходим в каталог проекта и собираем его для публикации:

cd weather-forecast/

dotnet publish DeployToProduction.WeatherForecast.App --configuration Release

Теперь нам нужно создать базы данных. Заходим в панель управления Selectel, в левом меню выбираем "Облачная платформа" -> "Базы данных", жмем "Создать кластер".

Первой базой данных мы создадим Postgres.

Выбираем "Произвольная" конфигурация и ставим минимальные ресурсы, мы тренируемся, тратить лишние деньги нам ни к чему. Реплики нам тоже пока не нужны.

В настройках сети выбираем ранее созданную с виртуальной машиной подсеть.

И жмем "Создать кластер баз данных".

Второй базой данных создаем Redis. Также выбираем минимальные ресурсы.

Выбираем политику вытеснения. И генерируем пароль. С паролем тут аккуратно. Нам нужен пароль без запятых (замените запятые на другой символ). Сохраните пароль.

Выбираем подсеть. Жмем "Создать кластер баз данных".

Ждем пока базы данных будут созданы.

Теперь нужно настроить Postgres: создать пользователя и базу данных.

Кликаем на строку "WeatherForecastPgsql" в списке кластеров, выбираем вкладку "Пользователь".

Жмем "Создать пользователя". Вводим имя и пароль.

Ждем завершения операции:

Открываем вкладку "Базы данных", жмем "Создаем базу данных".

Выбираем имя, и влаельца, жмем "Создать".

Готово.

На вкладке "Настройки" вы можете увидеть как подключиться к базе данных, нам эта информация пригодится при настройке ConnectionStrings нашего сервиса:

С настройкой демонов вы уже знакомы. Кратко:

sudo nano /etc/systemd/system/weatherforecast.service

Меняем в настройках путь к каталогу куда проект был опубликован, имя dll-ки. И добавляем два ключа Environment (ConnectionStrings + два символа _ + название = значение в кавычках):

[Unit]
Description=weatherforecast

[Service]
WorkingDirectory=/home/aseverin/weather-forecast/DeployToProduction.WeatherForecast.App/bin/Release/net7.0/publish
ExecStart=dotnet ./DeployToProduction.WeatherForecast.App.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=weatherforecast
User=aseverin
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://127.0.0.1:5022
Environment=ConnectionStrings__Postgres="Host=192.168.0.115;Port=6432;UserName=webapp;Password=*******;Database=weatherforecast"
Environment=ConnectionStrings__Redis="192.168.0.136:6379,password=********"


[Install]
WantedBy=multi-user.targetmulti-user.targetmulti-user.target

Запускаем:

sudo systemctl enable weatherforecast.service
sudo systemctl start weatherforecast.service

Настраиваем NGINX:

sudo nano /etc/nginx/sites-available/default

Оставляем только один сервер для обработки запросов:

upstream backend {
        server 127.0.0.1:5022;
}
server {
        location / {
                proxy_pass http://backend;
        }
}

Перезапускаем NGINX:

sudo service nginx restart

Результат:

И давайте бонусом настроим DNS для нашего проекта.

Я открываю панель управления доменами в REG.RU, выбираю домен deploy2production.ru, жму "Добавить запись".

Выбираю запись "А"

Ввожу под-домен weather-forecast и публичный IP адрес моей виртуальной машины, жму "Готово":

Ждем, когда изменения DNS вступят в силу. Проверяем:

Готово.

З.Ы.

Не забываем после экспериментов и тренировок удалять не нужные ресурсы (виртуальные машины, базы данных)

Для дальнейшего погружения в тонкости разворачивания проектов нам понадобится подопытный кролик - веб-проект с типичной архитектурой, но с простой бизнес логикой и легко читаемым кодом. Мне пришел в голову сервис, который "предсказывает" случайную погоду.

Не смотря на свою банальность, в проекте используется база данных Postgres для хранения "предсказаний", более того предсказания кэшируются в базе данных Redis. Это типичная связка, "бд-кэш", используется для облегчения нагрузки на базу данных и ускорения ответа пользователю.

Исходный код всего проекта находится на GitHub. Я буду фиксировать код на состояние каждого поста в отдельных ветках. Код для этого поста находится в ветке dev.

Поехали

Посмотрим из чего состоит проект

DeployToProduction.WeatherForecast.App - ASP.NET Core приложение, которое использует только Razor-pages.

DeployToProduction.WeatherForecast.Core - библиотека с модельками

DeployToProduction.WeatherForecast.Data - библиотека описывающая абстракцию доступа к данным.

DeployToProduction.WeatherForecast.Data.Psql - библиотека с реализацией доступа к данным через базу данных Postgres.

Тут нужно поговорить подробнее. Я хотел бы отметить два момента:

1. Данные для бизнеса - это ключевой актив. Работу с данными нужно организовывать тщательнейшим образом, сто раз всё продумать, сто раз всё проверить, сделать все возможные бэкапы, проверить, что бэкапы работают, максимально автоматизировать, чтобы избежать человеческий фактор, проверить автоматизацию... В общем вы поняли, данные - это серьезно.
2. ORM - инструмент, который облегчает работу с данными на старте и многое скрывает от разработчика, в этом его и плюс и минус. Базы данных - это очень сложный инструмент и в устройстве работы конкретной базы данных в конкретном проекте придется разбираться, когда бизнес выйдет в свет (вырастит нагрузка, увеличится количество функционала, изменения требований посыпятся одним за одним). Поэтому, я считаю, стоит в пет-проектах потренироваться работать с базовым уровнем - SQL.

Создание схемы базы данных описывается в sql-файле:

Для выполнения этого sql используется библиотека DbUp, которая помогает с созданием и миграцией схем баз данных:

Это очень простой по сути подход, со 100% контролем происходящего - вы пишите SQL-скрипты создания всех объектов схемы БД и их последующую модификацию/миграцию. А библиотека DbUp обеспечит применение этих скриптов. Делает это она тоже довольно просто. В БД создается таблица schemaversions, в которую записываются все примененные скрипты. Таким образом каждый скрипт будет выполнен только один раз.

Ну и сам код работы с базой данных я не стал нагружать транзакциями, специфическими для Postgres конструкциями, а написал наиболее простой вариант, хоть и не корректный с точки зрения конкурентной записи в БД:

DeployToProduction.WeatherForecast.Data.Redis - библиотека с реализацией доступа к данным через кэш в Redis.

Кэширование в Redis я делаю с помощью паттерна "обертки":

Вернемся к основному приложению DeployToProduction.WeatherForecast.App и его запуску. Как вы поняли для запуска приложения нам понадобится Postgres и Redis. Их, конечно, можно установить в вашу систему, но так уже никто не носит. Для разворачивания подобных зависимостей сегодня используют Docker, с которым вы уже знакомы. Базового уровня "запустить контейнер из командной строки" вам будет достаточно. Необходимые команды есть в README.md:

Для подключения к базам данных вам нужно будет прописать ConnectionStrings в appsettings.Development.json:

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

Ну и конечно тесты. Без тестов нельзя. Логика у нас тривиальная и не требует юнит-тестов. А вот написание интеграционных и UI тестов показать хочется, потому что часто это дело кажется сложным и откладывается на потом, а потом уже поздно. Юнит тесты помогают держать дизайн кода чистым, а интеграционные тесты помогают держать чистой архитектуру. Поэтому тесты нужно писать сразу.

Для тестирования работы с базами данных я использую тот же Docker, но с помощью библиотеки Testcontainers. (Да, я хотел показать ещё один плюс от владения инструментом Docker)

DeployToProduction.WeatherForecast.Data.Psql.IntegrationTests

DeployToProduction.WeatherForecast.Data.Redis.IntegrationTests

Код тестов я специально оставил примитивным и с повторениями, чтобы было проще в нем разобраться. В боевом проекте задача по созданию тестового контейнера выносится в базовый класс, и код теста остаётся чистеньким.

Перед запуском тестов выключайте контейнеры, созданные для разработки, и запускайте тесты по одному, иначе будет ошибка из-за конфликта портов.

При запуске этих тестов вы можете заметить, как в приложении Docker Desktop создаются и удаляются контейнеры из ваших тестов + 1 вспомогательных контейнер:

DeployToProduction.WeatherForecast.App.UITests - тесты UI с помощью Selenium.

Автоматизировать запуск проекта ASP.NET из тестов - задача не тривиальная, но наиболее простым способом решается с помощью Docker-a и Docker Compose. И вернемся мы к этому вопросу, когда будет говорить о контейнеризации нашего приложения. А пока, я вам предлагаю вручную запустить проект без отладки (предварительно стартанув контейнеры для разработки) и потом запустить тест.

На этом наше знакомство с проектом завершено. Далее мы запустим проект в Selectel с управляемыми базами данных Postgres и Redis.

Заходим в панель управления Selectel, в левом меню выбираем "Облачная платформа" -> "Серверы", в списке выбираем свой сервер и жмем в "Выключить".

Ждем изменения статуса.

Копируем имя сервера. Нажимаем "Удалить сервер". В диалоге выбираем все галочки и вставляем скопированное имя сервера. "Удалить"

Список пуст: