DevOps *

Привет, админы! 25 апреля проводим Selectel Admin Meetup.

Обсудим применение IAC для тестирования облачной платформы. Понаблюдаем за эволюцией установщиков ОС. Устроим дискуссию о том, кем становиться в 2024 году — DevOps-инженером или системным администратором.

Темы докладов и спикеры

Применяем IAC для тестирования облачной платформы — не terraform’ом единым
Олег Зайцев, архитектор клиентских решений, Selectel.

Эволюция установщиков ОС — нельзя автоматизировать?!
Александр Никифоров, старший системный администратор, Selectel.

Баттл «DevOps и системный администратор — в чем разница и куда стоит развиваться в 2024 году?»
Михаил Морев, старший эксперт по развитию DevOps-практик, Райффайзенбанк.
Александр Никифоров, старший системный администратор, Selectel.
Антон Алексеев, DevOps-инженер, Selectel.

Смотрите подробную программу и регистрируйтесь →

Друзья, у нас вышла заключительная часть серии «Б значит не Безумие, а Безопасность».

В финальной статье наш DevOps‑инженер Алексей покажет, как защитить ваши базы данных. В роли БД рассматривается PostgreSQL версии 14 с управлением через patroni.

Вы узнаете, как повысить скорость анализа потенциальных инцидентов, как настроить процессы шифрования дисков, как сгенерировать SSL‑сертификаты для базы данных и обеспечить их двухстороннюю проверку. А ещё познакомитесь с wal‑g-backup.

Если ещё не читали, то сейчас самое время;) Нажмите сюда, чтобы начать.

Приглашаем на новый бесплатный вебинар «Стратегии успешной непрерывной интеграции».

На вебинаре поговорим о непрерывной интеграции, обсудим ее преимущества, стратегии и необходимые инструменты.

Дата: 11.04.2024
Время: 15:00-16:00 (МСК)

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

Спикер вебинара: Никонов Герман работает в ИТ с 2012 года. Начал свою карьеру как системный администратор Windows и перешел к администрированию Linux и DevOps в 2018 от Junior Engineer до DevOps Engineer.

Регистрация по ссылке.

Прекрасный и ужасный Kubernetes

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

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

? Помещают внутрь Supervisorctl несколько процессов.

? У каждого свои лог-файлы для разных мест.

? Состояние лежит рядом в виде файла.

Понятно, что такой катавасией невозможно управлять. Kubernetes к тому же и сложный инструмент, который нужно использовать правильно. И при условии, что разработка и эксплуатация работают вместе. Можно сказать, что разработчик и инженер едут в двухместных санях по бобслейной трассе.

Чтобы ехать хорошо и быстро, нужно правильно написать, собрать и доставить код.

? Если конвейер CI/CD построен правильно, мы успешно доедем до финиша.

? Чтобы было куда доставить код, нужен правильно приготовленный Kubernetes.

? Приложение должно быть написано в соответствии с 12 факторами:

? И еще 7 факторами:

• наблюдаемость (observable);

• прогнозируемость (schedulable);

• обновляемость (upgradable);

• минимальные привилегии (least privilege);

• контролируемость (auditable);

• защищенность (securable);

• измеримость (measurable).

Схема заимодействия контейнерных технологий в рамках работы с привычными инструментами может быть представлена следующим образом:

1. Утилита podman с помощью Libpod API обращается к библиотеке libpod, которая вызывает низкоуровневый container runtime (по умолчанию утилиту runc)
   containers/podman
   Podman Commands

2. Утилита docker с помощью Docker API вызывает сервис dockerd
   docker/cli
   Docker CLI reference
   Docker architecture
   Docker API

3. Сервис dockerd вызывает сервис containerd
   Dockerd reference

4. Сервис containerd вызывает низкоуровневый container runtime (по умолчанию утилиту runc)
   containerd/containerd
   Containerd Scope and principles

5. Сервис kubelet с помощью протокола CRI вызывает сервис container runtime (например, containerd или crio)
   Container Runtime Interface
   Container Runtimes
   CRI: the Container Runtime Interface

6. Сервис containerd вызывает низкоуровневый container runtime (по умолчанию runc)
   Containerd CRI

7. Сервис cri-o вызывает низкоуровневый container runtime (по умолчанию runc)
   cri-o/cri-o

8. Утилита OCI container runtime (по умолчанию runc):

• runc с помощью библиотеки libcontainer создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups)
  opencontainers/runc
  runc man
  opencontainers/runc/libcontainer

• crun создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups)
  containers/crun

Приглашаем на бесплатный вебинар «Безопасность контейнеров Docker: уязвимости образов и сканеры проверки, методы обеспечения безопасности».

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

В рамках вебинара мы:

• изучим инструменты проверки уязвимости образов;

• проанализируем примеры проведения проверок для open‑source проектов и для enterprise;

• рассмотрим разработку образов, обеспечивающих большую безопасность сред;

• обсудим развертывание контейнеров — угрозы ИБ и их минимизация при выборе сетевых параметров.

Спикер вебинара: Буравцов Евгений — тимлид команды DevOps‑инженеров, DBA, системных администраторов в компании АО «БАРС Груп». Более 15 лет работает с государственными и частными заказчиками по различным ИТ‑проектам.

Дата: 14.03.2024

Время: 18:00–19:00 по МСК.

Регистрация по ссылке.

Как внедрить телеметрию в on-premise-инфраструктуре

На предстоящий DevOpsConf 2024 выступлю с докладом по телеметрии и расскажу:
— Какие инструменты вам помогут в деле формирования, сбора, хранения и отображения данных телеметрии.
— Как выбрать тот или иной продукт и не наткнуться на несовместимость решений.
— Какой набор инструментов использовать, если вы работаете исключительно с on-premise инфраструктурой.
Материалы доклада помогут собрать решение для вашего случая.

Кому будет полезен доклад:
DevOps-инженерам и архитекторам.

Обо мне:
Ведущий DevOps-инженер Hilbert Team. Более 15 лет в IТ. Cоавтор курсов Yandex Cloud: «DevSecOps в облачном CI/CD», «Аутентификация и управление доступами», «Managed Service for ClickHouse», «Масштабирование нагрузки в K8s».

Если планируете посетить DevOpsConf, приходите 4 марта в 10:00 в Зал «Кейптаун».

Kubernetes 1.29: Mandala

Основные апдейты

На этой неделе выпускаем в релиз версию 1.29: Mandala в Managed Kubernetes и рассказываем вам про значимые фичи, перешедшие в статус стабильных.

⬜Режим доступа для особо конфиденциальных данных. Если вы создаете под с PVC, который использует режим доступа ReadWriteOncePod, Kubernetes гарантирует, что ни один другой модуль во всем кластере не сможет считать или записать в PV данные.

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

⬜NodeExpandSecret в GA. Эта функция добавляет Node Expand Secret к источникам постоянных томов SCSI и позволяет клиентам CSI отправлять его как часть запросов NodeExpandVolume драйверу CSI.

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

Как включить доступ к CUDA внутри контейнера Podman.

Как полагается, и на сей раз официальные инструкции не работают. А надо так.

1. Ставим Podman если нет. dnf install podman

2. Подключаем репу и ставим Nvidia container toolkit.

   
wget https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
sudo cp nvidia-container-toolkit.repo /etc/yum.repos.d/
sudo dnf update
sudo dnf nvidia-container-toolkit
   
   В процессе dnf ругнётся на отсутствующие сертификаты, предложит скачать.

3. Вводим в Podman параметры аккаунта на Docker Hub. podman login docker.io А дальше отвечаем на вопросы.

4. Скачиваем образ заранее. Заковыка в том, что Podman может скачать только образ, которому указана полная версия. И никаких latest. Варианты смотреть на Docker Hub. Например podman pull nvidia/cuda:12.3.1-runtime-rockylinux9

5. Создаём конфиг Container Device Interface
   sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

6. Его есть смысл проверить (от юзера!):
   nvidia-ctk cdi list

7. Ну и наконец запускаем и проверяем. Должна вылезти табличка с параметрами видеокарты, это значит что всё работает.
   podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable nvidia/cuda:12.3.1-runtime-rockylinux9 nvidia-smi

Вот теперь на основании этого образа можно клепать свои контейнеры.

P.S. Проверял на Nobara, это Федоры кусок, но должно работать так же на всей РэдХат-е.

Как регулярный бэкап позволил сэкономить 120 млн. ₽

Сегодня расскажу, как регулярный бэкап данных может спасти деньги заказчика.

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

Их девопс, суперпрофессионал в этой области, уничтожил на продакшене всё содержимое докер-контейнера и его volume. После разбора инцидента стало понятно, что это человеческий фактор. Он сделал это не со зла, такое бывает.

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

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

Сумма потенциального ущерба — 120 млн рублей.

В Kotelov мы делаем бэкап и бэкапа на этот бэкап, чтобы 100% сохранить данные клиенты. Никто не защищен от человеческого фактора — ошибаются любые профи.

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

Рассказывайте, были ли у вас тупые ошибки, которые если бы не бэкап — принесли бы чудовищные последствия.

Топ-3 авторских DevOps/сисадмин-канала

Эта подборка появилась после ручного анализа всех Telegram-каналов (более 50) в тематике DevOps/системное администрирование. Упор в первую очередь сделан на каналы, которые ведутся от первого лица и содержат действительно полезную информацию.

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

BashDays - смелый проект от действующего девопс инженера, акцент сделан на работу с командной строкой и утилитами в linux. Автор самобытно и с долей юмора рассказывает про то, что в книжках обычно не пишут. Очень клевые кейсы по отладке и дебагу различных проблем. А самое главное всё разжевано до мелочей. Мастхев.

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

Записки админа - больше как копилка знаний про linux утилиты, технологии и системное администрирование. Иногда пролетают действительно крутые штуки, о которых мало кто знает.

Если знаете еще какие-то вменяемые каналы, которые ведутся от первого лица, закидывайте в комментарии.

Уже сегодня в 19:00 МСК РСХБ-Интех проведет RSHB DevSecOps Meetup, посвященный теме информационной безопасности в процессах. В своих докладах спикеры расскажут о подходе DevSecOps и его внедрении, интеграции проверок безопасности и угрозах, которые принесли с собой CI/CD-конвейеры.

В программе:

✔️Доклад Светланы Газизовой, руководителя направления безопасной разработки в Swordfish Security, «Какие процессы приводят к результату?».

✔️Доклад Михаила Синельникова, руководителя направления DevSecOps в РСХБ-Интех, «Безопасность на первом месте: Интеграция проверок безопасности на всех этапах CI/CD».

✔️Доклад Артема Пузанкова, DevSecOps Cluster Lead из МТС Диджитал, «Чтобы труба не падала, нужно использовать простые советские OWASP Top 10 CI/CD Security Risks».

Участие бесплатное. Мест на оффлайн уже нет, но вы можете зарегистрироваться для просмотра онлайн-трансляции.

Общаться и следить за ходом митапа можно в Telegram-чате.

У нас изменения в программе! 27 октября в офисе РСХБ-Интех на Теплом Стане (Москва, ул. Профсоюзная 125а) пройдет RSHB DevSecOps Meetup, посвященный теме информационной безопасности в процессах.

Третий доклад митапа вместо Алексея Федулаева и Андрея Моисеева прочтет Артем Пузанков, DevSecOps Cluster Lead из МТС Диджитал.

В докладе «Чтобы труба не падала, нужно использовать простые советские OWASP Top 10 CI/CD Security Risks» Артем расскажет о методологии CI/CD и познакомит с ее самыми популярными недостатками и уязвимостями безопасности (по мнению OWASP). Вы узнаете, что с ними делать и как их закрыть.

• Участие бесплатное (онлайн и оффлайн). Успейте зарегистрироваться на сайте РСХБ в цифре.

• Общаться и следить за ходом митапа можно в Telegram-чате.

27 октября в офисе РСХБ-Интех на Теплом Стане (Москва, ул. Профсоюзная 125а) пройдет RSHB DevSecOps Meetup, посвященный теме информационной безопасности в процессах.

Второй доклад митапа, «Безопасность на первом месте: Интеграция проверок безопасности на всех этапах CI/CD», зачитает Михаил Синельников, руководитель направления DevSecOps в РСХБ-Интех.

Михаил расскажет о процессах DevSecOps-автоматизации с использованием open source-решений и систематизации результатов проверок, которые понадобятся для получения максимальной эффективности работы AppSec и SecOps-специалистов. Вместе со спикером вы пройдете весь путь построения платформы информационной безопасности и увидите решения проблем на каждом этапе.

• Участие бесплатное (онлайн и оффлайн). Успейте зарегистрироваться на сайте РСХБ в цифре.

• Общаться и следить за ходом митапа можно в Telegram-чате.

27 октября в офисе РСХБ-Интех на Теплом Стане (Москва, ул. Профсоюзная 125а) пройдет RSHB DevSecOps Meetup, посвященный теме информационной безопасности в процессах.

Первый доклад митапа, «Какие процессы приводят к результату?», зачитает Светлана Газизова, руководитель направления безопасной разработки в Swordfish Security.

Светлана расскажет, почему недостаточно подключить в IDE проверки кода, что делать, если инструменты не умеют проверять уязвимости бизнес-логики, в чем смысл безопасной разработки и почему это называется DevSecOps, а также чем отличается процессный подход от «безопасного» Waterfall’а и как живется командам разработки, когда внедряются практики AppSec.

• Участие бесплатное (онлайн и оффлайн). Успейте зарегистрироваться на сайте РСХБ в цифре.

• Общаться и следить за ходом митапа можно в Telegram-чате.

Приглашаем всех на RSHB DevSecOps Meetup — бесплатный митап по информационной безопасности в процессах, который пройдет 27 октября. В своих докладах спикеры расскажут о подходе DevSecOps и его внедрении, интеграции проверок безопасности и угрозах, которые принесли с собой CI/CD-конвейеры. Можно прослушать доклады онлайн или зарегистрироваться на офлайн-участие.

В программе:

• Доклад Светланы Газизовой, руководителя направления безопасной разработки в Swordfish Security, «Какие процессы приводят к результату?».

• Доклад Михаила Синельникова, руководителя направления DevSecOps в РСХБ-Интех, «Безопасность на первом месте: Интеграция проверок безопасности на всех этапах CI/CD».

• Доклад Алексея Федулаева, DevSecOps Lead из Wildberries и Андрея Моисеева, DevSecOps из Bimeister, «Безопасность CI/CD 2».

Офлайн-часть митапа пройдет в офисе РСХБ-Интех на Теплом Стане (Москва, ул. Профсоюзная 125а). Успейте зарегистрироваться на офлайн-участие на сайте РСХБ в цифре.

В рамках митапа пройдет розыгрыш призов за лучшие вопросы спикерам и розыгрыш призов среди тех, кто пройдет опрос и оставит отзыв о мероприятии.

Общаться и следить за ходом митапа можно в Telegram-чате.

Hilbert Team и Yandex Cloud проведут бесплатный вебинар по автоматизации создания окружений для R&D-команд

12 октября в 12:00 мск приглашаем CTO и DevOps-инженеров на вебинар «Автоматизация создания окружений для R&D-команд».

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

На вебинаре мы расскажем расскажем, как облегчить жизнь вашим разработчикам и внедрить подходы по автоматизации создания R&D-окружений, а также покажем, как вы можете организовать это на практике в своей организации.

Программа
1. Создание динамических окружений в Kubernetes (пример реализации; плюсы и минусы),
2. Создание статических окружений с помощью Terraform и Terragrunt (пример реализации; плюсы и минусы),
3. Создание окружений с помощью CrossPlane и ArgoCD (пример реализации; плюсы и минусы; планы Yandex Cloud на развитие CrossPlane),
4. Как выбрать подходящий сценарий в зависимости от требований бизнеса.

Спикеры
Михаил Кажемский – ведущий DevOps-инженер Hilbert Team.
Антон Брехов – партнерский архитектор Yandex Cloud.

Вебинар бесплатный, для участия нужно зарегистрироваться по ссылке: https://hilbertteam.timepad.ru/event/2563423/

Как урезать расходы на виртуальные машины на 35% и заставить разработчиков ночью спать, а не работать?

Решил пройтись по документации Yandex Cloud и случайно наткнулся на сервис Cloud Apps. Ознакомился со списком приложений и больше всего заинтересовал VM Watchdog. С помощью VM Watchdog можно выключать и включать виртуальные машины по расписанию. Время задается в формате crontab.

Насколько я понял, VM Watchdog является "надстройкой" над Cloud Functions. Ранее я не использовал возможности Cloud Functions, но слышал, что с помощью него можно запускать и останавливать виртуальные машины назначенным триггером. Но я не знал, что триггером может быть расписание.

Так, например, можно останавливать сервер с Gitlab Runner (или даже с OpenVPN!) по ночам, так как в такое время все разработчики спят и виртуальная машина простаивает.

Отличный доклад с митапа DevTalks от Олега Казакова, CTO в Spectr.

Заказная разработка и DevSecOps: существующие инструменты, процесс внедрения и сопровождения

В докладе Олег рассказал о существующих способах обеспечения безопасности и о том, как сложно/дорого их интегрировать в процесс разработки в условиях неоднородности стека/архитектуры/инфраструктуры/процессов реализуемых проектов. Рассмотрел основные классы инструментов автоматической проверки безопасности и процесс внедрения по каждому их них: Gitleaks, Trivy, OWASP ZAP и др. Особое внимание уделил стоимости первичного внедрения и дальнейшего применения.

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

Презентация из доклада