DevOps *

Привет, Хабр! Расскажу про единый деплой для всех приложений в кластер K8s и поделюсь, как нам удаётся жить без OPA rules и не допускать дичи некорректных манифестов в кластере.

Привет, на связи Олег Казаков из Spectr. Сегодня мы разберем тему параметризованных сборок в GitLab и чем они могут быть полезны.

Доброго дня, уважаемые!

Идём по плану и сегодня делаем обзор требований регуляторов к практикам разработки безопасного ПО (РБПО) для отраслей, относящихся к критической информационной инфраструктуре. Такой регуляторики немного, пройдемся быстро.

В предыдущих статьях я рассказывал как мы перешли на vector.dev с Elastic для обработки логов и как мы теперь считаем метрики по логам с его помощью.

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

TL;DR:

Нам помогли наработки по Vector.dev, договоренность с разработчиками и обнаруженная OpenTelemetry Logs Data Model. В итоге это все скомпоновалось в решение которое существенно упростило нам жизнь.

В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?

Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.

Автоматизация деплоя React-приложения на VPS с Jenkins и Nginx: настройка вебхуков GitHub и триггеров для запуска деплоя при каждом изменении в коде.

Скорость сборки Docker-образов играет важную роль в CI/CD, особенно для микросервисов, где частые обновления и тестирования требуют быстрой доставки изменений.

Одним из решений для оптимизации сборок является Docker Buildx — расширение к стандартной команде docker build. Docker Buildx предлагает дополнительные возможности, такие как кэширование слоев образов, что помогает значительно сократить время сборки за счет повторного использования неизменных слоев. В отличие от стандартного процесса сборки, Docker Buildx предоставляет более гибкое управление кэшем, поддерживает мультиархитектурные сборки и работу с несколькими платформами.

В этой статье мы сосредоточимся на том, как эффективно настроить и использовать кэширование с Docker Buildx в CI/CD пайплайнах на GitLab. Мы рассмотрим примеры, когда кэширование позволяет ускорить сборку, и ситуации, когда его лучше отключить для гарантии корректности итогового образа.

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

Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.

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

Всем привет! Меня зовут Антон Володченко, в Positive Technologies занимаюсь разработкой продуктов на стыке ИТ, ИБ и R&D. Этим небольшим постом я хотел бы чуть сблизиться с нашей аудиторией и побольше узнать, что вас волнует в контексте работы с репозиториями пакетов, образов, библиотек. Это поможет нам в расстановке приоритетов в рамках разработки нового, пока не анонсированного продукта. Интересно будет мнение активных участников DevOps-процессов, небольших команд, да и просто разработчиков-фрилансеров.

В последнее время все чаще доступ к ресурсам по различным причинам оказывается ограничен. Вспомним историю Terraform или JetBrains, а еще случай Docker, но там все быстро вернулось в строй. Прибавьте к этому проблемы безопасности сторонних библиотек (одну из множества таких проблем описывали в нашей статье). В общем, нюансов с пакетами и образами бывает много разных, но хочется понять, насколько часто возникают такие проблемы — поэтому прошу вас ответить на несколько вопросов, связанных с организацией процесса разработки. Если у вас будет время и желание пообщаться на эту тему подробнее — смело пишите мне здесь @Zero5 или в Telegram @parazero5. А в комментариях к этому посту можно добавить свои варианты ответов и обсудить эту тему.

Всем привет. Сегодня я хочу рассказать о том, как мы прошли наш путь от хаоса к нашим Paas внутри нашего внутреннего облака. Меня зовут Михаил Марченко, я руководитель центра компетенций, сопровождения и построения процессов разработки. Это наше подразделение, где мы сосредотачиваем экспертизу DevOps. В девопсе я уже семь лет, из них последние три года в билайне. 

В большой бренд билайна входят достаточно большое число юрлиц, такие как Вымпелком, Датафорт, который реализует публичное облако билайна, и другие. И мы поняли, что IT у нас абсолютно распределённая и существует во всех юрлицах, во всех подразделениях и во всех командах, которые внутри этих юридических лиц. И внутри Вымпелкома есть отдельное подразделение, которое  возглавляю я, в котором сосредоточена экспертиза DevOps, мы его называем "DevOps Governance".

Делим мы его на две части. 

Разберемся в преимуществах и недостатках каждой системы, а также настроим мониторинг гетерогенной Linux-Windows инфраструктуры средствами централизованного управления.

Всем привет! Меня зовут Дмитрий Мамонтов, я DevOps-инженер с опытом работы более пяти лет, а также наставник на курсе «DevOps для эксплуатации и разработки» и один из авторов курса «Эксплуатация и разработка в Kubernetes» в Яндекс Практикуме.

Представим, что у нас есть приложение, которое шлёт свои метрики в Yandex Monitoring, и стоит задача: масштабировать это приложение с помощью HPA в кластере Kubernetes в зависимости от метрики.

Есть два популярных варианта решения этой задачи:

Если вам важна высокая стабильность и скорость сети на ваших серверах, тогда вам надо отвественнее подойти к выбору провайдера. В данной статье я показываю, как добавить метрики и дешборды в Grafana для оценки скорости сети с помощью speedtest-exporter.

В конце августа разработчики проекта OpenTofu приняли решение ограничить доступ к своему реестру для российских IP-адресов и удалить из GitHub-репозитория провайдеров российских облачных сервисов, таких как Yandex Cloud, Cloud.ru, Rustack Cloud Platform, VK Cloud и других.

​​Команда OpenTofu объяснила свои действия необходимостью соблюдать международные санкции против России, а технический лид проекта предоставил ссылки на политику безопасности и сводку заседания Технического руководящего комитета (TSC) от 20 августа 2024 года, на котором и было принято решение.

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

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

Как отмечается в сводках заседаний Технического руководящего комитета (TSC) от 15 октября 2024 года и Технического руководящего комитета (TSC) от 23 октября 2024 года, Технический лидер проекта готов ответить на вопросы касательно политики для существующих issues и pull request'ов на GitHub, включая обсуждения в официальном Slack проекта. Тем не менее, в настоящее время команда не планирует принимать какие-либо действия по ранее предпринятым шагам, например, возвращать ранее удаленные провайдеры в реестр.

Привет Хабр! С вами снова ServerFlow, и сегодня мы хотим поговорить об удалённом доступе к графическим приложениям на Linux-серверах. Тема эта стала особенно актуальной в последнее время – всё больше задач требует работы с GPU на удалённых машинах. Будь то рендеринг в Blender на мощном сервере, работа с нейросетями или даже облачный гейминг.

Обо всё этом в новой статье ниже.

Всем привет! На нашем последнем ИТ-митапе на тему «Девопс, инфобез и ИИ» мы объединили серьезные темы с хорошим настроением, а также не забыли про вкусную еду и кучу нетворкинга.

Но это еще не все! В одном из наших докладов спрятана пасхалка! Первые три человека, которые ее найдут и напишут мне в ЛС правильный ответ, получат эксклюзивный мерч! Так что готовьте свои глазки и уши и поехали — под катом вас ждут удобные видеонарезки каждого из докладов.

DevSecOps — это не просто модное словечко, а целая философия, объединяющая разработку, безопасность и операции. Но как применить эту философию на практике? Здесь на помощь приходят международные стандарты.

В этой статье мы рассмотрим пять основных международных DevSecOps-стандартов: DSOMM, BSIMM, OWASP SAMM, Microsoft SDL и NIST SP 800-64. Мы разберем их особенности, сильные и слабые стороны, а также поговорим о том, как адаптировать эти стандарты к российским реалиям.

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

При работе с облачной инфраструктурой важна не только гибкость использования ресурсов, но и возможность автоматизировать основные рутинные процессы. При разработке своих продуктов мы в команде VK Tech стараемся следовать именно этим принципам. В нашем продукте Dev Platform в рамках одной из возможностей реализовано автоматическое управление инфраструктурными ресурсами, необходимыми для разработки программного обеспечения — например, виртуальными машинами, Kubernetes-кластерами и прочими.

Меня зовут Виктор Горячкин. Я старший разработчик Dev Platform в VK Tech. В этой статье я расскажу о разработанном нашей командой решении для автоматизации развертывания инфраструктуры.