деплой java приложения на сервер
Начало работы с Heroku на языке Java
Heroku – очень крутая штука! Тебе не нужно заморачиваться с настройкой железа, балансирования, маршрутизации и прочими радостями воздвижения нового сервиса, т. к. все за тебя сделали (и будут делать) разработчики. Тебе дается уже готовый сервак – бери и ваяй свое приложение.
Самое начало
Это руководство поможет развернуть Java-приложение за считанные минуты.
Предполагается, что у тебя уже:
Если ты больше любишь Gradle, то тебе в раздел официального хелпа.
Установка
Для Heroku CLI требуется система контроля версий Git. Если она у тебя еще не установлена, выполни следующие действия:
CLI используется для управления и масштабирования приложений, подготовки модулей, просмотра журналов и т. д.
После установки уже можно вводить команды с помощью директивы heroku в любимом терминале.
Используй команду heroku login для входа в Heroku CLI (может ругнуться фаервол – все разрешаем):
Подготовка приложения
Чтобы создать локальную копию приложения, которую можно развернуть в Heroku, выполни следующие команды в терминале:
Теперь у тебя есть рабочий репозиторий. Приложение включает в себя файл pom.xml, используемый менеджером Maven.
Развертывание приложения
На этом шаге ты развернешь приложение в Heroku.
Первым делом подготовим Heroku к получению исходного кода:
На этом шаге создается удаленный репозиторий (с именем heroku) и связывается с локальным.
По дефолту Heroku генерирует случайное имя для приложения, но можно указать и свое.
Теперь давай развернем код:
Готово. Убедись, что хотя бы один экземпляр приложения запущен:
Теперь перейди в приложение по ссылке, созданной из его имени, или поступи следующим образом:
Heroku собирает события со всех выходных потоков приложения и компонентов платформы в единый журнал, упорядоченный по времени.
Объявление Procfile
Heroku использует специальный текстовый файл Procfile (мини-конфиг) для явного указания директив запуска приложения.
Procfile в развернутом приложении выглядит примерно так:
Здесь объявляется тип процесса web и команда, необходимая для его запуска. Web указывает на то, что этот тип процесса будет прикреплен к стеку маршрутизации Heroku для получения трафика.
Масштабирование приложения
Сейчас приложение работает на одном dyno-процессе. Dyno – это легковесный контейнер Linux, запускаемый по команде из Procfile.
Проверить, сколько dyno сейчас запущено, можно так:
По умолчанию приложение деплоится в свободном dyno. Свободными они становятся (засыпают) после тридцати минут бездействия (т. е. если они не получают никакого трафика). Это поведение вызывает задержку в несколько секунд при первом запросе “пробуждения”. Последующие запросы будут выполняться нормально.
Чтобы избежать спящего режима dyno, можно обновить тип dyno на хобби или профи. Например, если ты мигрируешь свое приложение на профи уровень, можно легко масштабировать его, попросив Heroku подготовить определенное количество dyno.
Масштабирование приложения в Heroku эквивалентно изменению количества запущенных dyno.
Установить ненулевое количество веб dyno можно так:
Объявление зависимостей
В развернутой демке приложения уже имеется pom.xml с такой начинкой:
Запусти mvn clean install в локальном каталоге, чтобы установить зависимости и подготовить систему к локальному запуску приложения. Обрати внимание, что приложению требуется Java 8, но ты можешь запушить другие приложения с поддержкой другой версии Java.
Процесс Maven скомпилит и создаст JAR с зависимостями, помещая его в корневой каталог приложения. Этим процессом рулит spring-boot-maven-plugin из pom.xml.
Если ты не юзаешь Spring в pom.xml, можно указать иной плагин:
Локальный запуск приложения
Запусти приложение с помощью команды heroku :
Открой в браузере http://localhost:5000 – ты должен увидеть свое приложение.
Внесение локальных изменений
На этом шаге ты узнаешь, как внести локальные изменения и развернуть их в Heroku. В качестве примера мы добавим зависимость и некоторый код.
Измени pom.xml, добавив зависимости для jscience в блок dependencies :
В 28 строке добавь:
Теперь добавь следующие объекты в 19 строку файла src/main/java/com/example/Main.java :
Добавь метод hello в 59 строку src/main/java/com/example/Main.java :
Создай src/main/resources/templates/hello.html с таким содержимым:
По адресу http://localhost:5000/hello ты должен увидеть следующее:
Использование БД
Heroku предоставляет поддержку Postgres, Redis, MongoDB и MySQL.
Heroku Postgres сама по себе является надстройкой, поэтому для обзора БД можно использовать команду heroku addons :
Команда heroku pg предоставляет более подробную информацию о БД:
Дальнейшие действия
Вот инфа для изучения, чтобы продолжить свое путешествие с Heroku:
Развертывание Spring Boot приложений на Heroku
Heroku предоставляет платформу в качестве службы для развертывания приложений различных технологических стеков, таких как Node, Java, Python и т.д. Она заботится обо всех сложных аспектах развертывания, инфраструктуры, масштабирования, обновления, безопасности и т.д. И позволяет нам сосредоточиться на логика приложения и предоставление большей ценности нашим конечным пользователям, а не развертывание.
В этой статье мы создадим действительно простое API-приложение Spring Boot REST, которое предоставит конечную точку, и рассмотрим различные способы развертывания приложения в Heroku.
Создание приложения Spring Boot
Инициализация приложения Spring Boot
В качестве альтернативы мы можем создать приложение с помощью Spring Boot CLI:
Создать конечную REST точку
Сделав скелет, давайте добавим простую конечную точку REST:
Эта конечная точка просто возвращает текущее время сервера по запросу. Давайте запустим приложение на нашей локальной машине и проверим, работает ли оно:
Или, используя вашу IDE, просто запустите приложение и перейдите по URL-адресу вашего браузера localhost:8080/api/v1.0/time :
В качестве альтернативы вы можете использовать curl :
Развертывание в Heroku
Подготовив наше приложение, давайте рассмотрим различные способы его развертывания в Heroku.
Использование Heroku CLI с Git
Heroku предлагает собственный CLI, который мы можем использовать для развертывания приложения. Для этого нам нужно установить Heroku CLI и Git.
Прежде чем мы попытаемся развернуть его на Heroku, необходимо, чтобы приложение находилось в репозитории Git, поэтому давайте создадим репозиторий в каталоге нашего проекта:
После того, как репозиторий создан, давайте добавим и зафиксируем файлы:
Он запросит адрес электронной почты и пароль для вашей учетной записи Heroku:
После того, как мы вошли в систему, давайте создадим приложение:
Относительно быстро мы будем привязаны к приложению:
Наконец, мы можем развернуть наш код:
Heroku обнаружит, что это приложение Java / Maven по наличию файла pom.xml в хранилище. После нажатия, если вы посмотрите на журналы, вы сможете заметить:
И, наконец, развертывание завершено, и нам предлагается URL-адрес, ведущий к нашему приложению:
Давайте снова протестируем приложение, используя curl :
Или перейдя в наш браузер по его URL:
Heroku Deploy Plugin
Мы также должны упомянуть порт, с которым Heroku будет связывать приложение в файле application.properties :
Наконец, мы создаем наше приложение с Maven, чтобы создать jar файл и развернуть его:
Плагин Maven
Возможны сценарии, в которых мы хотели бы выполнить развертывание как часть нашей сборки Maven. Это возможно с помощью плагина Heroku Maven. Давайте разместим конфигурацию плагина в нашем pom.xml :
Всегда проверяйте последнюю версию плагина здесь.
И теперь мы можем использовать heroku:deploy для развертывания приложения:
Панель инструментов Heroku с GitHub
С CLI подходами в стороне, есть также действительно удобный подход GUI. Мы можем создать приложение на панели инструментов Heroku, связать его с учетной записью GitHub и развернуть оттуда.
Перейдите к опции «new app»:
Затем подключите свою учетную запись GitHub и найдите свой репозиторий для подключения:
После подключения вы можете развернуть свое приложение, выбрав ветвь для развертывания или непосредственно выбрав основную ветвь. Также вы можете включить автоматическое развертывание на основе коммитов в конкретной ветке:
Проверка журналов развернутых приложений
Проверка журналов развернутого приложения может быть полезна для многих целей. К счастью, к ним действительно легко получить доступ.
Используя CLI, это всего лишь одна команда:
Это позволит увидеть запущенные журналы:
Кроме того, панель инструментов Heroku позволяет нам получать к ним доступ с right-hand More > View Logs :
Heroku Procfile
Это также может быть добавлено в Procfile. Мы бы добавили команды для запуска приложения, такие как:
Здесь мы добавили команду для запуска приложения с Java и добавили аргумент JVM для переопределения привязки порта Spring Boot по умолчанию.
Удаление приложения из Heroku
В какой-то момент вы можете удалить свое приложение из Heroku по любой причине. Это делается с помощью простой команды:
В качестве альтернативы, мы можем удалить приложение из настроек Heroku Dashboard:
Вывод
С ростом популярности облачных вычислений важно знать, как мы можем развертывать и управлять нашим приложением на облачной платформе.
Intellij IDEA деплой на Tomcat
Хочу показать как можно быстро тестировать проект прям с IDE Intellij IDEA, а также расскажу плюсы от этого.
Шаг 0. Для чего это нужно?
Думаю вы уже работали над разработкой Java EE проектов ивам приходилось проверять его после написания очередной фитчи, а даже если не приходилось то придётся 🙂
Deploy – процесс развертывания (распаковки) проекта на сервере приложений.
О серверах приложений можно почитать тут. Так вот стандартный процесс деплоя:
1. Вы либо в ручную через Admin Panel или же через Console деплоите;
2. Вы используете Maven, Ant либо Gradle инструмент для этого.
Но не первый не второй способ не совсем удобный если вам к примеру нужно провести Debug проекта и отловить неисправность. И это одна из значительных причин использовать способ о котором я расскажу ниже.
Давайте теперь познакомимся собственно со способом деплоя используя Intellij IDEA.
Шаг 1. Готовим проект
Для того чтобы продемонстрировать данный способ мне необходимо иметь пример проекта для деплоя. Я буду использовать проект с этого урока Spring 3. JavaConfig на примере Spring MVC.
В скачанном вами проекте для деалоя на Tomcat необходимо в pom.xml добавить еще одну зависимость:
Открываем проект, справа в меню Maven Project выбираем clean | install как показано на изображении ниже, таким образом мы соберем наш проект и в итоге у нас получится war файл, который мы будем деплоить на сервер:
После этого в корне проекта появится папка target и в ней будет лежать ваш war архив.
Дальше нам нужно скачать сервер приложений Tomcat 8+ Скачать
Внимание! Вы можете использовать любой сервер приложения не обязательно Tomcat. Я рекомендую использовать его так как он лёгкий и быстро стартует.
Шаг 2. Конфигурируем Intellij IDEA для Deploy
Теперь в открытом вами проекте который вы хотите задеплоить, со студии IDEA выполните действия, которые показанные на изображении ниже:
После этого в появившемся окне нажмите на плюс и выберите Tomcat Server – Local:
После этого вводим имя и нажимаем Configure выбираете где лежит скачанный и распакованный Tomcat и жмете ОК.
Теперь переходите во вкладку Deployment жмем плюсик выбираем Artifact:
B в появившемся окне выбираете свой Artifact war:
Жмете ОК дважды. Вот общая конфигурация, которая должна появится у вас:
Шаг 3. Run и Debug
После настройки вы можите либо просто запускать ваш проект со студии либо проводить Debug со студии в зависимости от режима:
Зеленый треугольник просто запускает проект, а точней деплоит его и запускает в выбранном вами браузере при конфигурации.
Зеленый жучек деплоит проект на сервер и запускает Debug режим, который позволит вам отловить ошибки.
После запуска я получу задеплоиный проект:
Зеленый индикатор в Deployment говорит о том что проект удачно развернулся на сервере.
Сборка Java приложений при помощи Apache Ant, quick start
О чем эта статья
Одной из отличительных особенностей платформы Java является ее независимость от используемого инструментария. Вы можете разрабатывать сколь угодно большое Java приложение при помощи блокнота (vi) и командной строки. Понятно что так никто не делает и все используют какую-то IDE. Как следствие независимости от инструментов — IDE для Java много. Все это хорошо но есть одна особенность. Если Ваш коллега делал приложение и для сборки проекта использовал IDE_A то в IDE_B которая стоит у Вас — собрать приложение не получится.
В общем-то это давно уже не проблема. Хорошей практикой считается использовать систему сборки не зависящую от IDE. Для Java их две это Apache-Ant и Maven (тоже в общем-то Apache). Но тут есть один подводный камень. Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.
В статье рассматривается сборка и деплой Java web приложения шаг за шагом.
В целом задачу можно решить как с помощью ant так и с помощью maven, здесь будет рассмотрен ant. Для начинающих он проще и нагляднее.
Примечание 10 лет спустя
Решил посмотрел на свою статью написанную 10 лет назад. Звучит старомодно, в 2021 я в общем случае не рекомендую собирать Java приложения при помощи ant. НО если уж у вас возникла такая необходимость, то статья все еще может помочь. Пусть живет.
Зачем нужен скрипт сборки
Собираем и деплоим war
Есть много способов собрать war и есть много способов расположить файлы приложения. В статье дается один способ — может быть не самый лучший но вполне неплохой.
Структура проекта
Файлы проекта располагаем вот так.
В реальном проекте вместо stepN.xml будет build.xml. Библиотек будет больше и каждую следует располагать в отдельном каталоге. Имена пакетов выдают что я работаю в компании DataArt.
Шаг 1: компиляция
Шаг 2: улучшаем скрипт
Скрипт шага 1 довольно не гибкий и ряд путей там прописан дав раза. Давайте его улучшим
Шаг 3: Пути к библиотекам
Пути к библиотекам прописаны жестко в середине кода. Это не есть хорошо, меняем.
Шаг 4: Управление кофигурациями
Управление конфигурациями это мега технология о которой меня рассказал матерый американский программер Walden Mathews. Суть в следующем, при сборке вы пишете в файл свойств таймаут или путь до какого-то внешнего каталога или URL какого-то сервиса. На вашей локальной машине он один, на боевом сервере (или на машине коллеги другой). Вопрос — как использовать правильные значения свойств и не поубивать друг друга.
Здесь в target init читается файл с именем, совпадающим с Вашим именем пользователя. Если такой не находится сборка дальше не идет. А уже потом читаются дефолтные свойства из default. Так как в ant значения свойств переопределять нельзя то в default должны быть все свойства, а в Вашем файле только те значения которых отличаются.
default.properties
semenych.properties
Обратите внимание что в команде написано просто mihalych а не mihalych.properties
Шаг 5: Давайте уже соберем jar и war файл
Да действительно давайте.
вот эта секция делает замену внутри web.xml при этом web.xml выглядит так:
Шаг 6: war готов, последний штрих, деплой
Скрипт будет делать так называемый «холодный» деплой т.е. развертывание приложения с остановкой сервера. В ряде случаев «холодный» деплой позволяет избежать ряда проблем связанных с освобождением ресурсов и чисткой кэша.
Заключение
Вот собственно и все. Это почти готовый пример взятый из реального проекта. Пользуйтесь на здоровье, не забывайте писать комментарии.
Сборка Java приложений при помощи Apache Ant, quick start
О чем эта статья
Одной из отличительных особенностей платформы Java является ее независимость от используемого инструментария. Вы можете разрабатывать сколь угодно большое Java приложение при помощи блокнота (vi) и командной строки. Понятно что так никто не делает и все используют какую-то IDE. Как следствие независимости от инструментов — IDE для Java много. Все это хорошо но есть одна особенность. Если Ваш коллега делал приложение и для сборки проекта использовал IDE_A то в IDE_B которая стоит у Вас — собрать приложение не получится.
В общем-то это давно уже не проблема. Хорошей практикой считается использовать систему сборки не зависящую от IDE. Для Java их две это Apache-Ant и Maven (тоже в общем-то Apache). Но тут есть один подводный камень. Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.
В статье рассматривается сборка и деплой Java web приложения шаг за шагом.
В целом задачу можно решить как с помощью ant так и с помощью maven, здесь будет рассмотрен ant. Для начинающих он проще и нагляднее.
Примечание 10 лет спустя
Решил посмотрел на свою статью написанную 10 лет назад. Звучит старомодно, в 2021 я в общем случае не рекомендую собирать Java приложения при помощи ant. НО если уж у вас возникла такая необходимость, то статья все еще может помочь. Пусть живет.
Зачем нужен скрипт сборки
Собираем и деплоим war
Есть много способов собрать war и есть много способов расположить файлы приложения. В статье дается один способ — может быть не самый лучший но вполне неплохой.
Структура проекта
Файлы проекта располагаем вот так.
В реальном проекте вместо stepN.xml будет build.xml. Библиотек будет больше и каждую следует располагать в отдельном каталоге. Имена пакетов выдают что я работаю в компании DataArt.
Шаг 1: компиляция
Шаг 2: улучшаем скрипт
Скрипт шага 1 довольно не гибкий и ряд путей там прописан дав раза. Давайте его улучшим
Шаг 3: Пути к библиотекам
Пути к библиотекам прописаны жестко в середине кода. Это не есть хорошо, меняем.
Шаг 4: Управление кофигурациями
Управление конфигурациями это мега технология о которой меня рассказал матерый американский программер Walden Mathews. Суть в следующем, при сборке вы пишете в файл свойств таймаут или путь до какого-то внешнего каталога или URL какого-то сервиса. На вашей локальной машине он один, на боевом сервере (или на машине коллеги другой). Вопрос — как использовать правильные значения свойств и не поубивать друг друга.
Здесь в target init читается файл с именем, совпадающим с Вашим именем пользователя. Если такой не находится сборка дальше не идет. А уже потом читаются дефолтные свойства из default. Так как в ant значения свойств переопределять нельзя то в default должны быть все свойства, а в Вашем файле только те значения которых отличаются.
default.properties
semenych.properties
Обратите внимание что в команде написано просто mihalych а не mihalych.properties
Шаг 5: Давайте уже соберем jar и war файл
Да действительно давайте.
вот эта секция делает замену внутри web.xml при этом web.xml выглядит так:
Шаг 6: war готов, последний штрих, деплой
Скрипт будет делать так называемый «холодный» деплой т.е. развертывание приложения с остановкой сервера. В ряде случаев «холодный» деплой позволяет избежать ряда проблем связанных с освобождением ресурсов и чисткой кэша.
Заключение
Вот собственно и все. Это почти готовый пример взятый из реального проекта. Пользуйтесь на здоровье, не забывайте писать комментарии.