Как сделать первый деплой Java приложения на удаленный сервер. Инструкция от/для новичка
Как любой начинающий вкатун, который написал свое первое стартап приложение мне захотелось сделать его достоянием общественности доступным через Интернет. Долгие часы поиска не давали особых результатов, поскольку все что мне удавалось найти было только кусочками пазла, а полную картину я не мог увидеть, в силу отсутствия опыта и наличия наставника. После месяца проб и ошибок я сумел получить доступ к приложению через удаленный сервер.
Так у меня и родилась идея сделать одну полную инструкцию (прежде всего для себя), где в одном месте будет описан процесс деплоя. Если Вы читаете эту статью, значит мне удалось решить проблему «первой публикации приложения на сервер». К Вашему вниманию любимая рубрика «инструкция для чайников — как самостоятельно сделать свой первый деплой».
Дисклеймер:
Я классический вкатун с полного нуля; Java первый и на момент написания статьи единственный язык программирования, который я знаю; это моя первая статья; в этой статье нет рекламы; я не проходил платных курсов; у меня нет регулярного ментора.
Конец дисклеймера.
Шаг 0 — Java приложение
Этот шаг я добавляю скорее для еще одного дисклеймера — эта статья подразумевает, что у вас уже есть работающее Java приложение, которое может запустится и получить HTTP запрос из браузера. О том как сделать такое приложение, есть очень много статей и видео, оставлю выбор материала на ваш вкус.
Шаг первый — аренда сервера
Для каждого из нас, самым первым сервером становится localhost. Когда приложение запускается на компьютере, localhost указывает на местоположение этого приложения на том же компьютере. По сути, это специальное имя, которое используется для доступа к устройству, на котором запущено приложение, через сетевые запросы. Это позволяет приложению взаимодействовать с другими компонентами программы без необходимости использовать внешнюю сеть. Другими словами, доступ к Вашему приложению будет ограничен только локальной сетью, но как получить доступ через Интернет?
Для этого необходим «Белый IP адрес» — это уникальный идентификатор, присваиваемый устройству или сети, подключенной к Интернету. В отличие от частных IP-адресов, которые используются в локальных сетях, белый IP-адрес обеспечивает уникальность и доступность устройства или сервера в глобальной сети. В «обычных домашних» условиях мы пользуемся «Серыми IP адресами», потому что «белых» ограниченное количество. Поэтому у нас есть, по сути, два варианта — покупка у своего интернет провайдера «белого» адреса и самостоятельная настройка сервера, либо приобретение готового серверного решения. Как Вы понимаете, я выбрал второй вариант.
Сайтов и сервисов для аренды виртуального сервера бесчисленное множество, выбирайте на вкус и цвет. Мой выбор остановился на FirstVDS, где я по цене чашки кофе арендовал сервер на месяц, с предустановленной ОС Debian 10, т.к. именно ее посоветовали в одном из чатов (еще раз повторюсь это не реклама, Вы можете выбрать любой другой).
Шаг второй — подключение к серверу
Программа PuTTY
После получения доступа к желаемому серверу, необходимо воспользоваться программой PuTTY — это универсальное приложение для подключения к серверу, которое состоит из одного запускаемого файла и не требует установки. Для входа на сервер достаточно ввести в Host Name адрес вашего сервера и нажать Open.
Программа PuTTY
В моем сценарии использования в PuTTY достаточно нажать только одну кнопку, тьфу-тьфу тут проблем у меня не возникло.
Далее, в появившейся командной строке, введите имя пользователя, под которым будет выполнен вход на сервер. Для первого подключения к серверу или подключения в режиме администратора используется логин root, пароль тот, который Вы указали при регистрации сервера.
Программа FileZilla
Также для работы с сервером, а точнее с файлами, нужна еще одна программа — FileZilla — инструмент для управления файлами по протоколам FTP, SFTP и FTPS на удаленных серверах.
Вам может быть и смешно, но при первом знакомстве с FileZilla у меня возникли некоторые сложности, поэтому опишу ее немного подробнее.
Первое подключение к серверу через программу FileZilla
Для входа нам нужно ввести данные:
Хост — IP адрес сервера
Имя пользователя — root (если вы его еще не поменяли)
Пароль — тот, который вы указали при регистрации сервера
Порт — обычно 22, порт на котором работает SSH.
В программе у есть четыре основных рабочих зоны, давайте назову их как-нибудь оригинально, например «левая» и «правая»:
· «Левая» зона — это отображение файловой структуры вашего компьютера. Под цифрой »1» — это проводник вашего ПК; под цифрой »2» — отображение содержимого выбранной папки
· «Правая» зона — тоже самое, что и «левая», только для удаленного сервера. Под цифрой »3» — это проводник сервера; под цифрой »4» — отображение содержимого выбранной папки
Рабочие зоны программы FileZilla
Как Вы уже догадались, именно через эти окна мы будем передавать файл нашего приложения на сервер, подробнее в следующих шагах. Обмен файлами происходит интуитивно понятным методом — перетягиванием мыши, ну и Ctrl+C и Ctrl+V тоже работают.
Шаг третий — подготовка сервера к работе
OpenJDK
Конкретно в моем случае приложение написано на 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.
P.S.(финальный) если Вам нравятся фото котов (настоящих, матерых, уличных), а также показались занятными наблюдения, статьи, книги и пр., на которые обращает внимание любопытный Java новичок, то переходите в мой Telegram-канал — https://t.me/cod_cat, для меня это будет лучшей оценкой этой статьи!
Настоящие, матерые, уличные коты. За фотосессию всегда получают вкусняшку :-)
