DevOps *

Привет! Меня зовут Денис Макаров, я бэкенд-тимлид в KTS.

В прошлый раз мы сравнили Tarantool с Redis, а в этой статье решили провести тесты с Hazelcast.

Так же, как в прошлой статье, мы рассматриваем вариант Tarantool как замены: берём типичные кейсы работы с Hazelcast и реализуем такие же механики на Tarantool, начиная от простых K-V операций и заканчивая вторичными ключами.

Невозможно зайти в мобильное приложение, записаться к врачу, оплатить покупку в интернет-магазине, не работают кассы, подрядчик нарушает SLA по доступности сервисов, а инженеры поддержки приступают к поиску проблем после жалоб пользователей и проверяют вручную десятки, а иногда и сотни информационных систем – типичный процесс эксплуатации в быстро развивающихся и сильно зависящих от стабильной работы IT крупных компаниях. Инженерам сложно выполнять KPI по доступности и проактивно работать со сбоями, а бизнес несет финансовые и репутационные потери. 

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

Рассказываем, как работать с синтетическим мониторингом в платформе зонтичного мониторинга Monq (кстати, функционал доступен в бесплатной версии платформы).

У курса Слерма DevOps Upgrade прошло уже 5 потоков. Выпустился 161 студент. В честь завершения нашего 5-го потока решили поговорить с нашими выпускниками и узнать, с чем они сталкивались во время учёбы. Собрали истории выпускников в одну статью.

Однажды в поисках примера на React/Django я нашел на Хабре одну интересную статью. Она показалась мне полезной, и я решил дополнить пример из статьи новыми возможностями. В этом сиквеле мы добавим в веб-проект со списком студентов поддержку авторизации и real-time уведомлений на сокетах, улучшим систему Docker-сборки, оптимизируем модель очередей на RabbitMQ и немного пригладим косметику. В результате получим удобный базовый шаблон, с которого вы сможете начинать свои проекты.

Kyverno  — это  механизм политики с открытым исходным кодом  для  Kubernetes  , который позволяет вам определять, проверять и применять политики для вашего кластера.

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

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

Совсем недавно у нас прошел IT Squad Meetup. На неформальной конференции выступили специалисты различных банков и технологических компаний. В онлайн-формате было до 400 слушателей, офлайн – 50, суммарное время докладов – почти 5 часов, съедено X круассанов.

Коллеги обсудили современные технологии разработки веб-приложений. В частности, в программе выступлений были технологии нагрузочного тестирования приложений, аутентификации в том числе и с помощью биометрии по новому протоколу WebAuthn, прогрессивные веб-приложения (Progressive Web Applications – PWA), управление Kubernetes, другие аспекты DevOps и не только.

Под катом вас ждут удобные видеонарезки каждого из докладов.

Хотите узнать, как Kubernetes оптимально распределяет ваши контейнеры по нодам и каким образом можно этот процесс настроить или даже модифицировать?

В этой статье мы погружаемся в недра Kubernetes Scheduler — ключевого компонента, отвечающего за эффективное распределение ресурсов в вашем кластере. От базовых принципов и этапов планирования до возможностей расширения с помощью плагинов - здесь вы найдете всё, чтобы стать настоящим экспертом в этой области.
Не пропустите!

Планирую идти от простого к сложному, так что прошу отнестись с пониманием. Если вы уже знакомы с базовыми концепциями k8s scheduler, не стесняйтесь пропустить первую часть и перейти сразу ко 2-й (ссылка будет опубликована позже).

Привет! Меня зовут Александр Голиков, я работаю в компании Bercut. Наша компания разрабатывает и развивает IT-решения для операторов цифровых услуг и мобильных сервисов. Коротко говоря, мы помогаем цифровизации бизнеса. В компании я занимаюсь виртуализацией, СХД, мониторингом, разработкой и интеграцией продуктов Bercut c операционными системами. Для агрегации данных и анализа мы используем Prometheus.

В этой статье рассмотрю одну из конфигураций Prometheus в отказоустойчивом режиме, познакомлю вас с Karma alert dashboard и продемонстрирую написание алертов. Напишу несколько простых включений Go Template и рассмотрю ситуацию, где такие включения противопоказаны. Продемонстрирую, как на основе меток можно сделать исключения из общих правил и обучу Prometheus самостоятельно чинить поломки.

Привет, Хабр! Меня зовут Руслан Рахимкулов, я руководитель направления технической поддержки клиентов в VK Tech и ведущий преподаватель онлайн-курса «Техническая поддержка». После того, как мы  рассказали о запуске осенних образовательных программ VK Education, к нам стали обращаться с разными вопросами о том, как будет организован курс, чему студенты смогут научиться и как полученные знания и навыки помогут им в будущей карьере. В этом посте я решил рассказать обо всём подробнее.

Курс бесплатный, но количество мест ограничено и, чтобы на него попасть, нужно пройти предварительный отбор. Заявку на поступление можно подать на сайте до 29 сентября включительно, а занятия начнутся 10 октября и продлятся 1 семестр. 

Курс подойдет новичкам в IT, дополнительным плюсом на вступительных испытаниях станет владение одним из языков программирования. Будет неплохо, если вы уже разбираетесь в технологиях – например, понимаете, чем отличается роутер от маршрутизатора, что такое серверы, базы данных и т.п. На сайте есть список рекомендованных материалов, которые помогут подготовиться к тестированию и уверенному началу обучения на курсе. 

Для начала расскажу немного с своём опыте, а потом перейду к деталям о программе курса.

Всех приветствую. Переустанавливая Убунту, подумал, почему бы не попробовать Docker Desktop в этот раз, ведь он уже должен быть в приемлимом для использования состоянии. Для чего он может пригодиться, спросите вы? Как-то я насоздавал кучу volumes и разных images примерно одного и того же, и чистить это было не в удовольствие, хоть и есть специальные команды для этого, но зачем до такого доводить, не лучше было бы иметь какой-то UI, чтобы следить за всем и по необходимости сразу удалять? Казалось бы, раз на Linux с docker нет никаких проблем, то и с Docker Desktop не должно быть, но не тут то было...

Добрый день всем. Меня зовут Минисламов Руслан. В данной статье будет описан процесс настройки ванильного однонодового кластера k8s v1.26.8 c containerd, но сделать многонодовый не составит проблем. Весь код будет в статье. Статью написал так как на данный момент других мануалов нет и надеюсь помогу многим специалистам быстрее выполнить настройку k8s, буду так же признателен за ОС над тем как улучшить процесс установки. На офф. вики нам предлагают только версии 1.21 и 1.24, в которых достаточно много дыр и как минимум в версии 1.24 почти год как вышли последние изменения.

Праздник «день программиста» отмечается в 256-й день года, а это 2⁸, т.е. два в степени восемь. Это не просто так — на степенях двойки многое завязано в компьютерах и программировании, они повсюду. Настолько повсюду, что иногда даже слишком.

Благодаря празднику я вспомнил, что давно хотел написать эту статью, и поделиться несколькими техническими байками, где числа, являющиеся степенями двойки, вставляли «палки в колёса» мне или моим коллегам.

В текущих реалиях все IT-продукты разрабатываются с использованием какого-либо ПО, способного управлять репозиториями программного кода для Git. В нашем случае, хотелось бы рассказать про один из самых популярных продуктов — Gitlab. «Gitlab — наше всё» должно быть слоганом каждой компании, которая его использует, иначе могут произойти события, которые приведут к печальным последствиям. На Habr можно найти множество различной информации, связанной с кейсами, туториалами или просто интересными историями. Но сколько бы ни было написано, найти место где было бы собрано всё и сразу — не получилось. Придется исправлять. 

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

Мы в MOEX рассматриваем платформу как внутренний продукт, и в ходе разработки ориентируемся главным образом на “боли” и потребности команд. Platform engineering, или развитие платформ в нашем понимании – это процесс создания и предоставления удобных сервисов самообслуживания командам и инженерам, с целью ускорения потока создания ценностей, снижения объема нецелевых активностей команд, а также повышения качества, надежности и безопасности создаваемых решений.

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

Традиционно, для реализации CI/CD сценариев DevOps-инженеры используют различные платформы, такие как Jenkins, TeamCity, Azure DevOps и т.д. Их конфигурирование для сборки, версионирования, создания релизов решений может быть сложным и трудоемким, особенно если решение состоит из множества проектов/единиц развёртывания.

Обычно для настройки сборки решений в .NET используется большое количество разнородных скриптов, что создает ряд проблем:

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

• Отсутствие стандартизации: в случае использования скриптов, каждый разработчик может использовать свой собственный подход к настройке процесса. Это приводит к отсутствию стандартов и единого подхода в организации, затрудняя совместную работу и повышает сложность обслуживания.

• Непредсказуемость: нет уверенности, что процесс будет проходить одинаково на всех серверах сборки, поскольку он зависит от настроек окружения и установленных там SDK. Более того, сборка или запуск тестов могут проходить на одной ОС, а развёртывание - на другой, приводя к непредсказуемым ошибкам.

• Зависимость от инструментов: для настройки CI/CD с использованием скриптов обычно требуется определенный набор инструментов, создавая зависимость от них и усложняя переносимость настроек.

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

• Отсутствие вовлеченности разработчиков: поскольку, зачастую, настройка CI/CD выполняется DevOps-инженерами, разработчики не могут вносить изменения в процесс сборки напрямую. Более того, разработчики могут не знать, как настроен весь процесс, что делает его менее прозрачным и увеличивает время реакции на изменения или проблемы.

• Зависимость от внешних поставщиков: в постоянно изменяющихся условиях рынка, коробочные решения для CI/CD могут устаревать, переставать соответствовать требованиям организации или просто уходить с рынка. Всё это может приводить к необходимости перехода на другие решения и влечёт дополнительные затраты на переобучение и перенастройку процесса.

Что можно сделать, чтобы решить эти проблемы?

Всем привет! Меня зовут Сергей Смирнов, я DevOps экосистемы «Своё» в РСХБ-Интех (технологическая дочка Россельхозбанка).

Сегодня я расскажу вам об одном из способов доставки секретов в kubernetes из Hashicorp Vault. Это поможет решить сразу несколько задач:

• Создать единственное хранилище секретов;

• Защитить от утечки секретов;

• Сделать работу с секретами для пользователей удобной.

Развитие и обновление приложений - это важная часть жизненного цикла разработки программного обеспечения. В мире микросервисов и контейнеризации, Kubernetes стал платформой выбора для развертывания и управления приложениями. Однако одним из основных вызовов при обновлении приложений в Kubernetes является минимизация времени простоя (downtime) и рисков.

Blue-Green Deployment (сине-зеленое развертывание) - это стратегия, которая позволяет разработчикам и операторам эффективно справляться с этими вызовами. Она предоставляет возможность переключаться между двумя параллельными окружениями для приложения - активным (синим) и новым (зеленым), обеспечивая бесперебойное обновление приложения без ущерба для доступности.