Путь в DevOps: полное руководство для новичков с НУЛЯ - 2025

00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование Windows
12:38 - 3. Основы Linux
13:28 - 4. Ansible
13:56 - 5. Git
14:26 - 6. GitHub
14:52 - 7. CI/CD: GitHub Actions, GitLab CI/CD
15:29 - 8. Docker + DockerHub
16:16 - 9. Kubernetes + Helm + ArgoCD
17:04 - 10. AWS: Amazon Web Services
19:12 - 10. GCP: Google Cloud Platform
20:27 - 10. Azure: Microsoft Azure
21:38 - 11. Terraform + Terragrunt
22:42 - 12. Python
23:09 - Как стать профессиональным DevOps Ннженером
24:37 - Девопс это хорошее будущее вашей карьеры

источник

#devops #девопс

Подпишись 👉@i_DevOps

#devops #девопс

Подпишись 👉@i_DevOps

Каким образом мы можем управлять вычислительными ресурсами в k8s?

Для эффективного управления ресурсами в кластере k8s используются resources requests / limits. Они могут быть настроены для CPU, памяти и, в последних версиях k8s, для GPU.

Requests используются для определения типичного потребления ресурсов нашим приложением. На основе этих данных Kubernetes scheduler выбирает ноды для запуска PODов (сумма всех request'ов контейнеров во всех PODах не должна превышать доступные ресурсы на ноде).

Limits служат как механизм предотвращения, ограничивая потребление ресурсов контейнером в PODе. При превышении лимита процессорного времени применяется thermal throttling, а при превышении лимита памяти — механизм OOM.

Модель, при которой requests меньше limits, называется burstable QoS, а когда requests равны limits — guaranteed QoS.

Кроме того, можно установить квоты ресурсов на namespace (CPU, память, количество запущенных PODов, размер диска persistent volume) и указать требования к resources requests на PODах в namespace с помощью limit ranges.

Для управления ресурсами приложений также можно использовать автоскейлеры. В k8s доступны HPA (horizontal pod autoscaler), который регулирует количество PODов в зависимости от потребления CPU и/или памяти, и VPA (vertical pod autoscaler), который управляет resources requests / limits.

Существуют также реализации автоскейлеров, которые могут использовать внешние метрики (например, длину очереди), такие как carpenter или KEDA. В облачном окружении можно использовать cluster autoscaler для добавления или удаления нод в зависимости от общей загрузки кластера.

#devops #девопс

Подпишись 👉@i_DevOps

13 законов разработки ПО

Некоторые из них хорошо известны, другие — достаточно нишевые. Но все они очень полезны разработчикам и менеджерам. Любопытно, какие из них вам известны:

Закон Паркинсона.
Закон Хофштадтера.
Закон Брукса.
Закон Конвея (и обратный закон Конвея).
Закон Каннингема.
Закон Старджона.
Закон Завински.
Закон Хайрама.
Закон Прайса.
Эффект Рингельмана.
Закон Гудхарта.
Закон Гилба.
Закон Мёрфи.

https://habr.com/ru/companies/ruvds/articles/898254/

#devops #девопс

Подпишись 👉@i_DevOps

🛠Построение CI/CD-фреймворка MLOps уровня Enterprise (MLflow + Kubeflow)

Разработка MLOps-фреймворка в масштабах предприятия — непростая задача. Она требует интеграции множества компонентов: обработки данных, экспериментов, мониторинга и CI/CD. В этом посте рассказывается, как объединить MLflow, Kubeflow, Seldon Core, GitHub Actions и другие инструменты для построения полноценного MLOps-пайплайна.

Архитектура

Архитектура построена на:

- MLflow — для логирования и управления экспериментами
- Kubeflow Pipelines — для оркестрации пайплайнов
- Seldon Core — для деплоя моделей в Kubernetes
- MinIO — объектное хранилище для артефактов
- GitHub Actions — для CI/CD
- Prometheus + Grafana — мониторинг моделей

Компоненты развернуты в Kubernetes-кластере с использованием Helm.

Поток разработки

1. Подготовка данных — скрипты ETL обрабатывают сырые данные и сохраняют в MinIO.
2. Обучение модели — тренинг происходит в Kubeflow, результаты логируются в MLflow.
3. Тестирование и валидация — автоматизированные проверки модели.
4. CI/CD — GitHub Actions запускает пайплайны при изменении кода или модели.
5. Деплой — модель деплоится через Seldon Core, становится доступной по REST/gRPC.
6. Мониторинг — метрики поступают в Prometheus и отображаются в Grafana.

Преимущества подхода

- Реплицируемость и трассировка экспериментов
- Централизованное хранилище артефактов
- Автоматизация развёртывания моделей
- Мониторинг производительности и дрифта

Заключение

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

https://rkmaven.medium.com/building-an-enterprise-level-mlops-ci-cd-framework-mlflow-kubeflow-fb1cdd1f74fc

#devops #девопс

Подпишись 👉@i_DevOps

💡 Лучшие практики работы с Helm: что нужно знать

Если вы используете Helm для управления приложениями в Kubernetes, крайне важно следовать ряду проверенных практик, чтобы обеспечить поддержку, масштабируемость и безопасность ваших чартов.

📦 1. Структура директорий чарта
Соблюдайте стандартную структуру чарта Helm:

mychart/
  charts/
  templates/
  values.yaml
  Chart.yaml
  README.md

Избегайте добавления нестандартных файлов и директорий. Это сделает чарты переносимыми и читаемыми.

🧩 2. Разделяйте общие шаблоны
Используйте _helpers.tpl для определения общих шаблонов, таких как аннотации, метки и имена ресурсов. Это снижает дублирование и упрощает сопровождение:

{{/* Генерация полного имени */}}
{{- define "mychart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

⚙️ 3. Используйте параметры в values.yaml
Делайте чарты гибкими, передавая конфигурации через values.yaml. Никогда не хардкодьте значения в шаблонах.

🧪 4. Валидация values.yaml
Добавляйте проверку обязательных значений с помощью required:

{{ required "Variable mychart.image.repository is required" .Values.image.repository }}

🔍 5. Используйте шаблоны if/else разумно
Старайтесь не перегружать шаблоны логикой. Разделяйте шаблоны на несколько файлов, если они становятся слишком сложными.

🗃️ 6. Не добавляйте чарт в шаблон напрямую
Вместо включения зависимостей в директорию charts/, указывайте их в Chart.yaml и используйте helm dependency update.

🛑 7. Не хардкодьте версии образов
Передавайте версию через values.yaml. Это повышает гибкость CI/CD:

image:
  repository: nginx
  tag: "1.21.1"

🔒 8. Управление чувствительными данными
Не храните пароли и токены в values.yaml. Используйте секреты Kubernetes или инструменты типа Sealed Secrets или External Secrets.

🔁 9. Helm hooks
Helm предоставляет хуки для выполнения задач до/после установки. Используйте их, например, для миграций БД. Пример:

annotations:
  "helm.sh/hook": pre-install

🧹 10. Чистка старых релизов
Используйте helm uninstall и регулярно проверяйте статус релизов с помощью helm list. Это помогает избегать конфликта имён и мусора.

🧪 11. Тестирование чарта
Добавляйте unit-тесты с помощью helm unittest и не забывайте про проверку синтаксиса:

helm lint .

🔄 12. Автоматизация через CI/CD
Интегрируйте Helm в пайплайны CI/CD для установки и обновления чартов — например, с помощью GitLab CI, GitHub Actions, ArgoCD или Flux.


Придерживайтесь этих рекомендаций — и работа с Helm станет надёжной, устойчивой и более предсказуемой. Это особенно важно при масштабировании инфраструктуры и работе в команде.

#devops #девопс

Подпишись 👉@i_DevOps

Блокировка состояния Terraform с использованием S3 (без DynamoDB)

В этом посте мы рассмотрим:

- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3

https://devopscube.com/terraform-state-locking-with-s3/

#devops #девопс

Подпишись 👉@i_DevOps

• infosec - это один из самых ламповых каналов по информационной безопасности, где говорят об истории ИТ, публикуют актуальные новости и пишут технический материал на разные темы:

- Что из себя представляет официально взломанный iPhone от Apple?
- Кому и для чего выдавалось разрешение на ношение сотового телефона?
- Бесплатные курсы для ИБ специалистов на различные темы;
- Бесплатный бот, который проверит файлы на предмет угроз более чем 70 антивирусами одновременно.

• Присоединяйся, у нас интересно: @it_secur

Проект heynote — это минималистичное CLI-приложение для создания и хранения заметок прямо из терминала. Он позволяет быстро фиксировать мысли или команды без необходимости переключаться на редактор или веб-интерфейс.

📌 Особенности:
- Хранит заметки в простом .txt-файле.
- Поддерживает добавление тегов (`#`) и отметок времени.
- Удобная фильтрация заметок по ключевым словам или датам.
- Возможность настройки пути к файлу хранения.

Пример использования:

heynote "Перезапустить nginx #devops"

Эта команда добавит строку со временем и текстом в файл заметок. Удобно, когда нужно быстро сохранить мысль во время работы в консоли.

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

https://github.com/heyman/heynote

#devops #девопс

Подпишись 👉@i_DevOps

Addon Controller

Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:

- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.

Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.

Возможности

- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.

Архитектура

1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.


https://github.com/projectsveltos/addon-controller?tab=readme-ov-file

#devops #девопс

Подпишись 👉@i_DevOps

Как настроить автоматический откат в Ansible

Петя запускает плейбук, чтобы обновить конфигурацию Nginx — и ломает сайт. В конфиге ошибка, сервис не стартует.

Ansible не умеет откатывать изменения сам. Но есть способ настроить автоматический откат — с помощью блоков block, rescue и always.

https://habr.com/ru/articles/900240/

#devops #девопс

Подпишись 👉@i_DevOps

Запускаем Sentry в Kubernetes в Яндекс облаке и храним Nodestore в S3

Sentry — это инструмент для отслеживания ошибок и производительности приложений в реальном времени.

Кратко о Sentry: что это, зачем он нужен
- Отслеживает баги и exceptions в бекенд, веб и мобильных приложениях.

Для кого этот пост
- Этот пост для тех кто хочет перейти с Sentry в docker-compose
- Для тех кто хочет перейти с Nodestore в PostgreSQL

https://habr.com/ru/articles/900526/

#devops #девопс

Подпишись 👉@i_DevOps

Расследование аферы с GitHub: как тысячи «модов» и «кряков» крадут наши данные

Просматривая статьи на тематическом форуме по социальной инженерии, я обнаружил относительно новую схему мошенничества, которая меня потрясла. На GitHub создаются тысячи репозиториев с разными штуками — от модов для Roblox и Fortnite до «взломанных» FL Studio и Photoshop.

Как только вы скачиваете и запускаете любую из них, все данные с вашего компьютера собираются и отправляются на Discord-сервер, где сотни злоумышленников просматривают их в поисках закрытых ключей криптокошельков, банковских счетов и учётных данных социальных сетей, а также аккаунтов Steam и Riot Games.

https://habr.com/ru/companies/flant/articles/899158/

original https://timsh.org/github-scam-investigation-thousands-of-mods-and-cracks-stealing-your-data/

#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как ускорить docker build и сократить размер образа

Иногда docker build тянется вечность, а итоговый образ весит больше, чем база данных 🐘. Разбираемся, как ускорить сборку и оптимизировать размер образа без потери функциональности.


1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):

# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]

Образ получается меньше 10 МБ!


2. Минимизируй base image
Используй alpine, distroless, scratch, если не нужен полноценный дистрибутив:

FROM python:3.12-slim

Или вообще:

FROM scratch

3. Правильно расставляй COPY и RUN
Кешируй слои — сначала зависимости, потом исходники:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Так pip install не будет повторяться при каждом изменении исходников.


4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:

RUN apt-get update && apt-get install -y ... \
 && rm -rf /var/lib/apt/lists/*

5. Используй .dockerignore
Иначе в билд попадут node_modules, .git, логи и прочее:

.git
node_modules
*.log

Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай — docker build тоже надо профилировать.

#devops #docker #ci #optimization

Подпишись 👉 @i_DevOps

🔥 Ускоряем сборку Docker-образов: слои и кэш — наши друзья

Когда сборка Dockerfile занимает минуты — это мешает dev-loop'у. А ведь можно сильно ускориться с парой простых правил 👇


🧠 Основные принципы ускорения:

1. Максимально используем кэш
Docker кэширует каждый слой. Если слой не изменился — пересобирать не будет.

➤ Сначала COPY зависимости, потом остальной код:

   COPY requirements.txt .
   RUN pip install -r requirements.txt  # кэшируется

   COPY . .  # некэшируемо при любом изменении в коде
   

2. Объединяем RUN-команды
Меньше слоёв — быстрее сборка и push:

   RUN apt update && apt install -y curl git \
       && rm -rf /var/lib/apt/lists/*
   

3. .dockerignore
Убедись, что не копируешь лишние файлы (например, .git/, tests/, node_modules/):

   .git
   node_modules
   *.log
   __pycache__/
   

4. Меньше COPY, больше multi-stage
Разделяй сборку и runtime — не таскай компиляторы в прод:

   FROM golang:1.20 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o app

   FROM debian:bullseye-slim
   COPY --from=builder /app/app /usr/bin/app
   CMD ["app"]
   

5. Кэшируй pip/npm/go-пакеты
→ в Dockerfile сначала копируй файл зависимостей, ставь пакеты, только потом — весь код проекта.


📌 Используй эти практики, чтобы ускорить CI/CD, локальную сборку и деплой. Чем меньше слоёв изменяется — тем быстрее весь процесс.


#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как ускорить GitHub Actions на 40% и платить меньше

CI — это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день — сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.


🔹 1. Используйте actions/cache правильно
Загрузка и компиляция зависимостей — одно из самых дорогих мест. Добавьте кэширование для npm, pip, go mod, docker layers. Пример для Node.js:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) — это приведёт к нестабильности.


🔹 2. Job matrix + fail-fast: false = контроль над параллелизмом
Matrix позволяет запускать тесты параллельно (например, разные версии Python), а fail-fast: false не останавливает все джобы при первом фейле.

strategy:
  fail-fast: false
  matrix:
    python-version: [3.8, 3.9, 3.10]

🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в .github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.

- uses: ./.github/workflows/reusable.yml
  with:
    env: staging

🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут — дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).

📌 Попробуйте actions-runner-controller для Kubernetes:
https://github.com/actions/actions-runner-controller


🔹 5. Откажитесь от setup-* при каждом запуске
setup-node, setup-go, setup-java — удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.


✅ Вывод:
Оптимизация GitHub Actions — это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное — вы перестаёте платить за простой.


🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows


#devops #девопс

Подпишись 👉@i_DevOps

Dokploy — Самый простой способ развернуть и управлять вашими контейнерами

Dokploy — это open-source инструмент для деплоя и управления контейнерами, разработанный для упрощения процессов CI/CD и DevOps. Он позволяет разработчикам легко развёртывать, управлять и масштабировать приложения без необходимости писать сложные скрипты или конфигурации.

Возможности:
- 🚀 Быстрый деплой контейнеров
- 🔄 Автоматическое обновление на основе webhook’ов
- 🧩 Простая интеграция с GitHub
- 🔒 Безопасное хранение переменных окружения
- 📦 Поддержка множества приложений
- 🛠️ Web UI и CLI для управления

Как это работает:
1. Подключаете свой репозиторий GitHub.
2. Dokploy следит за изменениями и автоматически деплоит ваше приложение.
3. Управляете всем через простой UI или CLI.

Цель проекта — дать каждому разработчику простой и эффективный способ доставки своего кода в прод.

https://github.com/dokploy/dokploy

#devops #девопс

Подпишись 👉@i_DevOps

Что такое userspace, kernelspace? Чем они отличаются?

Под пользовательским пространством понимается весь код операционной системы, который находится вне ядра.

Большинство Unix-подобных операционных систем (включая Linux) поставляются с разнообразными предустановленными утилитами, средствами разработки и графическими инструментами — это все приложения пространства пользователя.

Все пользовательские приложения (и контейнеризированные, и нет) при работе используют различные данные, но где эти данные хранятся?

Ядро обеспечивает абстракцию для безопасности, оборудования и внутренних структур данных. Например, системный вызов open() используется для получения дескриптора файла в Python, C, Ruby и других языках программирования. Вряд ли бы вы хотели, чтобы ваша программа работала с XFS на уровне битов, поэтому ядро предоставляет системные вызовы и работает с драйверами. Фактически этот системный вызов настолько распространен, что является частью библиотеки POSIX .

Краткое определение:

👉 Пользовательское пространство представляющее собой набор местоположений, в которых выполняются обычные пользовательские процессы (т. е. все, кроме ядра). Роль ядра состоит в том, чтобы управлять приложениями, работающими в этом пространстве, от взаимодействия друг с другом и с машиной.
👉 Пространство ядра , то есть место, где хранится и выполняется код ядра.
Пользовательское пространство имеет доступ к ограниченной памяти, ядро имеет всю память.

И чтобы работать приложения взаимодествуют через интерфейс, которое называется системным вызовом.

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD пайплайны на стероидах: 5 фишек для ускорения сборок 🚀

⏱ Устали ждать, пока пройдут все джобы в CI? Время — деньги, особенно на продакшене. Вот 5 проверенных способов прокачать скорость и стабильность пайплайнов.


1. Кэширование зависимостей — must have
Кэшируйте node_modules, .m2, Docker-слои или Python virtualenv.
В GitHub Actions:

   - uses: actions/cache@v3
     with:
       path: ~/.npm
       key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
   

2. Matrix strategy для параллельных задач
Разбейте тесты по окружениям, версиям или компонентам:

   strategy:
     matrix:
       python: [3.9, 3.10]
   

3. Docker Layer Caching (DLC)
В GitLab CI включайте DLC:

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: ""
   services:
     - docker:dind
   

4. Пропускайте джобы при отсутствии изменений
Нет изменений в директории — не триггери билд. В GitHub Actions:

   on:
     push:
       paths:
         - 'src/**'
         - '!docs/**'
   

5. Self-hosted runners для тяжёлых задач
Сильная машина с нужными зависимостями сэкономит десятки минут. Плюс — контроль среды и логирования.


Вывод:
Оптимизация CI/CD — это не про магию, а про дисциплину: кэш, параллелизм, условные шаги и правильные раннеры. Регулярно профилируйте пайплайны и фиксируйте bottlenecks.

#devops #девопс

Подпишись 👉@i_DevOps