Это репост моей статьи, ранее опубликованной на удивительном SysAdvent Джордана Сисселя
Обязательно расскажите нам,
как вам нравится ваша Java в нашем
последнем посте Ask DZ
После многих лет работы в средах на основе Java я хотел бы реализовать ряд вещей вместе с командами, с которыми я работаю — приложение не имеет большого значения, будь то простой Java, Tomcat, JBoss и т. Д., Эти стратегии развертывания помогут вашим командам разработчиков и разработчиков создать более управляемые сервисы.
упаковка
Первый шаг заключается в том, чтобы пакеты нативной операционной системы выкатывались как артефакты сборки с вашего сервера непрерывной интеграции — нет файлов .ear, .war или .jar: я хочу иметь rpms или debs. С такими вещами, как fpm или плагин maven rpm, это не должно вызывать лишних хлопот, а преимущества, которые вы получаете от этого, бесценны.
Какие преимущества? Большинство собственных систем пакетов поддерживают разрешение зависимостей, проверку файлов и обновления (или более ранние версии). Это вещи, которые вы должны реализовать сами или собрать из нескольких инструментов. В качестве бонуса ваши коллеги-сисадмины, вероятно, уже знакомы с встроенным в ваши системы инструментом для создания пакетов, так почему бы не сделать это?
Прокси, не работает как root
Встряхивают, не перемешивают
Как и любой другой демон, по соображениям безопасности я предпочитаю запускать Tomcat или JBoss под своим собственным пользователем, а не под пользователем root. В большинстве случаев, однако, только root может связываться с портами ниже 1024, поэтому вам нужно поставить прокси впереди. Это удобное требование, потому что прокси (с чем-то вроде Apache) может использоваться для завершения соединений SSL, улучшения ведения журналов (журналов доступа и т. Д.) И предоставляет возможность запуска нескольких экземпляров сервера приложений Java в одной и той же инфраструктуре.
Управление Сервисом
Многие серверы приложений Java имеют полуфункциональный сценарий оболочки, позволяющий запустить службу. Часто эти сервисы не работают чисто, поэтому я предпочитаю использовать оболочку Java Service от Tanuki для управления большинством Java-сервисов. С небольшим конфигурационным файлом вы получаете чистый способ остановить и запустить java как сервис, и даже возможность добавить к нему еще немного мониторинга.
Однако есть некоторые проблемы, которые обертка Java Service оставляет нерешенными. Например, после запуска службы оболочка может вернуться с успешным кодом завершения, пока ваша служба еще не готова. Сервер приложений может быть готов, но сами ваши приложения все еще запускаются. Если вы отслеживаете эти приложения (например, для высокой доступности), вы действительно хотите рассматривать их как «активные», когда приложение готово, поэтому вы не хотите, чтобы ваш скрипт-обертка возвращал «ОК» до того, как приложение был развернут и готов. В противном случае вы получите ложные срабатывания или узлы, которые переходят на другой ресурс до запуска приложения. Таким образом, довольно просто создать сценарий перехвата службы пинг-понга в кластере.
Одно приложение на хост
Я предпочитаю развертывать одно приложение на хост, даже если вы можете легко развернуть несколько приложений в одной виртуальной машине Java. С одним на хост управление становится намного проще. Учитывая доступность и популярность хорошей виртуализации, затраты на запуск нескольких виртуальных машин Linux для различных приложений настолько низки, что есть больше преимуществ, чем недостатков.
конфигурация
Как насчет конфигурации приложения? Куда должны обращаться удаленные URL-адреса API, настройки базы данных и другие параметры? Хорошим подходом является создание стандартного местоположения для всех ваших приложений, например / etc / $ vendor / app / , где вы размещаете соответствующие файлы конфигурации. Изменяемая конфигурация приложения должна находиться за пределами артефакта, который выходит из сборки (.ear, .jar, .war, .rpm). Содержимое этих файлов должно управляться инструментом управления конфигурацией, таким как puppet, chef или cfengine. Разработчики должны пройти базовое обучение, чтобы они могли предоставить системной команде соответствующие шаблоны конфигурации.
бревна
Журналы тоже очень важны, и ими очень легко пренебречь. Существует множество альтернативных инструментов для входа в систему из приложения Java: Log4j, Logback и т. Д. Используйте их и убедитесь, что они настроены для входа в системный журнал, тогда их можно собирать централизованно и анализировать инструментами гораздо проще, чем если бы они были распространены по всей файловой системе.
Мониторинг
Вы также хотите, чтобы ваше приложение имело несколько способов контролировать его, помимо проверки, запущено ли оно — обычно недостаточно просто проверить, прослушивает ли tcp-сервер. Хорошее решение состоит в том, чтобы иметь простую простую текстовую страницу со списком критически важных сервисов и указанием, в порядке ли они (true / false), например:
someService: true
otherService: false
Это приносит пользу как людям, так и машинам. Такие инструменты, как mon , heartbeat или loadbalancers, могут просто найти «false» в файле. Если файл содержит значение false, он сообщает об ошибке и при сбое. Эта страница должна жить на стандартном месте для всех приложений, может быть картина , как это HTTP: // ч о с т / имя_службы / health.html и пример «http://10.0.129.10:8080/mrs-controller/ health.html». Страница должна быть доступна, как только приложение будет развернуто.
Этот отчет об истинном / ложном здоровье не должен быть статическим HTML-файлом; это должна быть динамически генерируемая страница. Текст означает, что вы также можете использовать curl, wget или любой инструмент командной строки или браузер для проверки состояния вашего сервиса.
Страница «health.html» должна честно сообщать о здоровье, выполняя любой код, необходимый для вычисления «здоровья», прежде чем получить результат. Например, если ваше приложение представляет собой простой калькулятор, оно должно проверить работоспособность, выполнив внутренние тесты, например, сложив несколько чисел, прежде чем делиться «myCalculator: true» в отчете о работоспособности.
Страница «health.html» должна честно сообщать о здоровье, выполняя любой код, необходимый для вычисления «здоровья», прежде чем получить результат. Например, если ваше приложение представляет собой простой калькулятор, то перед отчетом о работоспособности оно должно сложить два и два и получить четыре.
Такой подход также может быть использован для предоставления вам метрик, которые вы не можете узнать из JVM, таких как количество одновременных пользователей или другие допустимые метаданные приложения для целей измерения и анализа тенденций.
Вывод
Если вы не можете убедить своих разработчиков, то, возможно, вам могут помочь другие данные: Посмотрите на статью Мартина Джексона (презентация по развертыванию Java) Автоматизированные развертывания Java с помощью RPM
При наличии хороших стратегий в области упаковки, развертывания, ведения журналов и мониторинга вы сможете легко управлять, воспроизводить и масштабировать среду. Вы дадите своим разработчикам возможность сосредоточиться на написании приложения, они могут использовать те же настройки на своих локальных блоках разработки (например, с помощью vagrant), что вы используете на производстве.