Моё почтение за знания bash, но это не IaC, к которому нужно стремиться DevOps в моём понимании. VM надо бы разворачивать с помощью terraform, который хранит состояние, а все настройки, включая установку софта, с помощью того же ansible и будет IaC.
Выдёргивал динамический ip адрес создаваемой VM в yandex cloud из фактов, и добавлял его в inventory для других тасков. Своего рода динамический inventory. Хотя создавать VM с помощью Ansible весьма специфичная задача, для этого действительно есть terraform).
Важно отметит, что в кратких шпаргалках мало информации для изучения технологии с нуля. Поэтому проект полезен опытным программистам, которые хотят освежить знания.
А если я DevOps, и не считаю себя в принципе программистом, получается не полезен будет?)
Аллегория понятна. Но, когда речь идёт о Jenkins, это говорит о том, что в компании есть CI/CD, а если есть CI/CD, то помимо мониторинга инфраструктуры, скорее всего нужно мониторить и сервисы, и вот тут держать одновременно Zabbix под инфру и Prometheus+Grafana под сервисы, контейнеры и прочее жирновато, хотя и такой подход имеет право на жизнь. Сейчас работаю в компании, где как раз так. Недавно был кейс, на одном из хостов, какой-то контейнер стал съедать много памяти, пошёл в Zabbix, а там куча графиков на несколько страниц, и нет какого-то агрегированного дашборда как в Grafana, мне проще было воткнуть на хост cadvisor в контейнере, чем мучаться с Zabbix).
В статье описан мониторинг с помощью node-exporter, то есть самого хоста, плюс мониторинг веб морды Jenkins. Если эту связку разворачивать через тот же docker-compose, то там никаких лишних телодвижений не будет по сути, кроме установки самого docker и docker-compose. Я про это писал выше, что сомнительно ставить это всё прямо на хост. Ок, забудем про микросервисы. Если сравнивать мониторинг хоста с помощью node-exporter в Prometheus+Grafana и мониторинг хоста в Zabbix, то добавить на мониторинг хост конечно же проще в Zabbix, но в Grafana красивее, нагляднее и удобнее).
Слышал что были у них проблемы на железе определённых вендоров. Возможно уже пофиксили. Похожего функционала на VMware NSX здесь нет? Необходимо использовать аппаратные МСЭ?
#auth = "pam"
#auth = "pam[gid-min=1000]"
#auth = "plain[passwd=./sample.passwd,otp=./sample.otp]"
#auth = "plain[passwd=./sample.passwd]"
#auth = "certificate"
#auth = "radius[config=/etc/radiusclient/radiusclient.conf,groupconfig=true]"
# Specify alternative authentication methods that are sufficient
# for authentication. That is, if set, any of the methods enabled
# will be sufficient to login, irrespective of the main 'auth' entries.
# When multiple options are present, they are OR composed (any of them
# succeeding allows login).
#enable-auth = "certificate"
#enable-auth = "gssapi"
#enable-auth = "gssapi[keytab=/etc/key.tab,require-local-user-map=true,tgt-freshness-time=900]"
В конце конфига включил camouflage = true и указал camouflage_secret.
Из вашей статьи неочевидны некоторые моменты, по крайней мере для меня).
Если использовать camouflage = true, то необходимо все методы авторизации закомментировать в начале конфига. В настройках OpennConect-GUI в адресе хоста нужно указать camouflage_secret, вот пример: https://example.com:443/?mysecretkey
Не знаю, может это для кого-то очевидно, но я время потратил чтобы разобраться что к чему).
Для чего Podfile и Podfile.lock нужен? Почему последний вы каждый раз удаляете? Как это сказывается на времени сборки? Сорян за вопросы, но я DevOps, во flutter пока не очень. Думаю вот статью здесь написать по развёртыванию приватного репозитория для dart/flutter, аналог pub.dev, так как недавно с такой задачей столкнулся на практике.
Из своего опыта, готовиться к собеседованию нужно, хотя бы внимательно ознакомиться с вакансией и компанией. Далее всё индивидуально, кто-то может быть уверен в себе на все 100, и ему необходимо лишь восполнить какие-то небольшие пробелы, а кому-то действительно понадобится как минимум пару дней. Не знаю как у разрабов, но у тех же DevOps 70% вопросов практически всегда одинаковые, поэтому при поиске работы чем чаще ходишь на собеседования, тем больше откладывается в голове. Самое печальное, что даже на сегодняшний день у многих компаний собеседование до сих пор проводят как экзамен.
Спасибо. Было бы интересно ещё почитать про то, как сделать алертинг для дагов в тг, с помощью alertmanager Prometheus.
Моё почтение за знания bash, но это не IaC, к которому нужно стремиться DevOps в моём понимании. VM надо бы разворачивать с помощью terraform, который хранит состояние, а все настройки, включая установку софта, с помощью того же ansible и будет IaC.
Выдёргивал динамический ip адрес создаваемой VM в yandex cloud из фактов, и добавлял его в inventory для других тасков. Своего рода динамический inventory. Хотя создавать VM с помощью Ansible весьма специфичная задача, для этого действительно есть terraform).
А если я DevOps, и не считаю себя в принципе программистом, получается не полезен будет?)
Аллегория понятна. Но, когда речь идёт о Jenkins, это говорит о том, что в компании есть CI/CD, а если есть CI/CD, то помимо мониторинга инфраструктуры, скорее всего нужно мониторить и сервисы, и вот тут держать одновременно Zabbix под инфру и Prometheus+Grafana под сервисы, контейнеры и прочее жирновато, хотя и такой подход имеет право на жизнь. Сейчас работаю в компании, где как раз так. Недавно был кейс, на одном из хостов, какой-то контейнер стал съедать много памяти, пошёл в Zabbix, а там куча графиков на несколько страниц, и нет какого-то агрегированного дашборда как в Grafana, мне проще было воткнуть на хост cadvisor в контейнере, чем мучаться с Zabbix).
В статье описан мониторинг с помощью node-exporter, то есть самого хоста, плюс мониторинг веб морды Jenkins. Если эту связку разворачивать через тот же docker-compose, то там никаких лишних телодвижений не будет по сути, кроме установки самого docker и docker-compose. Я про это писал выше, что сомнительно ставить это всё прямо на хост. Ок, забудем про микросервисы. Если сравнивать мониторинг хоста с помощью node-exporter в Prometheus+Grafana и мониторинг хоста в Zabbix, то добавить на мониторинг хост конечно же проще в Zabbix, но в Grafana красивее, нагляднее и удобнее).
Слышал что были у них проблемы на железе определённых вендоров. Возможно уже пофиксили. Похожего функционала на VMware NSX здесь нет? Необходимо использовать аппаратные МСЭ?
Zabbix больше про инфраструктуру, а не микросервисы. Да, с помощью него тоже можно мониторить контейнеры, но с Prometheus+Grafana не сравнится.
На практике все либо в k8s с помощью helm разворачивают мониторинг, либо через docker-compose хотя бы. Смысл ставить всё на хост, если есть docker?
Прикольно, только вряд ли сильно востребовано. У Gitlab их shared runners разве не похожие функции выполняют?
Ну то есть если умрёт кластер куба, то и мониторинг ваш умрёт?
Тот же prometheus можно развернуть в не k8s - https://sysadmintalks.ru/kubernetes-prometheus-outside/
Про grafana вообще молчу, ей же по сути нужно только источники указать, а где она будет развернута вообще не принципиально.
Но хотелось бы конечно увидеть best practices, как это организованно в крупных компаниях.
Вот что я добавил в начале конфига:
auth = "plain[passwd=/etc/ocserv/ocpasswd]"Остальное все закомментировал:
В конце конфига включил camouflage = true и указал camouflage_secret.
Из вашей статьи неочевидны некоторые моменты, по крайней мере для меня).
Если закомментить все роуты, то наверное как раз-таки дефолтное значение должно ратотать route = default?
Установил с помощью PPA от @eisaev
Если использовать
camouflage = true, то необходимо все методы авторизации закомментировать в начале конфига. В настройках OpennConect-GUI в адресе хоста нужно указать camouflage_secret, вот пример: https://example.com:443/?mysecretkeyНе знаю, может это для кого-то очевидно, но я время потратил чтобы разобраться что к чему).
Обычно ведь прометей и графана развёрнуты отдельно от k8s? Есть ли best practices по данному вопросу?
Влепил бы минус за кликбейтный заголовок. Если только в планах отменить с середины 2024 года, то и заголовок должен соответствовать, не так ли?
Спасибо
Для чего Podfile и Podfile.lock нужен? Почему последний вы каждый раз удаляете? Как это сказывается на времени сборки? Сорян за вопросы, но я DevOps, во flutter пока не очень. Думаю вот статью здесь написать по развёртыванию приватного репозитория для dart/flutter, аналог pub.dev, так как недавно с такой задачей столкнулся на практике.
Офис у "Арт-Технологии" конечно повеселил, бельишко на верёвке сушится, наверное айтишники стиркой занимаются).
Из своего опыта, готовиться к собеседованию нужно, хотя бы внимательно ознакомиться с вакансией и компанией. Далее всё индивидуально, кто-то может быть уверен в себе на все 100, и ему необходимо лишь восполнить какие-то небольшие пробелы, а кому-то действительно понадобится как минимум пару дней. Не знаю как у разрабов, но у тех же DevOps 70% вопросов практически всегда одинаковые, поэтому при поиске работы чем чаще ходишь на собеседования, тем больше откладывается в голове. Самое печальное, что даже на сегодняшний день у многих компаний собеседование до сих пор проводят как экзамен.