Каталог решений - Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

В наличии

Решаем задачу: автоматизировать обновление тестовых баз 1С из хранилища конфигурации при появлении в нём новых изменений. Данная статья родилась в муках хождения по граблям и поиска безопасного форватора среди подводных камней. Изложение постарался представить в виде инструкции для новичка, в которой собрал всё, с чем пришлось столкнуться.
Сам я не DevOps-ер, ни на что не претендую, просто делюсь опытом 🙂

Категория:

Описание

Вводная

Обзаводимся софтом

Составление сценария запуска

   Запуск RAS как сервис

Установка Jenkins

   Решение проблемы занятого порта 8080

      Вариант 1. Как открыть порт в брендмауэре Windows

      Вариант 2. Как переопределить рабочий порт Jenkins

   Первоначальная настройка и установка плагинов

Настройка проекта в Jenkins

Вместо заключения. Запуск сценария и мониторинг результата

Перед началом хочу поблагодарить коллег из коллективов SilverBulleters и xDD за бесценную консультационную поддержку.

Итак, поехали!

Вводная

Есть тестовая база, в которой тестировщики проверяют результаты разработки на соответствие требованиям заказчика. База подключена к тестовому хранилищу. Изменения в тестовое хранилище помещает разработчик. После чего система на сервере должна увидеть, что изменения есть, и обновить тестовую базу из хранилища.

Обзаводимся софтом

Для решения задачи нам понадобится:

С установкой 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"

То есть, порядок такой:

  1. Блокируем сессии для входа в базу, оставляем себе лазейку в параметре -lockuccode;
  2. Убиваем все текущие сессии;
  3. Загружаем изменения конфигурации из хранилища. Тут столкнулся с проблемой правильного написания строки соединения с базой, которую требует первый параметр команды loadrepo. Решения было найдено здесь (есть пример строки подключения для файловой и клиент-серверной базы);
  4. Обновляем конфигурацию базы данных. Здесь ключевой момент — наличие ключа -allow-warnings. Он необходим на случай, если в конфигурации были изменения структуры, то их необходимо принять безоговорочно. В интерактивном режиме мы привыкли видеть дополнительное окно с перечислением изменений структуры, в котором нажимаем на кнопку "Принять", после чего обновление успешно завершается. Так вот, ключ -allow-warnings как раз "нажимает" на эту кнопку;
  5. Снимаем блокировку сессий, чтобы с базой могли работать пользователи.

Какие здесь есть нюансы:

  • Сервер 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. Приветственная страничка Jenkins

Рисунок 1

Если экран появился, можно переходить к первоначальным настройкам системы. В противном случает придётся еще побороться с закрытым портом 8080.

Здесь описан порядок подключения на локальной машине. В общем случае, в адресной строке браузера следует писать IP сервера, на котором установлен Jenkins: http://[IP-адрес сервера]:8080

Про более сложную распределенную установку Jenkins на сервере/клиентах написано здесь.

Другие способы установки Jenkins:

 

has been added to your cart:
Оформление заказа