Поддерживаю. Подобного рода документация имеет свойство хаотично устаревать и нет возможности проверить ее актуальность, кроме как ручками. Если документирование построено на базе ансибла, который используется для деплоя и конфигурирования приложений, то актуальность документации всегда соответствует дате последнего запуска плейбука. Тоже самое касается и мониторинга. Ресурсы учитывать стоит из системы мониторинга. Впрочем, было заявлено что это набор шаблонов для стартапа, в котором скорее всего как всегда нет человека, который бы занимался сопровождением ансибла и мониторинга, так что наверное в какой-то степени это может быть полезно до поры до времени.
Да уж, "куча сервисов". Как бы не сломаться от сложности. А когда нет куба и сворма - то вариант поставить по-человечески и не устраивать цирк из оверлеев и вольюмов, ковыряния дырок для разных юзеров, капабилетей, сетей и привязки всего к демону докера с его обвязками из шимов. Один бинарь. Минио - это даже не пять, это один бинарь. Есть какой-то предел когда у людей хотя бы неловкость какая-то просыпается?
"компетентности в Docker было достаточно" для того, чтобы воткнуть вольюмы, privileged, и host-network. Ах да, еще root в контейнере "как быстрое решение". Ну и как вишенка на торте - отключенный лог-драйвер.
Ну т.е. вам просто нужен был chroot готовый для агента?
Я поддерживаю вопрос. Если по http пробам вот даже кусочек кода выложили, то каким образом связан runc (а я так понимаю любой exec из containerd спускается туда) и исполнение systemd я так и не понял. Может дадите пояснение?
Дело тут не в мониторинге, а в readinessprobe, которая отвечает за наличие ip пода в списке эндпоинтов сервиса. Иначе говоря, под, у которого зафейлилась риднеспроба, должен быть оперативно выкинут из балансировщика.
Это правда, бридж не поднимется без единого подключенного устройства. Для поднятия в Вашем случае, я полагаю, можно добавить .netdev с типом dummy без .network параметров, кроме принадлежности к бриджу. Впрочем, естественно, конечная реализация - это на Ваше усмотрение. Я лишь рассуждаю вслух, исходя из позиции, что с сетью у systemd все в порядке.
Может я невнимательно читал, но в чем проблема с сетью у systemd? systemd-networkd может создавать бридж по конфигу и маппить к нему через .network конфиги через [Match]
Я не просил мне мануал написать. Просто давайте по-честному: Что я узнал из этой статьи? Если это «приглашение к диалогу», то это странный формат. Вон Флант (как бы я не относился к этой конторе) для диалога завел телеграм-канал. А Вы чего ждете, диалога в комментариях? Что мы Вам принесем замеры и бенчи сюда? Я думал это работает немного по-другому
Согласен. Тоже смутил знак равенства между отказоустойчивым кластером и «бд в контейнере». Аргументы «темной стороны» в итоге совершенно не актуальны. Да и вообще информативность стати, мягко говоря, страдает. Ни расчетов, ни алгоритмов, ни даже опыта использования.
Я бы постыдился на Вашем месте в подобных статьях указывать авторство. Это мусор.
gitlab-runner не соответствует pull модели. А в этом главная архитектурная предпосылка была в статье.
>>> Устанавливаем на bm kubernetes
>>> Долистал до половины - все еще мануал по созданию виртуалок
>>> Ура, устанавливаем куб - ну кароч кубспрей там в паре мест конфиги поправили и кароч оно работает, если что потом можете конфиги поправить
Ну тупо топ инструкция я считаю, дайте еще
Как с языка снял. Были админы, сетевеки и безопасники. Теперь devops, devsecops и netops. Ждем когда дба чего-нибудь этакое выдадут.
Поддерживаю. Подобного рода документация имеет свойство хаотично устаревать и нет возможности проверить ее актуальность, кроме как ручками. Если документирование построено на базе ансибла, который используется для деплоя и конфигурирования приложений, то актуальность документации всегда соответствует дате последнего запуска плейбука. Тоже самое касается и мониторинга. Ресурсы учитывать стоит из системы мониторинга.
Впрочем, было заявлено что это набор шаблонов для стартапа, в котором скорее всего как всегда нет человека, который бы занимался сопровождением ансибла и мониторинга, так что наверное в какой-то степени это может быть полезно до поры до времени.
Да уж, "куча сервисов". Как бы не сломаться от сложности. А когда нет куба и сворма - то вариант поставить по-человечески и не устраивать цирк из оверлеев и вольюмов, ковыряния дырок для разных юзеров, капабилетей, сетей и привязки всего к демону докера с его обвязками из шимов. Один бинарь. Минио - это даже не пять, это один бинарь. Есть какой-то предел когда у людей хотя бы неловкость какая-то просыпается?
"компетентности в Docker было достаточно" для того, чтобы воткнуть вольюмы, privileged, и host-network. Ах да, еще root в контейнере "как быстрое решение". Ну и как вишенка на торте - отключенный лог-драйвер.
Ну т.е. вам просто нужен был chroot готовый для агента?
Хм.
Что "переносимей" - chroot или chroot+overlayfs+cgroups+namespaces+dockerd + VNC/x11docker?
Срочно несите докер, а то chroot - это сложно!
Я поддерживаю вопрос. Если по http пробам вот даже кусочек кода выложили, то каким образом связан runc (а я так понимаю любой exec из containerd спускается туда) и исполнение systemd я так и не понял. Может дадите пояснение?
Странный вопрос
Дело тут не в мониторинге, а в readinessprobe, которая отвечает за наличие ip пода в списке эндпоинтов сервиса. Иначе говоря, под, у которого зафейлилась риднеспроба, должен быть оперативно выкинут из балансировщика.
rtfm: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Это правда, бридж не поднимется без единого подключенного устройства. Для поднятия в Вашем случае, я полагаю, можно добавить .netdev с типом dummy без .network параметров, кроме принадлежности к бриджу. Впрочем, естественно, конечная реализация - это на Ваше усмотрение. Я лишь рассуждаю вслух, исходя из позиции, что с сетью у systemd все в порядке.
Может я невнимательно читал, но в чем проблема с сетью у systemd? systemd-networkd может создавать бридж по конфигу и маппить к нему через .network конфиги через [Match]
Чисто такой, сисадминский подход. Сурово