Уволился с хорошего места и сменил направление ради удалёнки. Жил до этого в Сибири, теперь на юге. Работе уделяю даже больше времени чем раньше, но это не плюс и не минус, а просто много всего нового приходится изучать в связи со сменой направления. Осталось только заставить себя спортом заниматься, в остальном только плюсы.
Судя по тому как сейчас эйчары относятся к пройденным курсам и сертификатам, смысла платить за это особого нет. А вот почитать их бесплатные материалы можно конечно.
Вроде в целом понятно, но мне кажется нужен аналог "сети для самых маленьких" от linkmeup, только про k8s. Который будет состоять из нескольких частей, и где будет подробно описано как настроить кластер, про сети, безопасность, как задеплоить приложение и т.д. В общем я считаю что про k8s в одной статье можно описать только общее представление, не более того.
Подружить проблем нет, есть statsd и statsd-exporter, а вот как обогащать метрики необходимыми labels, чтобы например в сообщении помимо id завалившегося dag или task был линк на лог, время и т.д., вот с этим у меня как не у программиста проблемы возникли. Есть вариант с созданием своих кастомных метрик с необходимыми labels и отправкой их через StatsClient, но тоже не всё так гладко и понятно. Поэтому если напишите статью на эту тему, с удовольствием бы почитал.
Насчёт комфортного рабочего места согласен, я не представляю как можно сосредоточиться на работе, когда вокруг дети бегают, супруга постоянно мимо ходит. Из личного опыта, даже в двухкомнаиной квартире можно врезать замок в дверь одной из комнат, закрываться и спокойно работать). Главное чтобы в семье это находило понимание.
Моё почтение за знания 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.
Из вашей статьи неочевидны некоторые моменты, по крайней мере для меня).
Спасибо за статью, описание для приложения в TestFlight как добавить автоматически, например список изменений?
Уволился с хорошего места и сменил направление ради удалёнки. Жил до этого в Сибири, теперь на юге. Работе уделяю даже больше времени чем раньше, но это не плюс и не минус, а просто много всего нового приходится изучать в связи со сменой направления. Осталось только заставить себя спортом заниматься, в остальном только плюсы.
Судя по тому как сейчас эйчары относятся к пройденным курсам и сертификатам, смысла платить за это особого нет. А вот почитать их бесплатные материалы можно конечно.
Думаю что вместо Veeam можно было рассмотреть какой-нибудь Кибербэкап или rubackup.
Вроде в целом понятно, но мне кажется нужен аналог "сети для самых маленьких" от linkmeup, только про k8s. Который будет состоять из нескольких частей, и где будет подробно описано как настроить кластер, про сети, безопасность, как задеплоить приложение и т.д. В общем я считаю что про k8s в одной статье можно описать только общее представление, не более того.
Подружить проблем нет, есть statsd и statsd-exporter, а вот как обогащать метрики необходимыми labels, чтобы например в сообщении помимо id завалившегося dag или task был линк на лог, время и т.д., вот с этим у меня как не у программиста проблемы возникли. Есть вариант с созданием своих кастомных метрик с необходимыми labels и отправкой их через StatsClient, но тоже не всё так гладко и понятно. Поэтому если напишите статью на эту тему, с удовольствием бы почитал.
Насчёт комфортного рабочего места согласен, я не представляю как можно сосредоточиться на работе, когда вокруг дети бегают, супруга постоянно мимо ходит. Из личного опыта, даже в двухкомнаиной квартире можно врезать замок в дверь одной из комнат, закрываться и спокойно работать). Главное чтобы в семье это находило понимание.
Спасибо. Было бы интересно ещё почитать про то, как сделать алертинг для дагов в тг, с помощью 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?