Как стать автором
Обновить
290.94

DevOps *

Методология разработки программного обеспечения

Сначала показывать
Порог рейтинга

MongoDB + WARP + Xray = 💥 BSONError

У меня MongoDB начала выдавать ошибки:

BSONError: Invalid UTF-8 string in BSON document  

BSONError: bad embedded document length in bson

Документы в базе нормальные. Ошибки появлялись только при включённом Xray с WARP (через встроенный WireGuard). Когда VPN отключён — всё читается корректно.

Поначалу думал, что что-то с кодировкой или драйвером, но оказалось, что проблема в том, что Mongo работала через Cloudflare WARP.

Когда запросов было мало — срабатывало нормально.

Когда запускался алгоритм и начинались частые обращения к базе — Mongo валился с ошибками BSON.

Причина — искажение бинарного трафика при передаче через WARP.

Mongo использует бинарный протокол BSON, и даже один сбитый байт ломает парсинг.

Пофиксил так:

добавил в routing.rules Xray правило, чтобы трафик к Mongo шёл мимо WARP:

{

  "type": "field",

  "ip": ["<IP MongoDB>"],

  "outboundTag": "direct"

}
Теги:
+11
Комментарии1

NotCVE-2025-0001

Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков  делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001.
Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.

Теги:
+6
Комментарии0

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Теги:
+4
Комментарии1

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.

Теги:
0
Комментарии0

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

Шаг 1. Составьте карту сервисов и зависимостей

  • Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

  • Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

  • БД: connections > 90%, replica lag > 10 сек.

  • Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

  • Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

  • Рост ошибок 4xx > 5% за сутки.

  • Увеличение времени ответа API на > 20% за неделю.

  • Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

  • Liveness-пробы → авто-перезапуск пода при сбое.

  • Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

  • Отключайте случайные ноды в кластере.

  • Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Теги:
+1
Комментарии0

IMPulse - менеджмент инцидентов. Интеграция с Google Calendar, вложенные цепочки эскалации.

Предыдущие публикации:
https://habr.com/ru/articles/865208/
https://habr.com/ru/posts/889768/

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

Помимо интеграции с Google Calendar, мы реализовали вложенные цепочки эскалации. Теперь в chain можно добавить другой chain (nested), благодаря чему размер конфигурационного файла уменьшится.

Мы хотим создать достаточно гибкую, но не перегруженную систему цепочек эскалации, чтобы на проектах разной величины вы могли использовать IMPulse так как вам удобно. Для этого в комментариях расскажите, какой самый сложный кейс уведомлений / эскалации вам необходимо было реализовать. Например: во вторник нужно дёргать Антона, через 5 минут Олега, а по средам - только дёргать Геннадия, в остальное время, если severity == 'critical', звонить Грише.
Будем рады почитать самые сложные варианты и предложить наше универсальное решение для них.

Остаёмся на связи в нашем Telegram канале - там можно общаться / задавать вопросы.

Теги:
+2
Комментарии0

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

Подайте заявку на лендинге до 8 июня. Далее с вами свяжется рекрутер, чтобы обсудить общие вопросы и назначить интервью. После вы пройдете техническое интервью и интервью с менеджером, а в случае успеха получите оффер в компанию. Весь процесс займет 3 дня.

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Теги:
+8
Комментарии0

Настройка бекапа вашей Linux системы с помощью rsync: просто и со вкусом

Шаг 1: Подготовка сервера для бэкапов

Лайфхак: В Hostkey VPS с 4ТБ обойдется примерно в 2600₽/месяц

Настройка SSH-ключа для безопасного доступа:

# Создаем SSH-ключ
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_backup

# Копируем на сервер
ssh-copy-id -i ~/.ssh/id_rsa_backup.pub user@backup-server

# Создаем директории на сервере
mkdir -p /root/backup-{1,2,3}

Шаг 2: Настройка автоматических бэкапов

Добавляем три задания в crontab для ротации бэкапов по дням недели:

crontab -e

Вставляем три задания (замените SSH_USER, SSH_HOST и SSH_KEY_PATH):

# Бэкап в директорию backup-1 (воскресенье, среда, суббота)
0 */2 * * 0,3,6 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-1 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-2 (понедельник, четверг)
0 */2 * * 1,4 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-2 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-3 (вторник, пятница)
0 */2 * * 2,5 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-3 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

Что делает наш скрипт?

  • Умное расписание: Каждый день недели система копирует данные в одну из трех директорий

  • Защита от блокировок: Предотвращает запуск нескольких копий скрипта одновременно

  • Безопасность: Использует SSH-ключи вместо паролей

  • Исключения: Пропускает системные директории, которые не нужно бэкапить

  • Мониторинг: Отправляет уведомление в шторку уведомлений, если что-то пошло не так

ОБЯЗАТЕЛЬНО сохраните SSH-ключ в надежном месте! Без него восстановление данных будет невозможно.

Рекомендации:

  • Копия на USB-флешке (хранить отдельно от компьютера)

  • Распечатка на бумаге в сейфе (для параноиков)Зашифрованная копия в менеджере паролей

Проверка работоспособности

Регулярно проверяйте состояние ваших бэкапов:

ssh -i SSH_KEY_PATH SSH_USER@SSH_HOST "ls -la /root/backup-1"

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

Теги:
+1
Комментарии0

3 ключевые метрики, которые спасут микросервисный проект

Современные системы — это сложные экосистемы, где каждая ошибка может стоить бизнесу денег и репутации. Рассказываем, какие метрики нельзя игнорировать, чтобы не пропустить критичные сбои.

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

  • Количество рестартов.

  • Фейлы readiness/liveness проб.

  • Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

Инфраструктура может быть идеальной, но если падает конверсия — бизнес теряет клиентов. Отслеживайте:

  • Конверсию платежей (например, от корзины к оплате).

  • Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

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

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

  • Время отклика API (p95, p99).

  • Частоту ошибок 5xx/4xx.

  • Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Теги:
0
Комментарии0

Миграция сервера GitLab: инструкция от практика

Нужно перенести GitLab на новый сервер, но боитесь потерять данные? Я покажу проверенный способ миграции, сохраняющий все проекты, настройки и историю.

Подготовка

Убедитесь, что:

  • у вас есть root-доступ к обоим серверам;

  • на старом сервере ≥50% свободного места;

  • Вы знаете точную версию GitLab (критически важно!)

Шаг 1: Подготовка нового сервера

Установите идентичную версию GitLab на новую машину:

sudo apt-get update && sudo apt-get install -y curl openssh-server ca-certificates perl 
# Установка конкретной версии (пример для 17.5.5) 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash sudo apt-get install gitlab-ee=17.5.5-ee.0

Шаг 2: Создание бэкапа на старом сервере

# Проверка свободного места 
df -h  
# Создаем резервную копию
sudo gitlab-backup create

Процесс создания бэкапа может занять от минут до часов.

Шаг 3: Копирование файлов на новый сервер

Важно! Используем nohup для обеспечения непрерывности процесса и SSH-ключ для безопасного соединения:

# Копирование файла секретов 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /etc/gitlab/gitlab-secrets.json root@new-server:/etc/gitlab/gitlab-secrets.json'
# Копирование бэкапа 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /var/opt/gitlab/backups/1742165326_2025_03_16_17.5.5_gitlab_backup.tar root@new-server:/var/backups/gitlab/1742165326_2025_03_16_17.5.5_gitlab_backup.tar'

Примечание: В примере k — это файл приватного ключа. Файл конфигурации (gitlab.rb) намеренно не копируем, но при необходимости полной копии скопируйте и его.

Шаг 4: Восстановление на новом сервере

Сначала остановите необходимые сервисы:

sudo gitlab-ctl stop puma 
sudo gitlab-ctl stop sidekiq

Затем запустите восстановление (с nohup для надежности):

nohup /bin/bash -c "gitlab-backup restore BACKUP=1742165326_2025_03_16_17.5.5 force=yes"

Важно: Идентификатор бэкапа — это часть имени файла до gitlabbackup.tar. Параметр force=yes избавляет от подтверждений.

Шаг 5: Перезапуск и проверка

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure  
# Проверки целостности данных 
sudo gitlab-rake gitlab:check SANITIZE=true 
sudo gitlab-rake gitlab:doctor:secrets 
sudo gitlab-rake gitlab:artifacts:check 
sudo gitlab-rake gitlab:lfs:check 
sudo gitlab-rake gitlab:uploads:check

Финальная проверка

Убедитесь, что:

  • вход работает;

  • репозитории открываются;

  • CI/CD пайплайны запускаются;

  • все проекты на месте.

Типичные проблемы и их решение

Ошибка 502 при доступе к некоторым репозиториям:

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure

Рекомендации от практика

  1. Тестовая миграция: Сначала попробуйте на тестовом сервере.

  2. Окно обслуживания: Предупредите команду заранее.

  3. Резервный план: Не выключайте старый сервер до полной проверки нового.

  4. Мониторинг: Следите за логами первые дни после миграции.

  5. DNS: Обновите DNS-записи после успешной миграции.

Заключение

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

Подробнее: docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html

Бонус: инструмент для построения последовательности обновления гитлаба

Теги:
+3
Комментарии0

5 книг, чтобы прокачать скиллы в SRE 📚

Со всеми, кто развивает инженерные практики, подборкой делится Антон Быстров — SRE-инженер Cloud․ru.

📖 SRE Table of Contents OT Google. Это своего рода «путеводитель» по принципам Site Reliability Engineering (SRE). Он объясняет, почему определенные методы и процессы должны использоваться в разработке и эксплуатации систем. Книги служат отличной базой для понимания философии и практических аспектов SRE, включая мониторинг, автоматизацию, управление инцидентами и многое другое.

📖 Проект «Феникс». Книга, которая рассказывает историю трансформации крупной компании через призму внедрения методов DevOps. Автор романа Брайан Дэрроу показывает, как команда разработчиков и операционных сотрудников объединяется для достижения общей цели — создания и запуска нового продукта. Хотя «Проект „Феникс“» — это прежде всего художественное произведение, оно содержит множество реальных примеров и идей, которые будут полезны как разработчикам, так и менеджерам, стремящимся внедрить современные подходы к управлению проектами и процессами.

📖 Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих — Бхаргава А. Алгоритмы играют ключевую роль в работе любой системы, и эта книга поможет вам глубже понять их принципы. Она проиллюстрирована и написана понятным языком, что делает её идеальной даже для начинающих.

📖 Запускаем Prometheus. Мониторинг инфраструктуры и приложений: Пивотто, Бразил. Одна из базовых книг по мониторингу. Она подробно описывает, как использовать Prometheus для сбора и анализа метрик, что является неотъемлемой частью работы SRE. Понимание экосистемы Prometheus значительно упростит вашу повседневную работу.

📖 Киф Моррис — Программирование инфраструктуры. Это руководство по подходу к инфраструктуре как к самостоятельному продукту. Оно охватывает как теорию, так и практику, помогая понять, как эффективно управлять инфраструктурой и обеспечивать ее надежность и масштабируемость.

Уже читали книги из списка? А какие готовы порекомендовать от себя? Делитесь в комментариях 👇

Теги:
0
Комментарии0

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

  1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

  2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

  3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

Теги:
Рейтинг0
Комментарии0

Ближайшие события

Дайджест открытых мероприятий на май:

1️⃣ AI-агенты в облаке
🗓 13 мая, 18:00 по Мск, онлайн
Узнаем, как строятся AI-агенты, какие инфраструктуры стоят за их работой и какие возможности открывает стажировка в Cloud.ru.
🔗 Регистрация

2️⃣Вебинар от Московского инновационного кластера: «Защита и регистрация интеллектуальной собственности в России»
🗓 14 мая, 12:00 по Мск, онлайн
Практические советы о том, как защитить свои разработки и оформить права на них.
🔗 Регистрация

3️⃣MTS Startup Hub: как найти и реализовать идею для технологического проекта
🗓15 мая, 19:00 по Мск, онлайн
Как придумать идею для стартапа, пройти путь предпринимателя и найти ресурсы на развитие.
🔗 Регистрация

4️⃣ Т-Банк: образовательный кредит — как получить высшее образование с господдержкой
🗓 20 мая, 19:00 по Мск, онлайн
Разберем условия образовательного кредита, преимущества, оформление и действия в случае отказа.
🔗 Регистрация

5️⃣MTS Startup Hub: анализ единорогов как топливо для развития стартапов
🗓 22 мая, 19:00 по Мск, онлайн
Как изучение успешных стартапов помогает понять рынок, находить инновации и строить перспективные бизнес-модели.
🔗 Регистрация

6️⃣ Карьерный буст: как ускорить профессиональный рост
🗓 29 мая, 19:00 по Мск, онлайн
Поговорим о карьерных стратегиях, востребованных навыках и росте в новых реалиях.
🔗 Регистрация

7️⃣MTS Startup Hub: создание прототипов и MVP
🗓 29 мая, 19:00 по Мск, онлайн
Как быстро и эффективно протестировать идеи на практике.
🔗 Регистрация

8️⃣Экскурсия в Сбер
🗓 30 мая, 16:30 по Мск, онлайн
Смотрим, как работает один из самых технологичных банков страны изнутри.
🔗 Регистрация

Участие во всех мероприятиях - бесплатное. Регистрируйтесь по ссылкам выше, а также:

➡️ Скачайте брошюру о магистратуре «Науки о данных»
➡️ Проходите курс «Введение в машинное обучение»
➡️ Получите доступ к записи Дня открытых дверей онлайн-магистратуры «Науки о данных»

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

Теги:
Рейтинг0
Комментарии0

Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud

Привязка репозиториев GitHub, GitLab, BitBucket вызывала у наших пользователей затруднения, и мы обещали упростить процесс.

Теперь для привязки репозитория достаточно указать токен и выбрать ветку и репозиторий.

Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.

Заполняем три поля и CI/CD готов
Заполняем три поля и CI/CD готов

Подробная инструкция по подключению доступна по ссылке.

Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии0

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

Надеюсь, CVE заведут. Мне и моим коллегам по цеху по безопасности гораздо удобнее оценивать безопасность архитектуры, имея единый источник проблем безопасности (база CVE). А не рыскать по всему интернету, пытаясь собрать воедино информацию о проблемах безопасности конктерных продуктов, придумывая какие-то запросы, вовзращающие релевантную информацию. Даже если описание в самом CVE сухое - всегда проще искать подробности по уникальному идентификатору CVE, чем выдумывать разные запросы для каждого конктерного продукта.

К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно).

Теги:
Всего голосов 6: ↑6 и ↓0+10
Комментарии0

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

  • Продуктовая разработка: DevOps или Golang.

  • Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

  • Команда внедрения: QA.

  • Технические продажи: технический менеджер клиентов.

Что тебя ждет:

  • оплачиваемая стажировка,

  • работа в реальных проектах,

  • поддержка наставников и экспертов,

  • регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Приглашаем на второй Cloud․ru Tech Lab: DevOps — митап для DevOps- и SRE-инженеров 🎙️

📅 Дата: 22 мая в 18:00
📍 Место: Москва, Goelro Loft, Большая Почтовая улица, 40с4

Мы продолжаем серию технических митапов Cloud․ru Tech Lab — в этот раз обсудим сложности DevOps-процессов и разберем DevOps-практики на реальных кейсах.

Темы докладов:

  • ClusterAPI как цель, Terraform как мост: управляем жизненным циклом платформы — Олег Одинцов, Старший инженер платформы App.Farm, РСХБ-Интех.

  • Автомасштабирование K8s в ноль: от базы до хардкора — Илья Смирнов, Архитектор решений, Cloud․ru.

  • Calico CNI: жизнь после запуска — Александр Качмашев, Инженер, Точка.

  • Как организовать сетевую связность Bare C kubernetes — Антон Паус, DevOps-инженер, Cloud․ru.

Также в программе afterparty c нетворкингом, легкими напитками и закусками.

Мы предусмотрели два формата участия:

  • офлайн — для тех, кто планирует лично посетить площадку,

  • онлайн — для тех, кто хочет посмотреть доклады в записи.

Зарегистрироваться на митап 👈

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

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

Основные фичи:

  • помимо шаблонизации файлов умеет шаблонизировать входной поток (stdin), используя переменные среды и результат выводить в выходной поток (stdout). Также как это делает envsubst

  • поддерживает синтаксис Jinja2 и его основные фичи, такие как условия, циклы, переменные, инклюды, различные вспомогательные функции (например, из шаблона можно звать shell-скрипты)

  • написана на C++ и собрана в статический бинарник x86 размером 350КБ без каких-либо дополнительных зависимостей, что позволяет её включать прямо в репозиторий и использовать в пайплайнах

Ранее я использовал в своих пайплайнах для шаблонизации mustache реализованные на bash и это было довольно удобно, но сам синтаксис и возможности mustache довольно ограниченные, а тащить что-то серьезное типа Jinja2 на питоне мне очень не хотелось, так как это тянуло за собой жирный рантайм, поэтому я и написал эту утилиту.

Надеюсь другим девопсам это зайдет так же как и мне. А также хотелось бы получить фидбек, может какие-то фичи ещё можно допилить?

Несколько примеров использования:

Простая подстановка переменной среды:

echo "Hello, {{ USER }}!" | muenvsubst

Шаблонизируем файл:

muenvsubst -i ./config.yml.j2 -o ./config.yml -d ./includes/

Использование переменных в шаблоне:

muenvsubst <<EOF
{%- set username = upper(USER) -%}
Hello, {{ username }}!
EOF

Использование флагов и условий:

USE_GREETER=yes muenvsubst << EOF
## if default(USE_GREETER, null) | toBool
Hello, {{ USER }}!
## else
Bye, {{ USER }}!
## endif
EOF

Использование циклов и разделение строки в список по символу:

USERS="John,Mark,Peter" muenvsubst << EOF
{%- for user in split(USERS,",") -%}
Hello, {{ user }}!
{%- endfor -%}
EOF

Использование инклюдов:

muenvsubst << EOF
## set USER="John"
## include "greeter.j2"
EOF

Файл инклюда greeter.j2:

Hello, {{ USER }}!
Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии3

Начинаем вебинар по повышению производительности инфраструктуры

Привет, Хабр! В 12:00 по МСК проведем вебинар, где разберем, как эффективно использовать GPU в облаке для ML-проектов. Продакт-менеджер облачной платформы Selectel Антон Баранов расскажет, как оптимизировать производительность инфраструктуры и сократить расходы без потери качества. Присоединяйтесь!

Смотреть трансляцию:

на YouTube

в VK

Программа вебинара

  • Шесть способов сократить расходы на IT-инфраструктуру с GPU

  • Подбираем GPU под конкретную задачу. Разбор кейсов клиентов

  • Облако с GPU: обзор возможностей облачной платформы и доступных GPU-карт

  • Как выбрать подходящие карты в облаке и в MKS

  • Сокращаем сетевые задержки с помощью локальных SSD NVMe-дисков в облаке с GPU

  • Ответы на ваши вопросы

Кому будет полезно 

  • Техлидам и менеджерам ML-проектов: как выбрать оптимальную инфраструктуру.

  • Data-инженерам, MLOps-инженерам, DevOps-инженерам

  • Всем, кто работает с облачными ресурсами и хочет повысить ROI проектов.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Работа

DevOps инженер
32 вакансии