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

Сегодня мы очень рады сообщить вам, что стали доступны все видеозаписи докладов с прошедшей конференции БЕКОН, посвящённой безопасности контейнеров и контейнерных сред (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 на разных видеокартах — читайте в статье Антона Алексеева.

Вижу вилы и факелы, но ничего с этим поделать не могу =) Чем больше менеджерской работы, тем меньше остается времени на что-то техническое. Теперь технические победы остаются за моими коллегами, а моя задача - обеспечение их комфорта. А в связи с этим, запушу вакансии:

1) https://krasnogorsk.hh.ru/vacancy/89616137. Требуется классический продуктовый девопс - несколько продуктов, несколько команд, обеспечение работы девелоперов от пайпов до мониторинга. Удаленка только из рф. часовой пояс - Москва.

2) Нужен синьёор на задачи унификации, стандартизации, анализа и приведения подходов и инструментов используемых во всех девопс-командах, к единому знаменателю. Требования высокие, без знания сетей на уровне ССNA даже не пишите =) Сама вакансия открывается с 2024_Q1, поэтому сейчас без ссылки на хх.

#bizone #вакансии

jaeger релизнули поддержку эластика 8. Не прошло года (с), таки дождались пока EOL у 7ки наступит и вот тогда...

https://github.com/jaegertracing/jaeger/pull/4829
https://github.com/jaegertracing/jaeger/issues/3571

Записки о резюме и из резюме

Исходя из концепции Run-Change-Disrupt и учитывая современные вызовы BANI-мира рассматриваю только полную удаленку.