Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и SRE — это следующие этапы развития системного администратора.

Это наблюдение подтверждают и открытые вакансии: практически каждая дает список используемых технологий и бонусов для будущего кандидата, но не раскрывает специфику работы. Если бизнес не транслирует пользу от вакансии — сотрудники подбираются исходя из используемой технологии. А ведь есть разница в том, чтобы, например, администрировать Kubernetes, разворачивать полезную нагрузку в Kubernetes или обеспечивать высокую доступность приложению, развернутому в Kubernetes.

Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.

https://habr.com/ru/companies/ru_mts/articles/949910/

Мы в MAX

#devops #девопс

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

Варианты реализации GitOps при помощи Argo CD

В «Экспресс 42» — подразделении «Фланта», которое консультирует компании по DevOps-практикам, — решили проверить, как можно реализовать GitOps по модели BSA (Base, Service, Application) с помощью Argo CD. Чистый эксперимент на тестовом репозитории.

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

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

Мы в MAX

#devops #девопс

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

Перечислите различные сервисы K8, которые могут работать на узлах.

Kubernetes (K8s) запускает различные службы на узлах, в том числе:

На рабочих узлах:
kubelet: отвечает за управление узлами и обеспечение того, чтобы контейнеры работали должным образом.
kube-proxy: предоставляет службы сетевого прокси-сервера для обеспечения связи между узлами и службами.
На главных узлах:
kube-apiserver: предоставляет API Kubernetes, через который все остальные компоненты взаимодействуют с кластером.
kube-scheduler: назначает вновь созданные модули узлу на основе доступности ресурсов и других ограничений.
kube-controller-manager: отслеживает состояние кластера и выполняет задачи для поддержания желаемого состояния, такие как масштабирование вверх или вниз.
Другие службы, которые могут работать на рабочих узлах, включают kube-dns, который обеспечивает разрешение DNS для служб Kubernetes, и kubelet, который управляет жизненными циклами модулей на узле.

Мы в MAX

#devops #девопс

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

Платформа управления оповещениями и AIOps с открытым исходным кодом.

Рабочие процессы

Keep — это GitHub Actions для ваших инструментов мониторинга.

Рабочий процесс Keep — это декларативный YAML-файл, который автоматизирует управление оповещениями и инцидентами. Каждый рабочий процесс состоит из следующих элементов:

- Триггеры — что запускает рабочий процесс (оповещения, инциденты, расписание или ручной запуск).
- Шаги — чтение или получение данных (обогащение, контекст).
- Действия — выполнение операций (обновление тикетов, отправка уведомлений, перезапуск серверов).

https://github.com/keephq/keep

Мы в MAX

#devops #девопс

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

Atlantis

Автоматизация Pull Request в Terraform

https://github.com/runatlantis/atlantis

Мы в MAX

#devops #девопс

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

Синхронизация локальных изменений с docker/kubernetes контейнером

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

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

Мы в MAX

#devops #девопс

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

Изучаем Ansible Inventory: основы и примеры использования

Перевели статью об основах Ansible inventory. В ней рассматривается базовая функциональность, управление переменными, комбинирование нескольких источников Inventory и варианты работы с динамическими Inventory.

Статья будет полезна тем, кто изучает Ansible.

https://spacelift.io/blog/ansible-inventory

Мы в MAX

#devops #девопс

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

Опыт масштабирования Kubernetes на 2k узлов и на 400k подов

Расскажу, как мы в PayPal начинали осваивать Kubernetes. На тот момент большинство наших рабочих нагрузок выполнялось на Apache Mesos, и в рамках этой миграции нам требовалось разобраться с некоторыми аспектами производительности у кластеров, в которых будет работать Kubernetes – с учётом той плоскости управления, что действует в PayPal. Из всех этих аспектов важнее всего было понять, как именно масштабируется платформа, а также выявить, как можно было бы улучшить масштабируемость, настраивая параметры кластера.

https://habr.com/ru/companies/timeweb/articles/787774/

Мы в MAX

#devops #девопс

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

🧹 Автоматическая очистка логов старше N дней

Если логи разрастаются, а места становится всё меньше — пора автоматизировать их очистку! Вот простой способ удалить файлы старше, скажем, 14 дней:

find /var/log -type f -name "*.log" -mtime +14 -exec rm -f {} \;

🔧 Объяснение:
- /var/log — каталог с логами (можно заменить на нужный путь);
- -type f — только файлы;
- -name "*.log" — ищем только .log-файлы;
- -mtime +14 — которым больше 14 дней;
- -exec rm -f {} — удаляем.

🛡️ Сухой запуск перед удалением:

find /var/log -type f -name "*.log" -mtime +14

Так ты увидишь, что будет удалено, прежде чем запускать rm.

📌 Добавь в cron, чтобы забыть о рутине навсегда.

👉@bash_srv

GitQL — это инструмент, созданный с использованием GitQL SDK для выполнения SQL-подобных запросов к вашим локальным файлам .git.

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

https://github.com/amrdeveloper/GQL

Мы в MAX

#devops #девопс

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

Docker Build Checks: максимальный линтер для Dockerfile 🐳

Совершенствуйте свои Dockerfile с помощью простых проверок сборки
Docker Build Checks используются для проверки конфигураций сборки Dockerfile на наличие проблем, параметров сборки и лучших практик. Это продвинутый линтер, который помогает выявить ошибки и предупреждения до создания Docker-образа. Фактически, это своего рода "сухой запуск" Dockerfile, который позволяет заранее проверить, есть ли проблемы или предупреждения.

https://medium.com/@mathesh-me/docker-build-checks-the-ultimate-linter-for-dockerfiles-4de37ac6081a

Мы в MAX

#devops #девопс

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