Начинаем вебинар по повышению производительности инфраструктуры
Привет, Хабр! В 12:00 по МСК проведем вебинар, где разберем, как эффективно использовать GPU в облаке для ML-проектов. Продакт-менеджер облачной платформы Selectel Антон Баранов расскажет, как оптимизировать производительность инфраструктуры и сократить расходы без потери качества. Присоединяйтесь!
Вебинар: как устроена совместная работа виртуальных машин и контейнеров в Deckhouse
Завтра, 23 апреля, мы проведём вебинар о виртуализации в экосистеме Deckhouse. Расскажем, почему разрабатываем своё решение, и покажем, как запускать виртуальные машины рядом с контейнерами, чтобы управлять ими в рамках одной платформы оркестрации.
Будет полезно, если вы ищете альтернативу классической виртуализации или хотите начать использовать Kubernetes для оркестрации ВМ. Регистрируйтесь и подключайтесь с 12:00 по Москве. Ссылка для подключения придёт вам на почту.
Вы узнаете:
Какие возможности по управлению ВМ уже есть в Deckhouse.
Что мы вкладываем в понятие Cloud Native-виртуализации.
Для чего может быть нужна совместная работа ВМ и контейнеров.
На демо покажем возможности Deckhouse Kubernetes Platform по администрированию и мониторингу ВМ и контейнеров, конфигурации балансировщиков и микросегментации на основе сетевых политик.
Спикеры вебинара:
Георгий Дауман, менеджер продукта Deckhouse Virtualization Platform
Кирилл Салеев, архитектор инфраструктурных решений Deckhouse
Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:
ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);
precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).
Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.
Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.
Заполните опрос State of DevOps Russia 2025: помогите отследить тренды и развитие DevOps-практик
«Экспресс 42» запустил ежегодное исследование состояния DevOps в России. Ключевой темой исследования в 2025 году будет developer experience. На основании ваших ответов хотим изучить, что помогает компаниям формировать позитивный опыт для разработчиков и как на него влияют внутренние платформы, ML/AI-инструменты, облачные технологии и практики ИБ.
В остальном, как и всегда, посмотрим, какие инструменты используют в индустрии, отследим технологические тренды и изучим факторы, влияющие на профиль эффективности компаний. Результатами поделимся осенью. Если у вас есть опыт в сфере DevOps — пройдите опрос. Это займёт около 20 минут. Чем больше респондентов, тем точнее результаты.
Для кого опрос
Мы приглашаем заполнить анкету исследования всех специалистов, связанных с DevOps: инженеров и администраторов, разработчиков и тестировщиков, техлидов и тимлидов, CIO и CTO. В 2024 году в опросе приняли участие больше 4100 респондентов, и мы надеемся, что в этом году вас будет ещё больше.
Если вы заполните анкету, то сможете поучаствовать в лотерее с розыгрышем классных призов от «Экспресс 42» и генеральных партнёров исследования. Более 80 победителей получат мерч, подписки на полезные и развлекательные сервисы, промокоды на незаменимые в работе продукты и билеты на такие профильные конференции, как Highload и DevOpsConf.
Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).
Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.
Интересно, что TLS-сертификаты становятся больше похожи на квитанции доступа. Что-то вроде тикетов в каком-нибудь глобальном Kerberos, только повёрнуто в сторону к клиенту, который с браузером. При этом всякий веб-узел должен постоянно и автоматически отмечаться на центральном сервисе, получая новую квитанцию, которая разрешает браузерам доступ. Ну или квитанцию сервис не выдаёт, тогда доступ к веб-узлу для браузеров отключается автоматом. Да, нужно будет ещё в браузерах отключить возможность "отменить предупреждения безопасности" простым способом, но это уже детали.
Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в AvitoTech.
Недавно я рассказывал о новых подходах, которые мы использовали при создании дашбордов для диагностики. С тех пор дашборды такого типа обрели еще большую популярность, и мы решили выложить пример их реализации в галерею дашбордов Grafana.
За основу я взял наш дашборд Node Status, который показывал в предыдущей статье. Напомню, он служит для того, чтобы быстро понять, все ли в порядке с нодой в Kubernetes-кластере. В своей основе она содержит множество небольших панелек, которые единообразно подсвечиваются при возникновении аномалий: оранжевый значит «обрати внимание», красный - явно что-то не так. При необходимости по клику можно получить расширенную информацию по каждой метрике.
Я очистил наш внутренний вариант от специфики. Это позволяет использовать дашборд в любых окружениях, в которых развернуты нужные экспортеры:
node-exporter (лейбл «node» должен содержать имя Kubernetes-ноды);
kube-state-metrics;
node-problem-detector (опционально).
Несмотря на то, что все панельки должны в этом случае работать «из коробки», сам дашборд все же следует воспринимать как конструктор. У каждой инфраструктуры есть специфика, и вы можете легко отразить ее, опираясь на то, как реализованы уже имеющиеся панели.
Я полагаю, что ценность Node Status для комьюнити состоит не в том, какие именно метрики на ней собраны, а в том, на каких принципах она основана. Эти принципы зарекомендовали себя у нас, и вероятно будут также полезны и вам.
Если вы у вас возникнут сложности при использовании дашборда или предложения по его улучшению, пожалуйста, оставляйте свои комментарии!
Внедряем ИИ с умом: разбор Gartner AI Opportunity Radar
Привет, Хабр!
ИИ обещает многое, но без чёткого плана легко спустить бюджет впустую. Gartner утверждает, что до 70% ИИ-проектов не окупаются из-за хаоса в подходе. Их ответ на это — "AI Opportunity Radar", инструмент, который должен помочь бизнесу и ИТ-командам понять, где ИИ даст результат, а где пока рано спешить. Разбираем, как он работает, с примерами из практики и техническими деталями.
Фактически это стратегическая диаграмма, которая делит возможности ИИ на четыре зоны по двум осям:
Внешнее (Customer-Facing) vs Внутреннее (Operations-Focused): для клиентов или внутренних процессов.
Повседневный ИИ (Everyday AI) vs Изменяющий правила игры (Game-Changing AI): постепенные улучшения или радикальные перемены.
Радар помогает выбрать приоритеты: быстрые улучшения или долгосрочные инвестиции.
Четыре зоны применения ИИ
1. Фронт-офис: улучшаем клиентский опыт
Суть: ИИ для взаимодействия с клиентами.
Пример: Чат-боты на базе LLM (например, Telegram-боты для поддержки).
Техстек: Используются NLP-фреймворки (Rasa, Hugging Face), интеграция с CRM через API, деплой на облаке (AWS, Azure). Нужны данные о клиентах.
Результат: Снижение нагрузки на саппорт, рост удовлетворённости (NPS).
2. Продукты и услуги: создаём новое
Суть: ИИ как часть продукта или бизнес-модели.
Пример: GitHub Copilot (трансформеры, обученные на миллионах репозиториев).
Техстек: Кастомные модели (PyTorch, TensorFlow), большие датасеты, GPU/TPU для тренировки, сложный пайплайн деплоя.
Результат: Уникальное предложение, выход на новые рынки.
3. Ключевые компетенции: усиливаем преимущества
Суть: ИИ для стратегического превосходства.
Пример: Антифрод в финтехе (Mastercard использует ансамбли LightGBM для анализа транзакций с latency < 50 мс).
Техстек: Исторические данные, feature engineering, потоковая обработка (Kafka, Spark).
Результат: Снижение рисков, лидерство в нише.
4. Бэк-офис: автоматизируем рутину
Суть: Оптимизация внутренних процессов.
Пример: Прогноз сбоев в CI/CD (GitLab экспериментирует с anomaly detection).
Техстек: Лёгкие модели (scikit-learn) или SaaS-решения (RPA, OCR), низкий порог входа.
Результат: Экономия ресурсов, меньше ошибок.
Как оценить возможности?
Gartner предлагает три фильтра:
Техническая осуществимость:
Чат-бот: пара недель на API + настройку.
Кастомный ИИ: годы R&D, миллионы на инфраструктуру.
Готовность компании:
Данные в DWH или хотя бы в нормальной базе?
Есть ML-инженеры или хотя бы аналитики?
Рынок:
Клиенты примут бота, но скептичны к ИИ в критических сферах (медицина, финансы).
Каждая идея получает метку: "зелёный" (старт), "жёлтый" (дозреть), "красный" (ждать).
Практические кейсы
Фронт-офис: Бот для техподдержки (Rasa + PostgreSQL, деплой на Kubernetes).
Продукты: ИИ для анализа кода (Copilot: трансформеры + миллиарды строк кода).
Компетенции: Антифрод (LightGBM, данные транзакций, Spark Streaming).
Бэк-офис: Анализ логов (ELK Stack + ML для поиска аномалий).
Как внедрять: пошаговый план
Определить цель: Руководство решает — рутина или трансформация.
Карта идей: Нанести проекты на радар, оценить по трём критериям.
Быстрые победы: Начать с бэк-офиса или фронт-офиса для первых результатов.
Управление рисками:
Данные: шифрование, соответствие нормативке.
Модели: проверка на bias, мониторинг дрифта (MLflow, Prometheus).
Итерации: Постоянно обновлять подход с учётом новых технологий.
Плюсы и минусы радара
Плюсы:
Структурирует хаос внедрения ИИ.
Подходит для любых масштабов.
Минусы:
Без данных и команды — пустая теория.
Требует адаптации под ваш домен, требования.
Вывод
"AI Opportunity Radar" — это фильтр, а не готовое решение. Он помогает отделить реальные задачи (боты, автоматизация) от фантазий (полный ИИ без данных).
Для старта — берите простое, стройте инфраструктуру, а потом уже замахивайтесь на крупное.
13 марта 16:00 CET (18:00 Мск) Андрей Квапил, более известный в инженерном сообществе как @kvaps будет травить байки о том, как правильно готовить LINSTOR и Talos Linux — на этот раз на комьюнити-мите LINBIT (создатели LINSTOR и DRBD). Основано на реальных событиях, приключившихся в Cozystack:)
Программа комьюнити-мита:
Andrei Kvapil: LINSTOR on Talos Linux: A robust base for Cozystack
IMPulse - менеджмент инцидентов. Интеграция с Telegram.
После первой публикации об IMPulse, стало понятно, что основная интеграция, которую от нас ждут, это Telegram. И мы рады её представить!
Для работы с Telegram мы использовали группы с топиками - они лучше всего ложатся на наш функционал. В процессе разработки мы столкнулись с багом при упоминании (mention) пользователей в Telegram, о чём составили соответствующий issue. Если вы тоже заинтересованы в закрытии этого бага, пожалуйста поставьте "👍".
Помимо интеграции с Telegram стоит упомянуть реализованный шедулер для работы команд реагирования по расписанию. Синтаксис конфигурации составлен таким образом, чтобы в будущем была возможность интегрироваться с внешними календарями типа Google.
Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.
Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.
Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.
Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".
DevOps-инженеры, зовём на публичное собеседование на Хабр Карьере
Это что-то вроде тестового собеседования, в конце которого эйчар дает соискателю развернутый фидбек о том, где он ответил круто, а где — слабые места, которые нужно подтянуть. Отличная возможность проверить свои силы, набраться опыта в собеседованиях и получить обратную связь.
Кого ищем сейчас: middle+, опыт с Linux, Docker, Ansible и Kubernetes. Если вы хотите принять участие и выйти с нами в прямой эфир, откликайтесь здесь.
Linux Upscale – программа обучения Linux и погружение в DevOps
Привет, Хабр!
Мы открываем программу, на которой хотим обучить крутых специалистов правильно заходить в Ред Хату (RHEL-based дистрибутивы). Приглашаем Linux-инженеров прокачаться в DevOps и получить оффер по итогам программы Linux Upscale. Обучение состоит из нескольких модулей: базовый и продвинутый курс по Linux, курс по Ansible. В конце каждого курса есть лабораторная работа, результаты которой оцениваются экспертами.
Между курсами будет недельный перерыв, чтобы еще раз пройти материал и закрепить практикой в К2 Cloud. При успешном прохождении первых трех модулей — участники смогут пройти обучение K8s, Docker и Git, работая в одной из команд К2 Cloud.
Немного формальностей: на программе предусмотрена стипендия (трудоустройство с первого дня), обучение длится 2 месяца (апрель-май) и предполагает фулл-тайм загрузку. Обучение проходит онлайн. Если ты из Москвы, мы пригласим в офис для очной работы над задачами в рамках курса.
Подробнее можно прочитать на сайте. Кстати, мы спрятали там пасхалку;)
Программа для тебя, если ты:
< Уже работал с Linux и планируешь дальше >
< Предпочитаешь командную строку вместо UI >
< Знаешь основы TCP/IP, DNS, HTTP >
< Готов обучаться, ориентируясь на практику >
< Хочешь поднять уровень профессиональной экспертизы >
Отзывы выпускников прошлых лет:
< Антон Соболинский, системный инженер >
“С Linux я сталкивался вскользь уже давно, но никогда не углублялся дальше уровня обычного пользователя. Решив, что наконец-то пора понять Linux, я принял участие в обучении Linux Upscale. Школа стала для меня настоящим прорывом. Курс позволил мне собрать все мои разрозненные знания, упорядочить их, заполнить многочисленные пробелы и, самое главное, дал чёткое понимание, как применять эти знания на практике. После завершения обучения я смог перейти в команду сильных инженеров, где меня ждали по-настоящему сложные, нестандартные и интересные задачи. Уверен, что эти знания продолжат быть полезными на протяжении всей карьеры.”
< Дмитрий Горелко, cтарший инженер >
" У меня был опыт работы с Linux около 5-ти лет, но после этого я менял сферу деятельности, занимался предпринимательством. Какие-то знания растерялись и не хватало актуального опыта. Я решил, что лучшая инвестиция — это инвестиция в своё обучение. На программе я систематизировал знания, которые уже у меня были, и в итоге вышел на работу сразу на позицию инженера. "
< Егор Старков, дежурный инженер >
" До Linux Upscale я был недавним выпускником факультета компьютерных наук, где и заинтересовался Linux на последних курсах. Изучал Linux в основном самостоятельно, но не хватало системности в знаниях. Программа школы оказалась достаточно интенсивной и наполненной, что помогло как систематизировать уже накопленные знания, так и получить новые. После окончания я сразу вышел на позицию дежурного инженера в команду эксплуатации Облака. "
Регистрируйтесь на бесплатные вебинары, чтобы узнать больше про работу с сервисами платформы Cloud․ru Evolution:
Практикум Cloud.ru Evolution: как связать несколько виртуальных машин — 13 февраля. Покажем, как организовать сетевую связность между виртуальными машинами разных VPC на платформе Cloud.ru Evolution, а также между Cloud.ru Evolution и другими платформами или on-premise инфраструктурой.
Evolution Managed Spark и обработка миллиардов записей — 18 февраля. Узнайте, как обрабатывать большие массивы данных в несколько кликов с помощью сервиса Evolution Managed Spark. На вебинаре менеджер продукта Data Platform Cloud.ru Алексей Лицов расскажет и покажет, как работать с сервисом.
С какими вызовами мы столкнулись, пока строили DBaaS — 20 февраля. Расскажем про плюсы, минусы и особенности нашего решения — Database as a Service (DBaaS) поверх Kubernetes, а также про сервисы и режимы предоставления услуги.
А еще на каждом вебинаре будет сессия вопросов и ответов, на которой вы сможете задать экспертам любые интересующие вопросы по теме.
Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault
Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.
Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.
Какая вылезла проблема
Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):
Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.
В чем итоге была проблем и как Антон с ней справился, читайте в статье →
Приглашаем на бесплатные вебинары, посвященные K8s🎓
1. «Быстрое погружение в основы Kubernetes» — для тех, кто хочет понять технологию контейнерных приложений и начать с ней работать. На встрече разберемся с теорией: что такое контейнеры, какие основные компоненты есть у Kubernetes и для чего они нужны. Знаний будет достаточно, чтобы начать развиваться в направлении DevOps.
Программа вебинара:
чем микросервисная архитектура отличается от монолитной;
контейнеры — основа микросервисной архитектуры;
зачем нужен Kubernetes;
как устроен кластер Kubernetes.
Будет полезно тем, кто задумывается о переезде в облако и планирует узнать о нем больше. А также тем, кто планирует начать погружаться в DevOps в общем или в Kubernetes в частности.
2. «Как развернуть кластер Kubernetes за несколько кликов» — в прямом эфире покажем, как развернуть простое приложение в кластере Kubernetes в облаке Cloud.ru Evolution и сэкономить ресурсы, используя K8s как PaaS-сервис.
Программа вебинара:
обзор сервиса Evolution Managed Kubernetes;
демо развертывания кластера;
подключение к кластеру с помощью kubectl;
развертывание WordPress в кластере;
разбор нюансов управления кластером, развернутым как PaaS-сервис.
Будет интересно разработчикам, DevOps-инженерам, архитекторам облачных решений и всем, кто работает с Kubernetes (K8s).
Если у вас есть вопросы по теме, их можно оставить в комментариях под этим постом или задать в процессе встречи. Спикер вебинаров Илья Смирнов — архитектор решений, ответит на них в прямом эфире.
E: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/InRelease 403 Forbidden [IP: ...]
Теперь самостоятельно лепить образ на замену nvidia/cuda:11.7.1-cudnn8-runtime-ubuntu20.04 с не заблокированными зеркалами? Или какие еще варианты кроме как собирать на забугорной тачке?
В разработке на python, особенно в DS/ML проектах, мы все сталкиваемся со сложной схемой зависимостей на специфичной аппаратной платформе. Зачастую, вести разработку удобно в том окружении, в котором в последствии запускается приложение.
Если вы вдруг vim user, то можно просто доставить редактор в контейнер с окружением и разрабатывать прямо там. Такая схема достаточно лекговесна, позволяет относительно просто держать актуальными завистимости при разработке, переиспользовать существующие сборочные конвейеры с небольшим наборов слоёв для самого редактора. Так же это может быть удобно, если вам нужно работать где то на удалённом кластере по ssh.
У меня был некоторый шаблон Dockerfile с добавкой vim с плагинами который кочует из проекта в проект и я решил поделиться с вами этой наработкой.
Нужен ли вам Ansible AWX: обзор особенностей и функционала
Когда парк виртуальных машин разрастается, а ежедневно приходится запускать сотни плейбуков, то работа с командной строкой для DevOps-инженеров становится мучением. Упростить работу с Ansible поможет AWX. Удобный графический интерфейс, интеграция с системами контроля версий, обновление проектов и динамического inventory — только часть возможностей системы.
В подробной статье на базе опыта использования системы в YADRO:
рассказываем о сложностях запуска плейбука в Ansible,
разбираем, как именно AWX упрощает работу с Ansible,
изучаем почти 20 приятных плюшек и парочку подводных камней,
запускаем плейбук с AWX и без,
настраиваем уведомления в Telegram,
делимся отзывами 6 команд о работе с AWX.
Читайте обзор Ansible AWX от Ксении Кузьменко, DevOps-инженера DPS-команды, которая предоставляет платформенные сервисы для 40+ команд и 1000+ пользователей внутри компании. Если будут вопросы — пишите в комментариях к статье, Ксения с удовольствием ответит.
Всем привет! Мы начинаем подводить итоги 2024 года 🎄.
В этом году в Cloud.ru прошло целых 40 бесплатных вебинаров про эффективную миграцию в облако, создание облачной инфраструктуры, настройку сервисов, работу с данными и снижение затрат на обслуживание. Дальше — больше!
Все вебинары в любой момент можно посмотреть в записи и познакомиться с интересующей вас темой. А одна из самых популярных тем уходящего года — Kubernetes, поэтому ей мы посвящаем предновогоднюю подборку. Смотрите от простых тем к более сложным:
