✨ Идеальный конечный результат
⚠️ Если терминология и концепции звучат незнакомо - не переживайте и скорее подписывайтесь, потому что в следующих постах я шаг за шагом всё разъясню.
В первом посте я привел примеры операций, которые предстоит реализовать через манифесты и kubectl.
Здесь расскажу чуть подробнее о своем видении. Включайте воображение:
Имеем кластер k8s на несколько узлов, в котором установлен ArgoCD и какой-нибудь observability-стек типа VictoriaMetrics. В ArgoCD добавлено приложение (Application), желаемая конфигурация которого находится в определенной ветке репозитория GitLab. Репозиторий хранит заготовку нашего кластера 1C в виде yaml-манифестов или helm-чарта. Прямо в репозитории мы указываем параметры нашего кластера: количество центральных и рабочих серверов, ТНФ, подключаем сервер лицензирования, подсовываем конфиг для техжурнала. Мы коммитим и пушим наши изменения в репозиторий. ArgoCD определяет, что приложение рассинхронизировано с веткой, получает новые версии манифестов и начинает их применять в кластере. Что при этом происходит:
• поднимаются поды с контейнерами, в которых работают серверы 1С
• стартуют сервисы k8s (LoadBalancer, ClusterIP), поды подключаются к сервисам k8s
• некоторые сервисы k8s публикуются "наружу"
• из серверов 1С собирается кластер, на них настраиваются ТНФ, активируются лицензии
• подключаются экспортеры для техжурнала
Вуаля! Кластер работоспособен, а вы - великолепны. Можно создавать информационные базы и работать. Причем, любые изменения в конфигурации кластера 1С в дальнейшем выполняются точно так же, через git. А там, где git, там и версионирование, а там, где версионирование, там и контроль, и возможность откатить действие. К слову, этот подход называется GitOps.
📈 Наиболее смелая идея - это сделать так, чтобы кластер 1С мог автомасштабироваться в зависимости от нагрузки. Представьте, что когда в нашу ИБ зайдет еще 500 пользователей, то кубер автоматически создаст новый сервер 1С и подключит его к кластеру. А когда нагрузка снизится, то сервер будет удален. How cool is that? 😎
Я еще не решил, нужно ли делать так, чтобы сущность "Информационная база" тоже была объектом первого класса в k8s. Пока думаю, что нет, но в том же Strimzi из предыдущего поста даже такие штуки как Kafka Topic можно создавать с помощью отдельного манифеста. В общем, я буду рад услышать ваши соображения на этот счет.
Кстати, пишите мне пожелания, о чем надо рассказать подробнее. Особенно если ни*его не понял, но очень интересно 😁
⚠️ Если терминология и концепции звучат незнакомо - не переживайте и скорее подписывайтесь, потому что в следующих постах я шаг за шагом всё разъясню.
В первом посте я привел примеры операций, которые предстоит реализовать через манифесты и kubectl.
Здесь расскажу чуть подробнее о своем видении. Включайте воображение:
Имеем кластер k8s на несколько узлов, в котором установлен ArgoCD и какой-нибудь observability-стек типа VictoriaMetrics. В ArgoCD добавлено приложение (Application), желаемая конфигурация которого находится в определенной ветке репозитория GitLab. Репозиторий хранит заготовку нашего кластера 1C в виде yaml-манифестов или helm-чарта. Прямо в репозитории мы указываем параметры нашего кластера: количество центральных и рабочих серверов, ТНФ, подключаем сервер лицензирования, подсовываем конфиг для техжурнала. Мы коммитим и пушим наши изменения в репозиторий. ArgoCD определяет, что приложение рассинхронизировано с веткой, получает новые версии манифестов и начинает их применять в кластере. Что при этом происходит:
• поднимаются поды с контейнерами, в которых работают серверы 1С
• стартуют сервисы k8s (LoadBalancer, ClusterIP), поды подключаются к сервисам k8s
• некоторые сервисы k8s публикуются "наружу"
• из серверов 1С собирается кластер, на них настраиваются ТНФ, активируются лицензии
• подключаются экспортеры для техжурнала
Вуаля! Кластер работоспособен, а вы - великолепны. Можно создавать информационные базы и работать. Причем, любые изменения в конфигурации кластера 1С в дальнейшем выполняются точно так же, через git. А там, где git, там и версионирование, а там, где версионирование, там и контроль, и возможность откатить действие. К слову, этот подход называется GitOps.
📈 Наиболее смелая идея - это сделать так, чтобы кластер 1С мог автомасштабироваться в зависимости от нагрузки. Представьте, что когда в нашу ИБ зайдет еще 500 пользователей, то кубер автоматически создаст новый сервер 1С и подключит его к кластеру. А когда нагрузка снизится, то сервер будет удален. How cool is that? 😎
Я еще не решил, нужно ли делать так, чтобы сущность "Информационная база" тоже была объектом первого класса в k8s. Пока думаю, что нет, но в том же Strimzi из предыдущего поста даже такие штуки как Kafka Topic можно создавать с помощью отдельного манифеста. В общем, я буду рад услышать ваши соображения на этот счет.
Кстати, пишите мне пожелания, о чем надо рассказать подробнее. Особенно если ни*его не понял, но очень интересно 😁