DevOps *

Привет, Хабр! Меня зовут Дмитрий Зайцев. Я руководитель ПК конференции DevOpsConf. А ещё CTO/CIO @flocktory.com. Помогаю компании делать платформу реферального маркетинга для половины магазинов рунета, которая не падает в черную пятницу. Вместе с сообществом делал техническую редактуру перевода книги «Руководство по DevOps». Свое участие в мероприятиях начал с проведения московских DevOpsDays в 2017 году, был и членом ПК и частью команды организаторов. А с 2018 года зашел в ПК DevOpsConf и с прошлого года его возглавляю. В этой статье расскажу, чего ждать от конференции в 2023 году.

Скорее всего, вы уже слышали про service mesh — в последние два-три года этот подход становится все популярнее.

Одной из распространённых моделей service mesh считается Sidecar-прокси, которые отвечают за сетевое взаимодействие, безопасность и мониторинг. Правда у этой модели помимо плюсов есть и свои минусы: падение производительности, дополнительные издержки при развертывании и др. В этой статье поговорим о том, сможет ли решить эти проблемы плагин с eBPF, а также о том, как он меняет наш подход к работе с service mesh. 

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Если верить статистике MacOS то топовые приложения которые я использую для работы это Chrome, VS Code, iTerm и VK Teams. При этом в консоли я провожу от часа до трех ежедневно. На самом деле время в терминале больше, потому что часть того что трекается как VS Code тоже является временем работы в консоли, только встроенной в VS Code. Поэтому консоль хочется сделать удобнее и красивее. Особенно этой поздней осенью. Этими красивостями и удобностями и хочется поделиться. И не просто поделится, а что бы с красивыми картинками, некоторые из которых были бы не совсем статичны. Ну или совсем не статичны. Это как кому нравится.

Всем привет! Я - Кирилл, DevOps компании sports.ru. Не так давно мы начали процесс переезда в Yandex Cloud, хочу рассказать, как это было.

Привет, Хабр! DevOps-инженеры нужны везде, но чаще всего их пока ищут крупные компании. Мы поговорили с Павлом Селивановым — сейчас он архитектор Yandex Cloud, а в прошлом долго и много работал в качестве DevOps-инженера. Павел ответил на вопросы о том, где и как ищут DevOps-инженеров, что с них спрашивают на собеседовании и чего ждать от работы непосредственно в крупной компании.

Установка SLO (Service Level Objective, целевых уровней обслуживания) — одна из базовых задач SRE. По этим показателям удобно оценивать надежность службы. Противоположность SLO — бюджет на ошибки, то есть какой уровень ненадежности считать допустимым. Когда мы определим эти показатели и установим SLO, нужно проверить их реалистичность с учетом архитектуры приложения и рабочих практик. Мы точно сможем их достичь? На что, скорее всего, уйдёт наш бюджет на ошибки?

SRE-инженеры из Google отвечают на эти вопросы при выпуске нового сервиса, когда проводят PRR (Production Readiness Review — проверку готовности продукта). Мы анализируем риски не для того, чтобы изменить SLO. Скорее, мы хотим приоритизировать риски для сервиса, чтобы прикинуть, сможем ли мы достичь наших SLO с учетом изменений сервиса или без них. Кроме того, с помощью анализа мы определим самые важные риски. Определяя и снижая риски, мы повышаем надежность сервиса.

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

Последнее время доверие к облакам как-то резко упало, и пока кончалась годовая подписка на Google One на 2Т было время подумать, что делать дальше. В итоге родилась старая концепция - 'храним данные дома'. И вот что их этого получилось.

DevOps-практики, как известно, требуют освоения длинного ряда инструментов, и если с каким-нибудь git можно экспериментировать практически на любой машине, то Nexus или Jenkins надо ставить на сервер. Они требовательны к ресурсам, и бесплатным t2.micro на AWS не обойтись. Конечно, можно получить 3 month trial от Google Cloud, но он потребуется позже для игр с managed Kubernetes. Так что я решил сделать из своего десктопа homelab. Дальше о том, что я сделал, с какими проблемами столкнулся и как их решил.

Привет! Начинающие devops инженеры часто задают вопрос: что мне поучить, чтобы стать лучше (привет diablo)? Обычно я отвечаю: поучи команды linux. Но в целом посыл обычно ясен, чтобы что-то учить, надо хотя бы знать название утилит. Цель этой статьи и является ознакомление любопытного читателя с интересными сетевыми утилитами которые есть (или легко устанавливаются) в любом дистрибутиве linux. И так начнем! 

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

Недавно мной, совместно с коллегой, был реализован оператор для Kubernetes’a - Vector Operator. (Вот тут описано как мы пришли к решению, что там нужен свой оператор для Логирования в Kubernetes).

В рамках данной статьи я опишу разные интересные Задачи/Проблемы с которыми мы столкнулись в процессе разработки и как их решили.

Я PHP разработчик, решил поделиться с Хабром своим опытом в части того, как подготовить на своем компьютере окружение, чтобы можно было создавать сайты PHP. Будет пример для Drupal. Но Drupal или нет, даже не важно, подойдет для любого другого PHP проекта. Грамотная настройка компьютера для разработки поможет в дальнейшем не тратить время и нервы. Этим придется пользоваться каждый день, поэтому стоит уделить время и сделать все так, чтобы было удобно пользоваться.

А что вообще надо чтобы запустился PHP сайт?

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

Приветствую тебя, %username%! Меня зовут Владимир Жуков, и я не хочу впаривать тебе очередную историю успешного успеха про Kubernetes. Я хочу рассказать о наших кластерах Kubernetes с необычной архитектурой. «Что же там необычного?» спросишь ты. Это самая сложная и непонятная часть кластера, это сеть. Я знаю, что идея плоской сети не новая и применяется много у кого, но кажется об этом еще не кто тут не писал.

Безопасное хранение и передача секретов (токенов, паролей и т.п.) между пользователями и сервисами – это один из вызовов, с которыми сталкиваются разработчики и DevOps инженеры. Традиционные централизованное хранение в менеджерах паролей, например, полностью проблему не решает, а лишь смещает её в сторону управления мастер-паролями, которые, к тому же, становятся «ключами к царству» и компрометация которых может иметь катастрофические последствия. Данную проблему «курицы и яйца» ещё иногда называют проблемой «нулевого секрета» (Secret Zero Problem). В этой заметке я расскажу о попытке решить эту проблему при помощи механизма обёртки ответа (Response Wrapping).

Когда мы собрались писать статью про Kubernetes, у нас была куча идей для мемов, картинок и интересных историй из жизни. Стоило только заварить эфиопских зёрен, достать пару куросанчиков (пасхалка из курса). Всё перевернулось с ног на голову. И знаете почему?

Какими бы интересными ни были истории из жизни, статья про Kubernetes всё равно превращается в «очередную статью про Kubernetes». Вот вам история Kubernetes, вот его архитектура, а вот манифесты и пример приложения. И так каждый день: приложения, манифесты, релизы. Снова релизы, откаты релизов.

Даже работая YAML-программистом и выкатывая по 10 раз на дню в Kubernetes очередной релиз, задумываешься об однообразии процессов. Не хочется растягивать резину и петь дифирамбы kubectl, а хочется, чтобы за твоим приложением в Kubernetes следила автоматика: выкатывала новые версии, восстанавливала после сбоя и перезапускала, если закончилась память. Поэтому рано или поздно на свет должны были появиться операторы Kubernetes!

В предыдущей статье мы рассмотрели основы языка HCL, используемого Terraform для описания требуемых конфигураций. Также мы подготовили небольшое описание для создания экземпляра EC2 в AWS. Однако, в представленном описании у на присутствуют только основные параметры, необходимые для создания узла, но отсутствуют, к примеру параметры для настройки сети.

Для полноценной автоматизации нам было бы неплохо прописать все необходимые для работы сетевые интерфейсы. Для этого объявим две переменные net_primary и net_ad для двух сетевых интерфейсов. Если вам не требуется второй интерфейс, net_ad можно не указывать, однако в большинстве случаев для серверов требуется скорее большее количество сетевых портов.