Решение проблемы занятого порта 8080
Вариант 1. Как открыть порт в брендмауэре Windows
Вариант 2. Как переопределить рабочий порт Jenkins
Первоначальная настройка и установка плагинов
Вместо заключения. Запуск сценария и мониторинг результата
Перед началом хочу поблагодарить коллег из коллективов SilverBulleters и xDD за бесценную консультационную поддержку.
Итак, поехали!
Вводная
Есть тестовая база, в которой тестировщики проверяют результаты разработки на соответствие требованиям заказчика. База подключена к тестовому хранилищу. Изменения в тестовое хранилище помещает разработчик. После чего система на сервере должна увидеть, что изменения есть, и обновить тестовую базу из хранилища.
Обзаводимся софтом
Для решения задачи нам понадобится:
- OneScript
- Библиотека Deployka из серии oscript-library
- Jenkins
- Платформа 1С: Предприятие с установленными средствами управления хранилищем и серверной частью
С установкой OneScript затруднений никаких не возникает. После установки самого 1Script, ставим Деплойку из командной строки:
opm install deployka
Консоль командной строки должна быть запущена под администратором. И нужно самому быть администратором на машине, где происходит сие представление. Понимаю, совет банальный, но у меня были затруднения из-за корпоративных политик безопасности нашей компании, поэтому предупреждаю.
На установке 1С-ки вообще не вижу смысла останавливаться :) Переходим к сути.
Составление сценария запуска
Сам сценарий работы с deployka взят из примера и адаптирован "под себя". Собственно, самих изменений немного, вот результат сценария команд, который у меня получился в результате:
deployka session lock -ras dev-td:2845 -rac "C:\Program Files\1cv8\8.3.10.2466\bin\rac.exe" -db "zup cb fin test" -db-user "Admin" -lockmessage "Плановое обновление" -lockuccode update
deployka session kill -ras dev-td:2845 -rac "C:\Program Files\1cv8\8.3.10.2466\bin\rac.exe" -db "zup cb fin test" -db-user "Admin" -lockmessage "Плановое обновление, 5 мин" -lockuccode update
deployka loadrepo "/IBConnectionString""Srvr=dev-td:2841;Ref='zup cb fin test'""" \\dit-dev1\1C-Storage\8.3\hrm_test_fin -db-user "Admin" -storage-user admin -storage-pwd 777 -uccode update
deployka dbupdate "/IBConnectionString""Srvr=dev-td:2841;Ref='zup cb fin test'""" -db-user "Admin" -allow-warnings -uccode update
deployka session unlock -ras dev-td:2845 -rac "C:\Program Files\1cv8\8.3.10.2466\bin\rac.exe" -db "zup cb fin test" -db-user "Admin"
То есть, порядок такой:
- Блокируем сессии для входа в базу, оставляем себе лазейку в параметре -lockuccode;
- Убиваем все текущие сессии;
- Загружаем изменения конфигурации из хранилища. Тут столкнулся с проблемой правильного написания строки соединения с базой, которую требует первый параметр команды loadrepo. Решения было найдено здесь (есть пример строки подключения для файловой и клиент-серверной базы);
- Обновляем конфигурацию базы данных. Здесь ключевой момент - наличие ключа -allow-warnings. Он необходим на случай, если в конфигурации были изменения структуры, то их необходимо принять безоговорочно. В интерактивном режиме мы привыкли видеть дополнительное окно с перечислением изменений структуры, в котором нажимаем на кнопку "Принять", после чего обновление успешно завершается. Так вот, ключ -allow-warnings как раз "нажимает" на эту кнопку;
- Снимаем блокировку сессий, чтобы с базой могли работать пользователи.
Какие здесь есть нюансы:
- Сервер RAC используем той версии платформы, на которой крутится целевая база;
- Имя пользователя прописываю латиницей (завёл отдельного пользователя для этого). Когда используешь командную консоль, Jenkin и еще какой-нибудь редактор текста, то договориться между ними о кодировках кириллицы - это отдельный тур вальса с бубном, на нём останавливаться не буду.
- Предварительно должен быть запущен сервер RAS.
Запуск RAS как сервис
Сервер RAS можно разово запустить отдельным bat-файлом, а можно запустить его как сервисную службу. Я пошёл вторым путём, команда для запуска следующая:
sc create "1C:Enterprise RAS" binpath="\"C:\Program Files\1cv8\8.3.10.2466\bin\ras.exe\" cluster --service --port=2845 localhost:2840"
Номера портов следует прописывать, исходя из того, на каких портах "сидит" соответствующий сервер 1С: Предприятия.
Сервис должен запуститься под пользователем с правами администратора системы, иначе ничего не получится. Настройку можно выполнить в списке служб операционной системы в Панели управления.
На данном этапе сценарием уже можно пользоваться из командной строки или в виде bat-файла. Но наша задача - обернуть ещё это всё в CI и автоматизировать процесс.
Установка Jenkins
Скачиваем установочный пакет под нужную ОС по ссылке в начале статьи.
Запускаем, устанавливаем всё по умолчанию. После установки, Jenkins будет доступен из браузера по адресу: localhost:8080. Должен появиться приветственный экран Jenkins:
Рисунок 1
Если экран появился, можно переходить к первоначальным настройкам системы. В противном случает придётся еще побороться с закрытым портом 8080.
Здесь описан порядок подключения на локальной машине. В общем случае, в адресной строке браузера следует писать IP сервера, на котором установлен Jenkins: http://[IP-адрес сервера]:8080
Про более сложную распределенную установку Jenkins на сервере/клиентах написано здесь.
Другие способы установки Jenkins:
Решение проблемы занятого порта 8080
Если после установки Jenkins в браузере появляется что угодно, но только не то, что изображено на рисунке 1, значит порт 8080 на вашем компьютере закрыт или занят другим приложением (PS а заодно проверьте статус работы сервиса Jenkins и наличие оперативной памяти, Jenkins потребляем от 256Мб до 1Гб оперативы). Решения проблемы два: либо открыть порт средствами Windows, либо переопределить номер порта для Jenkins.
Вариант 1. Как открыть порт в брандмауэре Windows
Открываем брандмауэр: нажимаем [Win+R], даём команду firewall.cpl. В открывшемся окне переходим в «Дополнительные параметры», затем открываем раздел «Правила для входящих подключений». Должно появиться окно:
Рисунок 2
В правой колонке нажимаем «Создать правило…».
Шаг 1. Выбираем тип правила «Для порта» и нажимаем «Далее».
Рисунок 3
Шаг 2. В поле «Определённые локальные порты» вводим номер нашего порта 8080, и нажимаем «Далее»
Рисунок 4
Шаг 3. Выбираем вариант «Разрешить подключение» и жмём «Далее»
Рисунок 5
Шаг 4. Оставляем всё по умолчанию и нажимаем «Далее»
Рисунок 6
Шаг 5. На заключительном шаге указываем имя для нового правила файервола и нажимаем «Готово».
Рисунок 7
Если и после этого Jenkins не запустится, добавьте еще одно такое же правило, только на шаге 2 укажите правило UDP.
Вариант 2. Как переопределить рабочий порт Jenkins
Чтобы Jenkins подключался к другому порту, в файле \Program Files\Jenkins\jenkins.xml нужно найти ключ:
--httpPort=8080
и поменять номер на желаемый, после чего перезапустить сервис Jenkins.
Первоначальная настройка и установка плагинов
После того, как установка выполнена, в браузере мы попадаем в окно приветствия (см. Рисунок 1). Здесь нужно вставить пароль из файла \Program Files\Jenkins\secrets\initialAdminPassword и нажат «Продолжить». На следующем шаге выбираем режим установки плагинов: Install suggested plugins.
Рисунок 8
Для решения нашей задачи нам понадобится плагин Filesystem Trigger Plug-in, его и устанавливаем.
После установки создаём профиль администратора, имя пользователя и пароль запоминаем для использования в дальнейшей работе. Нажимаем «Продолжить», на экране появится сообщение, свидетельствующее о готовности Jenkins к работе.
Рисунок 9
Нажимаем «Start using Jenkins» и переходим в рабочую панель системы.
Дополнительно:
Настройка проекта в Jenkins
Теперь, когда Jenkins настроен и готов к работе, создадим наш сценарий. Выбираем на главной странице Jenkins команду «Создать Item» («New Job»). Задаём название нашему проекту, выбираем тип «Создать задачу со свободной конфигурацией» («Free-style project») и нажимаем OK.
Рисунок 10
Далее открывается окно настройки проекта. В основном разделе при желании можно описать, что реализуется в данном сценарии, и настроить правила очистки истории выполненных сборок.
Рисунок 11
Переходим в раздел "Триггеры сборки". Здесь настраиваются условия, при которых наш сценарий будет выполняться. Нам нужно, чтобы сборка производилась при изменении файла хранилища конфигурации.
Устанавливаем флажок [FSTrigger] - Monitor files, далее ставим флажки Inspect fila contents (собственно проверка, а не поменялся ли файл?) и Ignore modification data (дабы избежать ложных срабатываний сценария). В поле File Path прописываем полный путь к файлу *.1cd хранилища конфигурации.
В поле «Расписание» («Schedule») прописываем строку: */15 * * * *. Это означает, что проверка изменений файла (а значит и необходимости дальнейшего запуска сборки) будет выполняться каждые 15 минут. Подробнее о формате написания этой строки можно почитать в справке, которая открывается по «знаку вопроса» справа от поля ввода.
Рисунок 12
В разделе «Сборка» выбираем команду «Добавить шаг сборки – Выполнить команду Windows», и в появившемся поле ввода прописываем команду соответствующего шага. Затем повторяем то же самое для остальных шагов. В результате должно получиться то, что показано на рисунке 13.
Рисунок 13
Еще один вариант:
Нажимаем «Сохранить».
Поздравляю! Вы автоматизировали одну из рутинных операций в своей работе. Добро пожаловать в мир DevOps-а! :))
Вместо заключения. Запуск сценария и мониторинг результата
После сохранения сценария открывается страница управления этим сценарием. Если выбрать команду «Собрать сейчас», то сценарий будет запущен, а результат появится в разделе «История сборок».
Рисунок 14
Из контекстного меню конкретного запуска сценария можно через команду «Console Output» посмотреть детали выполнения.
Рисунок 15
Также запустить сценарий можно из контекстного меню конкретного проекта в списке главного окна системы.
Рисунок 16
