В этом суждении я руководствуюсь мнением Джеза Хамбла и Дейвида Фарли, которые в своей книге «Continious delivery», обсуждали процесс СI/CD, а также связанные с ним вопросы. В частности, обсуждалось хранение артефактов сборки. И хотя авторы допускают хранение артефактов в гите, они считают что так делать не стоит, поскольку артефакты достаточно просто получить из кода, путем запуска пайплайна.
например, проверять диф, что не появилось что-то лишнее тогда, когда не было никакой выкатки
Возможно, в дальнейшем вы откажитесь от практики ручного входа на оборудование. Дело в том, что при ручных правках конфигурации вы приводите систему из известного состояния (полученного в ходе CI/CD, выполнения тестов) в неизвестное состояние. Подобное может привести к сбою в процессе деплоя новых версий конфы, сбоям в момент применения конфы руками. Она ведь становится не протестированной как в пределах самой себя, так и во взаимодействии с остальным оборудованием. Пишу об этом, поскольку мы много такого хапнули при применении конфигурации на сервера. В итоге, отказались от входа на сервера вообще и конфа катится только пользователем ci.
Этот и следующие вопросы всё же достойны отдельных статей, а не комментариев.
В таком случае, с удовольствием прочитаю следующие статьи. Видите ли, у нас возникла схожая потребность, а именно, сделать IaC. С серверами все хорошо, есть пайплайны, тестирование и т.п, а вот к сетевому оборудованию пока непонятно как подобраться. Вопросы, которые я задал выше — это те вопросы которые сейчас перед нами стоят.
Спасибо за статью, очень интересное содержание и легкий слог. Есть несколько вопросов по материалу.
Зачем хранить бэкапы в гите? Это ведь, при вашем подходе, данные, которые можно получить путем применения CI/CD пайплайна. Конечно же, бэкапы необходимы, но складывать их в гит, на мой взгляд, не самая лучшая идея.
Как будет контролироваться идемпотентность применения кофигурации? Будет ли конфигурация катиться полностью или будет высчитываться дифф? Как система управления конфигурацией поймет какое состояние на сетевом устройстве?
Спасибо за статью. Хочу отметить, что kubeadm не единственный способ установки kubernetes. Автор рассматривал альтернативные пути установки и настройки кластера? К примеру, максимально с infrastructure as code в моем понимании соотносится kubespray. Его можно запихнуть внутрь ci/cd, выполнять развертывание на тестовом кластере, гонять тесты testinfra, а потом применять на прод. При этом все выполняется не вручную, что минимизирует количество ошибок, повышает управляемость кластера.
Спасибо за статью. Однако, возникает вопрос: чем обоснован выбор PPTP? Насколько я знаю это весьма уязвимый протокол. Лучшим решением видится IPSEC + EAP + RADIUS.
Ну или хотя бы заворачивание PPTP внутрь IPSEC.
Добрый день!
Посмотрел на ваш проект после неуспешного опыта эксплуатации ELK стека.
Действительно, ELK очень требователен к ресурсам и падает чуть больше, чем постоянно с ошибкой OutOfMemory.
Я весьма признателен за инструмент, который вы выпустили, поскольку, все что я нашел на просторах интернета в плане логов, использует elasticsearch.
Однако, после ознакомления с helm пакетом, возникло несколько вопросов:
1. Чем продиктовано использование отдельного файла namespace.yaml? Ведь helm создает namespace при инсталляции пакета.
2. Почему используется .Values.namespace вместо .Release.namespace? Ведь чем больше переменных нужно изменить, тем больше вероятность ошибки при развертывании.
3. Почему Вы используете alpha k8s API в файле loghouse-cronjob.yaml? Вроде бы возможности, которые описаны у вас в CronJob, не альфа, а установить без включения alpha feature gate ваш пакет невозможно.
4. Вы не учли возможность указания ресурсов в ингрессе и полагаете, что каждый ингресс будет отдавать приложение из корня, а это может быть не так, если используется один хост на всё. Также отсутствует возможность увказания имен секретов.
Я склонировал репозиторий и пилю сейчас helm пакет по вышеозначенным вопросам.
Но, возможно, я что-то упустил и не прав. Прошу пояснить, мои вопросы это баги, которые я нашел или фичи которые я принял за баги?
В k8s все сервисы кластера stateless, мультимастера нет. Обычно вертят сверху HA решения, чтобы обращения шли на «общий» ipшник. Однако, имеет смысл сделать несколько инстансов etcd, поскольку этот сервис как раз использует k8s для хранения конфигурации кластера.
В этом суждении я руководствуюсь мнением Джеза Хамбла и Дейвида Фарли, которые в своей книге «Continious delivery», обсуждали процесс СI/CD, а также связанные с ним вопросы. В частности, обсуждалось хранение артефактов сборки. И хотя авторы допускают хранение артефактов в гите, они считают что так делать не стоит, поскольку артефакты достаточно просто получить из кода, путем запуска пайплайна.
Возможно, в дальнейшем вы откажитесь от практики ручного входа на оборудование. Дело в том, что при ручных правках конфигурации вы приводите систему из известного состояния (полученного в ходе CI/CD, выполнения тестов) в неизвестное состояние. Подобное может привести к сбою в процессе деплоя новых версий конфы, сбоям в момент применения конфы руками. Она ведь становится не протестированной как в пределах самой себя, так и во взаимодействии с остальным оборудованием. Пишу об этом, поскольку мы много такого хапнули при применении конфигурации на сервера. В итоге, отказались от входа на сервера вообще и конфа катится только пользователем ci.
В таком случае, с удовольствием прочитаю следующие статьи. Видите ли, у нас возникла схожая потребность, а именно, сделать IaC. С серверами все хорошо, есть пайплайны, тестирование и т.п, а вот к сетевому оборудованию пока непонятно как подобраться. Вопросы, которые я задал выше — это те вопросы которые сейчас перед нами стоят.
Зачем хранить бэкапы в гите? Это ведь, при вашем подходе, данные, которые можно получить путем применения CI/CD пайплайна. Конечно же, бэкапы необходимы, но складывать их в гит, на мой взгляд, не самая лучшая идея.
Как будет контролироваться идемпотентность применения кофигурации? Будет ли конфигурация катиться полностью или будет высчитываться дифф? Как система управления конфигурацией поймет какое состояние на сетевом устройстве?
molecule? testinfra? Используете ли CI/CD пайплайн для раскатки?
Ну или хотя бы заворачивание PPTP внутрь IPSEC.
Посмотрел на ваш проект после неуспешного опыта эксплуатации ELK стека.
Действительно, ELK очень требователен к ресурсам и падает чуть больше, чем постоянно с ошибкой OutOfMemory.
Я весьма признателен за инструмент, который вы выпустили, поскольку, все что я нашел на просторах интернета в плане логов, использует elasticsearch.
Однако, после ознакомления с helm пакетом, возникло несколько вопросов:
1. Чем продиктовано использование отдельного файла namespace.yaml? Ведь helm создает namespace при инсталляции пакета.
2. Почему используется .Values.namespace вместо .Release.namespace? Ведь чем больше переменных нужно изменить, тем больше вероятность ошибки при развертывании.
3. Почему Вы используете alpha k8s API в файле loghouse-cronjob.yaml? Вроде бы возможности, которые описаны у вас в CronJob, не альфа, а установить без включения alpha feature gate ваш пакет невозможно.
4. Вы не учли возможность указания ресурсов в ингрессе и полагаете, что каждый ингресс будет отдавать приложение из корня, а это может быть не так, если используется один хост на всё. Также отсутствует возможность увказания имен секретов.
Я склонировал репозиторий и пилю сейчас helm пакет по вышеозначенным вопросам.
Но, возможно, я что-то упустил и не прав. Прошу пояснить, мои вопросы это баги, которые я нашел или фичи которые я принял за баги?