Так как целью статьи было сравнить prometheus и zabbix в контексте минимальной работоспособности и Zabbix уже имеет встроенную систему визуализацию дашбордов, в данном примере мы к нему не подключаем Grafana. А так да, подключить можно без проблем.
Спасибо за статью. Будет здорово если в следующих работах сделаете актуальную карту для роста компетенций на основе уточненных с статье данных. Всегда полезно знать во что выгоднее вкладываться.
Можно и так, не стал просто заморачиваться, на iptables все работает отлично. В идеале да, во вложенную директорию вносим все изменения, чтобы ничего не сломать.
Спасибо за идею! Проблема в том что иногда приходится работать с изолированными сетями. с настроенным локальным зеркалом репозиториев. Все равно приходится лезть в сеть аппаратно. Предлагаете развернуть контейнер Дженкинса на микрокомпьютере?
Спасибо за идею! termux отличен для работы с телефона, нужно будет испытать как он поведет себя с Ansible. К сожалению, если в сети нет точек wifi, приходится искать пограничные устройства типа микрокомпьютеров с соответствующими модулями.
Думаю что разницы почти нет, взаимодействие между ними сетевое, главное чтобы все компоненты были настроены, а также версия cri-docked была под нашу архитектуру
Наш API кластера работает на управляющем узле/узлах. Поэтому есть 2 варианта:
Хороший вариант-управляющих узлов несколько. В таком случае API будет доступен и поды будут в работе. Мы сможем уточнить токены и подключить заново настроенный управляющий (либо восстановить его из бекапа)
Плохой вариант - управляющий один и он умер. Тут я подозреваю что поды продолжат работу, но вот доступа к ним без балансировщика может и не быть не говоря уже об управляемости.
Ну а по восстановлению, думаю по класике, понять причину через логи, статусы служб, и попытаться точечно восстанвить, если там не слишком все критично.
Ну стоит помниить, что система регулярных и автоматических бекапаов по правилу 321 - должна быть обязаловкой.
В теории, если на работе много лишнего железа то можно сделать и так. Но текущая цель была все же потестировать одноплатники на ARM и их применимость в подобной роли.
На работе я развернул 3 qemu/kvm и держу на них все сервера для организации, но отказоустойчивость, если это можно назвать отказоустойчивостью, пока обеспечиваю бекапами veeam. Но тут всегда возникает вопрос, что будет при отказе железа гипервизора. Пока из бекапа все восстановится, пройдет уйма времени. Здорово будет создать такой кластер о котором вы рассказали и не переживать за такие случаи. Спасибо.
.
спасибо, учту
Prometheus как раз и подойдет, мониторить службы будет удобно
Мне нравится что он легковеснее, меньше ресурсов ест
Так как целью статьи было сравнить prometheus и zabbix в контексте минимальной работоспособности и Zabbix уже имеет встроенную систему визуализацию дашбордов, в данном примере мы к нему не подключаем Grafana. А так да, подключить можно без проблем.
.
Именно так
Спасибо за статью. Будет здорово если в следующих работах сделаете актуальную карту для роста компетенций на основе уточненных с статье данных. Всегда полезно знать во что выгоднее вкладываться.
Можно и так, не стал просто заморачиваться, на iptables все работает отлично. В идеале да, во вложенную директорию вносим все изменения, чтобы ничего не сломать.
Вроде то что нужно. Спасибо! Буду испытывать.
Спасибо за идею! Проблема в том что иногда приходится работать с изолированными сетями. с настроенным локальным зеркалом репозиториев. Все равно приходится лезть в сеть аппаратно. Предлагаете развернуть контейнер Дженкинса на микрокомпьютере?
Спасибо за идею! termux отличен для работы с телефона, нужно будет испытать как он поведет себя с Ansible. К сожалению, если в сети нет точек wifi, приходится искать пограничные устройства типа микрокомпьютеров с соответствующими модулями.
С
Думаю проблем нет. Как через Docker Hub, так и напрямую можно передавать контейнеры и работать это будет
Думаю что разницы почти нет, взаимодействие между ними сетевое, главное чтобы все компоненты были настроены, а также версия cri-docked была под нашу архитектуру
Наш API кластера работает на управляющем узле/узлах. Поэтому есть 2 варианта:
Хороший вариант-управляющих узлов несколько. В таком случае API будет доступен и поды будут в работе. Мы сможем уточнить токены и подключить заново настроенный управляющий (либо восстановить его из бекапа)
Плохой вариант - управляющий один и он умер. Тут я подозреваю что поды продолжат работу, но вот доступа к ним без балансировщика может и не быть не говоря уже об управляемости.
Ну а по восстановлению, думаю по класике, понять причину через логи, статусы служб, и попытаться точечно восстанвить, если там не слишком все критично.
Ну стоит помниить, что система регулярных и автоматических бекапаов по правилу 321 - должна быть обязаловкой.
спасибо
В теории, если на работе много лишнего железа то можно сделать и так. Но текущая цель была все же потестировать одноплатники на ARM и их применимость в подобной роли.
Сразу менять пароль скорее привычка. Можно и нового пользователя и не создавать, но с точки зрения безопасности лучше все же дефолтную учетку убрать
На работе я развернул 3 qemu/kvm и держу на них все сервера для организации, но отказоустойчивость, если это можно назвать отказоустойчивостью, пока обеспечиваю бекапами veeam. Но тут всегда возникает вопрос, что будет при отказе железа гипервизора. Пока из бекапа все восстановится, пройдет уйма времени. Здорово будет создать такой кластер о котором вы рассказали и не переживать за такие случаи. Спасибо.