Forwarded from DevOps Deflope News
Весьма объемная статья в блоге Segment про оптимизацию их инфраструктуры
http://amp.gs/qedd
#segment #blog
http://amp.gs/qedd
#segment #blog
Подсмотрел в чате тут про https://github.com/jacksontj/promxy - proxy для Prometheus который позволяет сделать HA #proxy #prometheus
GitHub
GitHub - jacksontj/promxy: An aggregating proxy to enable HA prometheus
An aggregating proxy to enable HA prometheus. Contribute to jacksontj/promxy development by creating an account on GitHub.
Один из наших подписчиков написал статью про интересную штуку - анализатор сетевой топологии. Читаем, ставим лойсы https://habr.com/ru/post/472724/
#network
#network
Хабр
Введение в skydive.network
Введение в Skydive Skydive — это анализатор топологии сети и протоколов с открытым исходным кодом в реальном времени. Он направлен на то, чтобы предоставить исчерпывающий способ понять, что...
Forwarded from Go Дайджест
Forwarded from chiki_briki
Все новое это хорошо забытое старое.
Автор предлагает взять и любую дичь (ваши ежедневные команды из консоли) и обернуть в Makefile, что по сути будет той же башнянкой.sh
Возможно я не оценил профит и кто-то готов пояснить мне где же там все-таки собака зарыта?
сайт - http://bit.ly/2oe5TzU
github - http://bit.ly/2p9oCgr
За материал спасибо @pavkazzz
Автор предлагает взять и любую дичь (ваши ежедневные команды из консоли) и обернуть в Makefile, что по сути будет той же башнянкой.sh
Возможно я не оценил профит и кто-то готов пояснить мне где же там все-таки собака зарыта?
сайт - http://bit.ly/2oe5TzU
github - http://bit.ly/2p9oCgr
За материал спасибо @pavkazzz
Forwarded from chiki_briki
Уже постил видео доклада коллеги с конференции DevOpsConf 2019 «Логи не нужны?», а теперь и текст подъехал.
Если у вас на ровном месте петабайты логов, условный эластик вам не рад и вы ему тоже, то вам стоит задуматься:
- что из этого всего вам действительно нужно
- что превратить в метрики и использовать как метрику (e.g. Prometheus)
- возможно отделить критические ошибки и положить в специализированное место (e.g. Sentry)
- такая же история с бизнес метриками
Статья: http://bit.ly/2ocTcVU
Видео: http://bit.ly/2ocTNqC
Если у вас на ровном месте петабайты логов, условный эластик вам не рад и вы ему тоже, то вам стоит задуматься:
- что из этого всего вам действительно нужно
- что превратить в метрики и использовать как метрику (e.g. Prometheus)
- возможно отделить критические ошибки и положить в специализированное место (e.g. Sentry)
- такая же история с бизнес метриками
Статья: http://bit.ly/2ocTcVU
Видео: http://bit.ly/2ocTNqC
Forwarded from Записки админа
🧪 Методы "отравления" кеша CDN, которые могут привести к частичной, либо полной недоступности ресурса для остальных посетителей: https://cpdos.org
#security #линк #фидбечат
#security #линк #фидбечат
По поводу поста https://xn--r1a.website/chiki_briki_it/132 от подписчика пришло вот такое мнение:
Привет. Суть make для разного рода проектов в том, что он позволяет скрыть разного рода команды и хранить их унифицированно. Посмотрим на примере. У меня есть несколько заказчиков, я для них написал небольшой набор плейбуков и ролей на ансибле. У этих плейбуков единый костяк, но они чуть отличаются per кастомер. Соответственно, я при ручных деплоях запускаю что-то типа
1. Очень надоедает писать всю эту простыню руками. Поиск по C-r не спасает, потому что плейбуков 30 * N кастомеров, запускается оно часто. Решение приходит постепенно. Сначала мы делаем
2. Эту хню надо запускать не только руками, но часто на проде, где надо автоматически вводить become password и vault password. Для vault в ансибле есть удобное решение. Для become нет ничего, кроме того чтобы запрашивать из extra vars. Ты к аргументам добавляешь конструкцию вида
3. Тут внезапно оказывается, что ты в CI хочешь делать так, как есть, а на локальной машине хочешь использовать mitogen еще. И у тебя ansible.cfg в репе. И ты не хочешь вписывать mitogen_linear в него, потому что на CI нет митогена и все развалится. И ты снова придумываешь с env vars, но теперь их надо экспортить перед тем, как ты запускаешь плейбуки локально и про это надо не забывать.
4. И тут ансибл обновляется и говорит "чувак, теперь вместо sudo_user" можно использовать только "become_user" и ты идешь и все шебанги во всех плейбуках для всех кастомеров переписываешь. Ну чо, sed позапускал, все норм вроде.
Так вот. Вместо этого всего ты делаешь make и кладешь его в оригинальную репу. И в этот make вписываешь все, что тебе нужно. И когда придет время менять синтаксис, он поменяется в одном makefile, а не в 150 плейбуках. Когда надо будет что-то добавить, оно снова поменяется в 1 makefile. А еще можно выкинуть
И таких примеров, на самом деле, не слишком уж много и я вообще прекрасно жил без make лет примерно 15. А потом внезапно понял, что на моем объеме автоматизации он решает кучу задач и вообще очень норм. (c)
От себя добавлю - Makefile и правда бывает удобен, для того чтобы забутстрапить сборку, например. Сам использовал Makefile в прошлом году, для запуска плейбуков ansible + генерации vars для них и мне даже понравилось, но ощущения были странные.
Привет. Суть make для разного рода проектов в том, что он позволяет скрыть разного рода команды и хранить их унифицированно. Посмотрим на примере. У меня есть несколько заказчиков, я для них написал небольшой набор плейбуков и ролей на ансибле. У этих плейбуков единый костяк, но они чуть отличаются per кастомер. Соответственно, я при ручных деплоях запускаю что-то типа
ansible-playbook -i inventory/customer.hosts -K --ask-vault-pass run-minimal.yml. Таких плейбуков типа run-minimal.yml набралось уже около 30. Спустя какое-то время возникают следующие проблемы:
1. Очень надоедает писать всю эту простыню руками. Поиск по C-r не спасает, потому что плейбуков 30 * N кастомеров, запускается оно часто. Решение приходит постепенно. Сначала мы делаем
alias apl=ansible-playbook, потом мы засовываем аргументы в shebang (а чо, так можно было? - постоянно спрашивают меня коллеги).
2. Эту хню надо запускать не только руками, но часто на проде, где надо автоматически вводить become password и vault password. Для vault в ансибле есть удобное решение. Для become нет ничего, кроме того чтобы запрашивать из extra vars. Ты к аргументам добавляешь конструкцию вида
-e @extra/vars.yml, в которой тащишь env var, которую пробрасываешь в become. Все это снова приезжает в shebang каждого плейбука.
3. Тут внезапно оказывается, что ты в CI хочешь делать так, как есть, а на локальной машине хочешь использовать mitogen еще. И у тебя ansible.cfg в репе. И ты не хочешь вписывать mitogen_linear в него, потому что на CI нет митогена и все развалится. И ты снова придумываешь с env vars, но теперь их надо экспортить перед тем, как ты запускаешь плейбуки локально и про это надо не забывать.
4. И тут ансибл обновляется и говорит "чувак, теперь вместо sudo_user" можно использовать только "become_user" и ты идешь и все шебанги во всех плейбуках для всех кастомеров переписываешь. Ну чо, sed позапускал, все норм вроде.
Так вот. Вместо этого всего ты делаешь make и кладешь его в оригинальную репу. И в этот make вписываешь все, что тебе нужно. И когда придет время менять синтаксис, он поменяется в одном makefile, а не в 150 плейбуках. Когда надо будет что-то добавить, оно снова поменяется в 1 makefile. А еще можно выкинуть
alias apl=ansible-playbook. А еще можно переменные окружения настраивать автоматически перед вызовом деплоя. Ну и митоген можно локально настраивать тут же, а на CI не делать этого.
И таких примеров, на самом деле, не слишком уж много и я вообще прекрасно жил без make лет примерно 15. А потом внезапно понял, что на моем объеме автоматизации он решает кучу задач и вообще очень норм. (c)
От себя добавлю - Makefile и правда бывает удобен, для того чтобы забутстрапить сборку, например. Сам использовал Makefile в прошлом году, для запуска плейбуков ansible + генерации vars для них и мне даже понравилось, но ощущения были странные.
Telegram
chiki_briki
Все новое это хорошо забытое старое.
Автор предлагает взять и любую дичь (ваши ежедневные команды из консоли) и обернуть в Makefile, что по сути будет той же башнянкой.sh
Возможно я не оценил профит и кто-то готов пояснить мне где же там все-таки собака…
Автор предлагает взять и любую дичь (ваши ежедневные команды из консоли) и обернуть в Makefile, что по сути будет той же башнянкой.sh
Возможно я не оценил профит и кто-то готов пояснить мне где же там все-таки собака…
Forwarded from HABR FEED + OPENNET
6 практических историй из наших SRE-будней
https://habr.com/ru/post/471892/
Tags: Блог компании Флант, Системное администрирование, Серверное администрирование, SRE, troubleshooting
Author pashcovich on #habrahabr
https://habr.com/ru/post/471892/
Tags: Блог компании Флант, Системное администрирование, Серверное администрирование, SRE, troubleshooting
Author pashcovich on #habrahabr
Хабр
6 практических историй из наших SRE-будней
Современная веб-инфраструктура состоит из множества компонентов разного назначения, имеющих очевидные и не очень взаимосвязи. Это становится особенно хорошо ви...
Бесплатный онлайн практикум DevOps by REBRAIN: Helm-Ansible
Для системных администраторов / Инженеров / Программистов
Регистрация - https://clck.ru/JG8wW
Количество мест строго ограничено!
Практикум по освоению DevOps
Время проведения:
29 Октября (Вторник) в 19:00 по МСК
Что будет на практикуме?
🔹Почему Helm? Зачем Ansible?
🔹Обзор шаблонов роли и плейбука
🔹Создание роли и плейбука для своего собственного деплоймента приложения
Кто ведет?
Лиза Постарнак - Senior DevOps engineer AirPush. Senior DevOps engineer Arvato Financial Services. Creator REBRAIN. Estonia, Tallinn
Открытые еженедельные DevOps практикумы - https://bit.ly/2CGmm3C
Присоединяйтесь!
Для системных администраторов / Инженеров / Программистов
Регистрация - https://clck.ru/JG8wW
Количество мест строго ограничено!
Практикум по освоению DevOps
Время проведения:
29 Октября (Вторник) в 19:00 по МСК
Что будет на практикуме?
🔹Почему Helm? Зачем Ansible?
🔹Обзор шаблонов роли и плейбука
🔹Создание роли и плейбука для своего собственного деплоймента приложения
Кто ведет?
Лиза Постарнак - Senior DevOps engineer AirPush. Senior DevOps engineer Arvato Financial Services. Creator REBRAIN. Estonia, Tallinn
Открытые еженедельные DevOps практикумы - https://bit.ly/2CGmm3C
Присоединяйтесь!
Forwarded from Записки админа
sed_v1p0.pdf
404.1 KB
📚 Автор сделал свою книгу бесплатной на некоторое время. Тем, кто хочет потренироваться в использовании sed'а, стоит обратить на неё внимание.
#книга #sed
#книга #sed
Forwarded from linkmeup
Саша Клиппер так и не решился сдать контору, поэтому за всех будет отдуваться его коллега Василий Пантюхин, архитектор Amazon Web Services.
https://habr.com/ru/company/oleg-bunin/blog/471688/
https://habr.com/ru/company/oleg-bunin/blog/471688/
Хабр
Как AWS «варит» свои эластичные сервисы. Масштабирование сети
Масштаб сети Amazon Web Services — это 69 зон по всему миру в 22 регионах: США, Европа, Азия, Африка и Австралия. В каждой зоне находится до 8 ЦОД — Центров Обра...
Forwarded from Golang drawer
https://curl.trillworks.com/#go
Convert curl syntax to Python, Ansible URI, Node.js, R, PHP, Strest, Go, Dart, JSON, Rust
Convert curl syntax to Python, Ansible URI, Node.js, R, PHP, Strest, Go, Dart, JSON, Rust
Forwarded from DevOps&SRE Library
Persistent Disks and Replication
Пост в блоге Google Cloud про то, как работают Persistent Disks.
https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565
Пост в блоге Google Cloud про то, как работают Persistent Disks.
https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565
Ещё одна статья про concurrency в golang, на этот раз с разбором конкретных примитивов https://medium.com/@abhishek1987/using-synchronization-primitives-in-go-mutex-waitgroup-once-2e50359cb0a7 #golang #concurrency
Medium
Using Synchronization Primitives in Go
Exploring Mutex, WaitGroup, and Once with examples
Forwarded from oleg_log (Oleg Kovalov)
То, чего точно не хватало для Постгреса:
A flamegraph generator for Postgres EXPLAIN ANALYZE output.
https://github.com/mgartner/pg_flame
A flamegraph generator for Postgres EXPLAIN ANALYZE output.
https://github.com/mgartner/pg_flame
И снова про пятничный деплой https://hackernoon.com/deploy-on-fridays-or-dont-qg2y32jk
Hackernoon
Deploy on Fridays, or Don't.
There seems to be a debate that has gone on for quite some time now on the Twitters about whether or not you should do Friday deploys, and whether there should be Friday moratoriums, etc. There are a lot of accusations being thrown around about fear, testing…
Forwarded from Dev Tools
HTTP-Prompt
HTTP Prompt - Интерактивный консольный HTTP клиент.
Из того что мне понравилось:
- Response Cookies автоматически сохраняются для следующих запросов
- Автокомплит по встроенным командам
- Интеграция с httpie
Обязательно советую попробовать, если Вам приходится часто работать с curl или Httpie.
HTTP Prompt - Интерактивный консольный HTTP клиент.
Из того что мне понравилось:
- Response Cookies автоматически сохраняются для следующих запросов
- Автокомплит по встроенным командам
- Интеграция с httpie
Обязательно советую попробовать, если Вам приходится часто работать с curl или Httpie.
Forwarded from CatOps
Grafana делятся своими предположениями о будущем observability
1. Больший акцент на корреляциях между метриками, логами и трейсами
2. Использование новых сигналов для анализа (как, например, профайлеры)
3. Аггрегация логов без индексов
#observability
1. Больший акцент на корреляциях между метриками, логами и трейсами
2. Использование новых сигналов для анализа (как, например, профайлеры)
3. Аггрегация логов без индексов
#observability
Grafana Labs
What's Next for Observability | Grafana Labs
It's no longer just about metrics, logs, and traces. Grafana Labs' VP of Product Tom Wilkie and Red Hat Software Engineer Frederic Branczyk make some bold predictions for the future of observability.