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

25.01.21

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

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

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

 

Слайд3.JPG

 

Какие тесты вообще могут у нас быть?

Тесты условно можно разделить на три группы:

  • Smoke-тесты (дымовые тесты). Это какие-то обработки или скрипты, которые выполняют рутинные действия над вашей конфигурацией – открывают все формы, пытаются провести все документы. На основании этих действий вы можете понять, есть у вас какие-то ошибки в базовой функциональности или нет.

  • Модульные тесты служат для проверки маленьких компонентов системы. Например, проверить что вызов функции с определенными параметрами вернет ожидаемый результат.

  • BDD или сценарные тесты. Если говорить про 1С, то чаще всего под сценарными тестами подразумевается нажатие кнопок на интерфейсе и проверка того, что на форме отображаются правильные данные – например, что документ провелся корректно, без сообщений об ошибок, всплывающих окон и т. д. Но это не всегда так. Есть классический пример сценарного теста выглядящий так: «Если у меня на счету 300 долларов и я подхожу к банкомату и пытаюсь снять 200 долларов, тогда банкомат дает мне 200 долларов наличными». Это тоже сценарий, все это тоже можно автоматизировать и переложить в тесты.

 

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

 

Слайд4.JPG

 

Какие могут быть проблемы, когда вы пытаетесь запустить эти тесты?

  • Когда вы на своей рабочей машине запускаете тестирование с помощью какого-либо фреймворка (например, это может быть Vanessa Automation), и параллельно пытаетесь писать код в своем любимом редакторе, то в какой-то момент – бац! У вас всплывает модальное окно, которое вы не можете закрыть, и вам приходится выполнять какие-то действия над ним, чтобы продолжить свою работу. Такие проблемы очень часто отвлекают. Ладно бы это всегда были просто окна, но могут быть вообще непонятные артефакты – куски выпадающих списков, отдельные кнопки, прорисовывающиеся сквозь ваш интерфейс.

  • Кто хоть раз пытался запустить на своем компьютере несколько экземпляров какого-либо тестового фреймворка, сталкивался с тем, что они начинают друг другу мешать. Несколько Vanessa Automation начинают воевать друг за друга – тест-менеджеры цепляют чужие тест-клиенты, инструменты снятия скриншотов захватывают не те окна.

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

 

Слайд5.JPG

 

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

Каким образом эту проблему можно решить?

 

Docker. Решение проблемы путем изоляции

 

Слайд6.JPG

 

Первый, и, наверное, самый простой вариант – это попытаться изолировать различные экземпляры запущенных приложений.

Есть расхожая шутка о том, что любую проблему вашего приложения можно решить, поместив его в Docker:

  • упали тесты - запихните приложение в Docker, они станут зелеными;

  • продалбываете сроки – запихните приложение в Docker;

  • не понятен список задач по проекту... Думаю, вы поняли общий смысл.

 

Слайд7.JPG

 

Что вообще такое Docker? Docker – это один из инструментов виртуализации.

Виртуализацию глобально можно разделить на два способа реализации.

  • Первый – это виртуальные машины. На самом нижнем уровне у вас есть какое-то железо, на этом железе стоит операционная система с гипервизором, который занимается тем, что запускает новые операционные системы, в которых уже выполняются ваши клиентские приложения.

  • Второй вариант – это контейнеризация. Мы убираем слой гипервизора и заменяем его на слой оркестратора контейнеров, работающих непосредственно поверх операционной системы. В качестве такого средства можно использовать движок Docker. И уже этот движок запускает отдельные изолированные экземпляры вашего приложения с необходимым окружением, необходимыми библиотеками, но без полноценного эмулирования операционной системы..

 

Docker Swarm. Реализация масштабирования

У Docker есть довольно простая встроенная возможность объединить несколько узлов, несколько ваших машин в так называемый Docker swarm cluster.

 

Слайд9.JPG

 

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

Менеджеры соединены с воркерами, которые выполняют задачи – по сути, запускают контейнеры, в которых выполняются приложения, скрипты и т. д.

 

Слайд10.JPG

 

Но все мы знаем, что все системы первоначально запускаются на локальной машине (до того, как у вас есть сервера), поэтому в самом простом варианте Docker Swarm у вас есть один менеджер и один-два воркера. Зачастую и воркеров нет, и вы все задачи запускаете сразу на менеджере. Docker Swarm такой режим тоже поддерживает.

 

Слайд11.JPG

 

Создать docker machine и включить ее в docker swarm cluster несложно – это можно сделать с помощью доступной на GitHub утилиты docker-machine, которая позволяет буквально в два скрипта создать docker swarm cluster и подключить к нему новую машину.

 

Слайд12.JPG

 

После создания docker machine вы также получите набор ключей и сертификатов, чтобы обеспечивать доступ и управление созданными docker machine с использованием TLS-аутентификации.

Те, кто пользуются Docker for windows, могли заметить в настройках системы галочку «Expose daemon on tcp://localhost:2375 without TLS» (публиковать службу на порту 2375 без TLS).

На реальных рабочих станциях или продакшен-контуре так делать категорически нельзя. Если вы будете использовать docker с этой галочкой, это значит, что абсолютно любой человек в локальной сети может постучаться на порт 2375 к вашей машине и запустить на ней абсолютно что угодно – например, запустить контейнер со смонтированным целиком корневым каталогом вашего диска, выполнить над файлами какие-то действия - скопировать их, зашифровать, удалить.

 

Система Cloud Provider. Агенты по запросу

Следующая технология, которая поможет нам в масштабировании – это система Cloud Provider.

 

Слайд14.JPG

 

Я думаю, вы слышали о Google Cloud, об Amazon Cloud – это некая система, в которую вы можете отправить запрос вида: «Дай мне виртуальную машину на два ядра и 4Гб оперативной памяти». Происходит некая магия, и через некоторое время вы получаете либо удаленный доступ к только что созданной виртуальной машине по SSH или RDP и можете начинать с ней работать.

 

Слайд15.JPG

 

Этот же подход Cloud Provider можно применять на вашем сервере сборок. Например, на Jenkins. У него есть довольно много вариантов подключения различных провайдеров – будь то просто Amazon, Google, Kubernetes или просто docker.

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

 

Docker Swarm plugin.

Если мы объединим концепции Cloud Provider и Docker Swarm и попытаемся применить ее к Jenkins, то мы можем найти плагин под названием Docker Swarm.

 

Слайд18.JPG

 

Его конфигурирование довольно простое – в настройках Jenkins появляется новая закладка, в которой вы указываете:

  • Docker Host URI – где у вас живет master вашего docker swarm cluster;

  • Server credentials – параметры подключения к нему.

И все, для подключения больше ничего не нужно.

Слайд19.JPG

 

Параметры подключения – это TLS-ключи и сертификаты, которые требуются для поднятия защищенного соединения. Файлы, которые создались после инициализации docker machine, вы можете положить в сохраненные значения и секреты Jenkins и использовать для авторизации.

 

Слайд20.JPG

 

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

Что можно сделать, когда у вас есть такой Cloud Provider?

Для начала вы можете запустить базовый агент на основе образа eeacms/jenkins-slave-dind (Docker in Docker), в котором можно выполнить произвольные команды, запустить другие docker-контейнеры или собирать docker-образы, в том числе для 1С.

Самое главное – это указать правильные параметры запуска. Страшный скрипт, который нарисован в центре, генерируется автоматически, не нужно его запоминать. Его можно подсмотреть в справке, доступной по нажатию на кнопку с синим знаком вопроса справа от поля, и просто скопировать.

 

Слайд21.JPG

 

Конечно же, вы можете использовать Docker, чтобы запускать в нем тесты. Вы можете создать docker-образ с 1С нужной вам версии, указать, его в качестве build-агента в настройках облачного провайдера docker swarm, настроить метку агента (например, под версию платформы). И теперь ваши тесты будут запускаться в Docker, причем в агенте, который будет подниматься только на тот промежуток времени, когда он вам нужен.

 

Сборочная линия Jenkinsfile в Docker для 1С

Как может выглядеть сборочная линия для 1С, которая запускается в Docker?

 

Слайд23.JPG

 

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

  • Вам нужно разобраться с тем, какие данные нужно передавать между различными шагами вашей сборки. Если вы работали с постоянным build-агентом, вы могли привыкнуть к тому, что если вы обратитесь по пути C:\jenkins\artifacts\somedata\file – то вы этот файл оттуда достанете. В случае Docker у вас такой возможности не будет, потому что у вас маленький изолированный контейнер, который ничего не знает про окружение, на котором он запустился, и про то, куда он может достучаться. Эту проблему нам могут помочь решить различные шаги архивации для передачи артефактов между шагами и между сборками.

  • Второй момент – это работа с внешними ресурсами. Docker обычно запускается в Linux-окружении на Linux-ядре, и в Linux есть определенные особенности по настройке сетевых путей. Если вы работаете с Windows, вы открываете проводник, пишете //ИмяКомпьютера/СетеваяПапка и она у вас сразу открывается. Если у вас есть доменная авторизация, вам даже никакой логин/пароль вводить не нужно. А в случае Docker вам нужно лезть в файлы с конфигурацией сетевых устройств, либо в файлы с конфигурацией автомонтирования и там прописывать пути, куда нужно стучаться, и куда это нужно монтировать, и параметры авторизации, и т.д. Одним из простых способов решения этой проблемы являтеся установка перед вашими статичными внешними ресурсами (внешними файлами, которые вам нужно вытащить) простенького HTTP-сервера (например, Nginx или Apache, если вы умеете его конфигурировать, или даже IIS), который и будет отдавать эти старичные данные по HTTP.

  • И третье – это, конечно же, нужно написать Dockerfile для 1С.

 

Слайд24.JPG

 

Сама сборочная линия выглядит довольно привычно для тех, кто хоть раз ее писал для 1С.

  • Мы говорим о том, что наша сборка выполняется на каком-то определенном агенте. В данном случае используется метка с версией платформы. Такую метку мы задали для нашего build-агента с docker-образом 1С.

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

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

 

Слайд25.JPG

 

На следующем шаге в этом примере организуется контроль качества.

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

  • на шаге «syntaxCheck» мы эту информационную базу разархивируем – кладем в определенный каталог и выполняем дальнейшие операции – например, запуск синтаксического контроля, который делает конфигуратор, но с выводом информации в формате JUnit, чтобы красиво отображать ее в Jenkins.

  • здесь же может быть шаг sonar, при желании - с передачей результатов из “1С:Автоматизированная проверка конфигурации”;

  • вы можете сразу запустить сценарные тесты;

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

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

 

Слайд26.JPG

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

Разархивация – это получение файла из stash и его распаковка в папку с информационной базой.

 

Проблемы самостоятельного создания Dockerfile для 1С

 

Слайд27.JPG

 

С Dockerfile несколько сложнее. Есть несколько проблем, к которым нужно быть готовым, когда вы начинаете решать задачи построения Docker-образа для 1С.

  • Один из главных навыков – это умение гуглить ошибки. Когда вы начинаете работать с новым языком, вы начинаете сталкиваться с новыми неизвестными для вас ошибками. Эти ошибки могут быть по-разному отформатированы, в них может присутствовать дерево вызовов, служебная информация. В случае 1С вы привыкли к внешнему виду ошибок и беглым взглядом на сообщение сразу можете понять, где эту ошибку искать, вы в целом знаете методики и подходы к расследованию ошибок. В незнакомых языках и приложениях каждая новая ошибка - это вызов и проверка вашего навыка вычленения информации и поиска решения в интернете. Когда вы будете собирать образы для Docker или писать собственные Dockerfile, то у вас тоже будут различные ошибки – от команд Linux, от различных установщиков пакетов, от самого Docker. И вам нужно понимать, что из выводимой информации является текстом ошибки и понимать, как сформулировать запрос Google, чтобы получить решение этой проблемы.

  • Так как Docker – это в первую очередь система, которая применяется на Linix-машинах, вам нужны какие-то базовые знания Linux. Вам не нужно знать детально о том, как работает ядро, как собираются модули, детально разбираться в процессах сбора библиотек из исходников. Вам нужно понимание базовых команд, переходы между каталогами, копирование файлов, перемещение, переименование, запуск приложений и т.д.

  • И третье – это зависимости. В случае 1С, зависимости – это очень сложная штука, потому что, даже несмотря на то, что 1С имеет пакетный режим запуска, чтобы она запустилось в Linux, на машине должно быть установлено очень много дополнительных библиотек. Про это попозже чуть подробнее поговорим.

 

Готовый Dockerfile для 1С

 

Слайд28.JPG

 

К счастью, проблемой помещения 1С в Docker занимается довольно много людей. В частности, этой проблемой начала заниматься наша компания. Мы развиваем проект на GitHub под названием onec-docker от пользователя jugatsu.

Мы взяли его разработку за основу и развили ее в своем форке https://github.com/firstBitSemenovskaya/onec-docker. Часть доработок переносится в апстрим, к jugatsu, часть остается в форке, но главное, что все доработки доступны и открыты.

Если вы зайдете на страницу репозитория на GitHub и переключитесь на ветку feature/first-bit, то вы увидите скомбинированный результат работы jugatsu и нас по тому, как завернуть 1С в docker и как подключить ее к Jenkins.

 

Слайд29.JPG

 

Что же внутри?

Любая работа с платформой начинается с вопроса: откуда взять дистрибутив? Есть несколько подходов к этому – вы можете положить дистрибутив в локальный каталог, а потом его копировать, либо же вы можете (кодом) зайти на сайт releases.1c.ru и оттуда скачать релиз (естественно, у вас должны быть параметры авторизации и понимание того, какой тип клиента вы хотите установить).

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

 

Слайд30.JPG

 

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

Вам всего лишь нужно будет выполнить команды по сборке этого образа и по установке клиента 1С – на слайде показано, как стандартным дебиановским приложением dpkg устанавливается сервер, клиент и общие зависимости.

 

Слайд31.JPG

 

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

Эта задача здесь также решена через xvfb (X virtual framebuffer) и окружение xfce4. Вы можете подключиться к контейнеру через любой vnc-клиент и посмотреть, что же конкретно происходит в моменты прохождения тестов.

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

 

Слайд32.JPG

 

Так как мы пытаемся запустить нашу 1С-ку на Jenkins, нам нужно к этому Jenkins как-то присоединиться. А поскольку агент Jenkins – это приложение, написанное на Java, поэтому для работы вашего агента в docker-контейнере должна быть установлена Java.

Эта задача здесь тоже решена:

  • скачивается Java 13-й версии (дистрибутив от AdoptOpenJDK), хотя в принципе достаточно и 8-й версии, но 8-я потихоньку устаревает, поэтому идем вперед;

  • устанавливаются дополнительные зависимости для Java;

  • и ставится сама Java.

 

Слайд33.JPG

 

Следующий шаг – это Mono (среды исполнения, необходимой для работы OneScript) и дополнительных зависимостей.

После этого скачивается менеджер версий ovm, который устанавливает сам OneScript.

 

Слайд34.JPG

 

И заключительным шагом ставятся библиотеки для OneScript – это gitsync, vanessa-runner, add – то, что обычно используется для сборки и тестирования на Jenkins.

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

  • графическое окружение;

  • платформа 1С:Предприятие;

  • Java и настройки для подключения к Jenkins;

  • OneScript, позволяющий запускать тесты, gitsync и т.д.

 

Слайд35.JPG

 

В любом Dockerfile есть такое понятие, как «Точка входа». Это тот скрипт, который будет исполняться, когда вы запускаете docker-контейнер.

В случае этого образа точкой входа является инициализация графической подсистемы и подключение к Jenkins. Автоматически скачивается файл для подключения в качестве агента. Конфигурируется. Все переменные среды автоматически передаются самим сервером Jenkins при запуске контейнера. И вам ничего дополнительно настраивать не нужно.

 

Сборка и хранение Docker-образа

 

Слайд36.JPG

 

Собранные образы нужно где-то хранить. Вы, конечно, можете использовать бесплатное хранилище hub.docker.com, но нужно помнить, что вы не имеете права распространять дистрибутивы платформы, соответственно, вам нужно будет эти образы делать приватными и закрывать логином/паролем. При этом у hub.docker.com есть лимит на количество приватных образов. Если же вы пользуетесь, например, GitLab, то у GitLab есть собственное хранилище Docker-образов, в котором вы можете разместить все ваши собранные образы и иметь историю по версиям и по сборкам.

 

Слайд37.JPG

 

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

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

Последовательность и возможные способы комбинации слоев вы можете подсмотреть в файле Layers.md в корне репозитория.

 

Слайд38.JPG

 

Естественно, эту сборку можно автоматизировать. На сервере сборок можно создать отдельную задачу, которая и будет заниматься сборкой нужных образов.

В Jenkins есть такое понятие, как параметризируемая сборка – сборка, которой на вход помимо самого скрипта передаются дополнительные параметры, которые пользователь может указать в пользовательском интерфейсе. Например:

  • версия платформы 1С:Предприятие, которую вы собираете;

  • параметры авторизации;

  • путь к docker registry – информация о том, куда этот образ нужно отправлять;

  • дополнительные флаги сборки

 

Слайд39.JPG

 

И на выходе вы по одной кнопке можете, устанавливая и снимая те или иные галочки, и задавая параметры, автоматически примерно за 45 минут (среднее время сборки на нашем сервере) получить готовый Docker-образ. Аналогичным образом можно собрать образы с EDT на борту для запуска расширенной валидации или сбора покрытия.

 

Схема работы

 

Слайд44.JPG

 

Каким же образом будет выглядеть ваша система, если у вас получится все это запустить?

Во главе системы располагается сервер сборок (Jenkins), который:

  • собирает и получает информацию о собранных 1С-ных образах из Docker Registry;

  • запускает на подключенном Docker Swarm кластере агенты для сборочной линии, на которых выполняются ваши тесты.

Что вы в этом случае получите? Довольно простой механизм масштабирования. Неважно, появилась ли у вас новая рабочая станция или полноценный сервер - буквально одной командой в терминале вы добавляете машину в Docker Swarm Cluster и она сразу же становится доступной для запуска сборок.

 

Бонус. Оркестрация серверами хранилищ

И в качестве бонуса – я бы еще хотел сказать про сервер хранилищ.

Проблема с доступом к сетевым ресурсам по UNC-путям чаще всего первым делом стреляет на хранилищах. Мы привыкли к тому, что хранилище – это файловая шара, которая под windows подключается без каких-либо проблем, вы просто указываете в конфигураторе каталог размещения //ИмяСервера/СетеваяПапка и все работает.

В случае Linux и Docker вы такую штуку сделать не сможете, потому что вам этот каталог, опять-таки, нужно сначала смонтировать.

 

Слайд41.JPG

 

Решением этой проблемы является поднятие где-то у вас в контуре сервера хранилища с доступом по HTTP.

И эту задачу вы тоже можете решить с помощью Docker, собрав соответствующий Docker-контейнер (образ crs – сервер хранилищ).

 

Слайд42.JPG

 

Поверх сервера хранилища устанавливается Apache с настройкой всех нужных конфигурационные файлов и публикации (образ crs-apache).

 

Слайд43.JPG

 

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

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

  • Вариант посложнее - завернуть все это дело в Kubernetes. В Docker же уже завернули.

Мы сейчас работаем над тем, чтобы представить довольно красиво и просто конфигурируемое решение на базе helm chart, которое позволит каждое ваше хранилище развернуть внутри Kubernetes с помощью одного скрипта, автоматически конфигурирующего все, что нужно. Конечная цель – это получить что-то вроде crs.mycompany.com/ИмяГруппы/ИмяПроекта.

На этом у меня все, спасибо за внимание.

 

Вопросы:

  • Сколько у тебя месяцев ушло на то, чтобы все это осознать и освоить?

  • Почти весь последний год (мы начали в феврале 2019 года) мы занимаемся переносом в Kubernetes наших внутренних сервисов. Сейчас у нас там работает несколько систем – GitLab, SonarQube, Redmine, Jenkins. После того как мы подняли там инфраструктуру управления проектами и общую инфраструктуру разработчика, следующим шагом стала задача масштабирования тестов (тестовых контуров и запусков). Конкретно этой задачей мы занимаемся с конца декабря 2019. И этот доклад – это, по сути, компиляция тех доработок репозитория jugatsu, которые пришлось сделать, чтобы запустить это в Jenkins (с декабря 2019 по март 2020).

  • Почему Docker Swarm, раз у вас есть Kubernetes?

  • Docker Swarm и его плагин для Jenkins оказался очень удобной отправной точкой в условиях ограниченных серверных ресурсов. К Jenkins (а точнее к Docker Swarm Cluster) подключено несколько обычных машин разработчиков, и важным ограничением стал вопрос простоты и скорости настройки новой машины. Подключить рабочую станцию к сворму оказалось намного проще и быстрее, чем разворачивать на ней полноценный узел Kubernetes. Возможно в будущем мы откажемся от использоваться Docker Swarm и переведем 1сные сборки в Kubernetes, но пока нас устраивает текущее решение.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Kazan.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

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

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

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

2220 руб.

04.07.2022    6733    26    0    

23

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9153    78    4    

110

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 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.144.49.

1728 руб.

20.01.2022    6594    10    0    

9

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

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

2 стартмани

08.05.2019    24223    54    VPanin56    26    

26

1С, СППР и Архитектура как код

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

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

01.02.2024    2468    roman72    9    

7

TCP прокси-сервер хранилища конфигурации 1С

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

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2790    kamisov    17    

57

Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

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

Когда под каждый проект нужно развернуть отдельный стенд разработки и сборочную линию для его обслуживания, велик риск влияния человеческого фактора. О том, как зафиксировать инженерный опыт в скриптах и унифицировать необходимые настройки для автоматизированного разворачивания инфраструктуры с помощью Terraform и Ansible, пойдет речь в статье.

01.11.2023    1326    Libelle    5    

13

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

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

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    711    5    ICL-Soft    0    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Ambakollajder 25.01.21 14:39 Сейчас в теме
А как обстоит дело с 1С лицензиями серверными и пользовательскими как они взаимодействуют с докер контейнерами? Когда для тестов параллельно будем запускать несколько изолированных контейнеров. Я правильно понимаю, что на это все хватит 1 серверной и 1-й пользовательской (аппаратной) лицензии, так как виртуализации как таковой нет и контейнеры выполняются в среде основной ос.
2. nixel 1404 25.01.21 16:39 Сейчас в теме
(1) у нас в основном используются файловые базы и аппаратный ключ с пользовательскими лицензиями. В контейнер проброшен nethasp.ini с указанием IP для поиска лицензии.
3. MaxS 2827 25.01.21 20:10 Сейчас в теме
Очень всё интересно, есть необходимость освоить эти технологии.
Пугает одно. При смене компьютера или ОС необходимо всё восстановить за приемлемые сроки, т.е. вспоминать годами полученные знания, устанавливать софт, решать вопросы зависимостей. Понимаю, что это вопрос для другой статьи, которая надеюсь тоже появится. Чтобы раз и развернуть всё. )
4. nixel 1404 25.01.21 21:29 Сейчас в теме
(3) так прелесть докера как раз в том, что не нужно ничего вспоминать. Всё, необходимое для развёртывания, уже заскриптовано и нужно один раз сделать docker build/docker run
JohnyDeath; theshadowco; MaxS; +3 Ответить
5. Dach 372 27.01.21 13:05 Сейчас в теме
Как Jenkins взаимодействует с Docker Swarm? Есть плагин какой-то?

Как запускает "на подключенном Docker Swarm кластере агенты для сборочной линии"?

Вот мы добавили новую рабочую станцию в кластер. Кто и как запустит в ней агент сборки и как об этом узнает master J?
7. nixel 1404 28.01.21 09:08 Сейчас в теме
(5) мне кажется, я подробно рассказал об этом в самой статье :)
Подключение дженкинса к сворму организуется через docker swarm plugin (в статье есть ссылка).

Запускает - через функциональность клауд провайдера - посылает на сварм менеджер команду запуска нового сервиса.

Дженкинс мастеру не надо знать о том, что вы добавили новую ноду в кластер. Дженкинс как общался с сворм менеджером так и продолжит с ним общаться.
6. Niki_Pro 27.01.21 14:13 Сейчас в теме
Круто, спасибо за статью. Возник вопрос, можно ли туда впихнуть формирование скриншотов при появлении ошибки в сценарном тесте, в случае автоматизации Vanessa Automation + Docker + Swarm.
Не будет ли там черный экран, если смотреть например отчетик Allure в проблемном шаге
8. nixel 1404 28.01.21 09:10 Сейчас в теме
(6) да, эта схема используется у нас для тестирования на VA со снятием скриншотов. Причём работает и через утилиту снятия скриншотов (scrot) и через VanessaExt.
Niki_Pro; +1 Ответить
9. Cifer 157 07.04.21 09:36 Сейчас в теме
Для сеансов в докере нужны отдельные лицензии?
10. nixel 1404 07.04.21 10:04 Сейчас в теме
(9) да, клиентские, как обычно.
11. Cifer 157 07.04.21 11:29 Сейчас в теме
(10) в клиент-серверном варианте лицензия на сервер будет видна из докера или надо отдельную покупать?
12. nixel 1404 07.04.21 12:44 Сейчас в теме
(11) если сервер в докере, то надо будет либо активировать лицензию внутри контейнера, либо использовать отдельный сервер лицензирования и загонять докер-контейнер с сервером в кластер серверов
Оставьте свое сообщение