Админим с Буквой
5.51K subscribers
302 photos
8 videos
59 files
1.15K links
Канал о системном администрировании, DevOps и немного Инфобеза.

По всем вопросам обращаться к @bykva. Рекламу не размещаю.
Download Telegram
Forwarded from k8s (in)security (Дмитрий Евдокимов)
01_Kubernetes,_ответь_мне,_кто_я_для_тебя,_Константин_Аксенов,_Флант.pdf
2.4 MB
"Kubernetes, ответь мне, кто я для тебя", Константин Аксенов, Флант
02_Не_такой_очевидный_RBAC_Kubernetes,_Дмитрий_Евдокимов,_Luntry.pdf
1.9 MB
"Не такой очевидный RBAC Kubernetes", Дмитрий Евдокимов, Luntry
03_Как_приручить_Linux_capabilities_в_Kubernetes,_Николай_Панченко.pdf
5.8 MB
"Как приручить Linux capabilities в Kubernetes", Николай Панченко, Тинькофф
04_Контейнерная_ОС_Flatcar_как_обмазаться_докерами_и_забыть_про.pdf
2.2 MB
"Контейнерная ОС Flatcar: как обмазаться докерами и забыть про пакеты", Александр Кондратьев, BI.ZONE
05_NetworkPolicy_для_системных_и_инфраструктурных_компонент,_Александр.pdf
1.6 MB
"NetworkPolicy для системных и инфраструктурных компонент", Александр Кожемякин, VK
06_OPA_с_shared_Docker_executor,_Павел_Сорокин,_OZON.pdf
12.4 MB
"OPA с shared Docker executor", Павел Сорокин, OZON
Forwarded from YAH (Egor Bogomolov)
Открытая образовательная программа для Хакеров

Про программу «Профессия – белый хакер» я уже писал, но очень хочется правильно донести посыл.

Я захотел сделать открытый образовательный проект по наступательной кибербезопасности для всех, кто имеет отношение к ИБ. Даже если просто задумывается об учебе или работе в этой сфере. Программу для всех, кто, как я когда-то, не понимал, с чего начать. Дать возможность вкатиться в нашу теперешнюю профессию.

Сегодня с друзьями из сообщества - коллегами, преподавателями, учащимися - мы запустили образовательный трек "Профессия - белый хакер", который является абсолютно открытым, без какой-либо навязывающей рекламы типа «КУПИ чтобы идти дальше». Он дает продвинутое представление о том, как будет выглядеть ваша работа белым хакером, какие знания вам нужны и какие этапы вас ждут дальше. Со ссылками на международные платформы, с указанием материалов и мест, популярных в мире, где можно еще учиться хакерским навыкам. С большим упором на методичность объяснения, без "наговаривания фундаментальщины" и только с полезными замечаниями и мыслями.

Этот трек создан сообществом и для сообщества. Чтобы таких, как мы, становилось все больше. Чтобы мы объединялись вокруг подобных инициатив и делали наше российское комьюнити круче: пополняли новыми людьми CTF команды, стартапы, крупных игроков, университеты и лицеи.

Ссылка на регистрацию: https://u.to/TseyHw , после регистрации вам сразу придет приглашение на Stepik!

P.S. В том, что это сделали именно CyberEd, можно увидеть рекламу. Но кто-то должен был это сделать. Просто наслаждайтесь, и я надеюсь, это принесет вам пользу!
У меня честно говоря даже слов нет чтобы выразить все чувства и эмоции, которые переполняют меня при прочтении этой статьи: https://habr.com/ru/articles/742492/

Одно лишь могу сказать - когда вас спросят, почему вы зарабатываете 300-400-500к/месяц, покажите им эту статью
Victoriametrics релизнули продукт для сбора и визуализации логов. Интересно будет посмотреть-сравнить

https://docs.victoriametrics.com/VictoriaLogs/

https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs
Свежая статья от 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
Forwarded from FutureCrew
Мы приглашаем опытных девопсов для работы с тремя направлениями во 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.
Очень зашло, аж захотелось поделиться
Forwarded from k8s (in)security (Дмитрий Евдокимов)
Сегодня мы очень рады сообщить вам, что стали доступны все видеозаписи докладов с прошедшей конференции БЕКОН, посвящённой безопасности контейнеров и контейнерных сред (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-ветки при деплое на стенды: паттерн или антипаттерн?».
Александр Шрамко, Павел Степуро — «Единое рабочее пространство администратора, или Когда закончилось место на панели вкладок».
Дмитрий Мошенко — «Как мы в Сбере предоставляем техническую поддержку сотрудникам».

Для участия в онлайне или офлайне нужно зарегистрироваться.
Forwarded from Инженер Тяпкин (Clear Gray)
Ладно, покекали, давайте теперь и побухтим.

Есть один вопрос, который преследует меня постоянно. В работе, на собесах (причём с обеих сторон), в общении за пивом. Каждый раз он порождает жаркие дискуссии и взаимные обвинения в гомосексуализме профнепригодности. Каждый, сука, раз правильный ответ заставляет людей уходить со взглядом на тысячу парсек. И вопрос этот очень прост: "Как работают хелсчеки апстримов в 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) но он очень давно не обновлялся, хоть и присутствует в большом количестве публичных каналов, и не понятен его статус. Вдруг кто-то придумал что-то повеселее? =)