DevOps

🛠 Git Cheat Sheet: 12 команд, которые должен знать каждый DevOps 📂 Начало работы • git init - создаем новый репозиторий. Помните, что это просто создает скрытую папку .git. • git remote - связываем локальный код с удаленным сервером (GitHub/GitLab). • Совет: Используйте git remote -v, чтобы проверить, куда вы пушите код. 🔄 Основной цикл (Commit & Sync) • git add - добавляем изменения в индекс (staging). • git commit - фиксируем изменения. Пишите осмысленные сообщения! "Fixed bug" - плохо, "Fix: update nginx config for timeout issue" - хорошо. • git push / git pull - отправка и получение изменений. • Важно: git pull - это на самом деле fetch + merge. 🌿 Ветвление и слияние • git branch - работа с ветками. В DevOps мы часто используем feature-branches. • git checkout - переключение между ветками. (Кстати, в новых версиях Git для этого чаще используют git switch). • git merge - объединение веток. 🔍 Диагностика и откат • git status - ваша любимая команда. Показывает, что происходит прямо сейчас. • git fetch - забирает данные из репозитория, но не меняет ваш локальный код. Безопасный способ проверить обновления. • git reset - откат изменений. • ⚠️ Осторожнее с флагом --hard, он удаляет изменения безвозвратно! 💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в .bashrc или .zshrc. Например: alias gs='git status' alias gl='git log --oneline --graph --all' #git #devops #cheatsheet #programming #automation 📲 Мы в MAX Подпишись 👉@i_DevOps

📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Устранение проблем с отсутствующими логами Kubernetes в Elasticsearch Отсутствующие логи могут стать настоящей проблемой для многих пользователей Kubernetes. В этой статье мы разберемся, почему это происходит, и как этого избежать. Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов. https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/ 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Yandex BareMetal подтвердил соответствие высшему стандарту безопасности персональных данных. Сервис прошел аттестацию по высшей степени защиты персональных данных. Это значит, что пользователи гарантировано безопасно могут хранить на BareMetal всё, что требует максимальной безопасности — от CRM и бухгалтерии до медицинских и государственных данных. Независимый аудит подтвердил, что команда сервиса действительно серьезно относится к защите информации, а не просто формально выполняет требования. Кому это важно — госсектор, финтех, медицина, аутсорсеры и все, кто работает с чувствительными данными и нуждается в физической изоляции и официально подтвержденной безопасности. Как устроена безопасность - Дата-центры в России - Модульная L2-связность без единой точки отказа (SPOF) - Данные стираются полностью при возврате серверов - Поврежденные диски уничтожаются физически Кратко про Yandex BareMetal - Физические серверы без виртуализации - Высокая изоляция ресурсов - Интеграция с Yandex Cloud - Аренда от 1 дня - Готовые и кастомные конфигурации Подробнее по ссылке.

Furiko Это современный планировщик заданий Kubernetes, созданный с нуля для гибкости, расширяемости и надёжности. Он спроектирован для запуска заданий с различными политиками повторения, управления историей запусков и предоставления пользовательского интерфейса для просмотра и администрирования заданий. Furiko состоит из следующих компонентов: - QueueJob Controller: абстракция заданий, которые можно ставить в очередь с масштабируемой логикой запуска. - CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой. - Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями. - CLI: утилита командной строки для взаимодействия с заданиями Furiko. https://github.com/furiko-io/furiko 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Какую функцию выполняет ReplicaSet? Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей. Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений? Пространства имен позволяют разделить кластер на виртуальные группы, внутри которых можно объединять приложения по нужному принципу. Таким образом, создается возможность изолировать различные группы приложений друг от друга. Например, благодаря этой функции можно создать приложение с одинаковым именем в двух разных пространствах. Если использовать только одно пространство имен, которое было задано по умолчанию при запуске кластера, со временем может стать сложно ориентироваться во всех приложениях, запущенных в нем. Группировка приложений в разных пространствах имен упрощает работу: например, можно разместить приложение мониторинга в одном пространстве, а приложения, связанные с информационной безопасностью, в другом. Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером. 📲 Мы в MAX #devops #девопс Подпишись 👉@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

⚙️ CI/CD часто выглядит как набор разрозненных скриптов. Но платформа — это не пайплайн, а пайплайн — не YAML. На открытом уроке вы за один раз пройдёте весь путь: от выбора платформы до работающего CI/CD-конвейера. Покажем, как за 100 секунд получить первый результат, а затем разберём, из каких решений он состоит и почему это именно так. ⌨️ Вы увидите, как проектировать CI/CD системно: - создание пайплайнов - тестирование - деплой - обработка ошибок - обновления без простоев - масштабирование Разберём типовые архитектурные подходы и ошибки, которые мешают превратить CI/CD в устойчивую часть инфраструктуры. 💛Встречаемся 29 января в 20:00 МСК в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes». ➡️ Регистрация открыта: https://vk.cc/cTMqSm Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

SnapScheduler — это контроллер Kubernetes, который автоматически создает снапшоты PVC (PersistentVolumeClaim) по расписанию, используя встроенный механизм VolumeSnapshot. Он не зависит от CSI-драйвера, пока тот поддерживает VolumeSnapshot, и работает с любым сторедж-классом, поддерживающим снапшоты. Основные возможности: - Создание снапшотов PVC по расписанию (cron). - Поддержка нескольких расписаний для одного PVC. - Возможность настройки политики хранения (retention policy). - Не требует изменений в приложении или манифестах PVC. Как это работает: Вы создаете ресурс SnapshotSchedule, в котором указываете: - Селектор PVC. - Cron-расписание. - Максимальное количество снапшотов для хранения. Контроллер следит за расписанием и создает VolumeSnapshot объекты автоматически. Пример использования:

apiVersion: snapscheduler.backube/v1
kind: SnapshotSchedule
metadata:
  name: example-schedule
spec:
  schedule: "0 */6 * * *"
  snapshotTemplate:
    labels:
      createdBy: snapscheduler
  pvcSelector:
    matchLabels:
      snapshot: "true"
  retention:
    maxCount: 5

Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом snapshot=true, и хранить максимум 5 последних. https://github.com/backube/snapscheduler 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

DevOps, как сам? Как строили мост между разработкой и эксплуатацией Меня зовут Георг Гаал, я член ПК DevOpsConf. Я энтузиаст информационных технологий со школьной скамьи. Меня эта тема очень зажгла, когда я в первый раз сел за компьютер и осознал, что вообще не понимаю, как он функционирует. Сегодня я попытаюсь на примерах из своего опыта рассказать про эволюцию DevOps, актуальных трендах и о том, как оставаться востребованным в профессии. https://habr.com/ru/companies/oleg-bunin/articles/891422/ 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Сертификация, которая реально работает на вас 🔘DevOps‑инженеры с опытом от 2 лет могут пройти экзамен Yandex Cloud DevOps Engineer: 65 вопросов, 90 минут, онлайн. Это не просто теория — это подтверждение практического опыта с автоматизацией инфраструктуры и CI/CD. 🔘 После прохождения сертификации 74% участников отмечают, что почувствовали рост уверенности в своих знаниях. Такое нам надо! Успейте зарегистрироваться до 31 марта со скидкой 50% и получить буст для карьеры. Все подробности тут. 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Тренировки по DevOps. Часть 1 Лекция 1: Кто такой DevOps Лекция 2: Облако. Кто виноват и что делать? Лекция 3: Процессы Linux Лекция 4: Сети Часть 1. Коты и коробки Разбор домашнего задания 1: Кто такой DevOps Разбор домашнего задания 2: Облако. Кто виноват и что делать? Лекция 5: Linux: инструменты командной строки Лекция 6: Базы данных Разбор домашнего задания 3: Процессы Linux" Разбор домашнего задания 4: Сети. Часть 1. Коты и коробки источник #devops #девопс Подпишись 👉@i_DevOps

⚡️ Готовые решения и лучшие практики для надёжной защиты API в архитектуре бэкенда 📅 26 января | 20:00 мск | бесплатно Хотите, чтобы ваши API были надёжно защищены без потери производительности? На вебинаре разберём: - Типовые угрозы и уязвимости API - Аутентификация и авторизация - Защита на уровне архитектуры - Роль API Gateway и прокси в обеспечении безопасности - Лучшие практики проектирования защищённых API и контрактов ✅ После вебинара вы сможете: - Проектировать API с учётом безопасности на уровне архитектуры - Применять готовые решения для защиты API - Осознанно балансировать между безопасностью, сложностью и производительностью 👉 Регистрация https://vk.cc/cTFqe2 Занятие приурочено к старту курса "Software Architect" в OTUS. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Docker для начинающих: простое развертывание приложения за несколько шагов Всем привет! Для своей первой статьи я решил выбрать проблему, с которой сам столкнулся при изучении Java и попытке упаковки приложения в докер-контейнер. К сожалению не нашел ни одной исчерпывающей статьи, как это делать, поэтому решил написать свою. Начну, пожалуй, с самого сервиса. Я написал достаточно простое веб-приложение на стеке - Java, Spring, Maven, REST, HTTP, Hibernate, Postgresql, JSP/JSTL. Пока приложение представлено достаточно в сыром виде, но для понимания, как оно упаковывается в контейнер, вполне подойдет. Если вкратце, то это сервис для голосования за лучший ресторан, где можно зарегистрироваться, добавить ресторан, его описание, оставить отзыв и проставить рейтинг. Также, в зависимости от роли, можно посмотреть информацию о пользователях и редактировать ее. https://habr.com/ru/articles/888540/ 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

Это репозиторий aws2tf от AWS Samples, предназначенный для автоматического преобразования существующих ресурсов AWS в код Terraform. Он может помочь экспортировать инфраструктуру AWS в виде кода Terraform, что полезно для управления IaC (Infrastructure as Code). Основные возможности aws2tf: - Генерация Terraform-кода на основе существующей AWS-инфраструктуры. - Поддержка множества сервисов AWS. - Автоматическое создание зависимостей между ресурсами. - Упрощение миграции и управления конфигурацией. https://github.com/aws-samples/aws2tf 📲 Мы в 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

Давно планировал выучить Go, но не хотел тонуть в теории? Курс «Golang-разработчик» в Слёрме стартует 30 января. Мы создали его для бэкенд-разработчиков и DevOps-инженеров, которые хотят сменить стек или научиться писать инфраструктурные инструменты на Go. Важно: курс не для новичков. Почему этот курс дает результат: • 80% обучения — это практика. Вместо скучных лекций вы получите 53 часа прикладной работы. • Спикер-практик. Обучение ведет Виталий Лихачев, SRE в Booking.com. • Реальный проект в портфолио. Ты с нуля спроектируешь отказоустойчивый сервис на выбор: онлайн-банк, мессенджер или файловое хранилище. Попробуй продукт бесплатно: мы открываем демо-доступ на 3 дня. Ты сможешь оценить платформу, подачу материала и решить, подходит ли тебе темп обучения, прежде чем платить.

👉 Занять место или получить демо-доступ 👉 Проверь свои знания и получи полезные материалы от экспертов рынка.

Пакетная фильтрация в Linux Бесконтекстная пакетная фильтрация (iptables): stateless Контекстная пакетная фильтрация (iptables): stateful источник 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps

🔥 Kubernetes: Инструмент дьявола или необходимость? Давайте честно: у многих при слове «Кубер» начинает дергаться глаз. Бесконечные YAML-простыни, сложная архитектура и ощущение, что мы стреляем из пушки по воробьям. Если вы считаете, что docker-compose - это венец творения, а K8s - оверинжиниринг, этот материал для вас. На i-odmin вышел отличный «Гайд по Куберу для хейтеров». О чем речь: 🩵🤬 Почему Kubernetes вызывает столько боли (и почему это нормально). 🩵🐳 Как перестать бояться и понять базовые абстракции. 🩵🛠 Когда оркестрация действительно нужна, а когда можно обойтись без неё. Статья написана простым языком, без лишнего академизма. Отличный способ либо наконец понять K8s, либо найти новые аргументы для споров в комментариях. 👉 Читать гайд: https://i-odmin.ru/gajd-po-kuberu-dlja-hejterov/ 📲 Мы в MAX #DevOps #Kubernetes #K8s #Guide #Humor Подпишись 👉@i_DevOps

🚀 Шпаргалка по Docker 🐳 🔹 Сборка (Build) 🔹 Запуск (Run) 🔹 Шаринг (Share) 🔹 Управление (Management) 📌 Сборка образов 📍 Создать образ из Dockerfile и присвоить тег:

docker build -t myimage:1.0 .

📍 Посмотреть локальные образы:

docker image ls

📍 Удалить образ:

docker image rm alpine:3.4

📌 Запуск контейнеров 📍 Запустить контейнер на порту 5000:

docker container run --name web -p 5000:80 alpine:3.9

📍 Остановить контейнер:

docker container stop web

📍 Принудительно завершить контейнер:

docker container kill web

📍 Список запущенных контейнеров:

docker container ls

📍 Удалить все контейнеры:

docker container rm -f $(docker ps -aq)

📌 Работа с образами (Share) 📍 Скачать образ из реестра:

docker pull myimage:1.0

📍 Изменить тег у локального образа:

docker tag myimage:1.0 myrepo/myimage:2.0

📍 Запушить образ в реестр:

docker push myrepo/myimage:2.0

📌 Управление Docker (Management) ⚙️ docker app – Управление приложениями ⚙️ docker image – Управление образами ⚙️ docker container – Управление контейнерами ⚙️ docker network – Управление сетями ⚙️ docker volume – Управление хранилищами ⚙️ docker stack – Управление Docker Stack ⚙️ docker swarm – Управление кластером Swarm ⚙️ docker system – Управление всей системой 📝 Сохраните, поделитесь с друзьями и подписывайтесь на канал! 💙🐳 📲 Мы в MAX #devops #девопс Подпишись 👉@i_DevOps