Советы о том, как настроить персональные сервисы с Хелмом и Кубернетесом

Question

Это скорее вопрос советов, чем вопрос конкретной техники.

Я провел поиск, но трудно найти точно такую ​​же проблему.Если вы считаете, что это дубликат еще одного вопроса, пожалуйста, дайте мне несколько ссылок!: -)

Контекст

Как и многие разработчики (я предполагаю), у меня есть один сервер "Пещера Али Бабы", на котором размещен мой блог, и несколько служб: GitLab, Minio, система биллинга для моего внештатного сотрудникаучетная запись и т. д. *

Все службы настраиваются на сервере Ubuntu различными способами в зависимости от имеющихся у меня возможностей: apt-get install, извлечение tar или развертывание Capistrano для личных проектов.

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

Потребности

В настоящее время я изучаю диаграммы Kubernetes и Helm.Цель состоит в том, чтобы настроить новый сервер CoreOS и экосистему Kubernetes со всеми моими приложениями и проектами на нем.

С этим я смогу:

• Чтобы избавиться отад обслуживания с полностью независимыми приложениями.
• Простота поддержки конфигурации благодаря простому проекту git с развертыванием CI

Как использовать для этого Helm?

Iсделал тест, создав базовую диаграмму с helm create my-network, создав базовое приложение nginx, идеально подходящее для добавления моей домашней домашней страницы в сети!

Но теперь я хотел бы добавить и подключить некоторое приложение, давайте начнем с Gitlab .

Я нашел два способа добавить его:

1. Просто запустить команду helm upgrade --install gitlab gitalb/gitlab с файлом значений yaml для конфигурации, вне моей собственной диаграммы.
2. Добавление gitlab в качестве зависимости благодаря require.yaml

Оба работают, давая мне почти одинаковый результат.

Первое решение кажетсяболее "независимым", но я не знаю, хоw для сборки / тестирования под CI (я бы хотел автоматизацию обновления).

Второй позволяет мне настраивать все с помощью одного values.yaml файла, но я не знаю, что это делается во время обновления(Процессы обновления gitlab выполняются во время обновления моего графика?) И все вместе в одном «проекте».

GitLab - пример, но я хочу добавить больше «готовых к использованию» приложенийвот так.

Что бы вы мне посоветовали?Решение 1 или 2?И что я должен позаботиться об обоих решениях, особенно об обновлении / резервном копировании?

Если у вас есть совершенно другое третье решение, которое предлагает использовать Helm, не стесняйтесь!: -)

Спасибо

Answer 1

Мой опыт, как правило, заключался в том, что лучше использовать отдельную helm install для каждой единицы / услуги.Если у этих сервисов есть зависимости («микросервису X нужен кэш Redis»), то это хорошая вещь для размещения в requirements.yaml файлах.

Большой «график диаграмм» сталкивается с несколькими проблемами:

• Helm сгладит зависимости, поэтому, если для службы X требуется Redis, а для службы Y также требуется Redis, программа установки диаграмм установит один Redis и предоставит к нему доступ;но на практике это часто не то, что вам нужно.

• Разделение конфигурации «совместно используемой» и «для каждой услуги» становится немного странным.С отдельными диаграммами вы можете использовать helm install -f дважды для предоставления двух отдельных файлов значений, но в диаграммах диаграмм сложнее иметь набор действительно глобальных настроек, а также набор настроек для каждого компонента, не дублируя все.

• Существует стандартное соглашение об именах, которое включает в себя шлем helm install --name и имя конкретного компонента.Это выглядит нормально, если оно service-x-redis, немного странно, если оно service-x-service-x, и довольно странно, если у вас есть одно глобальное название релиза the-world-service-x.

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

Для вашегоВ случае использования вы также можете подумать, могут ли инструменты управления системами, не входящие в Docker (Ansible, Chef, Salt Stack), воспроизвести существующее развертывание вашей руки без полной перестройки архитектуры вашей системы;Кубернетес довольно увлекателен, но старые способы тоже работают очень хорошо.