Меня зовут Антон Антонов, я ведущий разработчик в компании IBS. На этом слайде отображены наши текущие реалии – где размещена инфраструктура разработки у нас на проектах:
-
для 40% проектов инфраструктура разработки располагается на серверах заказчика;
-
55% – это наши сервера;
-
5% – это комбинированная инфраструктура, где-то на серверах заказчика и где-то на наших серверах.
Возникает вопрос – каким образом обеспечить единообразие и стабильность этого зоопарка в рамках настроек серверов? Чтобы мы не попадали впросак от того, что при переносе конфигурации на контур заказчика база начнет тормозить, а мы не будем знать, что делать.
Кроме того, при размещении баз под разработку на сервере 1С под Linux возникают проблемы:
-
Например, когда из-за большого количества разработчиков сервер 1С сильно перегружен, сеансы сбрасываются – у нас за месяц было 43 сброса сеансов. Представьте себе, какие это потери по времени для разработчиков, особенно с учетом того, что разработка для части проектов ведется на EDT. Мы запускаем полное обновление, и все просто падает.
-
Ежемесячно 17% времени уходит на ожидание обновления. Люди сидят в креслах и ждут. А что еще делать? В конфигуратор тоже не зайти.
-
Из-за вылета сеансов в процессе обновления у меня на серверах улетело 4 базы. Они не открывались, выпадали в ошибку. Это довольно грустно.
И еще у нашего подразделения возникают проблемы, когда к нам приходят с некоторыми запросами.
-
Например, приходят аналитики и говорят: «Разверните базу с определенной конфигурацией. Нам надо посмотреть, как там работает механизм». Потом оказывается, что минимальная версия платформы для этой конфигурации отличается от той, что у нас на серверах. Начинается свистопляска с установкой дополнительного сервера с определенной версией платформы. И потом еще нужно, чтобы пользователь не забыл, что при работе с этой конфигурации нужно использовать другие порты – не по умолчанию.
-
А еще иногда у нас возникают проблемы с разницей версий, когда по договору с заказчиком разработка должна вестись на контуре, идентичном по версии платформы контуру продуктива. Хорошо, если эта разработка ведется на каком-то отдельном сервере, который выделен чисто под этот проект. А когда это общий сервер – это тоже свистопляска.
-
То же самое – когда при разработке используется комбинированная инфраструктура, что-то разрабатывается на серверах заказчика, а что-то на наших серверах. В этом случае версия платформы должна быть на обоих контурах идентична. Особенно, когда идет разработка под тем же EDT – там четко указана версия. Если ее поменять, при обновлении начинаются проблемы – EDT отказывается запускаться. Снова приходится ставить новый сервер и так далее.
Чтобы убрать эти проблемы и изолировать те же самые вылеты, у нас в организации было принято решение посадить 1С в контейнер.
Контейнеры
Контейнеры – это очень полезная вещь, которая позволяет изолировать сервер 1С.
Немного расскажу про контейнерное ПО.
-
Самое известное ПО для контейнеризации – это Docker.
-
Для выполнения контейнеров Docker использует среду runc.
-
И есть Podman – это альтернатива Docker от Red Hat с некоторыми своими нюансами.
-
И есть crun тоже от Red Hat – по умолчанию Podman использует runc, но можно подключить crun. Причем и runc, и crun можно использовать отдельно друг от друга.
Плюсы и минусы контейнеров для сервера 1С
Преимущества использования контейнеров для сервера 1С:
-
Изоляция – у нас не будет проблем из-за того, что какой-то разработчик перегрузит весь сервер, и все сеансы вылетят. Мы изолируем разработчика, дадим ему личный сервер, дадим определенные настройки, и пусть работает. Он запускает какую-то задачу, которая перегружает данные в тысячу потоков – по out of memory вылетает только его сеанс. Все, проблемы нет.
-
Гибкая настройка параметров – при необходимости мы можем выделить один сервер под одну информационную базу либо под несколько информационных баз. Нужно, чтобы там было именно 10 гигабайт оперативной памяти? Пожалуйста, настроили конкретный контейнер. Это все гибко можно описывать в текстовом виде либо накликивать мышкой. Нужно указать количество потоков процессора? Тоже все делается. Нужно настроить приоритеты использования процессора контейнерами – какой-то контейнер имеет больший приоритет, какой-то меньший? Все это можно сделать.
-
Перезапуски. Стандартный перезапуск сервера 1С неудобен и занимает довольно длительное время. Рестарт контейнера в нашей реализации занимает 10 секунд, причем 5 из них – это таймаут для решения с перебросом хостнейма.
-
Управление удалением. Если сервер больше не нужен, достаточно ввести одну команду – и все, контейнера нет.
-
Развернуть сервер через докер быстрее, чем ставить вручную. Чуть дальше я расскажу об этом подробнее.
Но в использовании контейнеров для сервера 1С есть и минусы:
-
Главная проблема, которая здесь возникает – это проблема лицензий. Потому что у нас может быть сотни информационных баз, а если мы разделяем их по отдельным контейнерам – сотни этих серверных лицензий просто улетают. Проблема с лицензиями – основное, что не позволяет использовать данное решение гибко, как «серебряную пулю».
-
Каждый из этих контейнеров представляет собой отдельную систему, и весь этот зоопарк необходимо мониторить. Заходить в каждый контейнер и запускать top (или htop) – проблемно. По-хорошему, там нужно настроить сбор метрик в Grafana, чтобы это все красиво было.
-
И эта технология пока недостаточно протестирована на стабильность работы. С учетом того, что сервер 1С на Linux мог и лицензии сбрасывать, и другие проблемы с ним возникали, а тут они еще и в контейнере – мы не можем с уверенностью использовать это решение полноценно. На это все пока еще требуется много тестов.
Я прошерстил кучу существующих репозиториев на GitHub c докер-контейнерами, посмотрел статьи на Инфостарте, и готовые решения для использования сервера 1С в контейнере нам не подошли.
-
В первую очередь, потому что они нацелены на загрузку этим же контейнером дистрибутива необходимой платформы с сайта «1С». Это хорошо, но нам лично не подошло, потому что лучше использовать какое-то локальное дополнительное зеркало и с него уже грузить без каких-либо проблем. Мало ли, в конкретной версии платформы какие-то баги, – нам нужна возможность указать, что она недоступна.
-
Отсутствие фиксации hostname – URL. Если вы замечали, 1С очень любит привязываться к хостнеймам. Что в Windows, что в Linux, это можно поправить – либо прописать на клиенте в hosts хостнейм этого компьютера с IP-адресом, либо через DNS указать конкретный URL за конкретной машиной, чтобы 1С ходила туда. Но поскольку Docker назначает IP-адреса динамически, с этим могут возникнуть проблемы. А наше решение поддерживает привязку конкретного URL к машине.
-
С учетом того, что разработка ведется на разных версиях, нам необходимо разово приготовить всю эту пачку образов для различных версий платформы 1С, чтобы потом использовать по необходимости с нужной версией.
-
И у нас запланировано колоссальное расширение функциональности. Мы хотим сделать возможность выбрать себе нужную себе версию 1С, определенную версию дистрибутива – Бухгалтерии предприятия, ERP и чего-то еще. Сделать скрипт, который развернет сервер 1С нужной версии с необходимыми конфигурациями на нем и сразу все отдаст пользователю. Участие человека здесь не планируется. Соответственно, у нас снизятся затраты на администрирование.
Само решение именно в рамках докер-контейнеров и конвейера мы решили выложить в open source.
В репозитории на GitHub можно самим посмотреть, что там сделано, как это все выглядит.
Пулл-реквесты приветствуются, лицензия MIT, делайте с этим, что хотите: можно не указывать авторство и использовать в своих решениях абсолютно бесплатно.
Конвейер
Чтобы понять, как эта штука работает, нужно посмотреть на общую последовательность, общий workflow конвейера.
Используются четыре слоя образов.
-
По умолчанию все находится на образе Ubuntu 20.04.
-
На этот слой ставятся все необходимые зависимости для платформы 1С.
-
Следующий слой – это установка и настройка платформы автоматическими скриптами.
-
И для того, чтобы сократить время запуска, на основе этого слоя сделан слой с уже готовой к эксплуатации системой – этот слой позволяет запустить сформированный сервер буквально за 5 секунд. Старт сервера занимает 5 секунд, точнее 10 с учетом таймаута.
Последователь запуска представлена на слайде:
-
нужно перейти в архив с дистрибутивом;
-
перейти в нужный каталог с конвейером;
-
запустить docker-compose с указанием версии платформы;
-
перейти в каталог с генератором;
-
запустить скрипт генерации;
-
перейти в сгенерированный каталог;
-
запустить docker-compose;
-
перейти в каталог с финальным Dockerfile;
-
изменить .env файл;
-
запустить docker-compose
Да, это длительно, но это в любом случае быстрее, чем ручками настраивать все на голом сервере.
Дальнейшее развитие
В дальнейшем мы хотим всю эту функциональность переложить на дополнительный портал Managed Service, чтобы пользователь мог зайти на портал и сам накликать нужную ему версию.
Сразу скажу, это сильно упрощенная схема – здесь не хватает очень многих управляющих блоков:
-
Крутиться все это будет на Kubernetes, чтобы иметь возможность горизонтального масштабирования и возможность включения подов в кластер серверов. Если мы видим перегруз по какому-то из серверов, Kubernetes понимает, что нужен дополнительный под, разворачивает его, выполняет определенные процедуры и включает этот под в кластер. Нагрузка спала – отключает под от кластера.
-
Слева здесь в качестве отдельной сущности показан тот конвейер, про который я рассказывал на предыдущем слайде – он будет класть подготовленные для Kubernetes образы в Container Registry.
Это позволит управлять инфраструктурой серверов 1С не в ручном режиме, а автоматически – аналитик либо руководитель проекта сможет сам руками создать себе необходимые базы. Это поможет сократить накладные расходы на администрирование, которые могут занимать довольно много времени.
Вопросы и ответы
Почему вы все-таки пошли к контейнерам, а не взяли Terraform, в котором это делается буквально тремя кликами? В Terraform у вас будут настоящие виртуалки, и часть проблем с сервером приложений и его взаимосвязью с другими ресурсами будут решены более оптимально, особенно когда вы говорите по поводу использования этой инфраструктуры на продуктиве заказчика. На контейнерах вы этого не сделаете. Контейнер все-таки для других задач.
Я бы здесь поспорил. Пока проблем, которые связаны с другими ресурсами, банально нет.
Тогда где размещаются остальные компоненты? Или у вас в одном контейнере находится и платформа, и СУБД, и логи, и вы их просто опустили для чистоты доклада?
Для баз данных мы используем вообще частично решение от «Яндекса» – это Managed Service для PostgreSQL. Здесь администрирование полностью на «Яндексе». А для того, чтобы пробросить туда данные, нет проблемы указать необходимый хостнейм.
Вы не пробовали для девелоперов вместо большого сервера приложений использовать кучу маленьких автономных серверов приложений? Я говорю про утилиту ibcmd, которая подключается к конкретной информационной базе.
Не рассматривали вообще.
Вы сказали, что PostgreSQL у вас разворачивается отдельно. Но все мы работаем с заказчиками и там чаще всего все-таки MS SQL. А разработка с PostgreSQL и с MS SQL – это абсолютно разные вещи.
У нас заказчики сейчас все стремятся использовать PostgreSQL. Опять же, никто не мешает пробросить пути и до MicrosoftSQL.
Вы же сами сказали, что основная проблема в совместной разработке и падение баз – это перегрузки на СУБД?
У нас были падения не на СУБД, решалась проблема конкретно с сервером приложений.
Опять же, использовать отдельно инсталляцию MS SQL никто не запрещает. Если у заказчика используется MS SQL, в рамках проекта придется руками делать соответствующие связи.
Мы тоже пробовали использовать серверы 1С в контейнерах для 50 разработчиков, но мы уперлись в лицензирование. Мы официально обращались в «1С», нам официально ответили, что на каждый экземпляр сервера приложений требуется отдельная лицензия. У нас тоже были проблемы с падением сеансов на сервере приложений, но все проблемы решались либо добавлением мощности, либо сменой платформы – не контейнеризацией. Так как вы все-таки с лицензиями поступили?
По лицензиям: мы их просто закупили. Были закуплены лицензии, они переиспользуются. Было использовано самое простое решение, потому что это все в тестовом контуре, у нас нет такого, что сотни баз и серверов крутятся в контейнерах. Используем программную лицензию. Да, слетает, переактивируемся.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.
