Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

Публикация № 1209079 13.03.20

Разработка - DevOps и автоматизация разработки

CI Jenkins Vagrant Linux QA Automation Тестирование

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

 

Обновление Jenkins и первый вход в систему

Общие настройки Jenkins

Создание узлов

Способы запуска узлов

Настройка анонимного подключения к Jenkins

Передача имени/адреса сервера в виртуальные машины

Скрипт для обновления и подключения агента

Перезагрузка виртуальной машины после развёртывания

Проверка подключения

Пример распределения задач по узлам CI-сервера

Архивация и включение в состав репозитория настроек узлов и задач

Другие части цикла "Многопоточный CI-контур для 1С":

1.  Описание системы и обзор инструментария

2.  Собираем образ виртуальной машины с PostgreSQL и платформой 1С

3.  Разворачиваем узлы CI через Vagrant, строим сеть из виртуальных машин

5. Пайплайны Jenkins - программирование и настройка. Загружаемые модули

 

 

В прошлый раз мы создали механизм, позволяющий разворачивать нужное количество виртуальных машин и объединять их в сеть. Для их подключения в качестве сборочных узлов к CI-серверу осталось только запустить на них агентов Jenkins.

Для этого потребуется:

  • Настроить сам сервер Jenkins  на хостовой машине.
  • Запустить агентов Jenkins в развёрнутых машинах c возможностью их взаимодействия с рабочим столом и запуска через них пользовательских "интерактивных" приложений. В частности - запуска клиентов 1С.
  • Обеспечить максимально простое подключение агентов Jenkins к серверу без ключей и паролей, зная только имя хостовой машины.

 

Конфигурирование Jenkins на хостовой машины - это единственное, что мы не будем пытаться полностью автоматизировать. Дело в том что Jenkins - это своего рода конструктор, состоящий из плагинов. С помощью плагинов реализуется даже такая базовая функциональность, как работа с Git, управление правами доступа, возможность описывать сборочные линии кодом. Настройки плагинов при этом могут меняться от версии к версии и хранятся в виде XML-файлов. Неизменность формата этих файлов не гарантируется, поэтому настройка плагинов через bat- или bash-скрипты может привести к нестабильности системы. Хотя возможно я просто не копал так глубоко, чтобы научиться это делать правильно и Вы сможете найти стабильное решение этой задачи ;)  

Выполняемых вручную настроек в Jenkins будет немного. Основной объем данных - настройки задач и узлов - мы всё же будем сохранять в составе репозитория и обеспечим возможность их восстановления на любом сервере.

 

В первой части этого цикла рассматривалась целесообразность разделения всего используемого кода на два независимых друг от друга репозитория:

  • первый - инфраструктурный, обеспечивающий развёртывание среды исполнения для CI 
  • второй - хранящий исполняемый на CI код, а также настройки задач сборки и тестирования

Именно на данном этапе имеет смысл выполнить такое разделение. Настройки задач и узлов Jenkins, а также код их архивации и развёртывания, сохраним в в отдельном репозитории:

Данный репозиторий должен позволять переносить все задачи сборки и связанный с ними код на любую инфраструктуру, независимо от того, как она создана - вручную на основе физических машин, или автоматически с помощью Packer и Vagrant, или каким-либо другим способом.

В то же время мы завершим настройку отдельных виртуальных машин для их развёртывания через Vagrant. Обеспечим их подключение к серверу Jenkins. Этот код по прежнему сохраним в "инфраструктурном" репозитории, с которым работали ранее.

 

Обновление Jenkins и первый вход в систему

 

Начнем работу с Jenkins с его обновления. Ранее был написан скрипт, осуществляющий конфигурирование хостовой машины. С помощью него мы устанавливали на хостовой машине Jenkins и включали в нём поддержку UTF-8 следующими командами:

  choco install jenkins -y --force

  sed -i "s/<arguments>-/<arguments>-Dfile.encoding=UTF-8 -Dpermissive-script-security.enabled=true -/"  "C:\Program Files (x86)\Jenkins/jenkins.xml"

 

Если с тех пор Вы не обновляли Jenkins, то можно воспользоваться преимуществами менеджера пакетов Chocolaty и выполнить обновление всего одной командой:

choco update jenkins -y

 

 

Главное, что происходит при обновлении - это загрузка и замена на новую версию файла jenkins.war - основного исполняемого файла, который на Windows расположен в каталоге C:\Program Files (x86)\Jenkins. После обновления можно приступить к первому входу в систему и первоначальной настройке.

Работа с Jenkins ведётся через веб-интерфейс. Если служба Jenkins запущена, то в системе работает веб-сервер на порту, который указан в файле jenkins.xml:

 

Таким образом, чтобы подключиться к нему с локального компьютера в адресной строке браузера достаточно вбить http://localhost:8080.

При первом входе в системе еще нет пользователей и поэтому Jenkins попросит подтвердить, что мы имеем доступ к серверу (к его файловой системе). Для этого нужно ввести в поле пароля содержимое файла, путь к которому будет здесь указан:

 

 

Получить содержимое этого файла можно через любой редактор или команду cat:

 

 

После создания первого же пользователя в системе этот файл будет удален. Далее нужно будет выбрать вариант установки. Будет предложена установка c самостоятельным выбором плагинов или с установкой рекомендуемых плагинов. Для наших целей подойдет вариант с рекомендуемыми плагинами. Это сократит время на дальнейшую настройку системы, а тюнинг для оптимизации занимаемого на диске места или скорости работы можно будет выполнить когда будет получен базовый опыт работы с этой системой. Кроме того плагины всегда можно не только установить, но и удалить ненужные.

 

 

То, что таким образом мы серьёзно экономим время настройки можно увидеть по списку устанавливаемых плагинов из которых нам в дальнейшем пригодятся:

  •  Folders  - для создания папок с задачами сборки для 1С и их логического отделения от других задач
  •  Build Timeout   - для задания максимального времени этапов сборки и предотвращения "вечного" зависания сборок
  •  Timestamper  - для вывода в логи сборок времени выполнения отдельных действий-шагов
  •  Pipeline  - для программирования сборочных линий на языке Groovy вместо накликивания мышкой с ограниченными возможностями
  •  Git  - для получения кода пайплайнов и сценарных тестов из git-репозитория
  •  Email Extension  - для отправки оповещений об упавших сборках на почту администратору
  •  Matrix Authorization Strategy  - для управления доступом. Возможности этого плагина мы будем скорее отключать, чем использовать, но при этом немного познакомимся с управлением доступом к Jenkins

 

 

После завершения установки плагинов остаётся только задать имя и пароль первого администратора системы.

Кстати, здесь есть команда-ссылка "Continue as admin" нажав на которую можно пропустить шаг создания администратора, но в этом случае при следующем входе в Jenkins снова придётся указывать текст из файла C:/Program Files (x86)/Jenkins/secrets/initialAdminPassword.  Если же этот шаг не пропустить, то данный файл будет больше не нужен и будет автоматически удалён:

 

 

Более подробно с процессом установки можно ознакомиться, посмотрев следующие два видео с канала Кирилла Семаева (а заодно рекомендую ознакомиться и с остальным содержимым канала):

 

Итак, теперь мы зашли в Jenkins и у нас есть настроенные стандартные плагины. Состав плагинов по умолчанию почти полностью покрывает наши потребности в построении CI для 1С. Приступим к конфигурированию системы.

 

 

Общие настройки Jenkins

 

HTTP-адрес сервера

 

Первое что необходимо сделать - это настроить http-адрес сервера на основе имени хостовой машины.

По умолчанию Jenkins использует порт 8080. Если необходимо изменить порт, то сделать это можно всё в том же файле jenkins.xml в каталоге установки, в котором мы ранее включали поддержку UTF-8. Но если порт не менялся, то адрес, который нужно задать в настройках должен выглядеть следующим образом:  http://ИМЯ-КОМЬЮТЕРА:8080

Выполнить эту настройку нужно потому, что многие внутренние гиперссылки внутри самого Jenkins и гиперссылки в плагинах для отчетности о результатах тестирования и e-mail рассылок генерируются относительно этого адреса. Если указать здесь что-то вроде http://localhost:8080, то и ссылка приходящая на почту или добавляемая в отчет будет выглядеть как http://localhost:8080/job/job_group/job/job_name/95.  Конечно, такого лучше избегать. Поэтому нужно перейти в конфигурацию системы:

 

и заполнить поле Jenkins URL. При желании также можно указать e-mail администратора системы. На этот e-mail будут приходить сообщения об исключительных ситуациях и ошибках:

 

Важный момент. После сохранения этой настройки в адресной строке браузера также стоит указывать именно этот адрес (при доступе в Jenkins через веб-интерфейс). Если продолжить в адресной строке указывать localhost:8080, то после входа в систему в web-интерфейсе будет светиться надпись, о том, что возможно эта настройка задана некорректно. Иными словами адрес заданный в настройках Jenkins URL должен совпадать с тем, через который осуществляется вход в веб-интерфейс сервера.

 

Настройка оповещений по e-mail  

 

Если вы хотите получать информацию о результатах выполнения задач не только через графический интерфейс Jenkins или Allure, но и другими способами, то есть множество плагинов, которые могут выводить информацию в мессенджеры, прикреплять ссылки к Jira или другим системам учета задач, даже слать СМС на телефон. Самым простым в настройке способом "из коробки" является настройка оповещений на e-mail.

Настройка может быть выполнена через настройки плагина "Extended E-mail Notification" или настройки "Уведомление почтой". Рекомендую делать это через настройки плагина "Extended E-mail Notification", так как далее в коде пайплайнов для отправки почты на указанный в настройках e-mail будет использоваться функция emailext, предоставляемая этим плагином.

Здесь можно настроить рассылку через корпоративную почту. Но в нашем случае для демонстрации возможностей можно задействовать открытый SMTP-сервер smtp.gmail.com. Для него требуется указать использование SSL и порт 465. В качестве имени пользователя обязательно указывать полный e-mail:

 

 

Имя исполняемого файла Git для работы с Linux

 

И еще один штрих на данный момент - настройка имени исполняемого файла git. Git используется в Jenkins на всех узлах. Подчиненные узлы, работающие на Linux, будут вызывать его для получения всех последних изменений из гит-репозитория, хранящего исполняемый на CI код (сейчас этот репозиторий хранит только скрипты архивирования и развертывания задач Jenkins, но позже в нём появится и исполняемый код пайплайнов).

Мастер-узел, работающий на Windows будет обращаться к тому же репозиторию. Но для получения меньшего объема данных - только текста файлов, содержащих код пайплайнов.

Важно здесь то, что происходить обращение к git будет как с Linux , так и с Windows. Но при установке Jenkins на Windows в конфигурации глобальных инструментов именем исполняемого файла будет git.exe.  Конечно на стороне Linux расширения "exe" у этого файла не будет. Поэтому его необходимо удалить, оставив в поле только "git ". Полный путь к файлу задавать не имеет смысла - во всех системах путь к нему будет включен в переменную PATH:

 

К настройке глобальных инструментов еще нужно будет вернуться, когда мы будем говорить про публикацию отчетности о результатах тестирования в Allure и настройку таймаутов для операций в пйплайнах. Но сейчас можно перейти к другой задаче - настройке сборочных узлов Jenkins.

 

 

Создание узлов

 

На главной странице Jenkins есть блок, отображающий состояние сборщиков. После первоначальной установки в нём будет только один узел - master. Он соответствует главному процессу Java на хостовой машине, является управляющим, и именно его настройки мы меняли, когда с помощью sed правили содержимое файла jenkins.xml.

Нам необходимо создать и настроить узлы, соответствующие агентам сервера, которые будут работать на наших виртуальных машинах. Описанным далее способом должно быть создано столько узлов, сколько будет у нас виртуальных машин.

Для добавления нового узла можно перейти по ссылке "Состояния сборщиков" и затем "Новый узел".

 

В зависимости от состава плагинов, установленных в системе в системе, при создании узла для него можно выбрать различные типы.

Настройку всегда можно скопировать с существующего узла (кроме узла master), но так как сейчас мы рассматриваем процесс создания первого узла и никаких плагинов, добавляющих новые типы узлов, у нас не установлено, то здесь следует выбрать Permanent Agent - это стандартный тип узла.

Название узла   - очень важный параметр, исполняющий скорее роль идентификатора и имени, чем просто заголовка.

В нашем случае название должно соответствовать имени хоста в виртуальной машине.  Это не требование Jenkins, а требование наших механизмов. При развертывании виртуальной машины через Vagrant мы передаем в него только одно уникальное имя - имя хоста. При подключении агента, запущенного в Linux к серверу Jenkins, необходимо указывать имя узла, с которым будет ассоциирован этот агент. Чтобы не множить количество переменных в нашей системе, удобно сделать так, чтобы имя хоста в виртуальной машины совпадало с именем узла Jenkins. Тогда можно не передавать имя узла через отдельную переменную окружения в Vagrantfile. Именно так и будут реализованы наши механизмы подключения далее.

Нажав на Ok попадем на страницу детальной настройки узла. Здесь много параметров и справку по каждому из них можно получить справку нажав на знак вопроса:

 

Количеством процессов-исполнителей

 

Параметр правильнее было бы написать "потоков-исполнителей", так как процесс Java останется один. Смысл параметра в том, что он определяет сколько задач параллельно могут выполняться на данном узле.

 

Вспомним еще раз схему, приведенную в первой части. У нас будут узлы выполняющие сценарные тесты и подготовку образа тестовой базы. Эти узлы будут запускать тест-клиенты и тест-менеджеры, открывать на выполнение внешние обработки, эмулировать интерактивные действия пользователей. В машинах, соответствующих таким узлам не должно исполняться более одного процесса одновременно и поэтому данный параметр надо установить в 1. В рассматриваемых далее примерах будет два таких узла с именами ubuntu-interactive-2 и ubuntu-interactive-3 .

 

Узлы, отвечающие за выгрузку изменений из хранилища и запуск основной задачи сборки, могут иметь сколь угодно большое количество потоков-исполнителей. На практике нам потребуется хотя бы два потока. Также имеет смысл ограничить их руководствуясь здравым смыслом. Например мы не хотим, чтобы на узле выполнялось одновременно более трех задач. Один поток будет выполнять выгрузку из хранилища. Второй - запускать основную задачу сборки. Третий может использоваться для каких-то тестовых задач.  В рассматриваемых далее примерах будет один такой узел с именем ubuntu-interactive-1.

 

Корень удаленной файловой системы  

Это место, куда агент Jenkins будет писать все необходимые ему данные: выкачивать гит-репозитории, складывать результаты сборок, размещать временные файлы с паролями (да, пароли всегда можно вытянуть из Jenkins). При этом для каждой задачи будет создаваться отдельный подкаталог.

 

Во всех наших узлах здесь будет один и тот же путь к каталогу, который мы будем создавать в каждой виртуальной машине посредством Vagrantfile.

 

Метки  

Тоже важный параметр. Метка - это по сути способ классификации узлов в Jenkins. С помощью них мы определяем к каким классам узлов относится данный узел. Так как в Jenkins всё построено на строках, а не на каталогах (справочниках) то для классификации узлов также используются строки. Нет необходимости предварительно заполнять какой-то каталог с классами узлов. Просто задаются метки.

 

При создании задачи Jenkins или при задании кода пайплайна можно указать на каких классах узлов может исполняться эта задача указывая допустимые для исполнения задачи метки узлов. Запуская задачу мастер-узел на хостовой машине будет искать подходящий свободный процесс/поток-исполнитель на узлах, подходящих под указанные метки, и если такой узел находится - передает исполнение на него. Если не находится - то ставит задачу в очередь и ждет.

 

Чтобы не запутаться в названиях давайте еще раз взглянем на схему задач Jenkins:

 

 

 

В каждой задаче у нас будет указана только одна метка. В задачах, связанных с эмуляцией интерактивных действий (это задача подготовки образа тестовой базы и основная задача сборки и тестирования), будет указана метка ubuntu_interactive и ее мы назначим узлам ubuntu-interactive-2 и ubuntu-interactive-3. В задаче выгрузки хранилища будет указана метка configuration_storage_reader, а в задаче-стартере   - метка starter. Обе эти задачи будут исполняться на узле ubuntu-interactive-1 и поэтому у этого узла следует указать обе эти метки через пробел.

Напомню, что на узле, отвечающем за выгрузку версий хранилища 1С, обязательно должна стоять платформа 1С той же версии, на которой работает сервер хранилища конфигураций. А на узлах, где выполняются процессы тестирования может стоять любая версия платформы, работу на которой мы хотели бы проверять тестами.

 

 

Последний параметр, который нужно изменить при настройке узла - это способ запуска. Он заслуживает отдельного рассмотрения.

 

 

Способы запуска узлов

 

 

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

 

 

SSH-подключение (Launch agents via SSH)

Особенности подключения с этим типом:

  • Выполняется по инициативе управляющего мастер-узла (в нашем случае мастер-узел работает на хостовой машине).
  • Иногда приходится включать узел из интерфейса Jenkins вручную, если сначала был запущен мастер-узел, а затем машины, на которых необходимо запустить агентов. Это как раз наш случай, так как виртуальные машины запускаются на хосте и служба Jenkins с мастер-узлом будет очевидно запущена раньше чем они.
  • Подходит для запуска агентов без их взаимодействия с графическим окружением.

 

На самом деле есть способы запустить SSH сервер как "интерактивное" приложение в Linux или в Windows, но это решение нельзя считать подходящим в общем случае. В большинстве случаев SSH-сервер запускается как служба, а не как приложение. Также есть способ взаимодействия с рабочим столом через SSH-соединение при работе с X11 на Linux. Но в данном варианте подключения Jenkins сам формирует команду для установки соединения и указать в ней параметры для доступа SSH к графической системе нет возможности.

 

Метод подключения работает так:

  • Управляющий Java-процесс на мастер-узле запускает ssh-клиента с параметрами подключения к ssh-серверу на той машине, где будет запускаться подчиненный узел. В качестве параметров авторизации используется SSH-ключ заданный в настройках Jenkins или ключ из каталога .ssh в домашнем каталоге пользователя, из под которого запущен мастер-узел. Для того чтобы подключение прошло без проблем стоит также заполнить поле " Host Key Verification Strategy " указав в нем отсутствие необходимости в проверке машины, к которой происходит подключение (значение " Non verifying verification strategy ").
  • Н а машину, к которой произошло подключение, загружается jar-файл агента. Конечно это происходит только если подключение выполняется в первый раз и файла агента на машине ещё нет.
  • Затем запускается Java-процесс с указанием пути к этому jar-файлу. Этот процесс и представляет из себя слейв-узел.
  • SSH-подключение удерживается, что позволяет получать на мастер-узле консольный вывод всех команд, выполняемых на слейв-узле.
  • Java-процесс на слейв-узле является родительским для всех процессов, которые им запускаются. При его завершении завершаются и все запущенные им процессы.

Похожий принцип с удержанием установленного соединения применяется и для других типов подключений.

 

Выполнение произвольной команды со стороны мастер узла  (Launch agent via execution of command on the master)

Этот вариант стоит предпочесть в том случае, если необходимо выполнение какой-то специфичной команды или скрипта для подключения. Или особых параметров подключения через SSH.  Выбрав такой вариант подключения мы можем вручную сформировать команду подключения через SSH к другому или даже текущему компьютеру со всеми нужными параметрами.

Например для подключения к узлу, работающему на Windows может подойти команда, подобная следующей:

ssh -i C:\ssh-keys\key_without_passphrase  -o StrictHostKeyChecking=no username@HOSTNAME "D:/jenkins_remote/jdk/bin/java.exe -Dfile.encoding=UTF-8 -Xmx1048m -jar D:/jenkins_remote/remoting.jar -workDir D:\jenkins_remote"

Здесь мы самостоятельно заботимся об указании нужных ключей для авторизации без пароля, отключении запроса на внесение хеша удаленной машины в список известных хостов ssh-клиента, указывая параметр -o StrictHostKeyChecking=no (это аналог выбора "Non verifying verification strategy" для прошлого варианта подключения).  

Преимущества и недостатки у этого варианта всё те же что и у предыдущего. Дополнительный плюс - этот вариант дает больше гибкости в настройках подключения. Дополнительный минус - о наличии jar-файла агента и всех параметров подключения придется заботиться самостоятельно.

 

Самостоятельное подключение узла к мастер-узлу (Launch agent by connecting it to the master)

В этом случае механизм запуска узла следующий:

  • Мастер-узел Jenkins сам не пытается запустить подчиненный узел. Вместо этого он ждет запроса на подключение со стороны подчиненного узла.
  • Агент подчиненного узла запускается внешними средствами: при загрузке операционной системы, логоне пользователя, вручную или любым другим способом. Запускается он по прежнему как Java-приложение поэтому необходимо обеспечить наличие на машине JVM/JRE и jar-файла агента.
  • При запуске подчиненного узла ему указывается http-адрес, по которому необходимо отправлять запрос на подключение.
  • Если запрос не завершается успешно, то подчиненный узел продолжает повторять этот запрос раз в 10 секунд,  бесконечно. Аналогично он ведёт себя при разрыве соединения. Это позволяет запускать сначала подчиненные узлы, а затем мастер узел. Или наоборот, сначала мастер-узел, а затем подчиненные узлы. В любой момент времени перезапускать службу Jenkins с мастер-узлом с последующим восстановлением соединения.
  • При получении запроса на подключение мастер-узел создает TCP-соединение с подчиненным узлом. Может использоваться как фиксированный порт, указанный в настройках Jenkins , так и "случайный" порт.
  • Подчиненный узел передает через установленное соединение информацию о консольном выводе всех запускаемых им команд, позволяя получать тот же результат, что и при ssh-подключении.

 

Именно этот третий вариант мы будем использовать так как он:

  • Позволяет стабильнее и проще остальных способов запускать агента в "интерактивном" режиме (с возможностью взаимодействия с рабочим столом).
  • Стабильнее устанавливать связь когда подчиненные узлы (виртуальные машины и агенты на них) запускаются после того как запущен мастер-узел.

С настройками Jenkins по умолчанию такого пункта как "Launch agent by connecting it to the master" в варианте запуска вообще не будет. Для того чтобы получить возможность выбирать такой вариант подключения необходимо явно разрешить его в настройках  Manage Jenkins > Configure Global Security > Agents > TCP port for inbound agents или в русифицированном варианте Настроить Jenkins > Глобальные настройки безопасности > Agents > TCP port for inbound agents.

В этом разделе необходимо выбрать либо "Случайный порт" либо указать фиксированный порт. Фиксированный порт имеет смысл указать если у вас работает фаервол и нужно настроить исключения для порта. Других отличий в стабильности связи между этими вариантами за время использования Jenkins я не замечал.

   

 

После того как эта настройка выполнена и сохранена в списке выбора варианта подключения появится нужный нам пункт.

 

 

Настройка анонимного подключения к Jenkins

 

 

Теперь позаботимся об удобствах. Посмотрим как при настройках по умолчанию Jenkins предлагает нам подключать узлы.

 

Для подключения нам предлагается указать ключ вида 35e2648c23c8aa6e92745b92fdf3d2cf85453be78b1d684825555afffc0e1730, который известен администратору Jenkins, настраивающему подключение, но не будет известен "вражеским" агентам. Этот ключ будет уникальным для каждого узла Jenkins. За такое поведение отвечает один из плагинов, которые устанавливаются по умолчанию - это плагин "Matrix Authorization Strategy" - именно этот плагин включает повышенные настройки безопасности и не позволяет подключать агенты без указания ключей.

Если оставить всё как есть, то нам придется передавать этот ключ в виртуальную машину через Vagrantfile (точнее через переменные окружения). Это не только доставляет сложности с введением еще одной  переменной, но и снижает переносимость наших механизмов между серверами, за которую мы с самого начала боремся и ради которой выбрали работу с виртуальными машинами.

При этом защищаться от "вражеских" агентов в нашей локальной сети нет никакой необходимости, им просто неоткуда взяться. Удалять плагин "Matrix Authorization Strategy" не нужно. Можно просто его настроить на возможность анонимного подключения агентов.

При этом можно сразу решить еще один вопрос. Нам нужно будет как то обеспечить первоначальную загрузку файла агента в каждую машину. И затем обновлять его, ведь при обновлении Jenkins может быть обновлена не только серверная часть, но и файлы агентов.

Пока мы залогинены в Jenkins исполняемый файл агента можно загрузить по ссылке http://ИМЯ-ХОСТА:8080//jnlpJars/agent.jar. Для скачивания этого файла другими приложениями им придётся авторизоваться - передать серверу Jenkins логин и пароль. Но хранить имя пользователя и пароль на стороне машин-узлов неправильно и неудобно. Для возможности загружать этот же файл без авторизации нужно разрешить анонимное чтение данных. Сделать это можно в том же разделе, где мы разрешали TCP подключение со стороны агентов. Таким образом настройки в разделе "Глобальные настройки безопасности" должны выглядеть следующим образом:

 

 

Теперь, если перейти к настройкам узла, то мы увидим, что ключ для запуска больше не нужен:

 

 

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

На этом с настройками Jenkins мы заканчиваем и вернемся к ним только когда будем конфигурировать плагин Allure. Далее мы ещё создадим простейшие задачи Jenkins для проверки сделанных настроек. Но сейчас вернемся к Vagrantfile и обеспечим запуск агента Jenkins в виртуальных машинах и их подключение к серверу.

 

 

Передача имени/адреса сервера в виртуальные машины

 

 

Как видно на скриншотах выше, для подключения подчиненного узла и загрузки jar-файла агента Jenkins потребуется знать имя хоста или IP-адрес машины, на которой работает сервер Jenkins, а также порт, на котором работает этот сервер. Их нужно будет передать в виртуальную машину. Как и в случае всех прочих параметров, сделаем это через Vagrantfile и переменные окружения, которые назовем host_machine_ip_or_hostname и jenkins_port.

Чаще всего удобнее передавать именно имя хоста, как и предлагает Jenkins в настройках узла. Особенно если для хостовой машины не назначен статический IP адрес. Но несмотря на установку Avahi иногда достучаться до хостовой машины по имени может не получиться, поэтому сохраним возможность передавать не только имя хоста, но и IP-адрес.

Для того чтобы упростить задание настроек узлов в командных файлах, можно в общем файле запуска (в рассматриваемом репозитории это vagrant-up-destroy-common.bat) сделать настройку по умолчанию. Если переменная окружения host_machine_ip_or_hostname не определена ранее в файле, специфичном для отдельной машины, то можно автоматически установить её равной имени компьютера:

 

 

 if NOT DEFINED host_machine_ip_or_hostname (

     SET host_machine_ip_or_hostname=%computername%

 )

 

 

Для того чтобы вместо имени хоста указать IP-адрес достаточно будет в файле настроек отдельного узла node-settings.bat определить значение этой же переменной:

 

 

 :my_config

 SET host_machine_ip_or_hostname=192.168.1.64

 SET host_phisical_adapter_name_for_bridge_connection=Realtek PCIe GBE Family Controller

 SET ram_memory_size_mb=2048

 SET cpu_count=2

 goto :end

 

 

Теперь настройка заданная в файле node-settings.bat имеет приоритет.

Команды, инициируемые Vagrantfile работают уже на стороне гостевой машины Linux и поэтому надо использовать уже команды bash.

Сервис Avahi работает таким образом, что к имени хоста может потребоваться добавить постфикс ".local". Сделать это необходимо при соблюдении двух условий:

  • Переданное значение не является IP адресом
  • Без постфикса .local до хоста не получилось достучаться

В ином случае можно использовать переданное значение переменной host_machine_ip_or_hostname внутри виртуальной машины не модифицируя его. Выполнить обе проверки и при необходимости добавить постфикс ".local" можно следующими строками кода:

 

 

 if [ $(echo $host_machine_ip_or_hostname | grep -P "^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" | wc -l) -eq 0 ] \

     && [ $(ping -c 1 $host_machine_ip_or_hostname 2>&1 | head -n 1 | grep 'failure in name resolution' | wc -l) -gt 0 ]

 then 

     host_machine_ip_or_hostname=$host_machine_ip_or_hostname.local

 fi

 

 

Располагаться эти команды будут в командном файле настройки подчиненного узла jenkins_node_configure.sh. Перейдем к его созданию.

 

 

Скрипт для обновления и подключения агента

 

 

Выше были описаны способы запуска агента. Наш выбор - отложенный запуск агента, как приложения, способного взаимодействовать с рабочим столом после каждой загрузки гостевой машины c Linux.  

Для выполнения команд при каждой загрузке машины  предназначены провизионеры Vagrant с типом запуска always. Но в данном случае они не подходят. Дело в том, что Vagrant взаимодействует с гостевой машиной Linux через ssh-соединение, а запуск интерактивных приложений через ssh доставляет слишком много сложностей и вносит нестабильность в систему (хотя такая возможность всё же существует и даже будет рассмотрена далее в этой публикации).

Для решения этой задачи нам подойдут механизмы автозапуска используемого в Linux графического окружения. В нашем случае это механизмы автозапуска Gnome. Конечно, если для своей сборки Вы решите использовать что-то более легкое и подходящее для целей CI, например LXDE или XFCE, то нужно будет адаптировать используемые далее команды.

Итак, возьмем за основу команду запуска агента, которую предлагает сам Jenkins

java -jar   agent.jar  -jnlpUrl http://HOST:8080/computer/ubuntu-interactive-4/slave-agent.jnlp -workDir "/home/vagrant/jenkins_agent/workdir"

и слегка модифицируем её, чтобы передавать основные составляющие как параметры:

 

jenkins_server=$host_machine_ip_or_hostname:$jenkins_port

java -Dfile.encoding=UTF-8 -jar agent.jar -jnlpUrl http://$jenkins_server/computer/$node_name/slave-agent.jnlp -workDir $jenkins_agent_dir 2>&1 | tee agent_console.log

 

 

Здесь же можно решить вопрос с обновлением агента. У нас включена возможность анонимного чтения с сервера Jenkins, поэтому для обновления агента достаточно выполнить команду загрузки агента с сервера Jenkins:

 

 wget -q -O agent_new.jar http://$jenkins_server/jnlpJars/agent.jar && mv agent_new.jar agent.jar

 

 

Но так как нам необходимо сформировать командный файл, который будет выполняться после запуска графической оболочки, то поместим все эти команды в файл .sh  (в данном случае он называется start_jenkins_node.sh) и укажем системе, что этот файл является исполняемым выполнив команду chmod u+x имя_sh_файла:

 

 

wgetCommand="wget -q -O agent_new.jar http://$jenkins_server/jnlpJars/agent.jar && mv agent_new.jar agent.jar"

startAgentCommand="java -Dfile.encoding=UTF-8 -jar agent.jar -jnlpUrl http://$jenkins_server/computer/$node_name/slave-agent.jnlp -workDir $jenkins_agent_dir 2>&1 | tee agent_console.log"

 

echo "cd $jenkins_agent_dir" > start_jenkins_node.sh

echo "sleep 15" >> start_jenkins_node.sh

echo "$wgetCommand" >> start_jenkins_node.sh

echo "$startAgentCommand" >> start_jenkins_node.sh    

 

chmod u+x start_jenkins_node.sh

 

 

После этого остаётся прописать запуск файла в механизмах автозапуска Gnome, сформировав файл нужного формата с расширением .desktop. Имя файла при этом может быть любым, главное чтобы он располагался в подкаталоге .config/autostart домашнего каталога пользователя и имел указанное расширение:

 

 cd $HOME

 mkdir -p .config/autostart

 cd .config/autostart

 

 echo [Desktop Entry] > autostart_jenkins_node.desktop

 echo Name=AutostartJenkinsNode >> autostart_jenkins_node.desktop

 echo Exec=$jenkins_agent_dir/start_jenkins_node.sh >> autostart_jenkins_node.desktop

 echo Terminal=false >> autostart_jenkins_node.desktop

 echo Type=Application >> autostart_jenkins_node.desktop

 echo X-GNOME-Autostart-enabled=true >> autostart_jenkins_node.desktop

 

 

Итоговый файл скрипта помещен в репозиторий:  jenkins_node_configure.sh

Примеры автоматически генерируемых файлов автозапуска и скрипта для запуска агента в репозитории не хранятся, поэтому посмотрим на них здесь. Файл автозапуска должен получаться таким:

     [Desktop Entry]

     Name=AutostartJenkinsNode

     Exec=/home/vagrant/jenkins_agent/start_jenkins_node.sh

     Terminal=false

     Type=Application

     X-GNOME-Autostart-enabled=true
 

 

Файл запуска агента /home/vagrant/jenkins_agent/start_jenkins_node.sh при этом будет иметь такое содержимое:

 

    cd /home/vagrant/jenkins_agent

    sleep 15

    wget -q -O agent_new.jar http://ИМЯ-СЕРВЕРА:8080/jnlpJars/agent.jar && mv agent_new.jar agent.jar

    java -Dfile.encoding=UTF-8 -jar agent.jar \
        -jnlpUrl http://ИМЯ-СЕРВЕРА:8080/computer/ubuntu-interactive-1/slave-agent.jnlp \
        -workDir /home/vagrant/jenkins_agent 2>&1 | tee agent_console.log

 

Теперь остаётся только обеспечить запуск командного файла jenkins_node_configure.sh из Vagrantfile при первом развертывании машины. В провизионере с типом shell  через параметр path можно указать путь к файлу, который будет скопирован в виртуальную машину и запущен в ней. Используя выражение Dir.pwd можно указать путь к файлу, относительно текущего каталога.

Переменные окружения, действующие в Vagrantfile нельзя передать в виртуальную машину напрямую. Но можно передать их в скрипт как параметры. Для этого существует параметр args. В sh-скрипте jenkins_node_configure.sh, который мы рассматривали выше к ним можно будет обратиться через знак доллара:

 

 

 host_machine_ip_or_hostname=$1

 jenkins_port=$2

 node_name=$3

 

 

Таким образом код провизионера в Vagrantfile будет следующим:

 

    config.vm.provision "Configuring and starting Jenkins node", type: "shell", run: $initRunType do |s|

        s.path = Dir.pwd+"/../jenkins_node_configure.sh"

        s.args = "#{ENV['host_machine_ip_or_hostname']} #{ENV['jenkins_port']} #{ENV['node_name']}"

        s.privileged = false

    end

 

 

Также будет удобно иметь возможность выводить диагностическое сообщение об успешном запуске по требованию запускающих развертывание механизмов. Не будем выводить это сообщение каждый раз, но сделаем возможность выводить из запускающего Vagrantfile командного файла по требованию. Для этого укажем тип запуска "never":

 

    config.vm.provision "CheckJenkinsNode", type: "shell", run: "never" do |s|

        $checkJenkinsAgentScript =<<-SCRIPT

        sleep 30

        echo "Output of ps aux | grep agent.jar must contain information about running jenkins agent."

        echo "If there is no such information then maybe Jenkins server or Jenkins agent is stopped:"

        ps aux | grep agent.jar

        SCRIPT

        s.inline = $checkJenkinsAgentScript

    end

 

 

В файл vagrant-up-destroy-common.bat теперь следует добавить строку

vagrant provision --provision-with CheckJenkinsNode

для вывода диагностического сообщения в консоль:

 

 if %vagrant_action%==up (

     vagrant up

     vagrant provision --provision-with CheckJenkinsNode

 ) else if %vagrant_action%==destroy (  

     vagrant destroy -f && rmdir /s /q .vagrant

 )

 

 

 

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

 

 

Итак при первом развертывании виртуальной машины мы настроили обновление агента Jenkins с хостовой машины и его запуск при логоне пользователя. Но сразу после первой загрузки (первого развертывания машины) агент не был запущен.

Как обеспечить его запуск, при том, что Vagrant устанавливает с виртуальной машиной только ssh-соединение и не может взаимодействовать с графическим окружением?

Варианта два:

1)  Обеспечить ssh-подключению доступ к дисплею. Эта возможность доступна только при использовании X Window System и не может применяться в получающем всё большее распространение Wayland. Для того чтобы обеспечить такую возможность достаточно выполнить команду export  DISPLAY=:0. Точнее, более правильной будет являться команда export DISPLAY=:$(echo $DISPLAY | cut -d. -f1 | cut -d: -f2), учитывающая то что номер дисплея может быть не равен нулю. Подробнее про это Вы можете прочитать вбив в поисковики ключевые слова SSH, export и DISPLAY. Тема довольно интересная.

2)  Второй вариант - просто перезагрузить операционную систему. Автологон у нас уже настроен, автозапуск скрипта при логоне тоже. После перезагрузки узел сможет сам подключиться к серверу Jenkins.

 

Оба варианта по своему хороши. Но так как в процессе развертывания машины мы вносили в нее существенные изменения - меняли имя хоста, настройки сервера 1С, а теперь еще и настроили автологон, то более правильным способом кажется именно перезагрузка машины. Это позволит убедиться, что все изменения сделаны корректно. А если нет - то мы об этом узнаем сразу, а не тогда когда нужно будет выполнить какое-то срочное действие в будущем, но окажется, что настройки некорректны и нужно сначала исправить какую-то ошибку.

Для перезагрузки машины существует команда vagrant reload, которую нужно добавить в наш общий командный файл vagrant-up-destroy-common.bat. Но при этом перезагрузка нужна не всегда, а только при первом развертывании.

Будем считать (и соответственно организовывать работу), что после уничтожения узла мы также удаляем каталог .vagrant виртуальной машины. А если каталог существует, то это означает, что машина уже развернута и остается ее только запустить. Это важный момент. Если при развертывании возникнет ошибка, то прежде чем повторять попытку развертывания нам необходимо будет выполнять командный файл vagrant-destroy.bat из каталога узла, и только потом снова выполнять vagrant-up.bat.

 

В файл vagrant-up-destroy-common.bat внесем следующие изменения:

1)  Будем формировать текст команды, выполняемой после развертывания машины, в зависимости от наличия каталога .vagrant. Если каталог есть, то выведем в консоль сообщение о том, что перезагрузка не требуется. Если же каталога нет, то команда будет перезагружать машину:

 

 if not exist .vagrant (

     SET vagrant_reload_command=vagrant reload

 ) else (

     SET vagrant_reload_command=echo It is not the first start, no need to reload machine

 )

 

 

2)  Если файл vagrant-up-destroy-common.bat вызывается из командного файла vagrant-up.bat, то затребовано действие "up". В этом случае вставим новую команду сразу после вызова vagrant up. Если же файл вызывается из командного файла vagrant-destroy.bat , то будет затребовано действие "desstroy". В этом случае  у нас уже предусмотрено удаление каталога .vagrant после вызова vagrant destroy:

 

 if %vagrant_action%==up (

 

     vagrant up

     %vagrant_reload_command%

     vagrant provision --provision-with CheckJenkinsNode

 

 ) else if %vagrant_action%==destroy (

 

     vagrant destroy -f && rmdir /s /q .vagrant

 )

 

 

Теперь все файлы для Packer и Vagrant приобрели свой окончательный вариант и можно перейти к проверке результата.

 

 

Проверка подключения

 

Проверим подключение узлов к серверу Jenkins. Завершим работу виртуальных машин. Если ранее они уже были подключены к Jenkins, то через некоторое время Jenkins поймет что узлы отключены и изменит статусы узлов в своем интерфейсе. После этого снова запустим машины и подождем из загрузки.

 

После загрузки постепенно отрабатывают скрипты запуска и агенты один за другим подключаются к серверу Jenkins:

 

 

Пример распределения задач по узлам CI-сервера

 

 

Создадим первую тестовую задачу, которая нужна только для того, чтобы проверить подключение к подчиненному узлу Jenkins. Сейчас на смысле выполняемых действий можно не сосредотачиваться - особенностям разработки пайплайнов будет посвящена следующая публикация. В этот раз нам нужно только проверить подключение и возможность запуска интерактивных приложений через агента Jenkins максимально простым способом.

В веб-интерфейсе Jenkins выберем "New Item":

Затем укажем тип "Pipeline". Это тип задач в которых необходимые действия можно задавать программным кодом. И укажем имя задачи connection_test:

 

В открывшемся окне настройки задачи укажем такой простейший код пайплайна:

 

pipeline {

    agent {label "ubuntu_interactive" }

    stages {

        stage('Connection test') {

            steps { script {

             
                sleep 15

                sh "code"

                sh "/opt/1C/v8.3/x86_64/1cv8"
               

            }}

        }
    }    
}

 

Здесь строкой agent {label "ubuntu_interactive"}  мы сообщаем Jenkins, что задача должна запускаться только на узлах с меткой ubuntu_interactive.

Сохраним задачу и запустим ее несколько раз. На узлах где один сборщик - запустится только одна задача за раз, следующая будет запущена только после завершения предыдущей, выполняющийся на том же узле:

 

Если задать другую метку: agent {label "starter"}, то задачи будут назначаться на узел, где у нас несколько потоков исполнителей (так мы настраивали узел ubuntu-interactive-1, предполагающий наличие нескольких потоков-сборщиков). И параллельно будут исполняться несколько задач:

 

 

 

 

Архивация настроек узлов и задач, включение их в состав репозитория

 

 

В случае установки Jenkins на Windows, настройки его задач хранятся в xml файлов в каталоге C:\Program Files (x86)\Jenkins\jobs, а настройки узлов в каталоге каталогах  C:\Program Files (x86)\Jenkins\nodes.

Создадим для наших задач отдельную папку через интерфейс Jenkins. Для этого в интерфейсе новой задачи выберем тип Folder, в следующем окне достаточно сохранить данные не внося в них никаких изменений:

 

Теперь уже в этой папке создадим четыре задачи с типом Pipeline:

  •  main_build - эта задача будет отвечать за основной процесс тестирования
  •  dump_storage_version_to_cf_file - будет отвечать за выгрузку хранилища в cf-файлы
  •  starter_for_main_build - будет запускать основную задачу тестирования
  •  create_test_database_image - будет осуществлять подготовку образа тестовой базы  

Эти задачи будем использовать в дальнейшем для всех остальных примеров. Никаких настроек и кода пайплайнов в них сейчас можно не задавать, сейчас они нам нужны только для настройки архивации задач и узлов и проверки этого механизма архивации:

Когда для задач создается отдельная папка, то для этой папки создается отдельный подкаталог в C:\Program Files (x86)\Jenkins\jobs. В нем помимо конфигурации самой папки (файла config.xml) будет находиться еще один подкаталог jobs и уже в него будут помещаться данные отдельных задач:

 

 

Все настройки сохраняется в файлах config.xml. Состав тегов и данных в этом файле определяется составом плагинов. Поэтому например настроив автоматическое архивирование этих файлов,  не всегда целесообразно автоматизировать их обратное копирование в каталог установки Jenkins. Лучше выполнять это обдуманно, убедившись, что все нужные плагины были настроены.

Чтобы обеспечить архивацию этих данных и сохранение их в репозитории достаточно скопировать их в отдельный каталог репозитория с сохранением иерархии каталогов.  Для этого достаточно очень простого скрипта:

 

 chcp 65001

 

 SET APACHE_PATH=C:/Apache24

 SET JENKINS_PATH=C:/Program Files (x86)/jenkins

 SET JENKINS_JOBS_FOLDER_NAME=ci_for_1c

 

 SET EXTERNAL_CONF_DIR=%~dp0/external_configuration_files

 SET JOBS_FOLDER_SOURCE_PATH=%JENKINS_PATH%/jobs/%JENKINS_JOBS_FOLDER_NAME%

 SET JOBS_FOLDER_DESTINATION_PATH=%EXTERNAL_CONF_DIR%/jenkins/jobs/%JENKINS_JOBS_FOLDER_NAME%

 

 rm -rf "%EXTERNAL_CONF_DIR%/jenkins"

 mkdir "%EXTERNAL_CONF_DIR%/jenkins/nodes"

 mkdir "%JOBS_FOLDER_DESTINATION_PATH%"

 

 cp "%JENKINS_PATH%/jenkins.xml" "%EXTERNAL_CONF_DIR%/jenkins/jenkins.xml"

 cp -a "%JENKINS_PATH%/nodes/." "%EXTERNAL_CONF_DIR%/jenkins/nodes"

 cp "%JOBS_FOLDER_SOURCE_PATH%/config.xml" "%JOBS_FOLDER_DESTINATION_PATH%/config.xml"

 

 for /F %%i IN ('ls -1 "%JOBS_FOLDER_SOURCE_PATH%/jobs"') DO (

     mkdir "%JOBS_FOLDER_DESTINATION_PATH%/jobs/%%i"

     cp "%JOBS_FOLDER_SOURCE_PATH%/jobs/%%i/config.xml" "%JOBS_FOLDER_DESTINATION_PATH%/jobs/%%i/config.xml"

 )

 

 rm -rf "%EXTERNAL_CONF_DIR%/apache"

 mkdir "%EXTERNAL_CONF_DIR%/apache"

 cp "%APACHE_PATH%/conf/httpd.conf" "%EXTERNAL_CONF_DIR%/apache/httpd.conf"

 

 

Здесь rm  и cp  - это утилиты из пакета git для Windows. Напоминаю, что путь к этим командам обязательно должен быть указан в переменной PATH в хостовой операционной системы.

За одно здесь выполняется архивирование основного конфигурационного файла Jenkins и файла конфигурации Apache.

Для восстановления узлов и задач на другом сервере достаточно выполнить bat-файл со следующими командами:

 

 chcp 65001

 SET EXTERNAL_CONF_DIR=%~dp0\external_configuration_files

 SET JENKINS_PATH=C:\Program Files (x86)\jenkins

 

 cp -a "%EXTERNAL_CONF_DIR%\jenkins\nodes\." "%JENKINS_PATH%\nodes"

 cp -a "%EXTERNAL_CONF_DIR%\jenkins\jobs\." "%JENKINS_PATH%\jobs"

 

 

После чего перезапустить службу Jenkins. Данный командный файл, также входит в состав репозитория, поэтому если Вы не хотите повторять создание узлов и задач вручную, то можете проверить его работу на своей машине.

 

На этом работа с репозиторием, хранящим код сборки образа и развертывания виртуальных машин, закончена. В него сделан последний коммит:  

Больше вносить изменения в него не потребуется, так как инфраструктура для нашего CI-контура фактически готова.

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

 

В следующих раз продолжим рассматривать функционал Jenkins. Поговорим про синтаксис пайплайнов, взаимодействие модулей (скриптов), подходы к хранению настроек, возможности переиспользования кода (за счёт создания общих модулей). Это будет временный переход от практики к теории, чтобы лучше понимать, как именно работает Jenkins и научиться писать пайплайны с минимальным привлечением внешних инструментов. Ведь под капотом у Jenkins полнофункциональная Java-машина!

 

Если Вы поделились ссылкой на публикацию с коллегами - большое спасибо! ;)  Ведь им тоже может быть интересна тема CI и повышения качества разработки на платформе 1С ))

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 13.03.20 13:10
(0) плюсы доставлены!

А откуда взялся минус у публикации - загадка...
newgluk; awk; Vladimir Litvinenko; +3 Ответить
2. Vladimir Litvinenko 2786 13.03.20 13:46 Сейчас в теме
(1) Спасибо! ))
Ну может быть случайно минус прилетел. Или заглавная картинка не понравилась )) На это у каждого есть право, иначе оценка публикации будет необъективной.
3. nonofusafree 14.03.20 11:24 Сейчас в теме
(0) спасибо большое за труды и старания. Пытаюсь изучать, но пока опыта не хватает.

Но буду меняться :)
Vladimir Litvinenko; +1 Ответить
4. Vladimir Litvinenko 2786 14.03.20 15:41 Сейчас в теме
(3) Если будут возникать сложности - спрашвайте. Здесь в принципе довольно пошаговые руководства и открытый репозиторий на Гитхабе, но если тема совсем незнокомая, то конечно возможны сложности.

Вопросы и уточнения позволят сделать лучше либо код, либо статьи )
5. wild83 15.03.20 22:23 Сейчас в теме
Сломал скролл пока листал
6. Vladimir Litvinenko 2786 16.03.20 01:01 Сейчас в теме
(5) Ну да, эти публикации для тех, у кого надёжное колесо мышки и накаченный палец )) Дальше ещё будет.

Была мысль по традиции ограничиться несколькими скриншотами с пушистыми котиками красивыми графиками и цветными круглешками, чем заработать кучу звёздочек. Но потом ударился головой и подумал, что была ни была - надо подробно тему расписать да кодом поделиться ))
eufes; AlexK_2012; adapter; sashocq; +4 Ответить
7. hr-orel 16.04.20 15:49 Сейчас в теме
Использую для подключения узлов к мастеру swarm-plugin. Когда машин и узлов много, это удобнее.
8. Andrei_Zoteev 03.09.20 11:00 Сейчас в теме
Спасибо за статью! Как всегда подробно и познавательно!
Одна из ссылок на канал Кирилла Семаева битая.
9. user1917873 05.03.23 11:49 Сейчас в теме
Всем привет.
С основными настройками Jenkins-а особых проблем нет.

Но, не получается настроить удалённое подключение из браузера.
В какую сторону смотреть?
Оставьте свое сообщение

См. также

Управление сборкой. Расширение для конфигурации СППР

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664

7000 руб.

26.08.2022    6656    3    5    

23

Получаем статистику по git-репозиторию в разрезе разработчиков

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Итак! Представим, что наступил момент, когда разработка через исходный код реализована на предприятии в полном объеме. Мы разрабатываем в EDT или конфигураторе (но выгружаем конфигурацию в исходный код), версионируем внешние отчеты и обработки и расширения, собираем релизы, проверяем код статическим анализом, в разработке царит гармония и мир. Красота! Но менеджерам этого мало, всегда хочется чего-то еще, и вот мне прилетает задача - дай статистику по вкладу в код каждого разработчика.

13.03.2023    1151    ardn    3    

25

SonarQube: про объемы, ветки, покрытие кода и интеграцию с Gitlab

DevOps и автоматизация разработки Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Опыт применения SonarQube в нескольких командах. Плюс некоторые тонкости: уменьшение объемов базы SQ, интеграция, покрытие кода.

26.02.2023    2525    kraynev-navi    10    

47

DevOps для Плейстоцена. Скрещивание обычных форм толстого клиента с практиками CI/CD

DevOps и автоматизация разработки Бесплатно (free)

Плейстоцен — эпоха четвертичного периода, начавшаяся 2.588 миллионов лет назад и закончившаяся 11,7 тысяч лет назад. В 1С этот период характеризуется обычными формами, использованием толстого клиента и вызовом «Предупреждение» без таймаутов прямо из модулей проведения документов. О том, как внедрять инженерные практики для огромного монолита легаси и тестировать функциональность без менеджера и клиента тестирования под разными пользователями, на конференции Infostart Event 2021 Moscow Premiere рассказал ведущий программист компании BCS FinTech Сергей Голованов.

20.02.2023    1504    Golovanoff    17    

16

Подсценарии для заполнения форм типовых справочников и документов конфигураций ERP 2.5 и КА 2.5 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Набор универсальных подсценариев для заполнения форм типовых объектов справочников и документов конфигураций ERP 2.5 и КА 2.5. Сценарии представляют собой feature-файлы для vanessa-automation с тегом @exportscenarios. Используются для разработки функциональных сценариев.

1500 руб.

26.01.2023    2011    0    0    

1

Жизнь платформы 1C:Предприятие в кластере Kubernetes

Сервера DevOps и автоматизация разработки Облачные сервисы, хостинг Бесплатно (free)

Во многих сферах запуск приложений в Kubernetes является де-факто стандартом архитектуры, так как это позволяет быстро и эффективно задействовать ресурсы, не затрачивая на это большие деньги. Но с платформой 1С:Предприятие не все так просто, но потенциально возможно. Руслан Жданов на митапе «DevOps в 1С: CI/CD. Непрерывная интеграция и поставка решений на 1С» рассказал про то, как с помощью Kubernetes организовать в облаке управление кластером из серверов 1С и реализовать там тестирование приложений на 1С или запуск скриптов на OneScript.

24.01.2023    6065    ZhdanovR    3    

25

Концепция ландшафта 1С-систем на предприятии

DevOps и автоматизация разработки Управление ИТ-подразделением Бесплатно (free)

Визуализация размещения программных ресурсов и сервисных данных 1С-систем в корпоративном ландшафте. Как 1С-службе и ИТ-службе договориться о разграничении, получить свободу для своих задач и сохранить порядок во взаимодействии.

09.12.2022    1379    roman72    13    

7

Прокси хранилища 1С (IIS, OneScript)

Групповая разработка (Git, хранилище) OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Россия Бесплатно (free)

Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript.

08.12.2022    5408    kamisov    31    

84

Что, если Continuous Integration – это прежде всего практика, а не набор инструментов?

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free)

Рано или поздно многие компании приходят к практикам DevOps. И начало этому – Continuous Integration. О том, что происходит в команде специалистов 1С, когда они переходят на Git, и почему простое внедрение CI-инструментов не решает проблему подходов к разработке, в докладе на Infostart Event 2021 Post-Apocalypse рассказал руководитель компании ПрогТехБизнес Александр Анисков.

07.12.2022    1587    vandalsvq    0    

23

Управление хранилищами без боли

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free)

Когда хранилищ много, возникает вопрос удобного управления ими. Андрей Овсянкин на онлайн-митапе «Инструменты автоматизации рутины в 1С-разработке» рассказал, как настроить перенос хранилища на новую версию платформы без перепрописывания путей у каждого разработчика, и как безболезненно обеспечить для хранилища запрет коммита с пустым комментарием.

28.11.2022    6971    Evil Beaver    12    

90

Гонка конфигураторов с помощью экзекутора

Инструментарий разработчика DevOps и автоматизация разработки Механизмы платформы 1С Платформа 1С v8.3 Абонемент ($m)

Выгружать конфигурацию в файлы в последнее время стало супер модно. Контроль версий, Git, CI/CD и вот это вот все. Исходники как тексты сегодня нужны всем. Но возникают вопросы: а каким методом лучше и быстрее выгружать конфигурацию в файлы, а какая версия платформы справляется с этой задачей оперативнее? Моя статья постарается ответить на эти вопросы. Как говорится, заставим попотеть ваши конфигураторы. С помощью 1С Исполнителя 2.0 мы выгрузим конфигурацию ЗУП, используя платформу пяти версий, от 8.3.18 до 8.3.22.

1 стартмани

16.11.2022    3549    infosoft-v    40    

44

Как избавиться от большого количества комментариев в коде с использованием EDT + Git

Рефакторинг и качество кода DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Публикация освещает вопрос улучшения качества и читабельности кода путем отказа от излишних комментариев. Рассматривается пример из опыта работы команды разработки на EDT + Git. Команда работает в EDT меньше года. Конфигурация сильно доработана и не обновляется типовыми релизами.

15.11.2022    1141    shastin87    5    

9

Автоматизация обновления до последнего релиза

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Это механизм, который автоматически обновляет базы 1С до последнего релиза, при разработке в 1С:Enterprise Development Tools c использованием распределённой системы управления версиями GIT.

1 стартмани

28.10.2022    2678    2    Knup    0    

5

Быстрое обновление базы 1С из XML-файлов конфигурации (EDT-GIT)

DevOps и автоматизация разработки EDT Обновление 1С Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Быстрое обновление конфигурации и базы данных 1С, вместо долгого обновления из EDT (1C:Enterprise Development Tools) при использовании хранилища GIT. Непосредственное обновлении базы на сервере баз данных (минуя сервер 1С) из XML-файлов конфигурации при помощи утилиты автономного сервера 1С - ibcmd.

1 стартмани

13.07.2022    9321    7    Bitnikov    19    

51

Улучшайзер - как одна внешняя обработка может улучшать другие внешние обработки

Универсальные обработки Инструментарий разработчика Идеи и тренды в разработке DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В публикации описывается технология использования специальной внешней обработки ("Улучшайзера") для улучшения (модификации) других внешних обработок. При этом каждому пользователю обработки нужен свой уникальный набор улучшений, и он (пользователь) не хочет/не умеет/не собирается (нужное подчеркнуть) лезть в Конфигуратор и/или просить помощи у 1С программиста.

08.07.2022    5143    86    delta    2    

21

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.8.321.

2004 руб.

04.07.2022    4019    3    0    

12

Быстро в Jenkins

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Написать свою сборочную линию для решения на 1С – задача нетривиальная: собрать конфигурацию из исходников, конвертировать между форматами, запустить множество инструментов, агрегировать результаты, сформировать отчеты... А хочется ведь просто ЗапуститьСвоюСборку()... Можно? Можно! О том, как создать сборочную линию за 5 минут в формате «Далее-далее-готово» на конференции Infostart Event 2021 Moscow Premiere рассказал Никита Федькин.

21.06.2022    7051    nixel    49    

82

APDEX 1C + Prometheus + Grafana + Superset, а точнее наоборот

DevOps и автоматизация разработки Платформа 1С v8.3 Россия Бесплатно (free)

Вы не задумывались о том, что расчет APDEX должен быть онлайн? Онлайн для всех - от бизнес-пользователей до команды разработки. Если задумывались - то в статье мы расскажем, зачем это делать, и поделимся наработками, как подключить 1С+APDEX к такой штуке, как Prometeus.

16.02.2022    7844    digital-samolet    42    

97

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.126.18, 3.0.129.13.

1728 руб.

20.01.2022    4770    1    0    

4

Как Gitlab-CI и OneScript могут отсортировать массив (Часть 2)

DevOps и автоматизация разработки Бесплатно (free)

Продолжение сквозного примера настройки Gitlab-CI - вывод результатов теста, условия запуска и таймауты.

12.12.2021    2505    SaschaG    4    

16

Как Gitlab-CI и OneScript могут отсортировать массив (Часть 1)

DevOps и автоматизация разработки Бесплатно (free)

С приходом в 1С EDT мы получили git. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который все сделает сам. Надо только правильно его попросить...

18.11.2021    4138    SaschaG    9    

74

Автообновление конфигурации после обмена

Архивирование (backup) DevOps и автоматизация разработки Обмен между базами 1C Платформа 1С v8.3 Украина Абонемент ($m)

Рабочий механизм автоматического обновления конфигурации "периферийной" базы после получения пакета обмена. Перед обновлением выполняется резервное копирование базы данных.

1 стартмани

02.09.2021    5236    2    Volvo32    1    

4

Как начать разработку проекта 1С, чтобы легко перейти к DevOps-практикам

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Многие рутинные операции при работе над проектом 1С можно автоматизировать – довериться готовым инструментам и уменьшить количество нажимаемых кнопок. О том, как с помощью готового шаблона проекта настроить окружение для разработки на митапе «DevOps в 1С» рассказал технический директор Инфостарта Артур Аюханов.

22.06.2021    8921    artbear    2    

72

Микросервисы на Golang. Часть 6. Докеризация, Начальная оркестрация, CD\CI

DevOps и автоматизация разработки Конфигурации 1cv8 Бесплатно (free)

Создадим микросервис, поместим его в докер, проведем его масштабирование на нескольких виртуальных машинах с помощью оркестрации Docker Swarm, выполним также CD\CD микросервиса с помощью GitHub Action (Микросервис взят с прода, обрезан лишний функционал) будет показан пример его взаимодействия с 1С клиентом.

21.06.2021    3103    dmitry-irk38    3    

6

Docker для 1Сника

DevOps и автоматизация разработки Платформа 1С v8.3 Бесплатно (free)

На онлайн митапе «DevOps в 1С» Руслан Жданов рассказал, для чего 1С-нику нужен Docker, как его применять, какие сервисы можно вынести в контейнеры и как организовать взаимодействие контейнеров друг с другом.

07.06.2021    13778    ZhdanovR    34    

42

Осторожный DevOps

DevOps и автоматизация разработки Платформа 1С v8.3 Бесплатно (free)

Начальник отдела разработки в компании «Билайн» Игорь Сухоруков на Meetup Infostart DevOps поделился особенностями работы своего ИТ-подразделения и рассказал о том, как устроено производство и внедрение ПО в режиме нон-стоп в компании, подразделения которой работают по всей России: от Москвы до Владивостока.

24.05.2021    4174    ig1082    4    

32

Ненавязчивая локальная разработка с traefik2, docker и letsencrypt

Групповая разработка (Git, хранилище) DevOps и автоматизация разработки Бесплатно (free)

Перевод статьи по проксированию HTTP траффика до сервисов развернутых в docker контейнерах. Оригинал от 24.09.2020.

16.05.2021    5485    malikov_pro    0    

8

Шпаргалка установки сервера взаимодействия без MSI(9.0.33) использованием Postgresql в docker-compose

DevOps и автоматизация разработки Платформа 1С v8.3 Бесплатно (free)

Какой бы не был бизнес - он нуждается в коммуникации. У кого-то Telegram, у других - Whatsapp, у кого то - электронные письма. Возникла задача наладить общение между пользователями базы 1С без мессенджеров. Скачав самую свежую версию на момент написания статьи 9.0.33, обнаружились некоторые подводные камни при установке.

07.04.2021    3046    yaroslavkravets    2    

24

Тестируем в Docker

DevOps и автоматизация разработки Бесплатно (free)

Чтобы продукт гарантированно отвечал функциональным требованиям, нужно писать для него тесты и часто их запускать. О том, через какие этапы проходит компания, которая хочет автоматизировать тестирование – от одного клиента на локальной машине до запуска тестов по запросу в Kubernetes, на INFOSTART MEETUP Ekaterinburg.Online рассказал Андрей Крапивин.

29.03.2021    8187    Scorpion4eg    8    

53

Полный пример запуска 1С в докере (Linux)

DevOps и автоматизация разработки Платформа 1С v8.3 Абонемент ($m)

Описание примера запуска сервера 1С в докере на CentOS 7. Содержит архив со скриптами и последовательность шагов для запуска тестового сервера (Сервер, Клиент, Web и простой консоли управления информационными базами).

1 стартмани

26.01.2021    24076    54    uasy_user611066    13    

35

1С on demand – скажи "нет" постоянным билд-агентам

DevOps и автоматизация разработки Бесплатно (free)

Каждый, кто пытался запускать на своем компьютере тесты для 1С, сталкивался с тем, что процесс тестирования не позволяет что-то делать параллельно. О том, как изолировать тестовые окружения и организовать «Агент по запросу» с помощью Docker на примере Jenkins CI, рассказал ведущий разработчик компании «Первый БИТ» Никита Грызлов.

25.01.2021    5755    nixel    12    

68

DevOps: бери и делай!

DevOps и автоматизация разработки Бесплатно (free)

В последнее время тема DevOps становится актуальной благодаря бесплатным инструментам автоматизации для проектов на 1С. О том, как вести разработку по DevOps и какие при этом могут возникнуть проблемы и сложности, рассказал разработчик Инфостарта Павел Олейников.

15.01.2021    5935    OPM    2    

38

SQLPad для удобной работы с запросами к SQL серверу

DevOps и автоматизация разработки Абонемент ($m)

В этой статье описывается веб-приложение SQLPad для работы с запросами к SQL серверу.

1 стартмани

11.01.2021    4519    ardn    5    

60

Практика применения DevOps. Автоматизированная сборочная линия

DevOps и автоматизация разработки Бесплатно (free)

В четвертой части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Валерий Пронин. Он рассказал, как развернуть автоматизированную сборочную линию, которая будет контролировать качество кода в проекте и в зависимости от прохождения порога отдавать релиз в виде cf-файла либо отправлять письмо об ошибках.

16.12.2020    8034    proninvvp    5    

65

Devops на коленке, или Иногда стоит отказаться от gitsync

DevOps и автоматизация разработки Платформа 1С v8.3 Россия Абонемент ($m)

В этой публикации описывается опыт выгрузки конфигурации в исходный код, ускорение выгрузки за счет отказа от использования gitsync в пользу своего решения.

1 стартмани

08.12.2020    2076    ardn    2    

28

Практика применения DevOps. Автоматизация процессов разработки, инструментарий и работа с Git

DevOps и автоматизация разработки Бесплатно (free)

Автоматизация процессов разработки с применением DevOps-практик помогает получать более качественный и осмысленный результат. На конференции Infostart Event 2019 Inception в ходе мастер-класса «Практика применения DevOps» команда Инфостарта разложила «по полочкам» инструментарий, который используется для каждого из процессов DevOps, и показала, как работать с ними на практике. В первой части выступил Павел Олейников – он сделал обзор инструментов, которые можно использовать при автоматизации процессов разработки, и рассказал про работу с Git (в том числе в EDT).

03.12.2020    6663    OPM    3    

45