Ферма приложений на Kubernetes

24.08.20

Интеграция - WEB-интеграция

При эксплуатации большого количества информационных систем 1С, предоставляющих интернет-сервисы, возникают проблемы, связанные с зависимостью от производительности и стабильности веб-сервера. Как объединить отдельно стоящие веб-сервера с помощью платформы Kubernetes для централизованного мониторинга всех опубликованных интернет-сервисов на конференции Infostart Event 2019 Inception рассказал программист компании BIA Technologies Владимир Кирбаба.

Меня зовут Владимир Кирбаба, я работаю программистом в компании BIA Technologies. Наша компания занимается разработкой и интеграцией программных комплексов для бизнеса.

И сегодня я хочу познакомить вас с нашей фермой приложений на Kubernetes.

 

 

Зачем нужны интернет-сервисы и как мы управляем ими через Kubernetes

Как известно, платформа «1С:Предприятие» имеет возможность предоставления своей функциональности посредством интернет-сервисов. А наша ферма – это не что иное, как средство для организации управления всеми интернет-сервисами нашей компании.

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

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

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

 

 

На слайде вы можете видеть скриншот рабочего стола нашего кластера Kubernetes, на котором отображается:

  •  информация обо всех приложениях, работающих в кластере прямо сейчас;
  •  и некоторая сводная информация о ресурсах, потребляемых всеми приложениями.

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

На скриншоте видно, что у нас есть около 400 приложений, постоянно работающих в кластере, и в этом списке есть абсолютно все виды интернет-сервисов, реализованные на платформе 1С:Предприятие. Это – всем известные веб-сервисы, HTTP-сервисы, даже веб-клиенты и стандартный интерфейс oData.

 

Как сервисы предоставляются платформой 1С:Предприятие

 

 

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

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

  •  управление пулом соединений с информационной базой;
  •  поддержка WSDL-описания функций;
  •  реализация SOAP-протокола;
  •  сериализация сообщения;
  •  и вызов конкретного нужного сервиса из 1С.

Но что самое интересное, менеджер сервисов выполняется в процессе веб-сервера, который по факту является передатчиком:

  •  принимает сообщения из сети и передает их менеджеру сервисов;
  •  и наоборот, принимает сообщения от менеджера сервисов и передает их обратно в сеть.

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

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

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

 

Как повысить устойчивость предоставляемого сервиса

 

 

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

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

 

 

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

 

Как распределить нагрузку между процессами одного сервиса. Технология контейнеризации Docker

 

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

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

 

 

Что же мы по факту называем контейнеризированным приложением при публикации интернет-сервисов для операционной системы:

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

А для получения таких контейнеризированных приложений, сразу скажу, что платформа Kubernetes поддерживает множество различных технологий контейнеризации и даже некоторые технологии аппаратной виртуализации. Но мы в компании BIA-Technologies используем технологию Docker.

 

 

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

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

Текст файла сборки Dockerfile для сборки контейнера я привел на слайде. Если убрать комментарии, в нем останется всего три строки – настолько просто создать контейнеризированное приложение, используя Docker.

 

Как сократить издержки на обслуживание пула веб-серверов. Платформа Kubernetes

 

 

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

Как выглядит процесс развертывания приложения в кластере Kubernetes? Его можно сравнить с запуском любого приложения в виртуальной машине:

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

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

Как я уже упомянул, нас интересует именно масштабирование. А как приятный бонус – если при дублировании конфигурации веб-серверов приходилось управлять входящим потоком сообщений, то Kubernetes делает это автоматически – масштабируя приложение, он автоматически может распределять входящий поток между элементами вашего приложения.

 

 

Платформа Kubernetes как программа реализует архитектуру «ведущий и ведомый», где:

  • У ведущего компонента (или мастера платформы) выделяют подсистему управления главным компонентом, которым является сервер API. Именно сервер API управляет внешним и внутренним доступом к функциям Kubernetes.
  • А ведомые компоненты платформы (или, иначе, узлы) – это физические или виртуальные машины, на которых развернуты и выполняются ваши приложения. Для эффективного управления жизненным циклом приложений, их развертыванием и предоставлением доступа к ним необходимо будет создавать некоторые объекты подсистемы управления – непосредственно взаимодействуя с сервером API.

Базовым компонентом для управления и запуска приложения в Kubernetes является объект под названием Pod (в переводе с английского «стручок»). Объекту типа Pod:

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

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

  • объекты типа Pod не предназначены для долговременного использования, они не переживут сбоя в работе планировщика (планировщик – это компонент подсистемы «Управление», который отвечает за назначение Pod'ов на узлы);
  • еще Pod’ы не переживут падение узла, на котором они размещены – если ноду выключат из розетки, то все Pod’ы, которые там были созданы, прекратят свое существование.

Чтобы использовать возможности самовосстановления Pod’а, а также управления процессами его развертывания и репликации, разработчики платформы Kubernetes советуют нам использовать объекты-контроллеры.

Существует контроллер репликации, который:

  • гарантирует нахождение заданного количества Pod’ов (контейнеров) и размещение их на узлах;
  • связан с ведомыми Pod’ами внутренней ссылкой и постоянно опрашивает об их текущем состоянии;
  • контроллер репликации может реагировать на такие моменты, как внезапное исчезновение Pod’а (его нужно создать) или почему-то Pod’ов стало больше (некоторые нужно удалить);
  • контроллер репликации способен анализировать текущее состояние Pod’а – например, по заданным нами алгоритмам он может все время опрашивать TCP-порт веб-сервера, выполняющегося в Pod’е, и в случае, если веб-сервер завис, перезапустить образ или контейнер внутри Pod’а (все остается, как было, просто контейнер перезагрузится);
  • а из-за того, что контроллер репликации перманентно поддерживает несколько Pod’ов для обеспечения жизнедеятельности всего приложения, мы можем говорить, что пользователи не теряют ни секунды времени из-за недоступности интернет-сервиса.

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

Также разработчики платформы Kubernetes советуют нам использовать более высокоуровневую концепцию – так называемые контроллеры развертывания, которые имеют возможность управлять контроллерами репликации, а также предоставлять декларативное обновление Pod’ов.

  • Оператор, взаимодействуя с подсистемой управления, создает новый контроллер развертывания.
  • Контроллер развертывания в свою очередь через взаимодействие с подсистемой управления создаст необходимый контроллер репликации.
  • Контролер репликации тоже будет взаимодействовать с подсистемой управления и создаст новые Pod’ы, если они нужны, в том количестве, в котором они нужны.
  • Если вчера ваша информационная система была под управлением платформы версии 8.2, а сегодня вы используете платформу 8.3, и все сервисы из-за этого вдруг перестали работать – тогда, чтобы это исправить, вы изменяете декларативное описание в контроллере развертывания, указывая новую версию платформы. Все остальное на себя берет платформа Kubernetes, а вам остается только проверить статус состояния операции развертывания, опросив платформу Kubernetes по имени созданного вами контроллера.

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

А для централизованного хранения всеми образами мы используем репозиторий под управлением GitLab. Там очень легко настроить хранилище образов. Оно совершенно бесплатно встроено в систему управления. Это очень удобно.

 

Заключение

 

 

В качестве итога своей речи я хотел бы еще раз озвучить:

  • Нам, используя технологию контейнеризации, удалось, имея всего один образ Docker, опубликовать все интернет-сервисы информационной системы и разграничить их процессы друг от друга, что физически сказалось на скорости работы наших сервисов. Не внося изменений в логику наших сервисов, они начали работать примерно на 50% лучше – в зависимости от нагрузки на конкретные интернет-сервисы.
  • Используя технологии масштабирования или репликации платформы Kubernetes, мы можем повышать устойчивость публикации наших сервисов за счет увеличения количества веб-серверов, на которых они размещены.
  • Также платформа Kubernetes позволяет нам использовать данные употребляемых ресурсов. Для большей экономии мы можем конкретно этому Pod’у выделить столько ресурсов, а соседнему – чуть больше или чуть меньше, в зависимости от нагрузки на интернет-сервис.
  • Все описанные мною практики и инструкции применяются в нашей компании уже долгое время, и по результатам их использования мы получили только положительные отзывы.
  • Мы автоматизировали работу создания необходимых объектов платформы Kubernetes через 1С. Наши разработчики работают только со справочником, создают новые записи, а взаимодействие между платформой 1С:Предприятие и Kubernetes происходит по сети через HTTP в стиле REST. Акцентирую ваше внимание – это Kubernetes, который работает из 1С, он подчиняется командам из справочника одной информационной системы. Это инструмент поднятия контейнеров Kubernetes, исходя из данных справочника 1С.
  • Мы избавились от всех ранее отдельно стоящих веб-серверов. Даже разработчики больше не используют локальные веб-сервера – все это происходит в платформе.
  • Из-за того, что все ранее отдельно стоящие веб-сервера теперь объединены установленной для них платформой Kubernetes, мы имеем возможность централизованного мониторинга всех опубликованных интернет-сервисов, а также снизили издержки на администрирование всего этого, потому что обновляем все централизовано через возможности Kubernetes.

 

От ведущего

 

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

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

Это не просто High Availability, где можно HAProxy поставить и переключать с одного IP на другой. Это несколько другой мир. Грубо говоря, выделяется пул IP-шников. Выделяется облако. Если у вас больше 10 серверов, вы размещаетесь в нескольких дата-центрах – положить приложение всеми усилиями очень сложно. Современные облака работают вот так. Если у вас что-то тормозит, вы просто добавляете сервер. Платформа Kubernetes видит, что у нее появился еще один сервер, и увеличивает ресурсы, закидывая несколько контейнеров на новый сервер. Это работает вот так.

Это не какой-то космос. Есть сборка, называется Minikube. Там три строчки инсталляции. Можно эту сборку поставить себе, открыть веб-интерфейс и попробовать посоздавать там эти Pod’ы – поэкспериментировать, попробовать и посмотреть, как работает. Оно вполне user-friendly – вы можете очень легко поиграться – запустить у себя файловую базу в одном кластере для одной ноды. Поставьте себе Kubernetes, модуль расширения веб-сервера и Apache в докере – это можно использовать, на этом можно реально построить отказоустойчивое решение.

Единственное, что еще один комментарий я хотел сказать – в stateful Pod’ы (stateful конейнеры) запихивать базу данных не нужно. Саму БД и данные запихивать в Kubernetes не нужно. С этим есть определенные проблемы и трудности.

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

Завалить Kubernetes – это то же самое, что забанить Telegram в России. Наверное, можно, но очень трудно, и не всем под силу. Это – будущее, это реальный HighLoad, это облака.

Сначала мы познакомились с Docker, потом мы познакомились с Docker-compose, теперь мы научились работать с Kubernetes в 1С. Растем – теперь мы можем строить реальные облака 1С-ок без использования технологии 1СFresh, потому что реальные облака делаются вот так.

 

Вопросы

 

  • Я правильно понимаю, внутри Docker располагается серверная часть платформы? А как решаются вопросы лицензирования? Она же требует индивидуального лицензирования? Как вы это решали в случае масштабирования, увеличения количества Docker-контейнеров?
  • Если сервер лицензирования находится в одной подсети, все можно легко организовать, просто прописав маршруты получения этих лицензий.
  • Вопрос про масштабируемость и отказоустойчивость – скажите, пожалуйста, когда у вас несколько нод, и при падении одной ноды каналы прописаны до сервисов – меняются адреса и т.д. Как происходит это переключение? Keep alive переключается или IP меняется? Какими средствами это организовано?
  • Кластер Kubernetes – это несколько машин, соединенных одним программным обеспечением. У него есть целый набор IP-адресов, по которым он откликается. Объединяя их всех одним доменным именем, мы сразу обращаемся ко всему кластеру. До тех пор, пока весь кластер устойчив – а это зависит именно от мастера кластера, не важно, что происходит с нашими узлами. Контроллеры репликации гарантируют восстановление подконтрольных им Pod’ов. И если у вас упал узел, контроллер репликации быстро создаст новые Pod’ы на других узлах. Все равно используется пул IP-адресов.
  • Я в своем докладе сказал, что только узел является физической или виртуальной машиной, а Kubernetes-мастер не является никакой машиной, он может стоять на одном компьютере с узлом, просто выполнять функции управления узлами и предоставлять доступ к компонентам управления объектами (как к внутренним, так и внешним).
  • Еще одно дополнение по поводу использования ресурсов и динамической балансировки. Платформа Kubernetes также предоставляет возможность декларативно указывать, какой будет реакция на повышение нагрузки. Можно указать, что изначально у вас есть два Pod’а, которые работают вхолостую и разнесены по двум разным нодам. При повышении нагрузки Kubernetes автоматически поднимет необходимое дополнительное количество этих Pod’ов. Опять же, при снижении нагрузки он высвободит ресурсы. Вот такая еще возможность есть.
  • Рассматривали ли вы с качестве оркестрации Docker Swarm? Если да, то какие плюсы Kubernetes вы видите по сравнению со Swarm? И еще один вопрос – если падает мастер-нода Kubernetes, что будет с кластером?
  • Если упадет мастер, у вас не будет кластера. А Docker Swarm – я только читал об этом, но фактически не использовал. Хотя я знаю, что Docker Swarm используется именно для этих же целей – как раз для масштабирования, управления развертыванием и запуска приложения.
  • Я хочу уточнить про пул IP-адресов. Вы используете какую-то DNS-службу, которая вам сервисы предоставляет?
  • Да, на каждом узле  Kubernetes существует свой прокси, Pod’ам, размещенным на узле, присваивается уникальный IP-адрес, но в пределах кластера. Соответственно, обращаясь к Kubernetes, переадресация к конкретному Pod’у происходит с использованием прокси, который находится на каждом узле.
  • А как сочетается то, что система очень отказоустойчивая, но если упадет мастер-нода, то работать ничего не будет. Как вы боретесь с тем, чтобы он не умер?
  • Во-первых, HAProxy никто не отменял, во-вторых, мастеров может быть несколько. Это не значит, что мастер – это целый большой сервер. Это может быть маленькая виртуальная машина, которая практически не потребляет ресурсов, ничего не делает. Ты на каждой ноде можешь развернуть мастеров. Это не 1С, это другая история. Чтобы это упало, надо постараться.
  • У кластера где-то должен храниться реестр – что вы используете в качестве хранилища, которое видно со всех машин кластера и может писаться и читаться. Или для работы Kubernetes это не нужно? Не в плане образа Docker, а в плане метаданных самого кластера, которым оперирует мастер – он же должен знать, где у него что поднято и т.д. Где он это хранит? Обычно используется GlusterFS – какое-то распределенное хранилище. Что у Kubernetes для этого? Что-то свое?
  • Да, у Kubernetes в подсистеме управления находится хранилище, к которому имеют доступ сервер API, планировщик и контроллер менеджеров. Всего три компонента всей подсистемы управления имеют доступ к хранилищу.

 

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

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

 

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

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

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

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

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

 


См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме. Без существенных изменений типовой конфигурации. Проверено с брендами: Интеграция 1С и GEELY Интеграция 1С и HAVAL Интеграция 1С и KIA Интеграция 1С и FORD Интеграция 1С и LADA ГАРАНТИЯ 100% ВНЕДРЕНИЯ!

36000 руб.

03.08.2020    15655    9    17    

9

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    12809    30    8    

10

Интеграция 1С — Битрикс24. Обмен задачами

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

Интеграция 1С и Битрикс24. Разработка имеет двухстороннюю синхронизацию 1С и Битрикс24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (8.3.18.1289). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    17419    6    15    

13

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25686    9    0    

7

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16253    41    49    

22
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. seeges 23.03.21 18:55 Сейчас в теме
Могли бы вы подсказать:
1) вам удалось добиться горизонтального масштабирования серверной части 1С путем размещения ее в докере? Что вы делаете когда не хватает ресурсов для серверной части 1С и требуется больше ресурсов - вы поднимаете новый контейнер с серверной частью 1С? Если да, то как эти "две части" работают с одной базой данных? Или под "серверной частью" вы понимаете именно модуль расширения веб-серверов?
2) когда вы пишете о преимуществам упаковки веб-сервисов 1С в контейнеры, вы говорите о только об отказоустойчивости? Правильно ли я понимаю, что "разбрасывать нагрузку" по контейнерам для одного веб-сервиса нет смысла, т.к. фактически на стороне веб-сервиса (модуля расширения веб-серверов) не выполняется программный код (он же выполняется на стороне rphost насколько мне известно)?
Оставьте свое сообщение