У нас есть файл войны, файлы xml файлов Liquibase и контрольные суммы sha1, которые мы хотим упаковать как Debian script для развертывания на одну платформу: ubuntu 14.1 64bit с tomcat 7 и java 7.
Мы пробрались через большое количество непонятных (для нас как разработчиков java) руководств по упаковке Debian, для большинства из которых требуется "восходящий исходный tar-мяч" (например, этот: https://wiki.debian.org/IntroDebianPackaging) и/или что-то, созданное при выполнении make/install.
У нас нет ни одного, что является основной проблемой нашей проблемы.
Мы имеем две фазы:
- Первоначальная установка (выполняется один раз)
- Обновление (выполняется много раз)
В руководствах не упоминается, как управлять этими двумя этапами.
Первоначальная установка (что мы делаем сейчас вручную на каждом сервере):
- установите java, tomcat7, используя apt-get как root. Предположительно это можно автоматизировать с помощью зависимостей
- сильно отредактируйте файл var/lib/tomcat7/conf/context.xml с целевой строкой/паролем подключения к базе данных и т.д. Предположительно, это должно быть сделано вручную после установки.
- создайте нового пользователя и группу для нашего приложения, например. "Foo".
- логин как foo
- В домашнем каталоге foos установите базовое приложение: 4.1 создайте каталог скриптов и скопируйте файл install.sh 4.2 отредактируйте файл install.sh и измените строку подключения к базе данных, секретный пользователь и пройдите в соответствии с целевым db (на другом сервере) 4.3 скопируйте бинарное распределение ликбазы банок и скриптов в подсистему Liquibase.
Само приложение, которое мы распространяем через tar файл, созданный с помощью Jenkins. В tar есть следующее:
- app.sha1
- migration/changelog.xml(и множество файлов xml файлов Liquibase)
- app.war
- classes.sha1
Мы scp tar файл в директорию /home/foo и запустим /home/foo/scripts/install.sh, который делает следующее:
- удаляет старый tar и неиспользуемый материал из /home/foo
- переносит новый tar файл.
- останавливает tomcat
- запускает команду Liquibase jar с файлом untarred migrations для создания/обновления db
- удаляет /var/lib/tomcat 7/webapps/*
- копирует новую войну в файл var/lib/tomcat7/webapps/
- запускает tomcat
- ждет немного
- использует sha1sum, чтобы убедиться, что классы верны (это не имеет никакой цели, кроме как это требование от клиента).
У нас есть следующие вопросы:
- Где и как создается пользователь? Например. foo в нашем случае, или tomcat7 в случае с котами.
- Установлен ли пакет "самостоятельно"? Или он только помещает файлы в файловую систему (и, следовательно, требует, чтобы администратор позже запускал один или несколько сценариев для выполнения работы. Есть ли какой-то стандарт для скриптов, выполняющих эту работу, например, имена стандартов?
- Есть много инструментов для упаковки, e, g, Jenkins plugins, dpkg, fpm, debuild, dpkg-buildpackage. Что мы должны использовать? Мы смотрели на fpm, но он предполагает, что у вас есть dir, созданный из исходной установки с файлами make и т.д., Мы не делаем.
- Где установлены пакеты? Будет ли это в say/var/lib/foo, или var/lib/foo-0.3.4? Если последнее, у нас проблемы, так как другим частям системы необходимо получить доступ к файлам .sha1 и, следовательно, нужно одно фиксированное место для установки.
- Есть ли лучший способ, чем вручную редактировать каждый сервер context.xml и install.sh для того, чтобы каждый клиент имел правильную информацию о соединении db? Например, люди используют awk/sed для таких вещей из script, или есть какой-то mysql-пароль и репозиторий строк строк?
- Как устанавливаются права доступа и разрешения целевых файлов?
- Кто-нибудь сталкивается с учебником по упаковке типа "привет мир", который не полагается на существующий "источник tar + make + install" и показывает взаимосвязь между файлами в пакете и файлами на целевом сервере после установки, и жизненный цикл пакета, включая работу с обновлениями?
-
Как система управляет только отправкой обновленных файлов, например, не двоичных файлов Liquibase в этом случае? Я предполагаю, что нам понадобится два пакета: один для базовой установки и один для tar, чтобы избежать дублирования?
Мы понимаем, что нам нужно помещать артефакты в специальную структуру каталогов и что это каким-то образом сопоставляется с файловой структурой целевых серверов, и нам нужно создавать различные управляющие файлы, но не как их склеивать на разных этапах, и какие сценарии необходимы.
Мы попытались прочитать руководство по политике Debian (https://www.debian.org/doc/debian-policy/), но это справочная информация для опытных разработчиков пакетов linux. Мы уверены, что ответы там, но мы не можем понять, где.
Этот пост: https://help.ubuntu.com/community/Tomcat/PackagingWebapps Имеет два других варианта (мы выбрали "избиение общесистемного экземпляра в представлении" ), но не дают никаких указаний о том, как фактические сборки пакетов.
