Spring Boot: Multistage Dockerfile and Spring Application Profiles #tutorial

В этом видео мы рассмотрим, как использовать многоэтапный Docker-файл для приложения Spring Boot. Также у нас будут разные профили для приложений Spring. Сначала мы соберем этот образ в Docker, а также у меня есть еще один профиль, который будет запускать этот образ в рамках настройки Cloud Run. Давайте посмотрим. Начнем с конфигурации Docker-файла. Это опять же из моего уровня моих проектов, и это очень простое приложение Spring Boot. В этом проекте у меня есть Docker-файл, вот он. И в этом файле у меня настроены два этапа. На первом этапе у нас есть сам Builder, который будет... Давайте рассмотрим все по порядку. Мы будем использовать его в качестве базового образа, а затем назовем этот этап, чтобы позже мы могли скопировать в качестве конечного результата рабочий каталог, Maven, а затем файл зависимостей. И здесь я также делаю строку, чтобы мы могли загрузить все эти файлы. То же самое произойдет, например... Если я внесу это изменение в GCP ( в моем случае я использую Cloud Run и Cloud Build), это также произойдет внутри Cloud Build: будет загружен исходный код и выполнена чистая установка. На этом этапе я выполняю настройку Docker, и это критически важный момент, потому что по умолчанию у меня есть эта конфигурация, и она зависит от внешней базы данных, в моем случае это PostgreSQL. Если я не изменю это, например, в настройке Docker или в любой внешней среде, например, в GCP Build, это, скорее всего, завершится неудачей, потому что у меня могут быть тесты, зависящие от этой базы данных, или мое приложение попытается запуститься, и поскольку эта независимость отсутствует, оно просто завершится неудачей. Вот почему в файле Docker крайне важно дать инструкции, например, для этого этапа сборки, чтобы он мог использовать другой профиль. И вот этот профиль, позвольте мне также показать этот файл. Он очень похож, возможно, я даже смогу объединить некоторые части и иметь только отдельные различия в виде разных профилей, но пока это просто... Итак, подготовьте тот же файл, и единственное отличие здесь в том, что в качестве источника данных я использую H2. Если в обычной настройке я использую PostgreSQL, то в этом случае я использую H2. Если я просто покажу, что такое H2, то H2 — это, по сути, движок базы данных, и он может работать как база данных в оперативной памяти, а также совместим с ней. Поэтому я могу без изменения какой-либо кодовой базы просто изменить конфигурацию, а затем запустить это приложение, и оно будет работать так же, как и с реальной базой данных. Вот почему, когда у нас есть эта настройка, а затем мы запускаем это, оно будет использовать эту конфигурацию, оно будет использовать базу данных в оперативной памяти, и в качестве результата мы ожидаем получить JAR-файл. Таким образом, мое приложение настроено на вывод результата в SHR-файл. Что мы делаем на следующем этапе? Мы запускаем другой уровень, еще один этап, по сути, мы снова настраиваем работу напрямую, мы открываем фактический порт, а затем выполняем копирование. Это важный этап, шаг на этом этапе. Это означает, что результаты сборки копируются в этот рабочий каталог, а затем запускаются. И на этом этапе мы запускаем с облачной конфигурацией. Это гарантирует, что наше приложение будет собрано с одной конфигурацией и будет работать, например, с UCP. У вас может быть база данных PostgreSQL с другими настройками строки подключения, именем пользователя и паролем. Таким образом, это обеспечит использование другой конфигурации при запуске самого приложения, и оно сможет подключиться к базе данных. Возможно, вам это не понадобится на этапе сборки. Конечно, есть и другие способы добиться того же, но этот, на мой взгляд, довольно прост и понятен. В данном случае, если у вас всего одна дополнительная зависимость, позвольте мне показать это. В моем файле формы у меня есть эта зависимость, которая фактически является десятой зависимостью для этой базы данных H2. Именно поэтому, когда у нас есть эта конфигурация, и я указал эту

зависимость в приложении, оно будет использовать эту зависимость. Это настройка, которую я использую для Cloud Run и Cloud Build. Таким образом, приложение будет работать в Cloud Run на этапе сборки. Это та же самая кодовая база и репозиторий, и когда я отправляю свои изменения в Triple Story, это логи из GCP, и мы видим, как он пытается загрузить и собрать образ, а в конце он создаст этот образ, а затем запустит его с другой настройкой базы данных, и это всегда происходит автоматически. Очевидно, это часть CCI/CICD, и затем я могу протестировать приложение без каких-либо ручных действий между ними. Вероятно, вот такая конфигурация и как она работает. Что такое фактическая конфигурация базы данных для облачного запуска? Мы можем посмотреть на руководство по этому вопросу. В заключение, у нас есть три основные части: первая — это сам Docker-файл, в котором у нас есть многоэтапная конфигурация, и в которой мы также используем различные профили; вторая часть — это использование, например, этого профиля, базы данных H2, чтобы мы могли запустить это приложение с базой данных в памяти; и вставка этой зависимости в наш файл pump. И как только у вас есть все три части, вы можете запустить приложение и использовать тот же подход.