🧑‍💻 Хватит читать про Linux. Открой терминал.

В IzzyLab мы подобрали для тебя более 400 заданий по разным темам и уровням сложности.

👨‍💻 Настоящий терминал прямо в браузере - ничего не нужно устанавливать.
👨‍💻 Задачи из реальной практики.
👨‍💻 От первых команд Linux до Terraform и Kubernetes.

Теория забывается за неделю. Практика - остаётся.

И да, это БЕСПЛАТНО.

Сохраняй в закладки - https://izzylab.ru

MemOps 😃

Как мы управляем инфраструктурой для 80 млн пользователей с командой из 5 человек

Часть 1 — Введение в инфраструктуру Yubo: Обзор и философия: https://medium.com/yubo-tech/how-we-manage-a-80m-users-infrastructure-with-a-5-person-team-part-1-introduction-to-yubos-d452103e6f0d

Часть 2 — Структура нашей команды и роли: Инженеры данных, DevOps и безопасность: https://medium.com/yubo-tech/how-we-manage-an-80m-user-infrastructure-with-a-5-person-team-part-2-our-team-structure-and-ce73b8d5bba4

Часть 3: Инженерия данных в масштабе и самообслуживание баз данных: https://medium.com/yubo-tech/how-we-manage-an-80m-user-infrastructure-with-a-5-person-team-part-3-data-engineering-at-scale-572d863598b0

Часть 4: Автоматизация в масштабе: https://medium.com/yubo-tech/how-we-manage-an-80m-user-infrastructure-with-a-5-person-team-part-4-automation-at-scale-944d86d5fd7f

Часть 5: Облачный нативный MLOps: https://medium.com/yubo-tech/how-we-manage-an-80m-user-infrastructure-with-a-5-person-team-part-5-cloud-native-mlops-332232f93aeb

MemOps 🤨

MemOps 😃

Создайте свой собственный управляемый сервис Kubernetes на Proxmox с помощью CAPI

Cluster API (CAPI) — это проект с открытым исходным кодом в экосистеме Kubernetes. Его цель — применить декларативные API и контроллеры в стиле Kubernetes к задачам инициализации, настройки, обновления и эксплуатации целых кластеров Kubernetes, рассматривая сами кластеры как первоклассные ресурсы Kubernetes, а не как внешнюю инфраструктуру, развертываемую вручную.

📌 Подробнее: https://itnext.io/build-your-own-managed-kubernetes-service-on-proxmox-with-capi-8d9786644818

MemOps 🤨

K8s мигрень. Т9 что-то знает

MemOps 😃

Migrate Datadog telemetry with the OpenTelemetry Collector

Если вы используете коммерческую APM (Dynatrace, Datadog, Appdynamics, Ключ Астром и пр.), она, скорее всего, совместима с OTel. А раз совместима, то и лить данные можно при помощи инструментов OTel. А раз вы уже используете инструменты OTel, то почему б не присмотреться к OTel-совместимой платформе ClickStack?

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

📌 Подробнее: https://clickhouse.com/blog/datadog-receiver-opentelemetry-collector

MemOps 🤨

MemOps 😃

Docker Model Runner (DMR) упрощает управление, запуск и развертывание моделей ИИ с помощью Docker.

Разработанный для разработчиков, Docker Model Runner оптимизирует процесс загрузки, запуска и обслуживания больших языковых моделей (LLM) и других моделей ИИ непосредственно из Docker Hub или любого реестра, совместимого с OCI.

Работает и в Docker Desktop для Window или MacOS, для нативного Linux - устанавливается в виде Docker plugin

📌 Подробнее: https://github.com/docker/model-runner

MemOps 🤨

MemOps 😃

Что на самом деле происходит, когда вы запускаете контейнер самой типичной командой docker run nginx?

На первый взгляд кажется, что Nginx становится вашим foreground-процессом в терминале – он перехватывает stdio-потоки и реагирует на сигналы, когда вы нажимаете Ctrl+C или меняете размер окна терминала.

Но в реальности терминалом управляет процесс Docker-клиента, а сам Nginx работает в фоне или вообще на удалённой машине. При этом между docker CLI, dockerd (основным Docker-демоном) и containerd (низкоуровневым container runtime) происходит довольно сложная проксировка данных и сигналов — из-за чего всё ощущается как простой локальный запуск.

Почему это важно? Понимание того, как работает docker run под капотом — ключ к пониманию Kubernetes и других продакшн-рантаймов. В продакшене контейнеризованные приложения обычно работают в фоне, но Kubernetes и похожие системы позволяют стримить логи приложений и даже переподключаться к процессам в контейнерах, используя те же самые трюки, что и Docker.

Подробнее о магии за командой docker run — в подробном разборе (с кучей практических упражнений):

📌 Подробнее: https://labs.iximiuz.com/tutorials/docker-run-vs-attach-vs-exec

MemOps 🤨

MemOps 😃

Pod завис в Pending? Вот по какой цепочке kube-scheduler решает, куда его посадить

kube-scheduler не выбирает ноду случайно. Сначала Pod попадает в ActiveQueue и сортируется по приоритету — PriorityClass здесь решает, кто пойдёт первым. Потом идёт фильтрация: какие ноды вообще подходят по ресурсам, taint’ам и affinity. Оставшиеся кандидаты проходят scoring, где учитываются запрошенные ресурсы, topology spread и affinity.

Если Pod не запланировался, смотрите kubectl describe pod: в Events увидите, на каком шаге отсеялись ноды и почему. Иногда причина в resource requests, иногда в taints или anti-affinity. Разбор на devops.dev проходит путь от очереди до binding и preemption.

📌 Подробнее: https://blog.devops.dev/where-did-my-pod-go-a-deep-dive-into-k8s-scheduling-d1d50c23e549

MemOps 🤨

MemOps 😃

offlog — бесплатный менеджер задач с открытым исходным кодом, ориентированный на локальное использование

📌 Подробнее: https://github.com/hrach-gevorgyan/offlog

MemOps 🤨

MemOps 😃

SRE-агенты переходят от рекомендаций к автономным действиям

В классическом SRE инженер получает алерт, открывает консоль, гоняет диагностику и правит по ранбуку. Агент ИИ может съесть тот же алерт, коррелировать его с недавним деплоем и выполнить рутинное исправление самостоятельно.

Это меняет роль SRE: из «делающего вручную» в «менеджера команды агентов», которые накапливают операционную память и снижают зависимость от одного эксперта. Но работает только при одном условии — выбираете один целевой сценарий, а не натягиваете «ИИ-слой» на всё подряд.

📌 Подробнее: https://thenewstack.io/sre-ai-agents-capabilities/

MemOps 🤨

MemOps 😃