⚡️Подробности про установку 1С в кластер Kubernetes
Манифесты для серверов 1С у меня уже были подготовлены, поэтому после настройки DNS я просто применил их.
Два сервера 1С получили EXTERNAL-IP из того диапазона, который я ранее определил в metallb.yaml, а имена соответствующих им LoadBalancer-ов успешно резолвились с моего хоста.
Для начала я попробовал создать информационную базу прямо с локальной машины, но столкнулся с тем, что СУБД должна быть с нее доступна 🤯. Я не публиковал ее наружу и не планировал, поэтому пришлось создавать базу изнутри контейнера.
Тут же обнаружилось несколько нюансов, связанных с cloudnative-pg: я взял 1С-совместимый образ, но совершенно забыл, что оператор cloudnative-pg переопределяет ENTRYPOINT. Это привело к двум проблемам:
1️⃣ стандартный пользователь app по-умолчанию является тварью дрожащей учеткой без каких-либо привилегий и не может создавать БД
2️⃣ кластер Postgres инициализировался с локалью en_EN.UTF-8 и с неправильным параметром --lc-collate=C, о чем платформа не постеснялась мне сообщить в консоли
Поэтому я почитал доку к cloudnative-pg (давно пора 😅) и немного дополнил манифест кластера Postgres в файле cnpg.yaml.
> ВАЖНО! Применение обновленного манифеста поверх имеющегося кластера вызовет его аварийную остановку. Поэтому лучше снести кластер и его PVC, а затем задеплоить по-новой.
Кстати, пароль от учётной записи app задаётся в типичном для Kubernetes стиле - с использованием секретов (Secrets).
После всего этого база 1С создалась и я добавил ее в список баз на локальной машине, причем сервер 1С я указал как server1c-01-lb.default.cluster.local. Но при запуске в режиме конфигуратора меня ждала подстава в виде ошибки:
Временный сбой в разрешении имен: server1c-01-0 и тд и тп
❓Откуда server1c-01-0?
Дело в том, что менеджер кластера передает клиенту адрес рабочего процесса с тем именем сервера 1С, которое указано в реестре кластера. А какое имя указано в реестре кластера? Правильно - имя хоста, то есть пода, то есть server1c-01-0. А моя локальная машина ничего не знает об именах подов в Kubernetes, да и не должна знать. Выходит, нужно сделать так, чтобы платформа возвращала имя сервиса с типом LoadBalancer.
Я попробовал удалить кластер и создать его заново с помощью rac с правильным именем хоста, в моем случае это server1c-01-lb.default.cluster.local. Но rac выдал ошибку:
Ошибка операции администрирования
Local host parameters are not found
command terminated with exit code 255
Похоже, в платформе есть какая-то проверка на то, что создание кластера должно выполняться именно на localhost.
Как заставить систему думать, что некое имя ресурса это localhost? Самый простой способ - с помощью /etc/hosts!
А в шаблоне пода в StatefulSet для этого есть даже специальный параметр:
...
spec:
hostAliases:
- ip: "127.0.0.1"
hostnames:
- "server1c-02-lb.default.cluster.local"
...
И это даже нельзя считать грязным хаком. Помните, в одном из прошлых постов я хотел, чтобы внутренний трафик ходил напрямую, а не через LoadBalancer? Короче, одним выстрелом двух зайцев, по крайней мере в рамках одного сервера 1С это будет работать. Получается, что Headless-сервисы пока мне не нужны.
Как обычно, дополнил и скорректировал лабу 03-kind-hello-world-1c.
Итогов года не будет, потому что канал я создал только в конце ноября. Но зато планы на 2026 год у меня большие! Перечислю несколько интересных задач:
🔸 активировать коммьюнити-лицензию на моем стенде
🔸 по-честному объединить несколько серверов 1С в кластер
🔸 добыть найти несколько серверных лицензий уровня КОРП для экспериментов
🔸 попробовать написать свой оператор для 1С (потихоньку уже изучаю go 😎)
🔸 проработать observability кластера: сбор метрик, ТЖ
Всех с наступающим! 🎄
Спасибо, что следите за моим каналом!
Манифесты для серверов 1С у меня уже были подготовлены, поэтому после настройки DNS я просто применил их.
Два сервера 1С получили EXTERNAL-IP из того диапазона, который я ранее определил в metallb.yaml, а имена соответствующих им LoadBalancer-ов успешно резолвились с моего хоста.
Для начала я попробовал создать информационную базу прямо с локальной машины, но столкнулся с тем, что СУБД должна быть с нее доступна 🤯. Я не публиковал ее наружу и не планировал, поэтому пришлось создавать базу изнутри контейнера.
Тут же обнаружилось несколько нюансов, связанных с cloudnative-pg: я взял 1С-совместимый образ, но совершенно забыл, что оператор cloudnative-pg переопределяет ENTRYPOINT. Это привело к двум проблемам:
1️⃣ стандартный пользователь app по-умолчанию является тварью дрожащей учеткой без каких-либо привилегий и не может создавать БД
2️⃣ кластер Postgres инициализировался с локалью en_EN.UTF-8 и с неправильным параметром --lc-collate=C, о чем платформа не постеснялась мне сообщить в консоли
Поэтому я почитал доку к cloudnative-pg (давно пора 😅) и немного дополнил манифест кластера Postgres в файле cnpg.yaml.
> ВАЖНО! Применение обновленного манифеста поверх имеющегося кластера вызовет его аварийную остановку. Поэтому лучше снести кластер и его PVC, а затем задеплоить по-новой.
Кстати, пароль от учётной записи app задаётся в типичном для Kubernetes стиле - с использованием секретов (Secrets).
После всего этого база 1С создалась и я добавил ее в список баз на локальной машине, причем сервер 1С я указал как server1c-01-lb.default.cluster.local. Но при запуске в режиме конфигуратора меня ждала подстава в виде ошибки:
Временный сбой в разрешении имен: server1c-01-0 и тд и тп
❓Откуда server1c-01-0?
Дело в том, что менеджер кластера передает клиенту адрес рабочего процесса с тем именем сервера 1С, которое указано в реестре кластера. А какое имя указано в реестре кластера? Правильно - имя хоста, то есть пода, то есть server1c-01-0. А моя локальная машина ничего не знает об именах подов в Kubernetes, да и не должна знать. Выходит, нужно сделать так, чтобы платформа возвращала имя сервиса с типом LoadBalancer.
Я попробовал удалить кластер и создать его заново с помощью rac с правильным именем хоста, в моем случае это server1c-01-lb.default.cluster.local. Но rac выдал ошибку:
Ошибка операции администрирования
Local host parameters are not found
command terminated with exit code 255
Похоже, в платформе есть какая-то проверка на то, что создание кластера должно выполняться именно на localhost.
Как заставить систему думать, что некое имя ресурса это localhost? Самый простой способ - с помощью /etc/hosts!
А в шаблоне пода в StatefulSet для этого есть даже специальный параметр:
...
spec:
hostAliases:
- ip: "127.0.0.1"
hostnames:
- "server1c-02-lb.default.cluster.local"
...
И это даже нельзя считать грязным хаком. Помните, в одном из прошлых постов я хотел, чтобы внутренний трафик ходил напрямую, а не через LoadBalancer? Короче, одним выстрелом двух зайцев, по крайней мере в рамках одного сервера 1С это будет работать. Получается, что Headless-сервисы пока мне не нужны.
Как обычно, дополнил и скорректировал лабу 03-kind-hello-world-1c.
Итогов года не будет, потому что канал я создал только в конце ноября. Но зато планы на 2026 год у меня большие! Перечислю несколько интересных задач:
🔸 активировать коммьюнити-лицензию на моем стенде
🔸 по-честному объединить несколько серверов 1С в кластер
🔸 добыть найти несколько серверных лицензий уровня КОРП для экспериментов
🔸 попробовать написать свой оператор для 1С (потихоньку уже изучаю go 😎)
🔸 проработать observability кластера: сбор метрик, ТЖ
Всех с наступающим! 🎄
Спасибо, что следите за моим каналом!