Анатомия Docker-образа для тестирования 1С: что скрыто внутри?

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

В первую очередь, давайте разберемся – зачем вообще использовать Docker?

• Первая причина, по которой Docker может оказаться полезным – это необходимость тестирования большого количества конфигураций. Потому что когда мы проверяем одну, две или даже пять конфигураций – у нас, как правило, нет никаких проблем с параллельностью запуска. В таких случаях мы редко задумываемся о пересмотре процессов и не стремимся уходить с Windows-сервера в контейнеры и образы. Но когда количество конфигураций вырастает до 10, 15 или 20, возникает закономерный вопрос – как выстроить процесс так, чтобы тесты запускались быстро, одновременно и параллельно, а результаты были готовы к нужному времени?

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

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

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

 

Плюсы и минусы

 

Теперь давайте поговорим о плюсах и минусах Docker. Начнем с плюсов.

• Первый и, пожалуй, один из самых важных плюсов – это централизованная поддержка. У нас есть единый образ, который собирается по заранее определенным правилам, и если в окружение тестирования нужно что-то добавить, убрать или изменить, мы просто вносим эти настройки в Docker-файл этого образа. Главное – понимать, где именно что вносится. А поскольку все настраивается в одном месте, этим можно быстро и легко управлять.

• Следующее преимущество – это параллельность запусков. Уровень параллельности напрямую зависит от тех мощностей, которые выделяются для нашего контейнера.

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

• И контроль над ресурсами. Под каждый запуск контейнера, в котором проходят тесты, выделяется определенное, заранее известное количество ресурсов – таким образом мы заранее знаем точные параметры того «замкнутого мира», где выполняется тестирование.

Но не все так просто – конечно же, есть и минусы.

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

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

• Еще один момент – это сложности в отладке. В некоторых случаях бывает непросто подключиться к контейнеру (например ограничения со стороны ИБ на использование VNC) и понять, что происходит внутри: почему зависла 1С, на каком этапе остановилось обновление или по какой причине не проходят тесты. Для анализа подобных ситуаций зачастую требуется отдельная Linux-виртуальная машина, где можно воспроизвести проблему и детально ее изучить.

• Кроме того, при разработке кода и всех вспомогательных скриптов важно учитывать кроссплатформенность. Процессы должны корректно запускаться как в Windows, так и в Unix-окружении. При этом компоненты, изначально написанные под Windows, могут просто не заработать в Linux, так как они не были на это рассчитаны.

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

 

Что же скрыто внутри?

 

 

Давайте теперь разберемся, что находится внутри контейнера Docker и как сформировать Dockerfile для тестирования 1С.

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

На слайде в качестве базового используется образ Ubuntu версии 20.04. Его сборка не требует сложных или специальных знаний. Когда мы указываем в Dockerfile:

FROM “ubuntu:20.04”

система автоматически понимает, что этот образ необходимо скачать из официального репозитория Docker Hub – т.е. фактически за этим названием скрывается полный путь: docker.io/library/ubuntu20.04.

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

Однако для задач, связанных с 1С, этого недостаточно – образ необходимо донастраивать. Чтобы было проще разбираться с настройками, весь текст Dockerfile я разделила на несколько пакетов:

• основные,

• дополнительные (они же «полезные»),

• специализированные.

 

 

Начнем с основных пакетов – именно они позволяют расширить базовый образ и наполнить его всем необходимым.

 

 

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

 

 

Процесс установки пакетов, как правило, выглядит одинаково:

DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends

Эта конструкция означает, что:

• Во-первых, мы отключаем интерактивные диалоги, поскольку в контейнере некому отвечать на вопросы установщика.

• Во-вторых, мы отказываемся от установки рекомендованных, но необязательных пакетов. Это позволяет не раздувать образ и оставить только действительно необходимый минимум.

 

 

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

&& rm -rf \
    /var/lib/apt/lists/* \
    /var/cache/debconf \
    /tmp/*

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

 

 

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

locales \
language-pack-ru \
tzdata \

Для 1С это особенно важно, потому что 1С – это русскоязычная система и должна корректно отображать текст, использовать нужные шрифты, правильно работать с датами и временем.

 

 

Далее идут пакеты, позволяющие корректно скачивать нужные нам для работы файлы – например, из репозиториев GitHub, GitLab или с ИТС. С помощью пакета:

ca-certificates \

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

 

 

И последняя группа пакетов в списке основных:

git \
wget \
curl \
sudo \
nano \
unzip \

Эти пакеты отвечают за работу с репозиториями и файлами:

• С помощью wget, curl и git можно взаимодействовать с репозиториями GitHub и GitLab.

• Пакет nano позволяет редактировать файлы, открывать и сохранять их.

• Пакет unzip – это распаковщик для архивов.

• А утилита командной строки sudo нужна для установки и настройки компонентов внутри образа – она позволяет запускать процессы с повышенными правами.

 

 

Следующая подгруппа – дополнительные пакеты, которые могут быть полезны в ряде сценариев.

 

 

Сюда входят пакеты:

apt-transport-https \
software-properties-common \
debconf-utils \
default-jre-headless \
procps \
scrot \

Разберемся, в каких случаях они необходимы:

• Утилита debconf-utils предназначена для управления настройками пакетов в контейнере.

• Пакеты apt-transport-https и software-properties-common пригодятся для корректной работы с репозиториями.

• Пакет default-jre-headless предоставляет среду для запуска Java-приложений.

• Утилита scrot позволяет делать скриншоты рабочего стола, чтобы мониторить ошибки, возникающие в процессе тестирования.

• А утилита procps помогает мониторить программные процессы – смотреть, какие процессы запущены, а также завершать их.

 

 

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

 

 

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

&& echo ttf-mscorefonts-installer msttcorefonts/accepted-mscorefonts-eula select true | debconf-set-selections \
    ttf-mscorefonts-installer \

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

 

 

Далее идет набор пакетов, которые являются основой графической системы:

libfreetype6 \
libfontconfig1 \
libglib2.0-0 \
dbus-x11 \
libgl1 \
libglx0 \
libegl1 \
at-spi2-core \
libgtk-3-0 \
libgtk2.0-0 \

Эти пакеты обеспечивают поддержку графического интерфейса и позволяют приложениям, включая 1С, отображать окна, кнопки, элементы управления, работать с 3D-графикой и веб-компонентами. Без этих библиотек 1С просто не сможет корректно открываться и отображать интерфейс.

 

 

Здесь отдельно выделен веб-движок на базе WebKit:

libwebkitgtk-6.0-4 \

Он необходим для отображения веб-страниц и HTML-отчетов внутри 1С.

 

 

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

 

 

Подсистема X11 разделена на две части:

• X-сервер, который управляет экраном.

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

Для 1С это особенно важно, поскольку контейнер не имеет физического монитора. В таком случае используется виртуальный экран, роль которого выполняет X-сервер.

 

 

Ключевые компоненты, которые нужны для работы X-сервера, выделены на слайде

libx11-6 \
libxext6 \
libxft2 \
libxcursor1 \
libxrandr2 \
libxcomposite1 \
libxss1 \
libxtst6 \
xvfb \

Здесь:

• Пакет libx11-6 – это базовая клиентская библиотека, которая отвечает за то, что происходит на экране в целом.

• Пакет xvfb – это виртуальный X-сервер.

• Пакет libxcursor1 отвечает за управление графическими курсорами – это песочные часы и стрелочки, которые мы видим при перемещении мыши.

• Пакет libxft2 обеспечивает сглаженную отрисовку шрифтов.

• Пакет libxrandr2 управляет разрешением и ориентацией экрана (повороты).

• Пакет libxtst6 позволяет программно эмулировать движения и клики мыши для автоматизированного тестирования в 1С.

Все эти библиотеки в совокупности формируют корректную графическую среду.

 

 

Рассмотрим заключительную часть списка специализированных пакетов, которые нужны для тестирования 1С.

 

 

Здесь перечислены пакеты для OneScript:

ca-certificates-mono \
libmono-i18n4.0-all \
libmono-system-net-http4.0-cil \
libmono-system-runtime-serialization4.0-cil \
mono-runtime \

Они отвечают за скачивание и установку OneScript, а также создают условия для корректной работы OneScript в контейнере.

 

 

Пакет x11vnc позволяет нам удаленно подключиться к работающему контейнеру и через VNC увидеть, что там происходит. Это особенно полезно в ситуациях, когда непонятно, почему процесс завис, тесты не завершаются, а платформа ведет себя не так, как ожидалось. VNC дает возможность «заглянуть внутрь» этого изолированного окружения и разобраться в проблеме.

 

 

И последняя группа пакетов нужна для установки менеджера рабочего стола XFCE:

mousepad \
xfce4 \
xfce4-terminal \
xfce4-goodies &&\
# Удаляем ненужные пакеты (скринсейвер, энергосбережение)
apt-get -gg purge -y pm-utils screensaver* &&\
# Настройка терминала по умолчанию
update-alternatives --set x-terminal-emulator /usr/bin/xfce4-terminal wrapper &&\

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

 

 

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

 

 

В первую очередь здесь настраиваются SSL-сертификаты, которые необходимы для безопасного подключения к внешним источникам и загрузке дистрибутивов – например, с GitHub или ИТС.

Также здесь задаются настройки по отображению языков и форматы дат.

 

 

В частности, с помощью конструкции:

cert-sync --user /etc/ssl/certs/ca-certificates.crt &&\

мы устанавливаем настройки SSL-сертификатов.

 

 

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

sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && \
sed -i -e 's/# ru_RU.UTF-8 UTF-8/ru_RU.UTF-8 UTF-8/' /etc/locale.gen && \
locale-gen && \

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

# Установка системной локали по умолчанию
update-locale \
LANG=ru_RU.UTF-8 \
LC_ALL=ru_RU.UTF-8 \
LANGUAGE=en_US:en

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

 

 

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

ENV LANG=ru_RU.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=ru_RU.UTF-8
ENV TZ=Europe/Moscow

 

 

Следующий блок настроек относится непосредственно к 1С.

 

 

Сначала создается симлинк – своего рода «ярлык» на исполняемый файл 1С.

RUN chmod +x /tmp/create-symlink-to-current-1cv8.sh &&\
    /tmp/create-symlink-to-current-1cv8.sh

Это позволяет обращаться к платформе по одному и тому же пути вне зависимости от установленной версии.

 

 

Далее настраиваются параметры запуска 1С.

RUN echo "SystemLanguage=RU" > /opt/1cv8/conf/conf.cfg &&\
    echo "DisableUnsafeActionProtection=.*" >> /opt/1cv8/conf/conf.cfg &&\

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

И последнее, что мы делаем – указываем, какие лицензии нужно использовать при запуске 1С.

echo UseHWLicenses=1 >> /opt/1cv8/common/1cestart.cfg &&\
chmod -R 777 /opt/1cv8/conf &&\
cp /tmp/nethasp.ini /opt/1cv8/conf/

В примере указано, что по умолчанию мы используем аппаратную лицензию – добавляем в существующий файл настройки 1cestart.cfg инструкцию UseHWLicenses=1, а также берем заранее подготовленный файл nethasp.ini с настройками подключения к серверу сетевых ключей и размещаем его в нужном каталоге.

Покажу, как выглядят файлы настроек внутри.

 

 

В файл conf.cfg мы прописали две строки – использование русского языка в качестве системного и отключение защиты от небезопасных действий.

 

 

В 1cestart.cfg указываются глобальные настройки запуска для 1С: нужно ли ей показывать окна при старте; как работать с лицензиями и т.д.

 

 

И файл nethasp.ini хранит информацию о сервере лицензирования и правилах подключения к нему.

 

 

Возвращаемся к изучению остальных настроек в Dockerfile.

# Создание пользователя и директории для 1С
ARG UID=1005
ARG GID=1005

RUN groupadd -g "${GID}" grp1cv8 &&\
    && useradd --create-home --no-log-init -u "${UID}" -g "${GID}" usr1cv8 &&\
    mkdir -p /home/usr1cv8/.1cv8/.local &&\
    chown -R usr1cv8:grp1cv8 /home/usr1cv8

# Том для данных пользователя
VOLUME /home/usr1cv8/.1cv8
# Переключение на пользователя
USER usr1cv8
WORKDIR /home/usr1cv8

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

 

 

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

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

 

 

Расскажу, на что здесь нужно обратить внимание.

Первое – мы указываем для Linux, на какой экран выводить интерфейс:

- export DISPLAY=":0"

Сообщаем системе, что вывод должен происходить на виртуальный экран с номером 0.

Далее запускается пустой виртуальный экран:

- /usr/bin/Xvfb :0 -screen 0 1680x1050x24 -shmem > /dev/null 2>&1 &

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

 

 

Далее отключаем энергосбережение, затемнение и спящий режим.

- xset -dpms &
- xset s noblank &
- xset s off &

потому что даже при отсутствии активности виртуальный экран не должен «гаснуть», иначе в спящем режиме мы не сможем ничего запустить.

 

 

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

- /usr/bin/startxfce4 --replace > /dev/null 2>&1 &

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

# Настройка XFCE (прозрачность, композитинг)
- xfconf-query -c xfwm4 -p /general/ignore-wm-hint -t bool -s true --create
- xfconf-query -c xfwm4 -p /general/default-opacity -t int -s 100 --create
- xfconf-query -c xfwm4 -p /general/allow-override-redirect-opacity -t bool -s false --create
- xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "auto" --create
- xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s true --create
- xfconf-query -c xfwm4 -p /general/frame_opacity -s 100 -t int --create
- xfconf-query -c xfwm4 -p /general/inactive_opacity -s 100 -t int --create
- xfconf-query -c xfwm4 -p /general/move_opacity -s 100 -t int --create
- xfconf-query -c xfwm4 -p /general/popup_opacity -s 100 -t int --create
- xfconf-query -c xfwm4 -p /general/resize_opacity -s 100 -t int --create
- xfconf-query -c xfce4-panel -p /panels/panel-1/background-alpha -s 100 -t int --create
- xfconf-query -c xfce4-panel -p /panels/panel-1/background-style --create -t int -s 1
- xfconf-query -c xfce4-panel -p /panels/panel-1/background-color -t uint -s 65535 -t uint -s 65535 -t uint -s 65535 -t uint -s 65535 --create

 

 

Возвращаемся в основной Dockerfile – расскажу, как в нем устанавливаются нужные нам для работы компоненты.

Первым делом указываем путь, откуда скачивать дистрибутив JDK, и устанавливаем его:

# Установка BellSoft Liberica JDK
WORKDIR /tmp
ARG ONEC_FILES_URL="https://artifactory.ru/files/jdk"
ARG JDK_VERSION="jdk17.0.13+12"

# Скачиваем, устанавливаем JDK и очищаем временные файлы
RUN curl -s ${ONEC_FILES_URL}/bellsoft-${JDK_VERSION}-linux-amd64-full.deb -o /tmp/bellsoft-${JDK_VERSION}-linux-amd64-full.deb &&\
    dpkg -i /tmp/bellsoft-${JDK_VERSION}-linux-amd64-full.deb &&\
    rm /tmp/bellsoft-${JDK_VERSION}-linux-amd64-full.deb

 

 

Следующим шагом мы выполняем установку OVM, который используется как менеджер версий для OneScript. Указываем путь к репозиторию OVM, нужную версию OneScript и список пакетов, которые нужно будет установить.

# Аргументы сборки
ARG OVM_REPOSITORY_OWNER=oscript-library
ARG OVM_VERSION=v1.6.1
ARG OVM_EXE_URL="https://github.com/${OVM_REPOSITORY_OWNER}/ovm/releases/download/${OVM_VERSION}/ovm.exe"
ARG ONESCRIPT_VERSION=stable
ARG ONESCRIPT_PACKAGES="add gitsync vanessa-runner stebi vanessa-automation-single 1connector ibcmdrunner edt-ripper"

# Директория установки OneScript
ENV OSCRIPTBIN=/root/.local/share/ovm/${ONESCRIPT_VERSION}/bin
ENV PATH="$OSCRIPTBIN:$PATH"

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

# Скачивание OVM и версии OneScript
RUN curl -fL --progress-bar ${OVM_EXE_URL} -o /usr/local/bin/ovm &&\
    chmod +x /usr/local/bin/ovm &&\
    mono /usr/local/bin/ovm install ${ONESCRIPT_VERSION} &&\
    mono /usr/local/bin/ovm use ${ONESCRIPT_VERSION}

# Установка и обновление пакетов OneScript
RUN opm install opm \
&& opm update --all \
&& opm install ${ONESCRIPT_PACKAGES} \
# Дополнительная настройка gitsync (если установлен)
&& if echo "${ONESCRIPT_PACKAGES}" | grep -q "gitsync"; then \
    gitsync plugins init \
    && gitsync plugins enable limit \
    && gitsync plugins disable limit; \
    fi

 

 

Следующее – это установка 1С. Указываем версию, тип дистрибутива (client или server) и учетные данные ИТС. Здесь логин и пароль указаны в открытом виде, но в рабочем варианте так делать не следует. Установка производится отдельным скриптом:

# Аргументы
ARG ONEC_VERSION="8.3.26.1581"
ARG ONEC_USERNAME="ПользовательИТС"
ARG ONEC_PASSWORD="ПарольИТС"
COPY scripts/download_yard.sh /tmp/download.sh
RUN chmod +x /tmp/download.sh
RUN /tmp/download.sh "$ONEC_USERNAME" "$ONEC_PASSWORD" "$ONEC_VERSION" "client"

ENV distrPath=/tmp/downloads/Platform83/${ONEC_VERSION}
ENV installer_type="client"
WORKDIR ${distrPath}
RUN ls . &&\
    chmod +x /tmp/install.sh &&\
    chmod +x $distrPath/setup-full-$ONEC_VERSION-x86_64.run &&\
    sync; /tmp/install.sh &&\
    # Очистка
    rm -rf $distrPath/setup-full-$ONEC_VERSION-x86_64.run

 

 

При необходимости аналогичным образом устанавливается EDT: указываем параметры установки, учетные данные и добавляем в PATH путь к утилите 1cedtcli.

# Аргументы
ARG EDT_VERSION="2024.2.5"
ARG ONEC_USERNAME="ПользовательИТС"
ARG ONEC_PASSWORD="ПарольИТС"
COPY scripts/download_yard.sh /tmp/download.sh
RUN chmod +x /tmp/download.sh
RUN /tmp/download.sh "$ONEC_USERNAME" "$ONEC_PASSWORD" "$EDT_VERSION" "edt"

ARG downloads=downloads/DevelopmentTools10/${EDT_VERSION}
WORKDIR /tmp/${downloads}
RUN chmod +x ./1ce-installer-cli \
&& ./1ce-installer-cli install all --ignore-hardware-checks --ignore-signature-warnings \
&& rm -rf /tmp/* \
# После установки перемещаем компоненты в удобное место
&& mv $(dirname $(find /opt/1C/1CE -name 1cedtcli)) /opt/1C/1CE/components/1cedtcli

ENV PATH="/opt/1C/1CE/components/1cedtcli:$PATH"

 

 

Для формирования отчетов в Allure нужно скачать и установить соответствующие инструменты – это может быть Allure или Allurectl для использования в Allure TestOps. Указывается источник загрузки и путь установки, который прописывается в переменную PATH. После установки обязательно удаляем временные файлы.

ENV ALLURE_HOME=/opt/allure
ENV PATH="${ALLURE_HOME}/bin:${PATH}"
ARG ALLURE_VER="2.27.0"
ARG ALLURE_CTL_VER="2.16.0"
RUN curl -fL --progress-bar https://github.com/allure-framework/allure2/releases/download/${ALLURE_VER}/allure_${ALLURE_VER}-1_all.deb -o allure.deb &&\
    curl -fL --progress-bar https://github.com/allure-framework/allurectl/releases/download/${ALLURE_CTL_VER}/allurectl_linux_amd64 -o /usr/local/bin/allurectl &&\
    chmod +x /usr/local/bin/allurectl &&\
    dpkg -i /tmp/allure.deb &&\
    ln -sf /usr/share/allure "${ALLURE_HOME}" &&\
    rm -rf /tmp/* &&\
    rm -rf /var/lib/apt/lists/* /var/cache/debconf

 

 

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

ARG COVERAGE41C_VERSION=2.7.3
ENV PATH="/opt/Coverage41C-${COVERAGE41C_VERSION}/bin:$PATH"
RUN curl -fL --progress-bar https://github.com/1c-syntax/Coverage41C/releases/download/v${COVERAGE41C_VERSION}/Coverage41C-${COVERAGE41C_VERSION}.tar -o /opt/ &&\
    tar xf /opt/Coverage41C-${COVERAGE41C_VERSION}.tar -C /opt/ &&\
    && rm -rf /opt/Coverage41C-${COVERAGE41C_VERSION}.tar &&\
    cp -r /edt-jar /usr/lib
ENV EDT_LOCATION=/usr/lib/edt-jar

Обратите внимание, что для Coverage41С можно использовать либо установленную EDT, либо заранее подготовленный каталог edt-jar с файлами com._1c.g5.v8.dt.debug.core_*.jar и com._1c.g5.v8.dt.debug.model_*.jar.

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

Этого набора инструментов и настроек достаточно для того, чтобы выполнить такой набор действия как: получить последнюю версию исходников из Git-репозитория, конвертировать их в формат конфигуратора (в случае разработки в EDT), собрать файлы cf\cfe, обновить новой версией тестовый контур и запустить все необходимые тесты. Это могут быть юнит-тесты, дымовые тесты или сценарные тесты. Там же можно запустить, например, синтаксический контроль кода.

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

 

Возможные сложности и их решение

 

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

 

 

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

Дело в том, что при стандартной работе на Windows-сервере после первого запуска 1С формируется кэш, который сохраняется и повторно используется. А в контейнерной модели каждый запуск начинается с «чистого листа»: контейнер поднимается заново, и никакого кэша в нем изначально нет.

Мы решили эту проблему за счет сохранения и повторного использования кэша через встроенные возможности GitLab.

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

Дальше перенаправляем поиск и хранение кэша в нужную нам папку, прописывая ее путь в файле location.cfg.

И потом эту папку используем

...
    script:
        # Создание директорий
        - mkdir -p /home/usr1cv8/.1cv8/1C/1cestart
        - mkdir -p /home/usr1cv8/.1cv8/1C/1cv8
        - mkdir -p ./1cv8_Cache

        # Добавление базы в ibases.v8i
        - sudo echo -e "${DB_NAME}\r\nConnect=Srvr=\"${DB_HOST}:${DB_PORT}\";Ref=\"${DB_NAME}\"\r\nID=812d2bf4-782b-4795-9357-5764930c3d73\r\nExternal=0\r\n" > /home/usr1cv8/.1C/1cestart/ibases.v8i
        - sudo cat /home/usr1cv8/.1C/1cestart/ibases.v8i

        # Перенаправление кэша в 1cv8_Cache
        - sudo echo -e "location=${CI_PROJECT_DIR}/1cv8_Cache" > /home/usr1cv8/.1cv8/1C/1cv8/location.cfg

…
    cache:
        key: artifact.$DB_HOST.$DB_RAS_PORT.$DB_NAME
        paths:
            - 1cv8_Cache/
        policy: pull-push

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

Таким образом, проблему с увеличением времени обновления нам удалось успешно решить.

 

 

Следующие распространенные проблемы с тестированием в Docker вызывают создание скриншотов и локализация:

• Например, мы ожидаем, что Vanessa Automation нам сделает скриншоты ошибок, а вместо этого получаем черный экран. У нас такая проблема возникла, когда мы использовали в качестве менеджера рабочего стола OpenBox, а скриншоты пытались снимали с помощью внешней компоненты VanessaExt. В итоге мы не смогли это побороть и перешли на XFCE.

• Во втором случае изображение на первый взгляд выглядит как чёрный экран, однако при внимательном рассмотрении становится ясно, что оно на самом деле синее с тёмными пятнами. Такой эффект проявился уже в окружении XFCE при использовании внешней компоненты VanessaExt. Причиной оказалось некорректное значение глубины цвета в настройках дисплея: изначально стояло 16 бит – этого было достаточно для утилиты scrot, которая автоматически определяет глубину и корректно работает с таким значением. Однако VanessaExt требует явного указания глубины цвета в 24 бита, без чего она не способна правильно распознавать и интерпретировать цвета.

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

 

 

Есть и другие нюансы Docker, связанные с тестированием. Например:

• Шаги для Vanessa Automation могут по-разному отрабатывать на разных операционных системах: то, что корректно работает под Windows, в Linux может работать не так, как мы ожидали.

• Время работы действий на клиенте тестирования 1С в Linux может быть дольше, чем под Windows.

• При использовании производительного режима работы RLS могут возникнуть проблемы: если под Windows автоматически запускается фоновое задание, обновляющее настройки доступа, то в контейнере этого по умолчанию не происходит, и необходимо запускать процесс обновления прав и доступов вручную.

• Необходимо адаптировать все наши скрипты, сценарии тестирования и код, чтобы они могли универсально выполняться под обеими операционными системами. Например, если мы обращаемся в скриптах к файлам или используем запуск внешних обработок, эти команды должны содержать только корректно интерпретируемые в обеих системах символы. В частности, если в команде использовался обратный слэш, его нужно развернуть и сделать прямым. У нас был случай, когда в параметре запуска внешней обработки логины пользователей передавались через обратный слэш (\npetrova\eivanova\astepanova) и при сочетании обратного слеша и начала логина получался \N, что интерпретировалось как перенос строки – в итоге выполнение ломалось. Это нужно помнить и учитывать при разработке.

• Еще одна проблема исполнения в среде Linux заключается в том, что наш код не должен содержать COM-объектов и других компонент, которые работают только под Windows. В частности, могут наблюдаться неожиданные сложности в редакторе Monaco Editor. Все это необходимо учитывать.

 

 

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

 

 

Но на самом деле, если есть желание, любая сложная задача вполне реализуема. Главное – поставить себе цель, не опускать руки и разбираться.

Потому что если очень хочется – то нужно обязательно. Крутой Уокер одобряет. Все получится.

 

Вопросы и ответы

 

При сборке образа пакеты каждый раз скачиваются из интернета? Разве это допустимо по безопасности?

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

Какая база используется в тестовом контуре – файловая или клиент-серверная?

Может быть и файловая, и клиент-серверная.

Зачем так усложнять? Почему просто не развернуть сервер, один раз его настроить и переиспользовать?

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

• Docker позволяет нам одновременно запускать огромное количество тестовых баз и контуров, используя ресурсы серверов наших РЕ-специалистов. Контейнеры позволяют централизованно управлять процессами: мы запускаем сразу 20-30 контейнеров, и все тесты идут параллельно. А поддерживать один общий сервер своими силами при такой нагрузке было бы крайне сложно.

• При этом каждому контейнеру выделяются свои ресурсы – нам не нужно ничего ждать и ни от кого зависеть.

За счет независимости ресурсов и параллельности исполнения мы получаем значительные преимущества.

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

Да, с программными ключами все работает отлично, никаких специфических настроек не требуется.

Зачем в контейнере, помимо клиента 1С, еще EDT и другие инструменты? Вы прямо в контейнере обновляете базу? Зачем? Ведь тогда контейнер получается очень большим?

Да, все процессы у нас выполняются внутри контейнеров: от конвертации исходников до обновления тестовых контуров и запуска тестов. Но на самом деле у нас нет одного «огромного» контейнера. В реальности контейнеры разделены по назначению, есть разные вариации:

• 1С+EDT – для конвертации исходников.

• 1С+OneScript – для обновления базы и запуска тестов.

• 1С+Python – для обновления и тестов.

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

 

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.