В этой статье я расскажу, как DevOps-инженеры «Фланта» интегрируются в команду клиента и по каким правилам мы работаем, чтобы сотрудничество было комфортным для всех. Мы пройдемся по каждому этапу внедрения и разберем основные принципы, проблемы и риски при интеграции сторонних DevOps-команд.

Статья будет полезна тем, кто только задумался о привлечении в свою компанию сторонней команды и хочет узнать, как строится процесс внедрения. Также она будет интересна тем, кто и сам оказывает похожие услуги или формирует внутреннюю DevOps-команду.

Мы во «Фланте» любим Open Source — причем не только пишем свои открытые инструменты (werf, shell-operator, grafana-statusmap, сommunity-версия Deckhouse), но и активно участвуем в разработке различных проектов — участвуем в KEP’ах Kubernetes, в составе небольшой группы разрабатываем Dex, вносим вклад в Istio, передаем патчи и сведения о найденных багах в Cilium.

Поэтому мы решили написать несколько материалов о том, какие возможности для контрибьюторов предлагают известные в мире Open Source- и Free Software-организации. В этом материале мы рассмотрим Linux Foundation, его дочку — CNCF и европейское отделение Free Software Foundation. Сразу отметим, что участвовать в Open Source-проектах можно, даже не будучи программистом, — есть немало задач, связанных с продвижением, контентом, переводами, менеджментом. 

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

Бэкенд приложения напишем на Go, а фронтенд — на Vue.js. Все это позволит быстро запускать проект для тестирования прямо во время разработки, что, несомненно, повысит удобство работы с приложением.

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

Чтобы попробовать Kubernetes-платформу Deckhouse в деле, придется найти мощный сервер, пространство у облачного провайдера или несколько машин и прокси-сервер. Но что делать, если хочется просто потестировать Deckhouse, а технических возможностей для этого нет? Конечно же, установить Deckhouse в kind — ведь для этой задачи сгодится даже ноутбук, а на выходе у нас будет рабочая инсталляция Kubernetes-платформы, правда, с некоторыми ограничениями. 

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.

В статье мы рассмотрим, как подступиться к миру Kubernetes в первый раз — развернуть кластер под управлением платформы Deckhouse, разработать и подготовить приложение, развернуть его с помощью утилиты werf, предназначенной для построения рабочего процесса по принципам CI/CD, а также настроить сертификаты для доступа по HTTPS.

Проблемы роста — обычное дело, и базы данных в этом смысле не исключение. Полтора года назад команда Loki задумалась о том, как на порядок повысить кардинальность (cardinality), производительность запросов (query throughput) и надежность (reliability). Работа над новым индексным слоем почти закончена — время остановиться и посмотреть: что же мы делаем, чтобы оставаться на пике прогресса.

Несколько месяцев назад у нас появилась необходимость разработать CSI-драйвер для Kubernetes, который в первую очередь использовался бы для хранения дисков виртуальных машин в Deckhouse Virtualization, но также мог бы использоваться и со стандартными контейнерами в Kubernetes. У оборудования наших заказчиков, как правило, есть определенная специфика — чаще всего это классическая SAN (Storage Area Network) с внешним хранилищем и общим shared LUN, который выделяется на несколько узлов. На одном LUN одновременно работает несколько виртуальных машин или контейнеров.

Помимо всего прочего, от драйвера нам требовалась поддержка различных CoW-фичей, таких как снапшоты, thin provisioning и возможность выполнять live-миграцию виртуальных машин в Kubernetes. Из существующих решений можно было бы отметить некоторые свободные проекты, однако ни один из них не реализует все желаемые фичи. Кроме того, у них есть явные проблемы с масштабированием.

Привет! На связи Василий Мармер, DevOps-тимлид компании «Флант». Сегодня мы поговорим об Atlas — еще одной утилите, которая делает работу DevOps-инженера более комфортной. Atlas увидел мир в ноябре 2021 года, а сейчас у него более 3,3 тысячи звёзд на GitHub. Язык программирования — Go.

Рассматриваемая утилита служит для управления схемами миграций баз данных и позволяет задействовать современные паттерны DevOps. Разработчики Atlas воспринимают свой инструмент как универсальный способ визуализировать, планировать и выстраивать миграции схем баз данных в соответствии с CI.

Виртуализация оборудования — одна из важнейших и фундаментальных технологий в области облачных вычислений. Без нее не смогло бы работать ни одно «устройство» внутри виртуальных машин: ни сетевая карта, ни диск, ни клавиатура, ни мышь и т. п. В статье мы проследим развитие технологий виртуализации оборудования в Linux.

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

Месяц назад компания «Экспресс 42» вместе с партнерами (одним из которых как раз был «Флант») выпустила подробный отчет на 75 страницах о состоянии DevOps в России. В этой статье мы бы хотели более подробно рассказать, какие инструменты и операционные системы компании используют для работы с инфраструктурой, как меняется их проникновение от года к году, как продвигается импортозамещение и что именно российские компании понимают под этим термином.

В ночь с 15 на 16 августа официально выйдет новая версия Kubernetes — 1.28. Среди главных изменений — оптимизация работы с sidecar-контейнерами и задачами (Job). Клиенты теперь будут переадресовываться на тот сервер API, который способен обработать их запрос, что упростит скользящие обновления. Проект Kubernetes продолжает размежевание с инфраструктурой Google — KEP 1731 описывает ряд шагов, направленных на оптимизацию и упрощение релизного процесса.

Мы подробно разобрали все новые фичи Kubernetes 1.28.

Работая с секретами, хочется получить две возможности: просто и централизованно управлять секретами в кластере и в то же время вынести их за пределы кластера в целях безопасности. В этой статье мы подробно рассмотрим работу External Secrets Operator в связке с Yandex Lockbox, AWS Secrets Manager, Vault by HashiCorp, а также наше собственное решение на базе Open Source-утилиты от «Фланта» shell-operator.

В этой статье мы рассмотрим самые важные обновления платформы Deckhouse версий 1.45 — 1.47 — всё то, что появилось за последние три месяца.

Версия Deckhouse 1.45 на канале обновлений Stable появилась 17 мая этого года. Из ключевых изменений можно выделить прекращение поддержки Kubernetes 1.21 и добавление поддержки Kubernetes 1.26, появление нового модуля хранилища логов и включение поддержки ALT Linux. Рассмотрим их подробнее.

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры. 

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется. 

Звучит как фантастика?

Всем, привет! Я Андрей Квапил, работаю во «Фланте» над Kubernetes-платформой Deckhouse. Это статья по мотивам моего доклада о разработке нашей системы виртуализации на основе KubeVirt. Я расскажу, какие альтернативы KubeVirt мы рассматривали, чем они нас не устроили, как устроен KubeVirt, как он работает с файловыми хранилищами, сетью и о том, как происходит запуск виртуальных машин внутри Kubernetes. А еще — какие изменения мы внесли в KubeVirt, чтобы он полностью соответствовал нашим задачам. Будет сложно, но интересно. 

Кстати, в начале 2023 года мы уже рассказывали на Хабре о Deckhouse Virtualization — нашей системе виртуализации нового поколения. 

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктам, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.

DevOps- и SRE-командам важно знать как можно больше о работе приложений, за которые они отвечают: как эти приложения работают в разных условиях, как их показатели меняются со временем, в какой точке можно ускорить работу, тем самым улучшив показатели производительности и доступности сервисов. Для всех этих задач важны показатели наблюдаемости (observability). Реализовать наблюдаемость можно при помощи технологии eBPF, которой уже более 10 лет.

Чтобы легко адаптировать статистику eBPF и получать из нее полезную информацию, нужен дополнительный инструмент. Одним из них и является Open Source-решение Coroot. Coroot — это observability-инструмент, который превращает данные телеметрии в полезную информацию, помогая быстро выявлять и устранять проблемы с приложениями. В статье проверим, какие у него есть возможности.