Spec-Zone.ru › Spring Boot

Развертывание приложений Spring Boot

Гибкие возможности упаковки Spring Boot предоставляют большой выбор при развертывании вашего приложения. Вы можете развернуть приложения Spring Boot на различных облачных платформах, на виртуальных/реальных машинах или сделать их полностью исполняемыми для Unix-систем.

В этом разделе рассматриваются некоторые из наиболее распространенных сценариев развертывания.

1. Развёртывание в облаке

Исполняемые JAR-файлы Spring Boot готовы к использованию с большинством популярных поставщиков облачных платформ PaaS (Platform-as-a-Service). Эти поставщики, как правило, требуют, чтобы вы «принесли свой собственный контейнер». Они управляют процессами приложений (а не Java-приложений конкретно), поэтому им нужен промежуточный слой, который адаптирует ваше приложение к понятию облака о работающем процессе.

Два популярных поставщика облачных услуг, Heroku и Cloud Foundry, используют подход «buildpack». Buildpack упаковывает ваш развертываемый код во всё необходимое для запуска вашего приложения. Это может быть JDK и вызов java, встроенный веб-сервер или полнофункциональный сервер приложений. Buildpack является подключаемым, но в идеале вы должны иметь возможность обойтись с минимальными настройками. Это уменьшает размер функциональности, которая не находится под вашим контролем. Это сводит к минимуму расхождения между средами разработки и производства.

В идеале ваше приложение, например, исполняемый JAR-файл Spring Boot, должно содержать всё необходимое для его запуска.

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

1.1. Cloud Foundry

Cloud Foundry предоставляет стандартные buildpack, которые используются, если не указан другой buildpack. Cloud Foundry Java buildpack имеет отличную поддержку Spring-приложений, включая Spring Boot. Вы можете развернуть как автономные исполняемые JAR-приложения, так и традиционные .war упакованные приложения.

После того, как вы построили своё приложение (например, с помощью mvn clean package) и установили cf командную утилиту, разверните приложение с помощью команды cf push, заменив путь к вашему скомпилированному .jar . Убедитесь, что вы войшли в систему с помощью вашего cf командного клиента, прежде чем развернуть приложение. Следующая строка демонстрирует использование команды cf push для развертывания приложения:

$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
В предыдущем примере мы подставляем acloudyspringtime вместо значения, которое вы даёте cf в качестве имени вашего приложения.

См. cf push документацию для получения дополнительных опций. Если в той же директории присутствует файл Cloud Foundry manifest.yml, он будет рассмотрен.

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

Uploading acloudyspringtime... OK
Preparing to start acloudyspringtime... OK
-----> Downloaded app package (8.9M)
-----> Java Buildpack Version: v3.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#6f25b7e
-----> Downloading Open Jdk JRE
       Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.6s)
-----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
       Memory Settings: -Xss349K -Xmx681574K -XX:MaxMetaspaceSize=104857K -Xms681574K -XX:MetaspaceSize=104857K
-----> Downloading Container Certificate Trust Store 1.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-1.0.0_RELEASE.jar (found in cache)
       Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.6s)
-----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
Checking status of app 'acloudyspringtime'...
  0 of 1 instances running (1 starting)
  ...
  0 of 1 instances running (1 starting)
  ...
  0 of 1 instances running (1 starting)
  ...
  1 of 1 instances running (1 running)

App started

Поздравляем! Приложение теперь доступно!

После того, как ваше приложение будет развернуто, вы можете проверить статус развернутого приложения с помощью команды cf apps, как показано в следующем примере:

$ cf apps
Getting applications in ...
OK

name                 requested state   instances   memory   disk   urls
...
acloudyspringtime    started           1/1         512M     1G     acloudyspringtime.cfapps.io
...

После того, как Cloud Foundry подтвердит развертывание вашего приложения, вы должны найти его по указанному URI. В предыдущем примере вы могли бы найти его по адресу https://acloudyspringtime.cfapps.io/.

1.1.1. Связывание со службами

По умолчанию метаданные о работающем приложении, а также информация о подключении к услугам предоставляются приложению в виде переменных среды (например: $VCAP_SERVICES). Такое архитектурное решение обусловлено полиглотной (любой язык и платформа могут быть поддерживаемы как buildpack) природой Cloud Foundry. Переменные среды, относящиеся к процессу, не зависят от языка.

Переменные среды не всегда представляют собой самый простой API, поэтому Spring Boot автоматически извлекает их и сжимает данные в свойства, которые можно получить через Environment абстракцию Spring, как показано в следующем примере:

Java
import org.springframework.context.EnvironmentAware;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;

@Component
public class MyBean implements EnvironmentAware {

    private String instanceId;

    @Override
    public void setEnvironment(Environment environment) {
        this.instanceId = environment.getProperty("vcap.application.instance_id");
    }

    // ...

}
Kotlin
import org.springframework.context.EnvironmentAware
import org.springframework.core.env.Environment
import org.springframework.stereotype.Component

@Component
class MyBean : EnvironmentAware {

    private var instanceId: String? = null

    override fun setEnvironment(environment: Environment) {
        instanceId = environment.getProperty("vcap.application.instance_id")
    }

    // ...

}

Все свойства Cloud Foundry имеют префикс vcap. Вы можете использовать свойства vcap для доступа к информации об приложении (такой как общедоступный URL приложения) и информации о службах (такой как данные для входа в базу данных). См. CloudFoundryVcapEnvironmentPostProcessor Javadoc для получения подробной информации.

Проект Java CFEnv больше подходит для задач, таких как настройка DataSource.

1.2. Kubernetes

Spring Boot автоматически определяет среды развертывания Kubernetes, проверяя среду на наличие "*_SERVICE_HOST" и "*_SERVICE_PORT" переменных. Вы можете переопределить это обнаружение свойством конфигурации spring.main.cloud-platform.

Spring Boot помогает вам управлять состоянием вашего приложения и экспортировать его с помощью HTTP-зондов Kubernetes с использованием Actuator.

1.2.1. Жизненный цикл контейнера Kubernetes

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

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

spec:
  containers:
  - name: "example-container"
    image: "example-image"
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 10"]

После завершения обработки pre-stop будет отправлен сигнал SIGTERM контейнеру и начнётся плавное завершение, позволяя завершить все оставшиеся в очереди запросы.

Когда Kubernetes отправляет сигнал SIGTERM под, он ожидает определённый период времени, называемый периодом завершения (по умолчанию он составляет 30 секунд). Если контейнеры всё ещё работают после этого периода, им отправляется сигнал SIGKILL и они удаляются принудительно. Если под занимает больше 30 секунд на завершение, что может быть связано с увеличением spring.lifecycle.timeout-per-shutdown-phase, убедитесь, что увеличили период завершения, задав параметр terminationGracePeriodSeconds в файле Pod YAML.

1.3. Heroku

Heroku — ещё одна популярная платформа PaaS. Чтобы настроить сборку Heroku, вы предоставляете Procfile, который содержит необходимые инструкции для развертывания приложения. Heroku назначает port для использования Java-приложением и затем гарантирует, что перенаправление на внешний URI работает.

Вы должны настроить приложение для прослушивания правильного порта. Следующий пример показывает Procfile для нашего стартового REST-приложения:

web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar

Spring Boot делает доступными аргументы -D в качестве свойств, доступных из экземпляра Spring Environment. Свойство конфигурации server.port передаётся встраиваемому экземпляру Tomcat, Jetty или Undertow, который затем использует порт при запуске. Переменная среды $PORT назначается нам платформой PaaS Heroku.

Этого должно быть достаточно. Наиболее распространённый рабочий процесс развертывания на Heroku — это git push код в производство, как показано в следующем примере:

$ git push heroku main

Что приведёт к следующему:

Initializing repository, done.
Counting objects: 95, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (78/78), done.
Writing objects: 100% (95/95), 8.66 MiB | 606.00 KiB/s, done.
Total 95 (delta 31), reused 0 (delta 0)

-----> Java app detected
-----> Installing OpenJDK... done
-----> Installing Maven... done
-----> Installing settings.xml... done
-----> Executing: mvn -B -DskipTests=true clean install

       [INFO] Scanning for projects...
       Downloading: https://repo.spring.io/...
       Downloaded: https://repo.spring.io/... (818 B at 1.8 KB/sec)
        ....
       Downloaded: https://s3pository.heroku.com/jvm/... (152 KB at 595.3 KB/sec)
       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/target/...
       [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml ...
       [INFO] ------------------------------------------------------------------------
       [INFO] BUILD SUCCESS
       [INFO] ------------------------------------------------------------------------
       [INFO] Total time: 59.358s
       [INFO] Finished at: Fri Mar 07 07:28:25 UTC 2014
       [INFO] Final Memory: 20M/493M
       [INFO] ------------------------------------------------------------------------

-----> Discovering process types
       Procfile declares types -> web

-----> Compressing... done, 70.4MB
-----> Launching... done, v6
       https://agile-sierra-1405.herokuapp.com/ deployed to Heroku

To git@heroku.com:agile-sierra-1405.git
 * [new branch]      main -> main

Теперь ваше приложение должно быть запущено на Heroku. Для получения более подробной информации см. Развертывание Spring Boot-приложений на Heroku.

1.4. OpenShift

OpenShift имеет много ресурсов, описывающих, как развертывать Spring Boot-приложения, включая:

  • Использование билдера S2I

  • Архитектурное руководство

  • Запуск как традиционное веб-приложение на Wildfly

  • Брифинг OpenShift Commons

1.5. Amazon Web Services (AWS)

Amazon Web Services предлагает множество способов установки приложений Spring Boot, как традиционных веб-приложений (war), так и исполняемых JAR-файлов с встроенным веб-сервером. К ним относятся:

  • AWS Elastic Beanstalk

  • AWS Code Deploy

  • AWS OPS Works

  • AWS Cloud Formation

  • AWS Container Registry

Каждый из них имеет разные функции и модели ценообразования. В этом документе мы описываем подход с использованием AWS Elastic Beanstalk.

1.5.1. AWS Elastic Beanstalk

Как описано в официальном руководстве по Elastic Beanstalk для Java, существует два основных варианта развертывания Java-приложения. Вы можете использовать «платформу Tomcat» или «платформу Java SE».

Использование платформы Tomcat

Этот вариант подходит для проектов Spring Boot, которые производят файл war. Специальная настройка не требуется. Вам нужно только следовать официальному руководству.

Использование платформы Java SE

Этот вариант подходит для проектов Spring Boot, которые производят JAR-файл и запускают встроенный веб-контейнер. Среды Elastic Beanstalk запускают экземпляр nginx на порту 80 для проксирования фактического приложения, работающего на порту 5000. Для его настройки добавьте следующую строку в ваш application.properties файл:

server.port=5000
Загрузка бинарных файлов вместо исходного кода

По умолчанию Elastic Beanstalk загружает исходный код и компилирует его в AWS. Однако лучше загрузить бинарные файлы. Для этого добавьте строки, подобные следующим, в ваш .elasticbeanstalk/config.yml файл:

deploy:
    artifact: target/demo-0.0.1-SNAPSHOT.jar
Сокращение затрат, установкой типа среды

По умолчанию среда Elastic Beanstalk сбалансирована по нагрузке. Балансировщик нагрузки имеет значительные затраты. Чтобы избежать этих затрат, установите тип среды на «Единственный экземпляр», как описано в документации Amazon. Также вы можете создать среды с единственным экземпляром, используя CLI и следующую команду:

eb create -s

1.5.2. Резюме

Это один из самых простых способов работы с AWS, но есть и другие моменты, такие как интеграция Elastic Beanstalk в любой инструмент CI/CD, использование плагина Elastic Beanstalk Maven вместо CLI и другие. Более подробную информацию по этим темам можно найти в статье блога.

1.6. CloudCaptain и Amazon Web Services

CloudCaptain преобразует ваш исполняемый JAR- или WAR-файл Spring Boot в минимальную виртуальную машину, которую можно развернуть без изменений в VirtualBox или AWS. CloudCaptain имеет глубокую интеграцию с Spring Boot и использует информацию из файла конфигурации Spring Boot для автоматической настройки портов и URL-адресов проверки работоспособности. CloudCaptain использует эту информацию как для создаваемых образов, так и для всех предоставляемых ресурсов (экземпляры, группы безопасности, балансировщики нагрузки и т. д.).

После создания аккаунта CloudCaptain, подключения его к вашей учетной записи AWS, установки последней версии клиента CloudCaptain и обеспечения того, что приложение было скомпилировано с помощью Maven или Gradle (например, mvn clean package), вы можете развернуть ваше приложение Spring Boot в AWS с помощью команды, аналогичной следующей:

$ boxfuse run myapp-1.0.jar -env=prod

См. boxfuse run документацию для получения дополнительной информации. Если в текущем каталоге присутствует файл boxfuse.conf, он учитывается.

По умолчанию CloudCaptain активирует профиль Spring с именем boxfuse при запуске. Если ваш исполняемый JAR- или WAR-файл содержит файл application-boxfuse.properties, CloudCaptain основывает свою конфигурацию на свойствах, содержащихся в нём.

В этот момент CloudCaptain создаёт образ вашего приложения, загружает его и настраивает и запускает необходимые ресурсы в AWS, что приводит к выводу, подобному следующему примеру:

Fusing Image for myapp-1.0.jar ...
Image fused in 00:06.838s (53937 K) -> axelfontaine/myapp:1.0
Creating axelfontaine/myapp ...
Pushing axelfontaine/myapp:1.0 ...
Verifying axelfontaine/myapp:1.0 ...
Creating Elastic IP ...
Mapping myapp-axelfontaine.boxfuse.io to 52.28.233.167 ...
Waiting for AWS to create an AMI for axelfontaine/myapp:1.0 in eu-central-1 (this may take up to 50 seconds) ...
AMI created in 00:23.557s -> ami-d23f38cf
Creating security group boxfuse-sg_axelfontaine/myapp:1.0 ...
Launching t2.micro instance of axelfontaine/myapp:1.0 (ami-d23f38cf) in eu-central-1 ...
Instance launched in 00:30.306s -> i-92ef9f53
Waiting for AWS to boot Instance i-92ef9f53 and Payload to start at https://52.28.235.61/ ...
Payload started in 00:29.266s -> https://52.28.235.61/
Remapping Elastic IP 52.28.233.167 to i-92ef9f53 ...
Waiting 15s for AWS to complete Elastic IP Zero Downtime transition ...
Deployment completed successfully. axelfontaine/myapp:1.0 is up and running at https://myapp-axelfontaine.boxfuse.io/

Теперь ваше приложение должно быть запущено в AWS.

См. также запись в блоге о развертывании приложений Spring Boot на EC2 и документацию по интеграции CloudCaptain с Spring Boot, чтобы начать работу с Maven сборкой для запуска приложения.

1.7. Azure

Это руководство по началу работы поможет вам развернуть ваше приложение Spring Boot на Azure Spring Cloud или Azure App Service.

1.8. Google Cloud

Google Cloud предлагает несколько вариантов запуска приложений Spring Boot. Наиболее простым для начала работы является App Engine, но вы также можете запустить Spring Boot в контейнере с помощью Container Engine или на виртуальной машине с Compute Engine.

Чтобы развернуть ваше первое приложение в стандартной среде App Engine, следуйте этому руководству.

В качестве альтернативы, для App Engine Flex вам необходимо создать файл app.yaml для описания ресурсов, необходимых вашему приложению. Обычно этот файл размещается в src/main/appengine, и он должен напоминать следующий файл:

service: "default"

runtime: "java17"
env: "flex"

handlers:
- url: "/.*"
  script: "this field is required, but ignored"

manual_scaling:
  instances: 1

health_check:
  enable_health_check: false

env_variables:
  ENCRYPT_KEY: "your_encryption_key_here"

Вы можете развернуть приложение (например, с помощью плагина Maven), добавив идентификатор проекта в конфигурацию сборки, как показано в следующем примере:

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>appengine-maven-plugin</artifactId>
    <version>2.4.4</version>
    <configuration>
        <project>myproject</project>
    </configuration>
</plugin>

Затем разверните с помощью mvn appengine:deploy (вам необходимо предварительно пройти аутентификацию, в противном случае сборка завершится ошибкой).

2. Установка приложений Spring Boot

Помимо запуска приложений Spring Boot с помощью java -jar, также можно создавать полностью исполняемые приложения для Unix-систем. Полностью исполняемый jar-файл можно запустить как любой другой исполняемый бинарник, или его можно зарегистрировать в init.d или systemd. Это полезно при установке и управлении приложениями Spring Boot в распространённых производственных средах.

Полностью исполняемые jar-файлы работают путём вставки дополнительного скрипта в начало файла. В настоящее время некоторые инструменты не поддерживают этот формат, поэтому использование этого метода не всегда возможно. Например, jar -xf может без ошибок пропустить извлечение jar-файла или war-файла, созданного как полностью исполняемый. Рекомендуется создавать полностью исполняемые jar-файлы или war-файлы только в том случае, если вы планируете запускать их напрямую, а не с помощью java -jar или развертывать их в контейнере сервлета.
Jar-файл в формате zip64 нельзя сделать полностью исполняемым. Попытка сделать это приведёт к тому, что jar-файл будет считаться повреждённым при запуске напрямую или с помощью java -jar. Стандартный jar-файл, содержащий один или несколько вложенных jar-файлов в формате zip64, может быть полностью исполняемым.

Для создания ‘полностью исполняемого’ jar-файла с Maven используйте следующую конфигурацию плагина:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <executable>true</executable>
    </configuration>
</plugin>

Следующий пример демонстрирует эквивалентную конфигурацию Gradle:

tasks.named('bootJar') {
    launchScript()
}

Затем вы можете запустить своё приложение, набрав ./my-application.jar (где my-application — имя вашего артефакта). Директория, содержащая jar-файл, используется в качестве рабочей директории вашего приложения.

2.1. Поддерживаемые операционные системы

По умолчанию скрипт поддерживает большинство дистрибутивов Linux и протестирован на CentOS и Ubuntu. Для других платформ, таких как OS X и FreeBSD, требуется использование пользовательского embeddedLaunchScript.

2.2. Unix/Linux-сервисы

Приложения Spring Boot можно легко запускать как Unix/Linux-сервисы с помощью init.d или systemd.

2.2.1. Установка в качестве сервиса init.d (System V)

Если вы настроили плагин Maven или Gradle Spring Boot для генерации полностью исполняемого jar-файла, и не используете пользовательский embeddedLaunchScript, ваше приложение можно использовать в качестве сервиса init.d. Для этого создайте символическую ссылку на jar-файл в init.d, чтобы поддерживать стандартные команды start, stop, restart, и status.

Скрипт поддерживает следующие функции:

  • Запускает сервисы от имени пользователя, которому принадлежит jar-файл

  • Отслеживает PID приложения с помощью /var/run/<appname>/<appname>.pid

  • Записывает логи консоли в /var/log/<appname>.log

Предполагая, что приложение Spring Boot установлено в /var/myapp, для установки приложения Spring Boot в качестве сервиса init.d создайте символическую ссылку следующим образом:

$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp

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

$ service myapp start
Если приложение не запускается, проверьте файл логов, записанный в /var/log/<appname>.log, на наличие ошибок.

Вы также можете настроить автоматический запуск приложения, используя стандартные инструменты вашей операционной системы. Например, в Debian можно использовать следующую команду:

$ update-rc.d myapp defaults <priority>
Защита сервиса init.d
Следующие рекомендации помогут защитить приложение Spring Boot, работающее как сервис init.d. Этот список не претендует на исчерпывающее руководство по всем необходимым мерам по повышению устойчивости приложения и среды его работы.

При выполнении от имени root, как это происходит при запуске сервиса init.d с правами root, по умолчанию исполняемый скрипт запускает приложение от имени пользователя, указанного в переменной среды RUN_AS_USER. Если переменная среды не задана, используется пользователь, которому принадлежит jar-файл. Вы никогда не должны запускать приложение Spring Boot от имени root, поэтому RUN_AS_USER не должен быть root, а jar-файл вашего приложения не должен принадлежать root. Вместо этого создайте отдельного пользователя для запуска приложения и задайте переменную среды RUN_AS_USER или используйте chown для задания владельца jar-файла, как показано в следующем примере:

$ chown bootapp:bootapp your-app.jar

В этом случае по умолчанию исполняемый скрипт запускает приложение от имени пользователя bootapp.

Для снижения вероятности компрометации учётной записи пользователя приложения, рассмотрите возможность предотвращения использования им login shell. Например, можно установить оболочку для учётной записи на /usr/sbin/nologin.

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

$ chmod 500 your-app.jar

Во-вторых, необходимо принять меры, чтобы ограничить ущерб, если ваше приложение или учётная запись, под которой оно работает, будут скомпрометированы. Если злоумышленник получит доступ, он может сделать jar-файл доступным для записи и изменить его содержимое. Одним из способов защиты от этого является применение необратимости, используя chattr, как показано в следующем примере:

$ sudo chattr +i your-app.jar

Это предотвратит изменение jar-файла любым пользователем, включая root.

Если root используется для управления сервисом приложения, и вы используете файл .conf для настройки запуска, то файл .conf читается и обрабатывается пользователем root. Он должен быть защищён соответствующим образом. Используйте chmod, чтобы файл был доступен только для чтения владельцу, и используйте chown для присвоения root в качестве владельца, как показано в следующем примере:

$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf

2.2.2. Установка в качестве сервиса systemd

systemd — это преемник системы инициализации System V, и в настоящее время используется во многих современных дистрибутивах Linux. Хотя вы можете продолжать использовать скрипты init.d с systemd, также можно запускать приложения Spring Boot с использованием скриптов сервиса systemd.

Предполагая, что приложение Spring Boot установлено в /var/myapp, для установки приложения Spring Boot как сервиса systemd создайте скрипт с именем myapp.service и поместите его в директорию /etc/systemd/system. Следующий скрипт предлагает пример:

[Unit]
Description=myapp
After=syslog.target

[Service]
User=myapp
ExecStart=/var/myapp/myapp.jar
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target
Помните о необходимости изменения полей Description, User, и ExecStart для вашего приложения.
Поле ExecStart не объявляет команду действия скрипта, что означает, что команда run используется по умолчанию.

Обратите внимание, что в отличие от запуска в качестве сервиса init.d, пользователь, выполняющий приложение, файл PID и файл лога консоли управляются самим systemd, поэтому должны быть настроены соответствующими полями в скрипте сервиса. Обратитесь к странице руководства по конфигурации единиц сервиса для получения дополнительной информации.

Для настройки автоматического запуска приложения при загрузке системы используйте следующую команду:

$ systemctl enable myapp.service

Запустите man systemctl для получения дополнительной информации.

2.2.3. Настройка скрипта запуска

По умолчанию, встроенный скрипт запуска, написанный плагином Maven или Gradle, может быть настроен различными способами. Для большинства пользователей достаточно использования скрипта по умолчанию с небольшими настройками. Если вы не можете настроить необходимый параметр, используйте опцию embeddedLaunchScript, чтобы написать собственный файл полностью.

Настройка скрипта запуска при его написании

Часто имеет смысл настраивать элементы скрипта запуска при его записи в файл jar. Например, скрипты init.d могут содержать «описание». Поскольку вы знаете описание заранее (и оно не должно изменяться), вы можете указать его при генерации jar-файла.

Для настройки элементов, записанных в файл, используйте опцию embeddedLaunchScriptProperties плагина Spring Boot Maven или свойство properties свойства плагина Spring Boot Gradle launchScript.

Следующие подстановки свойств поддерживаются в скрипте по умолчанию:

Имя Описание Значение по умолчанию Gradle Значение по умолчанию Maven

mode

Режим скрипта.

auto

auto

initInfoProvides

Раздел Provides в «INIT INFO»

${task.baseName}

${project.artifactId}

initInfoRequiredStart

Раздел Required-Start в «INIT INFO».

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoRequiredStop

Раздел Required-Stop в «INIT INFO».

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoDefaultStart

Раздел Default-Start в «INIT INFO».

2 3 4 5

2 3 4 5

initInfoDefaultStop

Раздел Default-Stop в «INIT INFO».

0 1 6

0 1 6

initInfoShortDescription

Раздел Short-Description в «INIT INFO».

Однострочная версия ${project.description} (возвращаясь к ${task.baseName})

${project.name}

initInfoDescription

Раздел Description в «INIT INFO».

${project.description} (возвращаясь к ${task.baseName})

${project.description} (возвращаясь к ${project.name})

initInfoChkconfig

Раздел chkconfig в «INIT INFO»

2345 99 01

2345 99 01

confFolder

Значение по умолчанию для CONF_FOLDER

Папка, содержащая jar-файл

Папка, содержащая jar-файл

inlinedConfScript

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

logFolder

Значение по умолчанию для LOG_FOLDER. Действительно только для сервиса init.d

logFilename

Значение по умолчанию для LOG_FILENAME. Действительно только для сервиса init.d

pidFolder

Значение по умолчанию для PID_FOLDER. Действительно только для сервиса init.d

pidFilename

Значение по умолчанию для имени файла PID в PID_FOLDER. Действительно только для сервиса init.d

useStartStopDaemon

Использовать команду start-stop-daemon, если она доступна, для управления процессом

true

true

stopWaitTime

Значение по умолчанию для STOP_WAIT_TIME в секундах. Действительно только для сервиса init.d

60

60
Настройка скрипта во время его выполнения

Для элементов скрипта, которые нужно настроить после создания jar-файла, вы можете использовать переменные среды или конфигурационный файл.

В стандартном скрипте поддерживаются следующие переменные среды:

Переменная Описание

MODE

Режим работы. По умолчанию режим зависит от способа сборки jar-файла, но обычно auto (пытается определить, является ли скрипт скриптом инициализации, проверяя, является ли он символьным ссылкой в каталоге init.d). Вы можете явно установить его в service, чтобы команды stop|start|status|restart работали, или в run, если вы хотите запустить скрипт в фоновом режиме.

RUN_AS_USER

Пользователь, который будет использоваться для запуска приложения. Если не указано, используется пользователь, владеющий файлом jar.

USE_START_STOP_DAEMON

Использовать ли команду start-stop-daemon, если она доступна, для управления процессом. По умолчанию true.

PID_FOLDER

Корневое имя каталога pid (по умолчанию /var/run).

LOG_FOLDER

Имя каталога для лог-файлов (по умолчанию /var/log).

CONF_FOLDER

Имя каталога для чтения файлов .conf (по умолчанию – тот же каталог, что и jar-файл).

LOG_FILENAME

Имя лог-файла в каталоге LOG_FOLDER (по умолчанию <appname>.log).

APP_NAME

Имя приложения. Если jar запускается из символической ссылки, скрипт пытается угадать имя приложения. Если это не символическая ссылка или вы хотите явно установить имя приложения, это может быть полезно.

RUN_ARGS

Аргументы, которые нужно передать программе (приложению Spring Boot).

JAVA_HOME

Расположение исполняемого файла java определяется по умолчанию с помощью PATH, но вы можете явно указать его, если исполняемый файл находится по адресу $JAVA_HOME/bin/java.

JAVA_OPTS

Опции, передаваемые JVM при запуске.

JARFILE

Явное расположение файла jar, если скрипт используется для запуска jar-файла, который не встроен в него.

DEBUG

Если не пусто, устанавливает флаг -x для процесса оболочки, позволяя просмотреть логику в скрипте.

STOP_WAIT_TIME

Время в секундах ожидания при остановке приложения перед принудительной остановкой (по умолчанию 60).
Переменные PID_FOLDER, LOG_FOLDER, и LOG_FILENAME действительны только для сервиса init.d. Для systemd, эквивалентные настройки выполняются с помощью скрипта «service». Для получения дополнительной информации см. страницы руководства по конфигурации служб.

Все настройки, кроме JARFILE и APP_NAME, можно настроить с помощью файла .conf. Ожидается, что файл будет расположен рядом с файлом jar и будет иметь такое же имя, но с добавленным суффиксом .conf вместо .jar. Например, jar-файл с именем /var/myapp/myapp.jar использует конфигурационный файл с именем /var/myapp/myapp.conf, как показано в следующем примере:

myapp.conf
JAVA_OPTS=-Xmx1024M
LOG_FOLDER=/custom/log/folder
Если вы не хотите, чтобы конфигурационный файл располагался рядом с jar-файлом, вы можете установить переменную среды CONF_FOLDER, чтобы настроить расположение конфигурационного файла.

Чтобы узнать, как безопасно настроить этот файл, см. руководство по защите сервиса init.d.

2.3. Службы Microsoft Windows

Приложение Spring Boot можно запустить как службу Windows, используя winsw.

В (отдельном примере) описано пошаговое создание службы Windows для вашего приложения Spring Boot.

3. Эффективные развертывания

3.1. Распаковка исполняемого JAR-файла

Если вы запускаете приложение из контейнера, вы можете использовать исполняемый jar-файл, но часто также выгодно распаковать его и запустить другим способом. Некоторые реализации PaaS также могут распаковывать архивы перед запуском. Например, Cloud Foundry работает таким образом. Один из способов запуска распакованного архива — запуск соответствующего запускателя, как показано ниже:

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher

Это фактически немного быстрее при запуске (в зависимости от размера jar-файла), чем запуск из нераспакованного архива. После запуска вы не должны ожидать никаких различий.

После распаковки jar-файла вы также можете получить дополнительный прирост времени запуска, запустив приложение с его «естественным» методом main вместо JarLauncher . Например:

$ jar -xf myapp.jar
$ java -cp "BOOT-INF/classes:BOOT-INF/lib/*" com.example.MyApplication
Использование JarLauncher вместо метода main приложения имеет дополнительное преимущество в виде предсказуемого порядка classpath. Jar-файл содержит файл classpath.idx, который используется JarLauncher при построении classpath.

3.2. Использование предварительной компиляции (AOT) с JVM

Для ускорения времени запуска желательно использовать приложение с сгенерированным кодом инициализации AOT. Сначала необходимо убедиться, что создаваемый jar-файл включает сгенерированный код AOT.

Для Maven это означает, что вам нужно скомпилировать с -Pnative для активации профиля native:

$ mvn -Pnative package

Для Gradle необходимо убедиться, что ваша сборка включает плагин org.springframework.boot.aot.

После создания JAR-файла запустите его, установив системную переменную spring.aot.enabled в true . Например:

$ java -Dspring.aot.enabled=true -jar myapplication.jar

........ Starting AOT-processed MyApplication ...

Обратите внимание, что использование предварительной компиляции имеет недостатки. Это предполагает следующие ограничения:

  • Classpath фиксируется и полностью определяется во время компиляции.

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

    • Аннотация Spring @Profile и профильная конфигурация, специфичная для профиля, имеют ограничения.

    • Не поддерживаются свойства, изменяющиеся при создании бина (например, @ConditionalOnProperty и .enable свойства).

Дополнительную информацию о предварительной компиляции см. в разделе «Понимание предварительной компиляции Spring».

END_OF_DOCUMENT_MARKER

4. Что читать дальше

Посмотрите на веб-сайты Cloud Foundry, Heroku, OpenShift и Boxfuse, чтобы узнать больше о том, какие возможности может предложить PaaS. Это всего лишь четыре из самых популярных поставщиков Java PaaS. Поскольку Spring Boot так хорошо подходит для облачных развертываний, вы можете свободно рассмотреть и других поставщиков.

Следующий раздел посвящен образам GraalVM Native, или вы можете перейти к чтению о Spring Boot CLI или наших плагинах инструментов сборки.

Copyright © 2012-2023 VMware, Inc.
Licensed under the Apache License, Version 2.0.
https://docs.spring.io/spring-boot/docs/3.1.3/reference/html/deployment.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API