DevOps *

Не у всех есть необходимость в тонкой настройке access logging в Envoy, но если она всё-таки возникает, то могут понадобиться примеры, которых почему-то не очень много в документации. Поэтому мы сделали перевод статьи, где вы можете познакомиться с Envoy, узнать, как включить журнал доступа (access log) Envoy в Istio, и научиться настраивать фильтры.

Предполагается, что у вас есть базовые знания об Istio, но даже если у вас их нет, вы можете следовать этому руководству и попробовать настроить всё на своей локальной машине.

Hello world!

В первой части шпаргалки (вопросника, если угодно) на высоком уровне рассматриваются такие вещи, как сеть, HTTP, операционная система, виртуализация, хранилище etc., а также несколько технологий, используемых в сфере DevOps, таких как Prometheus, OpenStack, Puppet, Elastic etc. (вопросы с ответами из основного репозитория оригинала). Полагаю, шпаргалка будет интересна всем, кто связан с разработкой программного обеспечения, прежде всего, с разработкой веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий/терминов, а также в обнаружении очепяток.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

Как я из телефона сделал сервер для своего бота в телеграме

Все началось с того что я написал своего бота и решил его выложить в открытый доступ, а точнее чтобы он работал круглосуточно, но платить деньги, за хостинг мне не хотелось. И тогда я вспомнил, что у меня как раз в ящиках залежались старые 2 телефона, можно сказать только один, потому что второй я превратил в кирпич (Неправильно перепрошил). Мой путь поиска программы для установки линукса начался с Termux, но к сожелению он работает только с Android 7+. А телефон на Android 5. Поэтому действенным решением я выбрал UserLAnd.

Кибербезопасность сейчас в тренде, безопасность инфраструктуры и ПО, располагаемого в ней, тоже. В рамках серии статей хотелось бы поговорить об этом и поделиться нашим опытом. 

В первой части я расскажу про проект, который недавно пришел к нам с таким ТЗ: 

1. Замкнутый контур;

2. Отсутствие CVE во всех используемых продуктах;

3. Контроль безопасности уже имеющейся инфраструктуры;

4. Контроль доступа до среды;

5. Автоматизация процессов.

Давайте посмотрим, что из этого вышло. 

Сетевой стек Linux не прост даже на первый взгляд: приложение — в юзерспейсе, а всё, что после сокета, — в ядре операционки. И там тысяча реализаций TCP. Любое взаимодействие с сетью — системный вызов с переключением контекста в ядре.

Чтобы лишний раз не дёргать ядро прерываниями, придумали DMA — Direct Memory Access. И это дало жизнь классу софта с режимом работы kernel bypass: например при DPDK (Intel Data Plane Development Kit). Потом был BPF. А за ним — eBPF. 

Но даже помимо хаков работы с ядром есть такие штуки, как sk_buff, в которой хранятся метаданные всех миллионов протоколов. Есть NAPI (New API), которая призвана уменьшить число прерываний. Есть 100500 вариантов разных tables.

И копать можно безгранично далеко. Но сегодня мы всё же поговорим о вещах более приземлённых и повседневных, которые лишь приоткрывают вход в эту разветвлённую сеть кроличьих нор. Мы разберём одну любопытную задачку, на примере которой ужаснёмся тому, как сложно может быть реализован такой простой протокол, как DHCP.

Приветствую!

В прошлой части мы развернули основные сервисы Airflow в k8s. В этот раз разберемся, как можно синхронизировать код DAD'ов с удаленным репозиторием, поймем, как перманентно сохранять логи, а также настроим HTTPS-соединение для UI!

Всем привет! На связи ITSumma.За 15 лет, что мы делаем нагрузочное тестирование, у нас накопился список самых распространенных ошибок, которые совершают, когда строят и отлаживают инфраструктуру.

Ну список и список скажете вы, но в этой статье мы хотим поделиться не только самими ошибками, но и инструкциями, как их найти. Так что не будем затягивать предисловие и сразу перейдем к делу.

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service. В прошлых статьях мы описали подход и показали пути решения проблем с контролем ресурсов команды и инфраструктуры, с ними можно ознакомиться тут и тут. Сегодня мы поговорим о построении процесса взаимодействия команд разработки и тестирования со службой DevOps, при этом отходя от дежурств подразделения в чате.

Для начала попробую описать суть проблемы. Представим, что у нас есть небольшое подразделение, не более 5 человек, которое как служба - одна на все команды разработки и тестирования. Количество обращающихся команд может быть от 10 до 20. Казалось бы – не мало ли людей на такое количество команд? Да, не много. А не хотим ли мы увеличить состав? Но реальность такова, что проблему обращений надо решить с помощью имеющихся в наличии ресурсов, а потом, разобравшись с ней и построив процесс работы с бэклогом команды и пониманием его объёма, уже запрашивать ресурсы на расширение команды. Пока этого нет, можем рассчитывать только на имеющиеся руки.

Как используя связку Promtail + Loki + Grafana настроить сбор логов из текстового файла и сделать простой, но функциональный дашборд.

Привет, Хабр!

MLOps, или Machine Learning Operations, это практика объединения машинного обучения и операционных процессов. Она направлена на упрощение и ускорение цикла разработки, тестирования, развертывания и мониторинга моделей машинного обучения. В MLOps применяются принципы DevOps, такие как автоматизация, непрерывная интеграция и доставка, для создания более эффективных и масштабируемых решений в области машинного обучения.

Объемы данных растут экспоненциально, способность быстро и эффективно обрабатывать эти данные становится ключевой для успеха. MLOps позволяет не просто создавать модели машинного обучения, но и быстро адаптироваться к изменениям, обновлять модели и поддерживать их работоспосоность на высоком уровне. Это важно, поскольку модель, которая работала хорошо вчера, может устареть сегодня из-за изменения данных или условий окружающей среды.

Привет, Хабр! Меня зовут Андрей, я новый Android-разработчик в команде онлайн-кинотеатра PREMIER. 

Когда я только пришел на работу в проект, мне поставили задачу внедрить измерение билдов для того, чтобы видеть, как с течением времени у нас меняется время сборки проекта на разных билд-машинах. 

Решение задачи

После проведенного анализа я выявил два варианта решения.

Всем привет меня зовут Максим, я SRE инженер в группе компаний Тинькофф.
Но сегодня я здесь по другой причине.

Я уже давно собираю и публикую подборки видео, от которых есть толк, с разных каналов SRE направленности в телеграмм канале https://t.me/sre_pub и спасибо им большое за то что позволяют мне это делать.

Но я не видел подобных подборок на хабре и для меня до сих пор загадка почему.
Лично для меня Хабр является основной площадкой для получения информации.
Вы можете это понять по 1500+ моих закладок в профиле.

Так вот я просмотрел все доклады с SREcon23 составил для вас подборку из докладов вырезав все доклады в которых было больше болтовни или рекламы чем пользы.

Ctrl-F + репозиторий и лампа джина из пещеры Чудес будет не нужна.

Спойлер: джины все же рассказывают секреты.

Во времена популярности микросервисной архитектуры появляется все больше потребности в платформах и решениях для автоматизации сложных или нереализуемых вручную процессов. Например, когда нам нужно работать с высоконагруженными приложениями, имеющими свои крутые пики и просадки посещаемости, было бы очень сложно построить архитектуру без использования Docker-контейнеров (виртуальных машин), которые позволяют разбивать приложение на части, взаимодействующие друг с другом. Однако задача становится еще более сложной, если мы работаем с приложением, которое делится на другие приложения, которые в свою очередь разделены на контейнеры, и вся эта система обрабатывает миллионы запросов пользователей и хранит невообразимый объем информации.

Яркие примеры таких приложений: YouTube или Google. Естественно, на одной машине такие сервисы не развернуть, поэтому в архитектуре используются тысячи компьютеров, именуемых Нодами (worker node). Однако эти Ноды, как части общего механизма, могут выходить из строя, и тогда их нужно заново поднимать, более того, хорошо бы вообще постоянно мониторить каждый Нод и считывать его состояние. Выполнять такие задачи становится очень сложно вручную. И, возможно, именно для этих площадок, а может быть и нет, но Google разработала технологию Kubernetes, которая выполняет роль оркестрации контейнеров. Kubernetes следит за Нодами и поднимает те, что выходят из строя, но это не единственная ее задача. Технология также может отключать неиспользуемые Ноды, оптимизируя расход ресурсов.

В мире, где Kubernetes доминирует в управлении контейнеризированными приложениями, один вопрос часто встаёт перед теми, кто стремится понять его внутренние механизмы: 'Как на самом деле работает k8s scheduler?' Эта статья предназначена для развенчания мифов и предоставления чёткого объяснения работы Kubernetes планировщика. Мы исследуем ключевые моменты этого процесса, начиная от того, назначает ли планировщик модули узлам один за другим в очереди или выполняет эту задачу параллельно, и заканчивая более сложными аспектами его работы. Погрузитесь в детали этой сложной, но увлекательной темы вместе с нами, чтобы лучше понять, как Kubernetes оптимизирует размещение подов в вашем кластере

Привет, Хабр! Я Степан, DevOps‑инженер, занимаюсь созданием CI/CD процессов с учётом проверки кода на безопасность, поддержкой и разверткой новых кластеров Kubernetes, соблюдением требований безопасности и созданием системы мониторинга и логирования — все это в рамках одной команды. Хочу рассказать об одной незадокументированной особенности Istio, с которой мне довелось столкнуться при внедрении Service Mesh.

Об Istio на Хабре написано уже немало (например, тут и тут, может пригодиться новичкам в этой теме), но вот разбора конкретных примеров не хватает. И когда у нас в ОТП Банке возникла проблема с «Истио», решать её нашей команде пришлось самостоятельно.

Быть может, наш опыт пригодится тому, кто позже наступит на те же грабли. Даже лучше будет, если кто‑то прочитает и уже не наступит. Конкретно наши грабли пригодятся при использовании Istio для маршрутизации в рамках одного кластера. Ещё наш кейс можно проецировать на другие задачи с маршрутизацией. И использовать как пример того, как в нестандартных ситуациях искать качественное решение.

Как и статьи по ссылкам выше, этот текст в основном для начинающих. Эксперты, вероятно, и без того в курсе (возможно, даже подскажут более эффективное решение). С экспертизой и более глубокой работой с istio + может быть с envoy данное решение будет найти не так сложно. Под катом — подробности проблемы, схема нашего конфига с решением и код.