Инструментарий инженера DevOps🧰🎒

Операционная система → Linux (recommended), Windows

Программирование → Go, Python, Groovy, Bash

Container orchestration → Kubernetes, Docker Swarm

Containers → Docker, Podman, Containerd

Source Code Management → Git, Subversion

Cloud → AWS, GCP, Azure, CivoCloud

CI/CD → Jenkins, CircleCI, Bamboo

Хостинг IT-проектов → GitHub, BitBucket, GitLab

IaC (Infrastructure as Code) and IP (Infrastructure Provisioning) → Ansible, Puppet, Chef, Terraform, Pulumi, Stack, Crossplane

Непрерывная обратная связь → GetFeedback, Jira, Slack, Pendo

Обсервация (мониторинг, протоколирование и анализ поведения системы) → Nagios, Grafana , Prometheus, New Relic, ELK Stack Datadog

Планирование → Jira Software, Confluence, Slack

Автоматизированное тестирование → xray, snyk, JUnit, Selenium, Appium

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


📲 Мы в MAX

#devops #девопс

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

SQL за полтора часа в одном видео! Полный базовый курс по SQL. Базы данных курс для начинающих!

00:00:00 Введение
00:02:43 Платные курсы и что изучать дальше
00:04:55 Коротко об онлайн редакторе
00:07:11 Что такое база данных
00:08:10 Что такое CRUD
00:10:05 Запрос на создание первой таблицы
00:11:57 Типы данных у атрибутов(колонок) (DATA TYPES)
00:17:26 Прописываем атрибуты(колонки) первой таблицы
00:21:07 Создаем первую таблицу (CREATE TABLE)
00:21:38 Проверка на наличие таблицы при создании (IF NOT EXISTS)
00:22:18 Запрос на удаление таблицы(DROP TABLE)
00:22:33 Проверка на наличие таблицы при удалении(IF EXISTS)
00:22:57 Запрос на добавление объекта в таблицу (INSER INTO table)
00:23:35 Запрос на чтение(получение) объектов из таблицы(SELECT * FROM table)
00:24:18 Модификаторы для атрибутов(колонок) таблицы(NOT NULL, DEFAULT, UNIQUE)
00:29:26 Изменение уже существующей таблицы(ALTER TABLE, ADD, DROP, RENAME, MODIFY COLUMN)
00:36:08 Удаление объектов из таблицы(DELETE FROM table)
00:37:06 Редактирование объекта в таблице(UPDATE table)
00:39:03 Первичный ключ(PRIMARY KEY)
00:45:37 Композиция в бд
00:50:38 "Иностранный" ключ(FOREIGN KEY)
00:57:26 Индексы в бд(INDEX)
00:59:24 Готовим данные для темы алиас, юнион и слияние таблиц
01:03:30 Слияние таблиц(INNER JOIN)
01:06:02 Слияние таблиц(LEFT JOIN)
01:06:53 Слияние таблиц(RIGHT JOIN)
01:07:26 Слияние таблиц(FULL JOIN/OUTER JOIN) и Union
01:09:04 Алиас(table AS alias)
01:12:18 Select Distinct в SQL
01:13:42 AND OR NOT в SQL
01:16:18 ORDER BY и LIMIT в SQL
01:17:35 MIN и MAX в SQL
01:18:25 COUNT SUM AVG в SQL
01:19:29 LIKE в SQL
01:21:31 IN и BETWEEN в SQL
01:22:50 GROUP BY в SQL
01:25:17 EXISTS в SQL
01:27:37 ANY и SOME в SQL
01:29:00 INSERT INTO в SQL
01:30:40 Отношения в базе данных
01:32:11 Отношения один к одному
01:33:09 Отношения один ко многим
01:34:09 Отношения многие ко многим
01:37:10 Отношения один к одному и один ко многим "через"
01:39:10 SQL инъекции

источник

📲 Мы в MAX

#devops #девопс

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

🚀 GitOps: Почему DevOps больше не будет прежним

GitOps – это не просто модное слово, а подход, который меняет игру в управлении инфраструктурой. Почему? Давай разберёмся!

🔹 1. Вся инфраструктура как код
Вместо ручного изменения конфигурации – все в Git. Хочешь новый сервис или обновление? Открыл Pull Request, проверил, замерджил – и всё развернулось автоматически.

🔹 2. Автоматическое применение изменений
Git становится единственным источником правды (SSOT). Если что-то изменилось в репозитории – операционные изменения автоматически применяются в инфраструктуре.

🔹 3. Быстрое восстановление
Если что-то сломалось, просто откатываешь коммит в Git, и система сама приводит всё в правильное состояние.

🔹 4. Аудит и безопасность
Любое изменение фиксируется. Можно посмотреть, кто что сделал, когда и зачем – плюс автоматический контроль доступа через Git-платформу.

🔹 5. Простота масштабирования
Добавить новый кластер или окружение? Просто создать новый файл в Git и всё развернётся само.

🔥 Топ-3 инструмента для GitOps
✅ ArgoCD – управление Kubernetes-кластерами через Git.
✅ FluxCD – лёгкое и гибкое GitOps-решение для Kubernetes.
✅ Terraform + Atlantis – автоматическое применение Terraform-конфигов по PR.

GitOps – это про контроль, скорость и удобство. Если ты всё ещё делаешь kubectl apply -f, самое время задуматься!

📲 Мы в MAX

#devops #девопс

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

🚀 Как правильно организовать CI/CD в Kubernetes

Если деплой в кластер до сих пор выглядит как «собрал образ руками - накатил kubectl apply - помолился», пора это менять. Разбираем, из чего должен состоять нормальный CI/CD-пайплайн для K8s.

1. Разделяйте CI и CD

CI (сборка, тесты, линт, сборка образа) и CD (доставка в кластер) - это разные зоны ответственности. Смешивать их в один монолитный скрипт - путь к боли. CI живёт в GitHub Actions / GitLab CI / Jenkins, а за CD лучше отвечает отдельный инструмент.

2. GitOps - ваш друг

Вместо того чтобы пайплайн напрямую пушил изменения в кластер, используйте GitOps-подход: Argo CD или Flux следят за Git-репозиторием с манифестами и сами синхронизируют состояние кластера. Плюсы:
— вся история изменений в Git;
— откат = git revert;
— кластер не нужно пускать в CI-раннер с полными правами.

3. Отдельный репозиторий для манифестов

Код приложения и его K8s-манифесты (или Helm-чарты/Kustomize-оверлеи) стоит держать раздельно. CI-пайплайн после сборки образа просто обновляет тег в репозитории с манифестами - а дальше в дело вступает GitOps-контроллер.

4. Иммутабельные образы и семантические теги

Никаких latest в проде. Тегируйте образы по SHA коммита или семверу — это даёт трассируемость и предсказуемость.

5. Progressive delivery

Canary- и blue-green-деплои через Argo Rollouts или Flagger снижают риск раскатки. Добавьте автоматический анализ метрик (Prometheus) - и плохой релиз откатится сам, без участия человека.

6. Секреты - не в манифестах

External Secrets Operator, Sealed Secrets или Vault - выбирайте, но никогда не коммитьте секреты в открытом виде, даже в «приватный» репозиторий.

7. Тестируйте манифесты до применения

kubeval, conftest (OPA), kube-score - валидируйте YAML и политики безопасности ещё на этапе CI, а не когда под уже упал в проде.

8. Отдельные пайплайны под окружения

Dev - быстрый автодеплой на каждый коммит. Staging - деплой по мержу в основную ветку. Prod - только по тегу/релизу, с ручным approval-гейтом.

Итог: связка CI (сборка + тесты) → registry → Git-репозиторий манифестов → GitOps-контроллер (Argo CD/Flux) → progressive delivery - это тот самый «правильный» CI/CD для Kubernetes, который не превращается в источник инцидентов.

Какой стек используете вы - Argo CD, Flux или что-то своё? 👇

📲 Мы в MAX

#devops #девопс

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

🚀 CI/CD: Как не устроить себе ад 🚀

Автоматизация деплоя – это must-have. Но сколько раз ты видел, как CI/CD ломает прод? Разберём ключевые моменты, чтобы не наступать на грабли.

✅ Грамотный пайплайн
1️⃣ Lint & Code Style – форматируй код перед билдами (Prettier, Black, ESLint).
2️⃣ Тесты – без них CI/CD превращается в русскую рулетку. Покрываем юнит и интеграцией.
3️⃣ Security Checks – SAST, DAST, секреты в коде (Trivy, Snyk, GitLeaks).
4️⃣ Билд образов – минимизируем размер, убираем уязвимости.
5️⃣ Деплой – делаем blue-green или canary, чтобы не убить прод сразу.

✅ Выбор инструментов
- GitHub Actions / GitLab CI – удобно, если уже сидишь на этих платформах.
- ArgoCD / Flux – GitOps для Kubernetes.
- Jenkins – старый, но всё ещё мощный, если его правильно готовить.
- Tekton – если хочешь true cloud-native CI/CD.

✅ Ошибки, которые убьют прод
⚠️ Деплой без тестов – поздравляю, у тебя теперь ручное QA на проде.
⚠️ Хранение секретов в репо – топ-1 причина утечек. Vault, SealedSecrets, Doppler.
⚠️ Отсутствие Rollback – если нет возможности быстро откатиться, ты в опасности.

🔥 Вывод: CI/CD – это не просто кнопка "деплой". Это стратегия, которую надо строить с умом. Инвестируй в тесты, автоматизацию и безопасность, и будет тебе стабильность.

📲 Мы в MAX

#devops #девопс

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

Garnet — это удалённое кэш-хранилище от Microsoft Research, обеспечивающее высокую производительность (пропускную способность и задержку), масштабируемость, хранение, восстановление, шардирование кластера, миграцию ключей и функции репликации. Garnet может работать с существующими клиентами Redis.

Основные возможности:
- Высокая производительность: миллионы операций в секунду с минимальной задержкой.
- Масштабируемость: поддержка горизонтального масштабирования.
- Оптимизация работы с памятью: эффективное использование DRAM и SSD.

Этот проект может стать серьезным конкурентом Redis и Memcached в сфере облачных сервисов.

https://github.com/microsoft/garnet

📲 Мы в MAX

#devops #девопс

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

🔥 Как снизить Latency в Kubernetes? 🔥

Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!

🚀 1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:

kubectl edit configmap -n kube-system kube-proxy

Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.

🚀 2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:

helm install cilium cilium/cilium --namespace kube-system

🚀 3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов.

🚀 4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

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

🚀 5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.

📲 Мы в MAX

#devops #девопс

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

Pipeline CI/CD, объясненный простыми словами

Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.

Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.

Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.

Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене

📲 Мы в MAX

#devops #девопс

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

Шпаргалка по Kubernetes

1. Основные понятия
🔘Pod – наименьшая единица развертывания, содержит один или несколько контейнеров.
🔘Deployment – контроллер, который управляет репликами Pod’ов и их обновлением.
🔘Service – абстракция, предоставляющая доступ к Pod’ам (ClusterIP, NodePort, LoadBalancer).
🔘ConfigMap – хранит конфигурационные данные в виде ключ-значение.
🔘Secret – безопасное хранилище для конфиденциальных данных (пароли, токены).
🔘PersistentVolume (PV) – абстракция для хранения данных.
🔘PersistentVolumeClaim (PVC) – запрос на использование хранилища (PV).
🔘Namespace – логическое разделение ресурсов в кластере.
🔘Ingress – объект, предоставляющий доступ к сервисам внутри кластера через HTTP/HTTPS.

2. Основные команды kubectl

Работа с контекстом

kubectl config get-contexts # Список контекстов
kubectl config use-context <name> # Переключение контекста
kubectl config set-context <name> --namespace=<namespace> # Установить namespace по умолчанию

Работа с ресурсами

kubectl get pods # Список Pod'ов
kubectl get deployments # Список Deployment'ов
kubectl get services # Список Service'ов
kubectl get nodes # Список узлов
kubectl get namespaces # Список namespace'ов
kubectl get events # Лог событий
kubectl describe pod <pod-name> # Подробная информация о Pod
kubectl logs <pod-name> # Логи Pod
kubectl exec -it <pod-name> -- /bin/sh # Зайти внутрь контейнера

Создание и удаление объектов

kubectl apply -f <file>.yaml # Применить манифест
kubectl delete -f <file>.yaml # Удалить объект
kubectl delete pod <pod-name> # Удалить Pod
kubectl delete deployment <deploy-name> # Удалить Deployment

3. Пример манифестов

Простой Pod

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80

Service (NodePort)

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
type: NodePort

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80

4. Полезные команды

kubectl top pod # Мониторинг использования CPU/RAM Pod'ов
kubectl top node # Мониторинг узлов
kubectl rollout status deployment <deploy-name> # Статус развертывания
kubectl rollout undo deployment <deploy-name> # Откат изменений
kubectl autoscale deployment <deploy-name> --min=2 --max=10 --cpu-percent=80 # Авто-масштабирование

5. Отладка и устранение проблем

kubectl get pods --all-namespaces # Проверить состояние всех Pod'ов
kubectl describe pod <pod-name> # Подробности о Pod
kubectl logs <pod-name> # Логи контейнера
kubectl logs <pod-name> -p # Логи завершившегося контейнера
kubectl exec -it <pod-name> -- /bin/sh # Подключение внутрь контейнера
kubectl get events --sort-by=.metadata.creationTimestamp # Последние события

📲 Мы в MAX

#devops #девопс

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

Ingress-nginx уходит в прошлое. С марта 2026 поддержка прекратилась. А что вместо него? Предлагаем посмотреть на Gateway API, новый стандарт Kubernetes SIG.

23 июля в 17:00 старший SRE-инженер MWS Cloud Евгений Макеев на практике покажет:

⚫️ чем маршрутизация Gateway API отличается от Ingress
⚫️ как выбрать контроллер
⚫️ как установить Gateway API в Managed Kubernetes
⚫️ как настроить безопасное подключение через TLS-сертификат

Будет полезно для DevOps, платформенным инженерам и разработчикам.

Регистрируйтесь по ссылке

📌Docker

Удаление промежуточных образов без тэгов:
docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

Мягко перезапустить контейнер:
docker kill --signal="USR1" <yourcontainer_name>

Список контейнеров:
docker ps -a

Подключиться к контейнеру:
docker exec -it container_name bash

Остановить все контейнеры:
docker stop $(docker ps -a -q)

Удалить все контейнеры, из которых вышли:
docker rm -v $(docker ps -aq -f status=exited)

Удалить образ:
docker rmi image_name

Создать образ:
docker build -t image_name

Удалить все неиспользуемые тома:
docker volume prune

Подключиться под рутом в контейнер Alpine:
docker exec -it --user root alpine-container bash

📲 Мы в MAX

#devops #девопс

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

🐳 Хватит тащить curl и vim в продакшн! (Используем Ephemeral Containers)

Салют, коллеги, всех с прошедшими праздниками! 👋

Сколько раз я видел Dockerfile, который начинается за здравие (FROM alpine), а заканчивается установкой половины интернета: apk add curl vim net-tools bind-tools...?

Аргумент всегда один: "Ну мне же надо как-то дебажить, если под отвалится!"

В итоге мы получаем:

1. Раздутый образ. (Платим за сторадж и трафик).
2. Дыру в безопасности. (Хакер, попавший в контейнер, скажет спасибо за curl и nmap, любезно оставленные вами).

Правильный путь - это Distroless образы или минимальный Alpine, где нет даже шелла. А для дебага мы используем Ephemeral Containers (эфемерные контейнеры).

🛠 Как это работает?

В Kubernetes (начиная с v1.25 это уже стабильная фича) вы можете "подселить" временный контейнер в работающий Pod. Он будет делить с подом пространство имен процессов (PID) и иногда сети, но файловая система у него будет своя.

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

🔥 Практика: kubectl debug

Допустим, у вас есть "глухой" под my-app, в котором нет ничего, кроме бинарника приложения. Вам нужно проверить сеть.

Вместо того чтобы пересобирать образ, делаем так:

kubectl debug -it my-app \
  --image=nicolaka/netshoot \
  --target=my-app-container

Разберем магию:

🔘 --image=nicolaka/netshoot: Мой любимый образ для траблшутинга. Там есть ВСЁ: tcpdump, curl, dig, iperf, mtr.
🔘 --target: Указываем, к какому контейнеру в поде подключиться (важно, чтобы видеть процессы друг друга).

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

💡 А если я не в K8s?

Если вы сидите на чистом Docker, похожий трюк делается через --pid и --network:

docker run -it --rm \
  --network container:my-prod-container \
  --pid container:my-prod-container \
  nicolaka/netshoot

Итог: Перестаньте бояться Distroless образов. Инструментарий для внешнего дебага уже давно вырос.


📲 Мы в MAX

#k8s #docker #security #tips #debug

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

🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?

Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).

Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская.

Разберем две крайности и как делать правильно.

❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)

Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.

🔘Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода.

🔘Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки.

🔘Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса.

❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)

Вы решили быть умными и в /health эндпоинт засунули проверку коннекта к Базе, Редису и S3.

🔘Сценарий: База данных немного приуныла (медленные запросы).

🔘Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать.

🔘Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself.

✅ Как делать правильно: Liveness vs Readiness

В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.

1. Liveness Probe (Я жив?)

🔘Цель: Понять, не завис ли процесс намертво.
🔘Действие при сбое: РЕСТАРТ контейнера.
🔘Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться.


2. Readiness Probe (Я готов работать?)

🔘Цель: Понять, можно ли пускать на меня трафик.
🔘Действие при сбое: УБРАТЬ из балансировки (не убивать!).
🔘Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров.



📝 Пример (K8s Manifest):

livenessProbe:
  httpGet:
    path: /health/live # Максимально тупой ответ 200 OK
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready # Проверка БД, очередей и т.д.
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

💡 Главный совет

Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он Ready, или отдавать ошибку юзеру, оставаясь "живым".

#k8s #devops #fails #stability #bestpractices

📲 Мы в MAX

#devops #девопс

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