DevOps *

Наша статья по DevSecOps победила в премии «Технотекст» в категории «Информационная безопасность», грейд Senior. Очень рад!

Расскажу в двух словах, о чём статья:
- В статье мы мы рассказали, что такое концепция Shift Left, и как она помогает сократить стоимость исправления ошибок и сроки разработки: чем раньше в процессе разработки начинаются проверки безопасности, тем лучше.
- Затем разобрали структуру DevSecOps-пайплайна и посмотрели, какие проверки безопасности проводят на каждом этапе пайплайна: от pre-commit до post-deploy.
- В конце рассказали о Security Dashboards — инструментах визуализации данных, которые помогают эффективно анализировать уязвимости и управлять процессом их устранения.

Читать статью

Все результаты премии «Технотекст»

Друзья, у Миши, нашего DevOps-инженера, вышла вторая часть серии про создание почтового сервера с чистого поля.

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

В новой статье он показывает, как его настроить с помощью PostfixAdmin, Dovecot и RainLoop. А ещё в тексте вы найдёте немного экзотики, а именно best practices по Dovecot.

? Если вы ещё не читали, то вот ссылка. А здесь опубликована первая часть серии.

21 мая проводим воркшоп «Приватные инсталляции Kubernetes»

Хотите узнать, как развернуть приватную инсталляцию Kubernetes в публичном облаке с помощью Terraform?

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

Задавайте вопросы через форму регистрации или в чате трансляции — ответим на них в конце вебинара. Авторам самых интересных подарим плюшевых Тирексов ?

Все зарегистрированные участники получат запись трансляции и примеры готовых манифестов Terraform.

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

Всем DevOps! Станислав Тибекин, CEO компании Nixys, публикует перевод огромного и полезного чек-листа по разработке облачного приложения. Первая часть посвящена бизнес-требованиям.

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

А ещё вы найдёте полезную информацию про:

• Базы данных;

• Хранилища данных;

• Инструменты;

• Мониторинг;

• Экологию.

Чтобы начать читать — кликайте сюда.

В 19:00 начинаем Selectel Admin Meetup.

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

Смотрите трансляцию прямо в этом посте или переходите на YouTube.

Всем привет! Мы продолжаем обзор Redis — системы хранения данных в виде структур. 

Новая статья Петра, нашего DevOps-инженера, — это детальное руководство по базовой репликации Redis. Благодаря ему вы сможете настроить эту СУБД на высокий уровень отказоустойчивости. 

Если суперкратко:

• Репликация в Redis ассинхронна. 

• Репликация не блокируется на стороне мастера. 

• Репликация (почти) не блокируется на стороне слейвов. 

• У мастера может быть любое количество реплик.

• Каждый слейв может выступать мастером для другого инстанса.

А ещё в конце вас ждёт приятный бонус в виде разбора атаки на Redis через H2Miner, из-за которой можно полностью потерять данные на инстансе Redis

Нажмите сюда, что начать читать.

Привет, админы! 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-чате.