Как запустить спринг приложение из под сервера tomcat

Развертывание приложения Spring в Службе приложений с использованием MySQL

Для приложений Spring рекомендуется использовать Azure Spring Apps. Однако вы по-прежнему можете использовать службу приложение Azure в качестве назначения.

Из этого руководства вы узнаете, как создавать, настраивать, развертывать и масштабировать веб-приложения Java, а также устранять неполадки с ними в Службе приложений в Linux.

Это руководство основано на популярном примере приложения PetClinic. В этом разделе вы протестируете версию HSQLDB приложения локально, а затем разверните ее в службе приложение Azure. После этого вы настроите и развернете версию, которая использует База данных Azure для MySQL. Наконец, вы узнаете, как получить доступ к журналам приложений и увеличить масштаб, увеличив число рабочих ролей, работающих в приложении.

Необходимые компоненты

Получение примера

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

git clone https://github.com/spring-petclinic/spring-framework-petclinic.git cd spring-framework-petclinic 

git clone https://github.com/spring-petclinic/spring-framework-petclinic.git cd spring-framework-petclinic 

git clone https://github.com/spring-petclinic/spring-framework-petclinic.git cd spring-framework-petclinic 

Сборка и запуск примера HSQLDB в локальной среде

Сначала мы протестируем пример локально, используя HSQLDB в качестве базы данных.

Создайте версию HSQLDB примера приложения.

mvn package 

Затем присвойте переменной среды TOMCAT_HOME расположение установки Tomcat.

export TOMCAT_HOME=

$env:TOMCAT_HOME="" 

set TOMCAT_HOME=

Затем обновите файл pom.xml для развертывания файла WAR. Добавьте следующий код XML в качестве дочернего узла существующего элемента . При необходимости измените 1.9.11 на текущую версию подключаемого модуля Cargo Maven 3.

 org.codehaus.cargo cargo-maven3-plugin 1.9.11  tomcat9x installed $ existing $  $ $ war /      

В такой конфигурации приложение можно развернуть локально в Tomcat.

mvn cargo:deploy 

Затем запустите Tomcat.

$/bin/catalina.sh run 

& $env:TOMCAT_HOME/bin/catalina.bat run 

%TOMCAT_HOME%\bin\catalina.bat run 

Теперь в браузере можно перейти по адресу http://localhost:8080 , чтобы увидеть работающее приложение и оценить его работу. По завершении нажмите клавиши CTRL+C в командной строке Bash, чтобы остановить Tomcat.

Развертывание в Службу приложений Azure

Теперь, когда приложение протестировано локально, его можно развернуть в Azure.

Сначала настройте следующие переменные среды. Для REGION используйте West US 2 или другие регионы, которые можно найти здесь.

export RESOURCEGROUP_NAME= export WEBAPP_NAME= export WEBAPP_PLAN_NAME=$-appservice-plan export REGION=

$env:RESOURCEGROUP_NAME="" $env:WEBAPP_NAME="" $env:WEBAPP_PLAN_NAME="$env:WEBAPP_NAME-appservice-plan" $env:REGION="" $env:SUBSCRIPTION_ID="" 

set RESOURCEGROUP_NAME= set WEBAPP_NAME= set WEBAPP_PLAN_NAME=%WEBAPP_NAME%-appservice-plan set REGION= set SUBSCRIPTION_ID=

Maven будет использовать эти значения для создания ресурсов Azure с предоставленными вами именами. С помощью переменных среды можно хранить секреты учетной записи отдельно от файлов проекта.

Затем обновите файл pom.xml, чтобы настроить Maven для развертывания в Azure. Добавьте следующий код XML после добавленного ранее элемента . При необходимости измените 2.5.0 на текущую версию подключаемого модуля Maven для Службы приложений Azure.

 com.microsoft.azure azure-webapp-maven-plugin 2.5.0 v2 $ $ $ $ P1v2 Linux Java 8 TOMCAT 9.0    $/target *.war       

Затем войдите в Azure.

az login 

После этого разверните приложение в Службе приложений в Linux.

mvn azure-webapp:deploy 

Теперь вы можете перейти по адресу https://.azurewebsites.net (после замены ), чтобы увидеть работающее приложение.

Настройка Базы данных Azure для MySQL

Теперь вместо HSQLDB будет использоваться MySQL. Вам нужно будет создать экземпляр MySQL Server в Azure и добавить базу данных, а затем обновить конфигурацию приложения, используя новые сведения о подключении к базе данных.

Сначала настройте следующие переменные среды для дальнейшего использования.

export MYSQL_SERVER_NAME= export MYSQL_SERVER_FULL_NAME=$.mysql.database.azure.com export MYSQL_SERVER_ADMIN_LOGIN_NAME= export MYSQL_SERVER_ADMIN_PASSWORD= export MYSQL_DATABASE_NAME= export DOLLAR=\$ 

$env:MYSQL_SERVER_NAME="" $env:MYSQL_SERVER_FULL_NAME="$env:MYSQL_SERVER_NAME.mysql.database.azure.com" $env:MYSQL_SERVER_ADMIN_LOGIN_NAME="" $env:MYSQL_SERVER_ADMIN_PASSWORD="" $env:MYSQL_DATABASE_NAME="" $env:DOLLAR="$" 

set MYSQL_SERVER_NAME= set MYSQL_SERVER_FULL_NAME=%MYSQL_SERVER_NAME%.mysql.database.azure.com set MYSQL_SERVER_ADMIN_LOGIN_NAME= set MYSQL_SERVER_ADMIN_PASSWORD= set MYSQL_DATABASE_NAME= set DOLLAR=$ 

Затем создайте и инициализируйте сервер базы данных. Выполните az mysql up для начальной настройки. Затем используйте az mysql server configuration set, чтобы увеличить время ожидания подключения и задать часовой пояс сервера.

az extension add --name db-up az mysql up \ --resource-group $ \ --server-name $ \ --database-name $ \ --admin-user $ \ --admin-password $ az mysql server configuration set --name wait_timeout \ --resource-group $ \ --server $ --value 2147483 az mysql server configuration set --name time_zone \ --resource-group $ \ --server $ --value=-8:00 

az extension add --name db-up az mysql up ` --resource-group $env:RESOURCEGROUP_NAME ` --server-name $env:MYSQL_SERVER_NAME ` --database-name $env:MYSQL_DATABASE_NAME ` --admin-user $env:MYSQL_SERVER_ADMIN_LOGIN_NAME ` --admin-password $env:MYSQL_SERVER_ADMIN_PASSWORD az mysql server configuration set --name wait_timeout ` --resource-group $env:RESOURCEGROUP_NAME ` --server $env:MYSQL_SERVER_NAME --value 2147483 az mysql server configuration set --name time_zone ` --resource-group $env:RESOURCEGROUP_NAME ` --server $env:MYSQL_SERVER_NAME --value=-8:00 

az extension add --name db-up az mysql up ^ --resource-group %RESOURCEGROUP_NAME% ^ --server-name %MYSQL_SERVER_NAME% ^ --database-name %MYSQL_DATABASE_NAME% ^ --admin-user %MYSQL_SERVER_ADMIN_LOGIN_NAME% ^ --admin-password %MYSQL_SERVER_ADMIN_PASSWORD% az mysql server configuration set --name wait_timeout ^ --resource-group %RESOURCEGROUP_NAME% ^ --server %MYSQL_SERVER_NAME% --value 2147483 az mysql server configuration set --name time_zone ^ --resource-group %RESOURCEGROUP_NAME% ^ --server %MYSQL_SERVER_NAME% --value=-8:00 

Затем с помощью CLI MySQL подключитесь к базе данных в Azure.

mysql -u $@$ \ -h $ -P 3306 -p 

mysql -u $env:MYSQL_SERVER_ADMIN_LOGIN_NAME@$env:MYSQL_SERVER_NAME ` -h $env:MYSQL_SERVER_FULL_NAME -P 3306 -p 

mysql -u %MYSQL_SERVER_ADMIN_LOGIN_NAME%@%MYSQL_SERVER_NAME% ^ -h %MYSQL_SERVER_FULL_NAME% -P 3306 -p 

В командной строке CLI MySQL выполните приведенную ниже команду, чтобы проверить, названа ли ваша база данных тем же именем, которое вы указали ранее для переменной среды MYSQL_DATABASE_NAME .

show databases; 

Теперь вы можете использовать MySQL.

Настройка приложения для работы с MySQL

Теперь нужно добавить сведения о подключении к версии MySQL приложения и выполнить развертывание в Службе приложений.

Обновите файл pom.xml, чтобы включить MySQL в действующую конфигурацию. Удалите элемент из профиля H2 и поместите его в профиль MySQL, как показано ниже. В оставшейся части фрагмента кода показана существующая конфигурация. Обратите внимание, как настроенные ранее переменные среды используются Maven для настройки доступа к MySQL.

 MySQL true  mysql MYSQL com.mysql.jdbc.Driver jdbc:mysql://$:3306/$?useUnicode=true $@$ $ . 

Затем обновите файл pom.xml, чтобы настроить Maven для развертывания в Azure и использования MySQL. Добавьте следующий код XML после добавленного ранее элемента . При необходимости измените 2.5.0 на текущую версию подключаемого модуля Maven для Службы приложений Azure.

 com.microsoft.azure azure-webapp-maven-plugin 2.5.0 v2 $ $ $ $ P1v2 Linux Java 8 TOMCAT 9.0   MYSQL_SERVER_FULL_NAME $ MYSQL_SERVER_ADMIN_LOGIN_NAME $ MYSQL_SERVER_ADMIN_PASSWORD $ MYSQL_DATABASE_NAME $    $/target *.war       

Затем выполните сборку приложения и протестируйте его локально, развернув и запустив с помощью Tomcat.

mvn package mvn cargo:deploy $/bin/catalina.sh run 

mvn package mvn cargo:deploy & $env:TOMCAT_HOME/bin/catalina.bat run 

mvn package mvn cargo:deploy %TOMCAT_HOME%\bin\catalina.bat run 

Теперь приложение можно просмотреть локально, перейдя по адресу http://localhost:8080 . Приложение будет выглядеть и работать так же, как и раньше, но теперь оно использует базу данных Azure для MySQL вместо HSQLDB. По завершении нажмите клавиши CTRL+C в командной строке Bash, чтобы остановить Tomcat.

Наконец, разверните приложение в Службе приложений.

mvn azure-webapp:deploy 

Теперь можно перейти по адресу https://.azurewebsites.net , чтобы увидеть работающее приложение, использующее Службу приложений и Базу данных Azure для MySQL.

Доступ к журналам приложения

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

az webapp log tail --name $ \ --resource-group $

az webapp log tail --name $env:WEBAPP_NAME ` --resource-group $env:RESOURCEGROUP_NAME 

az webapp log tail --name %WEBAPP_NAME% ^ --resource-group %RESOURCEGROUP_NAME% 

После завершения просмотра журналов нажмите клавиши CTRL+C, чтобы остановить поток.

Этот поток журналов также доступен по адресу https://.scm.azurewebsites.net/api/logstream .

Горизонтальное увеличение масштаба

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

az appservice plan update --number-of-workers 2 \ --name $ \ --resource-group $

az appservice plan update --number-of-workers 2 ` --name $env:WEBAPP_PLAN_NAME ` --resource-group $env:RESOURCEGROUP_NAME 

az appservice plan update --number-of-workers 2 ^ --name %WEBAPP_PLAN_NAME% ^ --resource-group %RESOURCEGROUP_NAME% 

Поздравляем! Вы создали и масштабировали веб-приложение Java, используя Spring Framework, JSP, Spring Data, Hibernate, JDBC, Службу приложений в Linux и Базу данных Azure для MySQL.

Очистка ресурсов

Ранее вы создали ресурсы Azure в группе ресурсов. Если эти ресурсы вам не понадобятся в будущем, вы можете удалить группу ресурсов, выполнив следующую команду.

az group delete --name $

az group delete --name $env:RESOURCEGROUP_NAME 

az group delete --name %RESOURCEGROUP_NAME% 

Следующие шаги

Ознакомьтесь с другими вариантами конфигурации и вариантами CI/CD, доступными для Java в Службе приложений.

Можно ли проект Spring запустить на удаленном сервере?

Я написал самое простое приложение на spring. Котрое принимает GET запрос и возвращает HTML страницу. На локалхлсте все работает. localhost:8080/index и он показывает страницу index.html
Так вот вопрос, можно ли как то запустить его на удаленном сервере, чтобы я мог например получать эту страницу по url — адресу, ну как все обычные веб приложения.

Если можно, то как? Можете привести пример?

• Вопрос задан более трёх лет назад
• 692 просмотра

1 комментарий

Простой 1 комментарий

Решения вопроса 1

Орхан Гасанлы @azerphoenix Куратор тега Java
Java Software Engineer

Здравствуйте!
Если кратко, то да, можно))))
А если подробно, то читайте дальше:
1) приложение Spring можно запустить на Томкат и т.д. Соответственно, нужен VPS, установите tomcat. А дальше соберите war проект и залейте на сервер.
https://docs.spring.io/spring-boot/docs/current/re.
2) можно развернуть приложение без стороннего софта (self-contained app)
https://docs.oracle.com/javase/8/docs/technotes/gu.

Если вы используете Intellij IDEA, то там при нажатии ПКМ (при условии, что вы уже настроили параметры деплоя), то можете сразу заливать проект на сервер из программы

Разверните Spring Boot WAR на сервере Tomcat

Spring Boot — это соглашение о структуре конфигурации, которое позволяет нам создать готовую к работе установку проекта Spring, а Tomcat — один из самых популярных контейнеров сервлетов Java.

По умолчанию Spring Boot создает отдельное приложение Java, которое может работать как настольное приложение или настраиваться как системная служба, но есть среды, в которых мы не можем установить новую службу или запустить приложение вручную.

В отличие от автономных приложений, Tomcat устанавливается как служба, которая может управлять несколькими приложениями в рамках одного и того же прикладного процесса, что позволяет избежать необходимости специальной настройки для каждого приложения.

В этом руководстве мы создадим простое приложение Spring Boot и адаптируем его для работы в Tomcat.

2. Настройка приложения Spring Boot​

Давайте настроим простое веб-приложение Spring Boot, используя один из доступных начальных шаблонов:

 parent>   groupId>org.springframework.bootgroupId>   artifactId>spring-boot-starter-parentartifactId>   version>2.4.0version>   relativePath/>   parent>   dependencies>   dependency>   groupId>org.springframework.bootgroupId>   artifactId>spring-boot-starter-webartifactId>   dependency>   dependencies> 

Нет необходимости в дополнительных конфигурациях помимо стандартного @SpringBootApplication, поскольку Spring Boot позаботится о настройке по умолчанию.

Затем мы добавим простую REST EndPoint, чтобы возвращать нам допустимый контент:

 @RestController   public class TomcatController     @GetMapping("/hello")   public CollectionString> sayHello()    return IntStream.range(0, 10)   .mapToObj(i -> "Hello number " + i)   .collect(Collectors.toList());   >   > 

Наконец, мы запустим приложение с помощью mvn spring-boot:run и запустим браузер по адресу http://localhost:8080/hello , чтобы проверить результаты.

3. Создание Spring Boot WAR​

Контейнеры сервлетов ожидают, что приложения будут развернуты в соответствии с некоторыми контрактами. Для Tomcat контрактом является Servlet API 3.0 .

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

Во-первых, нам нужно упаковать приложение WAR вместо JAR. Для этого мы изменим pom.xml следующим содержимым:

 packaging>warpackaging> 

Далее мы изменим окончательное имя файла WAR , чтобы не включать номера версий:

 build>   finalName>$ finalName>   .   build> 

Затем мы добавим зависимость Tomcat:

 dependency>   groupId>org.springframework.bootgroupId>   artifactId>spring-boot-starter-tomcatartifactId>   scope>providedscope>   dependency> 

Наконец, мы инициализируем контекст сервлета, требуемый Tomcat, путем реализации интерфейса SpringBootServletInitializer :

 @SpringBootApplication   public class SpringBootTomcatApplication extends SpringBootServletInitializer    > 

Чтобы создать наше WAR-приложение, развертываемое с помощью Tomcat, мы выполним пакет mvn clean. После этого наш WAR-файл генерируется по адресу target/spring-boot-deployment.war (при условии, что артефакт Maven — «spring-boot-deployment»).

Мы должны учитывать, что эта новая настройка делает наше приложение Spring Boot неавтономным приложением (если мы хотим, чтобы оно снова работало в автономном режиме, мы можем удалить предоставленную область из зависимости tomcat).

4. Развертывание WAR на Tomcat​

Чтобы наш файл WAR был развернут и запущен в Tomcat, нам необходимо выполнить следующие шаги:

1. Загрузите Apache Tomcat и распакуйте его в папку tomcat .
2. Скопируйте наш файл WAR из target/spring-boot-deployment.war в папку tomcat/webapps/
3. В терминале перейдите в папку tomcat/bin и выполните
4. catalina.bat запустить (в Windows)
5. запуск catalina.sh (в системах на базе Unix)
6. Перейдите по адресу http://localhost:8080/spring-boot-deployment/hello.

Это была быстрая установка Tomcat, поэтому ознакомьтесь с полным руководством по установке Tomcat . Существуют также дополнительные способы развертывания WAR-файла на Tomcat .

5. Вывод​

В этой краткой статье мы создали простое приложение Spring Boot и превратили его в действительное приложение WAR, которое можно развернуть на сервере Tomcat.

Как всегда, полный исходный код примеров доступен на GitHub .

• 1. Введение
• 2. Настройка приложения Spring Boot
• 3. Создание Spring Boot WAR
• 4. Развертывание WAR на Tomcat
• 5. Вывод

Как сделать первый деплой Java приложения на удаленный сервер. Инструкция от/для новичка

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

Так у меня и родилась идея сделать одну полную инструкцию (прежде всего для себя), где в одном месте будет описан процесс деплоя. Если Вы читаете эту статью, значит мне удалось решить проблему «первой публикации приложения на сервер». К Вашему вниманию любимая рубрика «инструкция для чайников – как самостоятельно сделать свой первый деплой».

Я классический вкатун с полного нуля; Java первый и на момент написания статьи единственный язык программирования, который я знаю; это моя первая статья; в этой статье нет рекламы; я не проходил платных курсов; у меня нет регулярного ментора.

Шаг 0 – Java приложение

Этот шаг я добавляю скорее для еще одного дисклеймера – эта статья подразумевает, что у вас уже есть работающее Java приложение, которое может запустится и получить HTTP запрос из браузера. О том как сделать такое приложение, есть очень много статей и видео, оставлю выбор материала на ваш вкус.

Шаг первый – аренда сервера

Для каждого из нас, самым первым сервером становится localhost. Когда приложение запускается на компьютере, localhost указывает на местоположение этого приложения на том же компьютере. По сути, это специальное имя, которое используется для доступа к устройству, на котором запущено приложение, через сетевые запросы. Это позволяет приложению взаимодействовать с другими компонентами программы без необходимости использовать внешнюю сеть. Другими словами, доступ к Вашему приложению будет ограничен только локальной сетью, но как получить доступ через Интернет?

Для этого необходим «Белый IP адрес» — это уникальный идентификатор, присваиваемый устройству или сети, подключенной к Интернету. В отличие от частных IP-адресов, которые используются в локальных сетях, белый IP-адрес обеспечивает уникальность и доступность устройства или сервера в глобальной сети. В «обычных домашних» условиях мы пользуемся «Серыми IP адресами», потому что «белых» ограниченное количество. Поэтому у нас есть, по сути, два варианта – покупка у своего интернет провайдера «белого» адреса и самостоятельная настройка сервера, либо приобретение готового серверного решения. Как Вы понимаете, я выбрал второй вариант.

Сайтов и сервисов для аренды виртуального сервера бесчисленное множество, выбирайте на вкус и цвет. Мой выбор остановился на FirstVDS, где я по цене чашки кофе арендовал сервер на месяц, с предустановленной ОС Debian 10, т.к. именно ее посоветовали в одном из чатов (еще раз повторюсь это не реклама, Вы можете выбрать любой другой).

Шаг второй – подключение к серверу

После получения доступа к желаемому серверу, необходимо воспользоваться программой PuTTY – это универсальное приложение для подключения к серверу, которое состоит из одного запускаемого файла и не требует установки. Для входа на сервер достаточно ввести в Host Name адрес вашего сервера и нажать Open.

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

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

Также для работы с сервером, а точнее с файлами, нужна еще одна программа – FileZilla — инструмент для управления файлами по протоколам FTP, SFTP и FTPS на удаленных серверах.

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

Для входа нам нужно ввести данные:

1. Хост — IP адрес сервера
2. Имя пользователя – root (если вы его еще не поменяли)
3. Пароль — тот, который вы указали при регистрации сервера
4. Порт — обычно 22, порт на котором работает SSH.

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

· «Левая» зона – это отображение файловой структуры вашего компьютера. Под цифрой «1» — это проводник вашего ПК; под цифрой «2» — отображение содержимого выбранной папки

· «Правая» зона – тоже самое, что и «левая», только для удаленного сервера. Под цифрой «3» — это проводник сервера; под цифрой «4» — отображение содержимого выбранной папки

Как Вы уже догадались, именно через эти окна мы будем передавать файл нашего приложения на сервер, подробнее в следующих шагах. Обмен файлами происходит интуитивно понятным методом – перетягиванием мыши, ну и Ctrl+C и Ctrl+V тоже работают.

Шаг третий – подготовка сервера к работе

Конкретно в моем случае приложение написано на Java 17 (версию приложения можно посмотреть в файле pom.xml в теге «java.version»). Конечно же версия OpenJDK, которая установлена на сервере, должна соответствовать версии вашего приложения.

Чтобы проверить версию Java на сервере введем команду java -version в командной строке сервера (это та, что открывается через PuTTY). В моем случае на сервере была установлена 11 версия и для обновления я воспользовался вот этой инструкцией. Не вижу смысла дублировать инструкцию, так как их написано множество и я воспользовался именно этой. Главное понять последовательность действий: обновить систему -> скачать нужную версию Java -> разархивировать в нужную папку -> указать для JAVA_HOME новый адрес Java.

После установки нужной версии Java (для проверки введем команду java -version ) фактически Ваше приложение уже может быть запущено и доступно по ссылке на сервер. Ура! Хотя погодите, чего-то не хватает… мы еще не поговорили про работу с базой данных, ведь скорее всего она у Вас еще не работает! Ведь приложение работает в облаке, а файл с БД у вас на ПК…

Шаг четвертый – настройка базы данных PostgreSQL

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

Инструкция очень подробная, поэтому я столкнулся только с одной проблемой на шаге «импортировать ключ подписи репозитория», указанная команда никак не хотела работать. Решение, которое мне помогло, на сервер нужно поставить дополнительную утилиту для шифрования и подписи данных — gnupg.

После завершения всех шагов текстовой инструкции – переходим к видео-инструкции от этого же автора, ведь PostgreSQL имеет крайне удобный графический инструмент для администрирования и управления базами данных – pgAdmin.

Видео-инструкция, существенно короче по шагам, но по ней у меня начались проблемы в самом начале… Я не смог создать резервную копию своей базы, т.к. при нажатии «Резервная копия» выдавало ошибку.

Указанную ошибку можно решить так — Откройте pgAdmin и найдите раздел «Настройки». В настройках программы найдите раздел «Пути программ», где можно указать путь к утилите для создания резервных копий баз данных. Обычно эта утилита находится в каталоге, где установлен PostgreSQL, например, C:\Program Files\PostgreSQL\13\bin\pg_dump.exe для Windows или /usr/bin/pg_dump для Linux.

После решение этой проблемы и выполнения всех инструкций из видео – поздравляю! Теперь БД доступна для приложения, размещенного на сервере. Файл application.properties остается таким же, только нужно поменять название БД (если Вы его меняли, когда создали резервную копию) и поменять логин/пароль на те, что были указаны при установке PostgreSQL на сервер.

Обращаю внимание, что установленная таким образом БД будет работать только на сервере, если Вы будете запускать приложение на локальном ПК с настройками к базе на сервере, то работать не будет. Если честно, я до конца так и не понял это баг или фитча…, напишите пожалуйста об этом в комментариях.

Шаг пятый – запуск приложения

Итак, мы добрались до финала! Осталось только собрать приложение и перенести его на сервер. Сборка Java приложения происходит через процесс компиляции в WAR (Web Application Archive) файл представляет собой архив, содержащий все необходимые компоненты веб-приложения. Если Вы используете Maven, то достаточно запустить команду из раздела lifecycle -> package , после успешной компиляции war файл будет находится в папке target , которая находится в папке Вашего проекта.

Открываем FileZilla и переносим war файл на сервер. В папке root я создал папку myapp, куда и скопировал мое приложение. Опять же не знаю, насколько именно такое решение корректное, напишите в комментариях, для меня как новичка главное, что работает.

Запустить приложение через командную строку (напоминаю, что командная строка сервера Вам доступна через PuTTY) достаточно просто – java -jar my_app.war . Перед тем как запускать приложение убедитесь, что Вы внутри нужной папки!

У такого простого способа есть нюанс, приложение будет работать пока работает сессия доступа к сервису, т.е. когда вы закроете PuTTY, то работа приложения остановится.

В процессе решения вопроса, нашел гениальный выход, всего лишь нужно запустить приложение в фоне! Для того чтобы это сделать нужно ввести вот эту команду – nohup java -jar my_app.war > /dev/null 2>&1 &

Поздравляю, Вы сделали свой первый деплой и ваше приложение доступно 24/7 в сети!

В конце хочу еще оставить несколько послесловий.

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

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

Мое Java приложение, с которым я прошел данную инструкцию, написано на Spring Boot, а это значит, что в нем уже встроен сервер Tomcat, именно поэтому для доступа достаточно просто запустить war файл. Если у Вас приложение не на Spring Boot, тогда Вам нужно воспользоваться вот этой инструкцией для установки Tomcat на удаленном сервере. После завершения всех шагов инструкции, необходимо war файл Вашего приложения положить в папку webapps Tomcat. После этого доступ к приложению будет http://хост_сервера:8080/my_app . Где my_app это название war файла, запускать приложение через командную строку не нужно.

Если статья окажется полезная и интересная, то планирую выпустить статьи в аналогичном формате «инструкция для/от чайника», о том, как я буду разворачивать приложение через Docker и делать pipeline через Jenkins.