​Свежая статья от Neil Buesing в которой он раскрывает все тонкости настройки Apache Kafka в режиме KRaft! Для тех кто не в курсе (что очень странно для меня т.к. мой видос про Kraft давно в сети), KRaft — это KRaft mode in Apache Kafka, режим, который позволяет Kafka работать без использования Apache ZooKeeper.
В статье вы найдете подробные инструкции и лучшие практики по настройке этого режима.
🔗 Статью вы можете прочитать по этой ссылке: тут
А если вы предпочитаете действовать на практике, у нас есть хорошая новость: код и docker compose файлы из статьи доступны на Github!
🔗 GitHub репозиторий: тут

Прикольная визуализация работы AWS
https://media.licdn.com/dms/image/D4E22AQE2jRapTPMMsg/feedshare-shrink_2048_1536/0/1687177177295?e=1690416000&v=beta&t=Wmenb5G5ELMptFLBernazh5RDNUz8hwOfnufvlNVdRw

🌍 Amazon CloudFront
🌐 Amazon Route 53
💻 Amazon EC2
⚖️ Amazon Autoscaling
🪪 Amazon Certificate Manager
🪣 Amazon Backup service
🗄️ Amazon RDS
☁️ Amazon VPC
🔐 Amazon WAF
👁️ Amazon CloudWatch

Мы приглашаем опытных девопсов для работы с тремя направлениями во Future Crew: это Data Platforms, приватная связь и защита от уязвимостей периметра.

Если темы вам интересны – откликайтесь по ссылкам.

DevOps в Data Platforms

Задачи: K8s, VMWare, Linux, изоляция ресурсов (GPU, CPU, RAM), LDAP, мониторинг, участие в создании архитектуры, развитие CI/CD для ML и не только.

О команде Big Data можно мы немного рассказывали здесь.

DevOps в Membrana

К8 – одна из ключевых составляющих нашей инфраструктуры. Девопс будет работать с контейнерами, сетями, маршрутами и Kafka.

Здесь можно прочитать о технологиях и о команде.

DevOps в Cicada8

Задачи: Построение и доработка кластера K8s, настройка системы мониторинга с нуля, автоматизация развертывания и скейлинга Cicada8. Опыт работы с облачными провайдерами и понимание процессов ИБ будет плюсом.

А здесь есть ещё три вакансии в команде Cicada8.

Очень зашло, аж захотелось поделиться

Сегодня мы очень рады сообщить вам, что стали доступны все видеозаписи докладов с прошедшей конференции БЕКОН, посвящённой безопасности контейнеров и контейнерных сред (Kubernetes в первую очередь).

Таким образом сейчас уже доступны все материалы с мероприятия:
- Видео
- Презентации
- Фотоотчет

P.S. Теперь уже можно смело готовиться к следующему БЕКОНу ;)

не самое лучшее мое выступление, но были причины много нервничать)

позитива и принятия заббиксоводам =)

Sber OPS Meetup: удобство, функциональность, надежность

🗓 10 июля 18:00 (МСК, GMT+3)

🌐Онлайн — трансляция на сайте
📍Офлайн — офис Сбера по адресу: Москва, Кутузовский проспект, 32, корпус Г

В большом комьюнити единомышленников будут обсуждать актуальные темы ИТ-сопровождения: Kubernetes Governance as a Code, dev/staging/testing-ветки, рабочее пространство администратора и техподдержку для сотрудников.

Что в программе:
✔ Максим Чудновский — «Kubernetes Governance as a Code, или Как содержать кластеры в чистоте и порядке».
✔ Семен Киреков — «Разделение на dev/master-ветки при деплое на стенды: паттерн или антипаттерн?».
✔ Александр Шрамко, Павел Степуро — «Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок».
✔ Дмитрий Мошенко — «Как мы в Сбере предоставляем техническую поддержку сотрудникам».

Для участия в онлайне или офлайне нужно зарегистрироваться.

Ладно, покекали, давайте теперь и побухтим.

Есть один вопрос, который преследует меня постоянно. В работе, на собесах (причём с обеих сторон), в общении за пивом. Каждый раз он порождает жаркие дискуссии и взаимные обвинения в гомосексуализме профнепригодности. Каждый, сука, раз правильный ответ заставляет людей уходить со взглядом на тысячу парсек. И вопрос этот очень прост: "Как работают хелсчеки апстримов в nginx?"

И честно, я не знаю, почему люди настолько уверены, что у nginx эти самые хелсчеки есть, что готовы с пеной у рта отстаивать свою позицию.

Если вы уже готовы негодовать "ДА КАК НЕТ-ТО БЛЯДЬ ТЫ ЧО ТАМ СОВСЕМ ОХУ...", то тут самое время притормозить и сделать глубокий вдох. Я уже много раз участвовал в этом диалоге, фоллоу ми.

Что такое healthcheck вообще? Это проверка какой-то системы на предмет её состояния, чтобы понять, с этой системой всё хорошо или не очень.

То есть, когда у нас есть апстрим, то мы в него кричим "Тебе там нормально вообще?" и ждём, что оттуда послышится "Нормально!". Тогда мы понимаем, что апстрим живой и в него можно слать наш драгоценный трафик.

Но у нас же обычно больше одного апстрима (больше ведь, да?) и называем мы это всё группой. И нам бы хотелось, чтобы в группе все апстримы были рабочими, а нерабочих не было и наши ценннейшие запросы не улетали в один конец гнить до таймаута. И поэтому мы берём наш хелсчек и кричим в каждый апстрим в группе "Нормально тебе?". И если слышим в ответ "Намана!", то считаем апстрим хорошим, годным, а если не "Намана!" или вообще тишина - то считаем его плохим. Хорошие оставляем в группе, плохие исключаем, пока снова не начнут отвечать "Намана!".

Ну классика же, да? Ну все же так работают, и Haproxy, и Envoy, и любой балансировщик, да даже Apache. Ну очевидно же. Так вот, nginx не таков.

В nginx у нас тоже есть группы апстримов, мы туда тоже кидаем запросы, они летят в апстримы по roundrobin (по умолчанию, ага), но что будет, если один апстрим в группе вдруг перестанет отвечать? А нихуя не будет, лол. Он просто останется в этой группе, потому что механизма проверки нет. И тут вы такие "СТОПЭ, КАК ЭТО НЕТ, ОН ЖЕ КАК-ТО ПОНИМАЕТ, ЧТО НАДО ПОСЛАТЬ ЗАПРОС В ДРУГОЙ АПСТРИМ?". И вот тут мы подходим к самой мякотке:

ЖИВОСТЬ АПСТРИМА ОПРЕДЕЛЯТСЯ ПО РЕЗУЛЬТАТУ ЗАПРОСА.

То есть прилетает наш боевой запрос в nginx и проваливается в группу апстримов, где просто засылается в первый апстрим из списка. Запрос прошёл успешно и апстрим вернул 200? Отлично, посылаем ответ клиенту. Апстрим ответил 502? Просто берём этот же запрос и отправляем его в следующий апстрим из списка. И так пока запрос не обработается или апстримы не кончатся. Когда прилетит следующий запрос, он тоже пойдёт по этому кругу и не важно, что первый апстрим в списке у нас умер и всегда отвечает 502, ведь механизма хелсчека нет.

И тут у большинства возникает логичный вопрос: а если апстрим не совсем умер, а просто не отвечает и запросы к нему падают по таймауту? Всё верно, запрос будет ждать ответа весь таймаут, после чего будет отправлен в следующий апстрим. И если у вас в группе три апстрима и два первых не отвечают, то да, суммарное время обработки запроса будет "таймаут 1-го апстрима + таймаут 2-го апстрима + время ответа 3-го апстрима". Вот на этом простом факте и ломается большинство неокрепших умов, особенно тех, кто с nginx'ом встречается только в составе ingress'а в кубах. И именно поэтому у меня непроизвольно закатываются глаза всякий раз, как я слышу "а для балансировки трафика мы возьмём nginx".

"Как же так может быть в 2К23 году, что у одного из самых популярных веб-серверов нет хелсчеков?", спросите вы. И я вам отвечу: они на самом деле есть, но только за деньги в nginx plus. Но идея платить за nginx по популярности болтается где-то на уровне "купить лицензию winrar", да и ценник там моё почтение.

Вот теперь можете выдыхать с протяжным "БЛЯЯЯяяяя..."

P.S. если всё ещё считаете, что я пизжу, вам в первые три абзаца документации к ngx_http_upstream_module

P.P.S да, я знаю про max_fail и fail_timeout, даже про retry знаю, но это просто костыли от отсутствия хелсчеков

.

С праздником, котаны!

Товарищи, подскажите пожалуйста кто чем пользуется для отслеживания новых релизов опенсорс продуктов? Интересует что-то типа телеграм бота, который будет ходить по гитхабу/гитлабу/конкретному урлу и сообщать в телегу о новом релизе (т.е. не ручная подписка!). Я знаю, что есть бот от Владимира (https://github.com/Civil/github2telegram/tree/master) но он очень давно не обновлялся, хоть и присутствует в большом количестве публичных каналов, и не понятен его статус. Вдруг кто-то придумал что-то повеселее? =)

Примечание: разбор python3 print(“hello, world”)

Что происходит, когда запускаешь «Hello World» в Linux

В статье рассказано об инструментах, при помощи которых вы можете исследовать происходящее. Будут рассмотрены утилиты readelf, strace, ldd, debugfs, /proc, ltrace, dd и stat. Читать статью.

А мы в BI.ZONE снова в поиске devops инженеров. и даже двух. Выкладываю наиболее горящую вакансию (возможна частичная удалёнка не более 2 дней в неделю из-за особенностей продукта)

https://hh.ru/vacancy/84677754

Когда вы разворачиваете ML-сервис, всегда возникает вопрос: как эффективно использовать ресурсы GPU?

Если вы это делаете в Kubertenes, то по умолчанию можете выделить подам только целое количество GPU. Даже когда вам достаточно 10%!
А избыточные мощности — это лишние затраты, которых хочется избежать.

Как зашерить GPU на разных видеокартах — читайте в статье Антона Алексеева.