Потому что с момента выхода второго издания вышло шесть новых версий Terraform со значительными изменениями: 0.13, 0.14, 0.15, 1.0, 1.1 и 1.2
Проблема таких книг in a nutshell, они устаревают в момент выхода оригинала (не говоря уже о переводе). Актуальная версия Terraform уже 1.7 (1.2 вышел два (!) года назад) и вся глава про тестирование, например, довольно сильно потеряла смысл, потому что в последних версиях завезли много нативных инструментов для написания тестов: https://developer.hashicorp.com/terraform/language/tests
Зависит от характера модификаций. Ejabberd, насколько я помню, отлично расширяется за счет плагинов и такие плагины могут трактоваться как отдельный piece of software, соответственно могут лицензироваться иначе.
Аналогичная история с WordPress например, он тоже под GNU GPL v2, однако ж никто не заставляет публиковать исходники платных плагинов к нему.
> This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII].
Sentry в старых версиях тоже имел очень небольшое количество контейнеров (по-моему аналогично, воркера, веб, базу и очередь) и невысокие системные требования. Есть у меня опасения, что в процессе развития Glitchtip точно также "потолстеет".
Не очень понятно, чем было обусловлено решение "хочу всё в одном", т.к. из требований следует, что надо было закрыть две потребности - в трейсинге и в мониторинге+алертинге.
Я бы при решении этой задачи всё-таки бы взял две утилиты, решающие каждая свою задачу, например Jaeger+Prometheus. Потому что тот же алертинг в ELK - это действительно ад и боль. APDEX на стороне Прометея считается без проблем, вот например: https://prometheus.io/docs/practices/histograms/#apdex-score
Как человек, в прошлом причастный к разработке Semaphore, рад, что проект живёт и развивается. Мы в своё время ушли на Rundeck, потому что не хватало хранения конфигурации в коде и местами начала мешать завязка на Ansible, но Rundeck тоже не без минусов.
Попадают, я именно так и сделал у себя. sort(max_over_time((sum(rate(container_cpu_usage_seconds_total{namespace="prod",container!="POD",container!="istio-proxy", pod!~".*-job-.*"}[2m])) by (container, namespace) / sum(kube_pod_container_resource_requests_cpu_cores) by (container, namespace)) [30d:5m]) < 0.5) типа такого запрос просто в таблицу в графане вывел и всё.
Тестировать базовый Groovy-код это конечно ок, но я ожидал тут увидеть лайфхаки по тестированию Shared Libraries, которые используют не "голый" Groovy, а Jenkins DSL. Как тогда писать тесты?
Пару недель назад аналогичные шишки собирали, и с LDAP, и с Registry. Где ж вы раньше с вашей статьёй были... :)
С HTTPS еще огребли историю с куками, у нас везде по умолчанию стоит `proxy_cookie_flags ~ httponly secure samesite=lax;` на Nginx, а NiFi такие параметры не подошли, в итоге вместо внятной ошибки NiFi просто 403 отдавал с довольно невнятной руганью
Третья причина - никто не хочет думать. Когда появился SELinux, каждый первый мануал по установке чего угодно начинался с "отключите SELinux". Сейчас ситуация стала получше, с таких слов начинается только каждый второй мануал.
Плюсую, мы пару раз пытались затащить к себе AWX и каждый раз обламывались на том, что требуется перепороть все плейбуки и тракт деплоя чтобы втиснуться в их концепцию.
etcd по моему опыту намного более чувствителен к IO и очень плохо переживает ситуации типа "одна из нод начала подтупливать", Zk в этом отношении куда стабильнее.
Проблема таких книг in a nutshell, они устаревают в момент выхода оригинала (не говоря уже о переводе). Актуальная версия Terraform уже 1.7 (1.2 вышел два (!) года назад) и вся глава про тестирование, например, довольно сильно потеряла смысл, потому что в последних версиях завезли много нативных инструментов для написания тестов: https://developer.hashicorp.com/terraform/language/tests
https://grafana.com/grafana/plugins/cloudspout-button-panel/
https://grafana.com/grafana/plugins/speakyourcode-button-panel/
и тому подобные плагины
Почему у меня не будет доступа к WordPress? Речь про self-hosted версию.
Зависит от характера модификаций. Ejabberd, насколько я помню, отлично расширяется за счет плагинов и такие плагины могут трактоваться как отдельный piece of software, соответственно могут лицензироваться иначе.
Аналогичная история с WordPress например, он тоже под GNU GPL v2, однако ж никто не заставляет публиковать исходники платных плагинов к нему.
Ну SPF кстати есть (был точнее) - https://www.rfc-editor.org/rfc/rfc4408
> This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII].
Sentry в старых версиях тоже имел очень небольшое количество контейнеров (по-моему аналогично, воркера, веб, базу и очередь) и невысокие системные требования. Есть у меня опасения, что в процессе развития Glitchtip точно также "потолстеет".
Модуль
yumсчитается deprecated в пользу модулейdnfиpackageи работает только с Python 2https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_module.html
>This module only works on Python 2. If you require Python 3 support see the ansible.builtin.dnf module.
Есть же коллбэк-плагины, которые умеют складывать логи напрямую в хранилища, https://docs.ansible.com/ansible/latest/collections/community/general/logstash_callback.html например.
Там поддерживается огромное количество сервисов, можно логи складывать, можно прям профилировать выполнение через Elastic APM например. Полный список тут: https://docs.ansible.com/ansible/latest/collections/community/general/index.html#callback-plugins
Писал Алисе в частном порядке, напишу и тут. :)
Не очень понятно, чем было обусловлено решение "хочу всё в одном", т.к. из требований следует, что надо было закрыть две потребности - в трейсинге и в мониторинге+алертинге.
Я бы при решении этой задачи всё-таки бы взял две утилиты, решающие каждая свою задачу, например Jaeger+Prometheus. Потому что тот же алертинг в ELK - это действительно ад и боль. APDEX на стороне Прометея считается без проблем, вот например: https://prometheus.io/docs/practices/histograms/#apdex-score
Как человек, в прошлом причастный к разработке Semaphore, рад, что проект живёт и развивается.
Мы в своё время ушли на Rundeck, потому что не хватало хранения конфигурации в коде и местами начала мешать завязка на Ansible, но Rundeck тоже не без минусов.
Также полезно выводить приложения с большим отношением limit к request (больше 40x например), это тоже помогает бороться с неадекватными значениями
Попадают, я именно так и сделал у себя.
sort(max_over_time((sum(rate(container_cpu_usage_seconds_total{namespace="prod",container!="POD",container!="istio-proxy", pod!~".*-job-.*"}[2m])) by (container, namespace) / sum(kube_pod_container_resource_requests_cpu_cores) by (container, namespace)) [30d:5m]) < 0.5)типа такого запрос просто в таблицу в графане вывел и всё.Тестировать базовый Groovy-код это конечно ок, но я ожидал тут увидеть лайфхаки по тестированию Shared Libraries, которые используют не "голый" Groovy, а Jenkins DSL. Как тогда писать тесты?
Пару недель назад аналогичные шишки собирали, и с LDAP, и с Registry. Где ж вы раньше с вашей статьёй были... :)
С HTTPS еще огребли историю с куками, у нас везде по умолчанию стоит `proxy_cookie_flags ~ httponly secure samesite=lax;` на Nginx, а NiFi такие параметры не подошли, в итоге вместо внятной ошибки NiFi просто 403 отдавал с довольно невнятной руганью
Еще пытаются вкрутить такую штуку как Turbo Mode (https://github.com/openshift/community.okd/blob/main/docs/ansible_turbo_mode.rst) - по факту легковесного агента, который позволит не тратить время на инициализацию каждый раз.
Третья причина - никто не хочет думать. Когда появился SELinux, каждый первый мануал по установке чего угодно начинался с "отключите SELinux".
Сейчас ситуация стала получше, с таких слов начинается только каждый второй мануал.
Плюсую, мы пару раз пытались затащить к себе AWX и каждый раз обламывались на том, что требуется перепороть все плейбуки и тракт деплоя чтобы втиснуться в их концепцию.
В итоге взяли Rundeck и счастливы.
Так а зукипер-то тут причем? :)
etcd по моему опыту намного более чувствителен к IO и очень плохо переживает ситуации типа "одна из нод начала подтупливать", Zk в этом отношении куда стабильнее.
Но ведь сейчас в ходу уже Kafka 2.6 (если не выше). Упомянутые оптимизации были реализованы 3-4 года назад.