Клиентская часть 1С:Предприятия в rootless podman-контейнере

Что случилось и зачем это

Так-то я давно не программист и не 1Сник. Но тут понадобилось посмотреть некоторые моменты в 1С, а у меня уже лет 7 даже ОС Windows на рабочем ПК нет. Но случайно купленная "антикризисная" 1С есть и community лицензию никто не отменял. Ставить полноценно 1С в свой любимый уютный арчик я конечно же не буду. Тянуть невнятную гору зависимостей - не-не-не, это точно не наш путь. Ставить виртуальную машину (ВМ) с Windows теоретически можно, но практически даже с моими 128 ГБ RAM, я стараюсь избегать больших и тяжёлых ВМ. А тут - Windows, да у неё минимальный образ что-то типа десятков ГБ! Нет, конечено, тоже не наш метод.

И 1С сопровождает дистрибутивы для linux как-то не то чтобы совсем плохо, но, видимо, по остаточному принципу. То неточная информация, то какие-то странные моменты с поддерживаемыми дистрибутивами и компонентами. Где их клиенты до сих пор Windows покупают - ума не приложу :) , но видимо клиентов под linux не очень-то и много.

Было бы классно, если бы 1С предоставляла, например, flatpak пакеты или что-то подобное для быстрого развёртывания, но... Но я, кажется, был первый, кто предложил это в @platform_suggestions

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

Что и как делать

А что же делать тогда нам, простым linux-извращенцам? А почему бы не заковырять клиента 1С к контейнер? К тому же у меня и так большая часть задачек изолированы по контейнерам. Большинство слышат "контейнер" и сразу думают "Docker", но у меня не docker, а podman. В целом, с точки зрения возможностей и простого пользователя они абсолютно заменяемы, так что обычно можно просто алиас назначить и всё работает, но внутри они отличаются (у podman нет постоянно висящей в памяти службы, например).

Замечу, что контейнер заметно отличается от виртуальной машины. Виртуальная машина запускается гипервизором, который запускается изолированное от реального железа ядро ОС, а ядро ОС с обычными для себя барьерами между кольцами доступа запускает процессы и думает, что оно настоящее ядро настоящей ОС. Гипервизор при этом подменяет железо на виртуализированные ресурсы. Это прекрасная модель для изоляции, но требует заметных избыточных ресурсов (одной только RAM 0,5-1 ГБ). Контейнер же это chroot доведённый до абсолюта. Linux запускает процесс программы как обычно, но подменяет ему файловую систему, сеть, контекст пользователя и переменные окружения на свои собственные. То есть это не вся ОС, а один процесс (программа), которому кажется, что он один в ОС и кажется, что у него есть своя ОС. Но системные вызовы он делает в ядро хоста, события journalctl ловит служба хоста и так далее. Изоляция тут заметно менее строгая. Но и накладных расходов по сути нет. И нередко могут быть папки общие с основным хостом (например, конфигурация ТЖ или сам ТЖ или файловая БД) - файлы в них доступны одновременно и одинаково из хоста и контейнера.

При помощи контейнеров легко делать переносимые "кубики" серверных служб - собственно для этого их и придумали. С клиентскими GUI-приложениями всё почти-почти также, но чуть сложнее. Контейнер не имеет своего графического стека: окно рисует не он, а X-сервер хоста. Контейнеру достаточно (а) найти сервер и (б) иметь право с ним соединиться. Архитектура Linux такова, что (почти) все взаимодействия на низком уровне являются чтением и записью файла (или сокета, что тоже файл). В том числе и вывод на экран. Поэтому можно просто указать контейнеру (примонтировать в него) нужный сокет и передать информацию (cookie).

В общем, взял я кружку кофе, LLM недорогую, положил в папку дистрибутив 1С, описал задачу и сделал набор скриптов, которые позволяют собирать и запускать контейнер. Не с первого раза, не мгновенно (LLM недорогая же), с аккуратной проверкой белковым интеллектом - но всё получилось.

Проверил на 1С 8.3.27 и 8.5.1. Проверил на работе с файловыми БД и с сервером (я же говорил - у меня есть антикризисный сервер-мини, он тоже в контейнерах но это другая история). Проверил, что community-лицензия хранится в постоянных файлах и не теряется в контейнере. На этом базовом уровне всё работает.

Что сделано и где взять, как использовать

Сборщик выложен на github.

В корневом README.md - инструкция по использованию.

Плюс дополнительно в файле run.md можно прочитать подробнее, как это запускать, а в файле integration.md - как контейнер дружится с UI.

Лицензия предполагается, что есть на сервере, но работает и community (просто получаете новую или складываете lic с хоста).

Не уверен, что буду отвечать на issue, но разумные PR могу и влить.

Никаких гарантий качества нет, никаких ожиданий что оно всё само и сразу заработает быть не должно. Если что-то непонятно или не работает - спросите LLM, потом гугл. В крайнем случае - можно спросить меня в стиле "что имел в виду автор".

Удачи в изучении и использовании!