Введение
В связи с постоянным выходом новых версий платформы 1С:Предприятие, одновременная работа с несколькими версиями платформы с целью тестирования, является достаточно распространенной практикой. Однако, поскольку как правило, количество серверных лицензий не безгранично, приходится развертывать несколько версий платформы одновременно, на одном физическом или виртуальном сервере. И если в случае с ОС Windows, установка и параллельное использование нескольких версий платформы не вызывает каких-либо затруднений, то в случае, если вашей рабочей системой является ОС Linux, реализация такого варианта использования становится несколько сложнее, и автоматизация в данном случае, может дать свои положительные плоды.
Соответственно, настоящая статья посвящена демонстрации использования программного пакета АИТП (проект на GitHub), для автоматизации установки и обновления множественных версий платформы 1С:Предприятие на серверах, под управлением ОС Linux.
Системные требования
Платформа 1С:Предприятие, версии не ниже 8.3.10.2252.
Операционная система Windows или Linux.
Лабораторная среда
Для экспериментов, автором использовалась лабораторная среда на базе виртуальных машин Hyper-V, схема которой представлена на рис. 1.
Рисунок 1. Схема лабораторной среды.
Более детальную информацию по подготовке лабораторной среды можно найти в этой и этой публикациях.
Архитектура решения
Используемые технологии
В качестве механизма, обеспечивающего возможность одновременной установки и запуска различных версий платформы на одном сервере, была выбрана система контейнеризации Docker.
В этом случае, различные версии платформ размещаются в отдельных контейнерах (см. рис. 2.).
Рисунок 2. Размещение различных версий платформы в контейнерах.
В качестве ОС для хоста была выбрана Centos 7, как достаточно распространенная в корпоративной среде, а в качестве базовой ОС для контейнеров – Ubuntu 16.04, как наиболее популярная (судя по публикациям) среди специалистов 1С.
Сетевое взаимодействие
Для упрощения сетевого взаимодействия выбрана схема, в которой для внешних устройств, набор контейнеров представляет собой один хост, а каждый экземпляр сервисов платформы использует свой собственный пул портов (см. рис. 3.).
Рисунок 3. Организация сетевого взаимодействия со службами платформы.
Хранение данных
Поскольку контейнеры по своей природе полностью виртуальны, а сервисы платформы используют постоянную информацию (настройки кластера, список информационных баз etc.), для хранения такой информации используются подключение папок, расположенных на хостовой системе внутрь контейнеров (см. рис. 4.).
Рисунок 4. Схема подключения папок.
Для упрощения лабораторной среды, дистрибутивы платформы, которые необходимы для создания образов docker, хранятся на сервере 1С:Предприятие, где развернута конфигурация АИТП. Конечно в продуктивных средах, особенно при наличии кластера из нескольких серверов приложений, так поступать не следует, и более правильным будет создание папки дистрибутивов платформы на отдельном сервере с монтированием при помощи sshfs, NFS или SAMBA, однако для нашей демонстрационной конфигурации, такой подход вполне допустим.
Создание образов
Для упрощения создания образов платформы, примем нижеследующую схему их генерации (см. рис. 5).
Рисунок 5. Схема генерации образов платформы.
Схема транспорта данных, необходимых для создания образов, представлена на рис. 6.
Рисунок 6. Схема транспорта данных, необходимых для создания образа Docker.
Начальная настройка серверов
Далее предполагается, что на сервере приложений 1С:Предприятие (172.16.210.44) развернута информационная база с демонстрационной конфигурацией из настоящей статьи. Также предполагается, что на сервере docker (см. рис. 1.) установлен Docker. С инструкциями по установке можно ознакомиться в этой статье.
Все административные действия производятся из-под аккаунта root, если не оговорено иное.
Настройка сервера docker
Подключаемся к серверу docker (172.16.210.40) клиентом ssh, к примеру putty.
Для упрощения перенаправления локальных папок хоста в контейнеры, отключаем SELinux, установив в файле /etc/selinux/config ключ SELINUX=disabled
Перезагружаем сервер.
Для управления сервером из АИТП, создадим пользователя с логином, совпадающим с учетной записью, из под которой работают сервисы 1С:Предприятие:
adduser usr1cv8
passwd usr1cv8
Поскольку для выполнения определенных операций, нашему пользователю будут необходимы права root, разрешим ему использование sudo:
gpasswd –a usr1cv8 wheel
Настройка сервера приложений 1C
Подключаемся к серверу приложений 1С:Предприятие (172.16.210.44) с использованием административного аккаунта (в моем случае – это ubadmin).
Для хранения дистрибутивов, в домашней папке пользователя usr1cv8, создадим папку distrib:
sudo mkdir /distrib
Разрешим сохранение в эту папку всем :
sudo chmod –R 777 /distrib
Поскольку мы сохраняем дистрибутивы платформы штатными средствами 1С:Предприятие, создаваемые файлы имеют разрешения только для пользователя usr1cv8 и группы grp1cv8. Далее положим, что для доступа к серверу будет использоваться аккаунт ubadmin.
Добавим административный аккаунт в группу grp1cv8 для предоставления возможности чтения, создаваемых платформой файлов:
sudo useradd –G grp1cv8 ubadmin
Создание базовых образов
В качестве более подробного справочного материала, описывающего создание собственных образов, можно воспользоваться этой статьей.
Подключимся к серверу docker с использованием ssh-клиента, с учетными данными usr1cv8.
Скачиваем образ ОС из официального репозитария:
sudo docker pull docker.io/ubuntu:16.04
Подключаемся к образу для внесения изменений:
sudo docker run –t –i docker.io/ubuntu:16.04
Далее, для целей тестирования, установим компоненты, необходимые для работы 32-битной версии платформы. Со списком необходимых компонентов можно ознакомиться, к примеру здесь.
Необходимо скопировать идентификатор контейнера (находится после @).
Устанавливаем необходимые компоненты и выходдим из контейнера:
dpkg --add-architecture i386 && sudo apt update
apt install unixodbc:i386 libgsf-bin:i386 ttf-mscorefonts-installer
apt install imagemagick-6.q16:i386
apt install imagemagick:i386
exit
Сохраняем изменения в новый образ:
sudo docker commit ИдентификаторКонтейнера ИмяОбраза
В моем случае имя образа – yury/1c-prerequestions-ubuntu
Просмотрим список образов:
sudo docker image ls
Результат выполнения команды представлен на рис. 7.
Рисунок 7. Список базовых образов.
Настройка конфигурации АИТП
Поскольку демонстрационная подсистема не имеет выделенной роли, необходимо создать пользователя, имеющего в системе полные права (в моем случае - Админ) .
Создание сервера управления контейнерами
Подключаемся к информационной базе в режиме предприятия с аккаунтом пользователя с полными правами (в дальнейшем предполагается, что все операции в информационной базе будут производиться от имени этого пользователя) и выбираем подсистему Управление контейнерами (см. рис. 8.).
Рисунок 8. Общий вид подсистемы “Управление контейнерами”.
В разделе Сервисы & Службы выбираем пункт Серверы управления контейнерами и создаем новый элемент справочника (см. рис. 9.).
Рисунок 9. Создание сервера управления контейнерами.
При создании реквизита Хост, в качестве имени хоста необходимо указать его имя. Данный момент важен для правильной работы сервиса.
При записи элемента справочника, производится создание и старт экземпляра процесса НастроитьУправлениеКонтейнерами, который создает на сервере docker.itpa.cf необходимую структуру папок (см. рис. 4., рис. 10.).
Рисунок 10. Файловая структура для создания образов docker.
Пронаблюдать за выполнением процесса можно перейдя в раздел Оркестратор и выбрав пункт Задачи IT-процессов (см. рис 11.).
Рисунок 11. Результат выполнения процесса “НастроитьУправлениеКонтейнерами”.
Создание дистрибутива платформы
Загружаем образы сервера 1С:Предприятия с сайта ИТС и сохраняем их на диск локального компьютера. Для нашей тестовой среды, были загружены 32-битные дистрибутивы версий 8.3.10.2252 (файл deb.tar.gz)и 8.3.13.1809 (файл deb_8_3_13_1809.tar.gz).
Настроим параметры хранения дистрибутивов. Для этого выберем пункт Настройки хранения дистрибутивов, в разделе Сервис (см. рис. 12.) .
Рисунок 12. Настройки хранения дистрибутивов.
Папка создания дистрибутивов – это папка, в которую 1С:Предприятие сохраняет дистрибутивы при создании.
Папка хранения дистрибутивов – это папка, из которой сервисы OneScript скачивают дистрибутивы платформы.
Сервер хранения дистрибутивов – сервер, где хранятся дистрибутивы платформы.
Пользователь дистрибутивов – учетные данные пользователя, для подключению к серверу дистрибутивов.
Поскольку для ханения дистрибутивов мы создали на сервере 172.16.210.44 папку /distrib, укажем эти данные в настройках, а также создадим аккаунт, для соединения с сервером. В моем случае – это пользователь ubadmin.
В разделе Создать, выбеем пункт Дистрибутив платформы и заполним необходимые реквизиты (см. рис. 13.).
Рисунок 13. Создание дистрибутива платформы.
Загрузим дистрибутив, нажав кнопку Загрузить, затем сохраним его, нажав кнопку Сохранить и закрыть.
Посмотрим содержимое папки /distrib, на сервере 172.16.210.44 и убедимся, что в указанной папке появился дистрибутив платформы (см. рис. 14.).
Рисунок 14. Файл дистрибутива в папке для дистрибутивов.
Создание образа платформы
В разделе Сервисы & Службы выберем пункт Серверы управления контейнерами.
Обновим список образов, нажав кнопку Обновить список образов.
Перейдя в раздел Docker и выбрав пункт Образы Docker убедимся, что в списке присутствует образ с компонентами, необходимыми для работы платформы (в моем случае – это yury/1c-prerequestions-ubuntu). Именно на основании этого образа мы создадим образ платформы.
В разделе Создать, выберем пункт Образ платформы , заполним необходимые реквизиты (см. рис. 15.) и сохраним изменения.
Рисунок 15. Создание образа платформы.
Примерно через две минуты, выберем пункт Задачи ИТ-процессов в разделе Оркестратор и убедимся, что все задачи по созданию образа успешно завершены (см. рис. 16.).
Рисунок 16. Задачи процесса создания образа платформы.
При этом, в списке образов docker (Docker->Образы Docker) появится созданный нами образ (см. рис. 17.).
Рисунок 17. Образ docker.
Создание сервиса
В разделе Сервисы & Службы, выберем пункт Сервисы 1С и создадим новый сервис (см. рис. 18.)
Рисунок 18. Создание сервиса 1С.
Заполним необходимые реквизиты и сохраним изменения.
Обратите внимание, что пул портов сервиса должен совпадать с пулом портов образа платформы, иначе создание службы будет невозможно.
Проверим наличие папок сервиса, на сервере docker (см. рис. 19).
Рисунок 19. Папки сервиса 1С.
Создание службы (контейнера) 1С
В разделе Создать выберем пункт Служба 1С, заполним соответствующие реквизиты (созанные ранее образ и сервис) и сохраним изменения (см. рис. 20.).
Рисунок 20. Создание службы 1С.
Управление службами 1С
В разделе Сервис, выберем пункт Консоль служб 1С. В открывшемся окне выберем сервер docker.itpa.cf и убедимся в наличии службы (см. рис. 21.).
Рисунок 21. Консоль служб 1С.
Как можно увидеть, созданная нами служба остановлена.
Для старта, нажмем кнопку Стартовать, при этом, состояние службы изменится на Up.
Подключимся к службе при помощи консоли администрирования серверов 1С:Предприятие и создадим новую информационную базу(см. рис. 22.).
Рисунок 22. Служба в консоли администрирования
Обновление информационной базы
Для тестирования процесса обновления, создадим новый сервис, с именем “Тестовые базы” и пулом портов 3540, 3541, 3560-3591, новый образ платформы, с версией 8.3.10.2252 и новую службу для этого сервиса. Затем стартуем службу и создаем новую информационную базу в консоли администрирования серверов (см. рис. 23, 24).
Рисунок 23. Список служб 1С для нескольких сервисов.
Рисунок 24. База для обновления в консоли администрирования.
Создадим новый дистрибутив платформы, с версией 8.3.13.1809, образ с пулом 3540 и службу для сервиса “Тестовые базы”.
Результирующий список служб, представлен на рис. 25.
Рисунок 25. Результирующий список служб перед обновлением.
“Ручное” обновление
Как вы уже наверное догадались, процесс обновления версии платформы состоит в том, чтобы остановить службу старой версии платформы и затем, запустить службу новой версии.
Проделаем эти операции и убедимся, что мы работаем с новой версией платформы (см. рис. 26.).
Рисунок 26. Состояние служб 1С после обновления.
Автоматическое обновление
Поскольку обычно, обновление платформы осуществляется в нерабочее для пользователей время, и это же время как правило является формально нерабочим и для IT-персонала, имеет смысл создать процесс, который проделывает все то, что мы сделали при “ручном” обновлении автоматически, в определенное время.
Поскольку в демонстрационной конфигурации такой процесс уже создан, протестируем возможность автоматического обновления по расписанию.
Для этого вернем службы в состояние, соответствующее состоянию до “ручного” обновления, затем выберем в разделе Создать, пункт Обновление платформы.
Заполним необходимые реквизиты (будьте внимательны с датой и временем т.к. часовой пояс и дата на сервере могут отличаться от Вашего) и проведем документ (см. рис 27.).
Рисунок 27. Создание документа “Обновление платформы”.
По достижении указанного времени (плюс время, необходимое для выполнения скрипта) проверим состояние служб и убедимся, что их состояние аналогично состоянию на момент после обновления в “ручном” режиме.
Перенос информационной базы АИТП в Docker
До сих пор, информационная база АИТП, которая управляла контейнерами на нашем сервере docker была расположена на отдельном сервере 1С:Предприятие, и вполне законным будет утверждение о том, что держать один сервер 1С:Предприятие для управления другим слишком расточительно. Поэтому мы перенесем его на тот же сервер, которым управляем.
Единственной проблемой, которая мешает нам это сделать является локальное хранилище дистрибутивов. Поэтому сначала необходимо удалить (пометить на удаление) имеющиеся дистрибутивы (см. рис. 28.).
Рисунок 28. Список дистрибутивов после удаления.
Завершим работу с конфигурацией АИТП на клиентских компьютерах.
Войдем на сервер 1С:Предприятие и остановим и запретим службу 1С, предварительно запомнив параметры подключения к серверу СУБД:
sudo systemctl stop srv1cv83
sudo systemctl disable srv1cv83
В консоли кластера администрирования серверов, добавим информационную базу АИТП на кластер серверов с пулом портов (1540, соответствует сервису “Конфигурация АИТП” ).
Подключимся к информационной базе в пользовательском режиме.
Поскольку нам бы не хотелось, чтобы дистрибутивы платформы пропали при удалении контейнера, (скажем после обновления версии платформы), изменим папку создания на /home/usr1cv8/data, поскольку эта папка перенаправляется с хоста в контейнер.
Поскольку при скачивании дистрибутива, сервис OneScript фактически обращается не к контейнеру, а к хосту, изменим папку хранения дистрибутивов на /home/usr1cv8/ID Сервиса/data.
В моем случае – это /home/usr1cv8/000000001/data
Также изменим сервер хранения дистрибутивов на docker.itpa.cf, а учетную запись на usr1cv8.
Новые настройки хранения дистрибутивов представлены на рис. 29.
Рисунок 29. Новые настройки хранения дистрибутивов
Сохраним изменения и заново создадим дистрибутивы (см. рис. 30.).
Рисунок 30. Вновь созданные дистрибутивы платформы.
Убедимся в их наличии на хосте (см. рис. 31.).
Рисунок 31. Дистрибутивы платформы на хосте.
Создадим образ для пула 1540, 1541, 1560-1591 и версии 8.3.13.1809 (см. рис 32.).
Рисунок 32. Создание образа для сервиса АИТП.
И в процессе выполнения получаем ошибку (см.рис. 33.).
Рисунок 33. Ошибка при создании образа.
которая свидетельствует о том, что система не может соединиться с фермой серверов OneScript для отправки запроса.
Источником данной проблемы являются настройки firewall на нашей ферме, которая была создана по методике, описанной в этой и этой публикациях. Как можно увидеть, с целью усиления безопасности, мы ограничили входящие https запросы компьютерами администрирования и сервером 1С:Предприятия 172.16.210.44.
Добавим разрешения для хоста 172.16.210.40 на нодах и маршрутизаторах:
firewall-cmd –zone=home –add-source=172.16.210.40/32
firewall-cmd –runtime-to-permanent
firewall-cmd --reload
и повторим выполнение задачи.
В результате, получим другую ошибку (см. рис. 34.)
Рисунок 34. Ошибка скачивания дистрибутива платформы.
Которая говорит нам о том, что сервис OneScript не может скачать платформу ввиду отсутствия файла.
Перейдем к настройкам хранения дистрибутивов и при внимательном рассмотрении обнаружим, что путь для скачивания платформы указан неверно.
Поправим его на /home/usr1cv8/1C/data/000000001/data и повторим выполнение задачи.
На сей раз все пройдет гладко и мы сможем увидеть созданный образ в списке образов (см. рис.35.).
Рисунок 35. Образ созданный для сервиса “Конфигурация АИТП”.
Обновление платформы для сервиса “Конфигурация АИТП”
Сначала, создадим службу с новой версией платформы, аналогично тому, как мы это делали ранее.
Дальнейшие действия по обновлению будут несколько отличаться от действий, выполняемых нами ранее, так как обновление платформы предполагает остановку сервиса 1С и после этого момента мы не сможем воспользоваться конфигурацией для осуществления каких-либо действий.
Также следует учесть, что в системе периодически запускаются процессы, стартуют фоновые задания etc. Соответственно простой рестарт сервиса может привести к негативным последствиям, когда выполнение фоновых заданий будет прервано в момент выполнения, поскольку далеко не всегда, системы, с которыми приходится взаимодействовать обеспечивают ACID.
Для подготовки системы к обновлению, в конфигурации есть подсистема Обновление системы (см. рис. 35.).
Рисунок 36. Подсистема “Обновление системы”.
Функции подсистемы заключаются в выполнении действий, предшествующих обновлению системы - запрет старта процессов, запрет выполнения ожидающих выполнение задач, запрет старта регламентных заданий, ожидание выполнения уже запущенных фоновых заданий, а также действий, которые необходимо выполнить после обновления системы – разрешение старта регламентных заданий, новых процессов и задач, ожидающих выполнения.
Схема проверки завершения фоновых заданий, представлена на рис. 37.
Рисунок 37. Схема проверки завершения фоновых заданий.
Проверка завершения фоновых заданий осуществляется в регламентном задании ОбработчикОжиданияЗавершенияФоновыхЗаданийАИТП. Его расписание определяет период выполнения проверок.
Количество выполнений задания и интервал неактивности задаются в настройках подготовки к обновлению.
Заполним эти настройки и настроим расписание регламентного задания (см. рис. 38, 39.).
Рисунок 38. Настройки подготовки к обновлению.
Рисунок 39. Настройки регламентного задания для проверки завершения фоновых заданий.
Приведенные выше настройки означают, что 5 раз с интервалом в минуту будет проверен факт того, что последнее фоновое задание было завершено не позднее, чем 120 секунд тому назад.
Если это условие не будет соблюдено в течении 5 проверок, система будет считать, что подготовка завершилась неудачей и вернет все в исходное состояние.
“Ручное” обновление
Выберем пункт Подготовить систему к обновлению и создадим новый документ.
Мы можем запланировать эти действия на определенное время и указать, что в случае возникновении каких-либо ошибок, необходимо автоматически вернуть все в исходное состояние.
Поскольку в нашем случае этого не требуется, просто проведем документ. После его проведения, процесс подготовки стартует автоматически.
Пронаблюдать за процессом подготовки можно в разделе Задачи ИТ-процессов, подсистемы Оркестратор.
После того, как процесс будет успешно выполнен, завершаем клиентские соединения с информационной базой АИТП, предварительно запомнив идентификаторы текущей и новой службы, которые соответствуют именам соответствующих контейнеров. В моем случае это – 000000001 и 000000004.
Подключаемся к серверу docker, останавливаем старый контейнер:
docker stop 000000001
Запрещаем ему рестарт:
docker container update --restart=no 000000001
Разрешаем рестарт новому контейнеру:
docker container update --restart=always 000000004
Стартуем новый контейнер:
docker start 000000004
Подключаемся к информационной базе в режиме предприятие, выбираем пункт Выполнить действия после обновления в подсистеме Обновление системы, создадим новый документ и проведем его. При проведении стартует бизнес процесс, который выполнит действия, обратные действиям перед обновлением (разрешит старт процессов, выполнение регламентных заданий etc.). Пронаблюдать за его работой можно в разделе Задачи ИТ-процессов, подсистемы Оркестратор.
Автоматическое обновление
Алгоритм автоматического обновления системы АИТП, мало чем отличается от алгоритма “ручного” обновления. Также, как и в предыдущем случае, необходимо подготовить систему, провести обновление и выполнить действия после обновления. Однако, ввиду того, что обновление осуществляется в автоматическом режиме есть некоторые нюансы.
Поскольку в процессе обновления службы 1С:Предприятие должны быть остановлены, скрипт обновления должен запускаться асинхронно.
Также, конфигурация должна каким-то образом узнать, что обновление произошло и выполнить действия после обновления. Этот функционал реализован в процессе ВыполнитьДействияПослеОбновленияАИТП, схема которго представлена на рис. 40.
Рисунок 40. Схема процесса выполнения действий после обновления.
Как можно увидеть, процесс имеет два режима выполнения. В первом, происходит разрешение использования регламентных заданий и старта процессов. Во втором, создается задача ожидания и активируется регламентное задание ПроверитьОкончаниеОбновленияАИТП, которое в обычном режиме выключено и должно быть запущено до того, как службы 1С будут остановлены. По окончанию обновления, когда службы сервера будут вновь запущены, регламентное задание выполнит задачу ожидания и начнется выполнение задания, которое разрешит старт процессов etc.
Поскольку остановка служб может занять некоторое время, для предотвращения ложного срабатывания вводится некоторая задержка, определяемая константой МинимальнаяДлительностьОбновленияАИТП. Соответственно задача ожидания не будет выполнена ранее, чем дата создания задачи плюс значение задержки.
Поскольку процесс выполнения действий после обновления должен быть запущен практически одновременно с процессом обновления, существует вероятность того, что к моменту остановки служб 1С регламентное задание еще не будет разрешено, а задача ожидания не будет сформирована. Для предотвращения этой ситуации, в самом скрипте, перед началом обновления необходимо ввести небольшую задержку.
Исходный код скрипта обновления представлен ниже:
Теперь посмотрим, как это работает на практике. Для этого, настроим расписание регламентного задания “АИТП: Проверить окончание обновления” таким образом, чтобы оно выполнялось раз в 60 секунд. Флажок Использование устанавливать не надо, так как он будет установлен автоматически.
В разделе Сервис, подсистемы Обновление системы, выберем пункт Настройки подготовки к обновлению и установим значение в поле Минимальная длительность обновления, равным, скажем 60 с.
В подсистеме Управление контейнерами, создадим документ Обновление платформы.
Установим чекбокс Это обновление АИТП, выберем текущую и новую службы (список доступных служб, а также текущую можно посмотреть в консоли служб 1С). Установим значение даты обновления равным началу вчерашнего дня, чтобы обновление началось сразу и проведем документ.
Просмотреть ход процесса, можно выбрав пункт Задачи ИТ-процессов, подсистемы Оркестратор. Если все настроено правильно, через некоторое время, при попытке работы с платформой, вы получите сообщение о несоответствии версий клиента и сервера. Закройте клиентское приложение и перезапустите его. Просмотрите информацию о платформе, чтобы убедиться, что обновление произошло.
Заключение
Надеюсь, что данный материал будет вам полезен и позволит сэкономить некоторое количество времени, а также сделать процесс обновления платформы на серверах чуть более простым и приятным.
P.S.
Конечно в производственных средах, также необходимо настроить оповещения и адресацию задач.
