DevOps *

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

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

Мы пообщались с Павлом Селивановым, архитектором Yandex Cloud, и написали эту короткую статью. Расскажем, какие возможности есть у K8s, как увидеть в нём что-то большее, чем простую «запускалку контейнеров» и как это пригождается на практике. Статья будет полезна тем, кто глубоко не разбирается в Kubernetes, но хочет узнать больше о его возможностях.

В данной статье я расскажу про жизненный цикл одной важной задачи - “Настроить сбор/парсер логов в Kubernetes”. Или “Почему мы решили написать свой оператор для сбора логов в Kubernetes”.

Меня зовут Александр и на момент подготовки этого материала я возглавлял RnD в Сбертехе. Я расскажу о частном облаке: какие существуют опенсорсные и не опенсорсные платформы биллинга для частных облаков, как выглядит референсная архитектура биллинга, что можно взять из опенсорса, чтобы построить свой биллинг и как все компоненты собрать в продукт.

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

С Вами снова Владимир и меня все еще зовут девопс.

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

Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.

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

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

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

Надёжное ПО повышает доверие пользователей к организации, эффективность процессов разработки и качество продуктов. Сбои вредят клиентам и бизнесу, но при разработке новых функций многие организации думают только об устранении последствий инцидентов и решают проблемы тактически, а не стратегически. Часто они не понимают, что можно работать быстро и при этом создавать надёжный продукт.

В Google много думают о надёжности продуктов, и некоторые аспекты этой философии хорошо изучены. Например, принципы проектирования продукта или системы. При этом мало кто задумывается о том, как влияют на надёжность продукта культура и менталитет в организации. Мы верим в то, что надёжность продукта зависит от архитектуры, процессов, культуры и менталитета в организации, а не только от усилий разработчиков при проектировании. Другими словами, надежность должна быть вплетена в ткань организации.

Не существует набора строгих правил, следуя которым можно гарантировать надёжность продукта. В этой статье SRE-инженеры из Google расскажут о том, как оценить культуру надёжности в вашей организации и какой она должна быть.

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

Canary-релизы достаточно просто реализуются на уровне Ingress-контроллеров. В статье рассмотрен практический пример настройки таких релизов в Kubernetes на базе Ingress NGINX Controller.

И снова здравствуйте! Я – Евгений Симигин, занимаюсь внедрением DevOps-практик в Центре компетенций по разработке облачных и интернет-решений МТС Digital. Как я и обещал – это вторая часть нашего обзора Argo Rollouts, из которой вы узнаете о том, как в процессе выкатки нового релиза организовать еще и тестирование.

Всем привет!

Будем использовать GitHub Actions. Создадим виртуальную машину в Яндексе. И многое другое.

Сегодня настраиваем деплой из GitHub в Яндекс Облако, используя Docker compose.

Управление распределенной архитектурой требует значительных трудозатрат и финансовых вложений. Для автоматизации этого процесса можно использовать различные самописные скрипты, но лучше воспользоваться готовыми решениями с открытым исходным кодом. Одним из наиболее известных решений для автоматизации управления инфраструктурой является Terraform. Это Open source решение для управления IaC от компании Hashicorp, разработанное в 2014 году. Решение придерживается декларативного стиля управления инфраструктурой, то есть, вы описываете в конфигурационном файле  финальное состояние инфраструктуры, а Terraform приводит её к этому состоянию. В качестве примера можно привести автоматическое развертывание пула виртуальных машин, например для проведения обучения работе с каким-либо ПО.

Ручное создание пары десятков виртуалок может занять целый день, а с помощью Terraform это займет менее часа.

Для того, чтобы описание работы с Terraform не было “сферическим конем в вакууме”, мы в качестве наглядного примера, рассмотрим практический пример создания экземпляра EC2 в AWS.

Много команд, много продуктов, каждый автоматизирует релизный цикл, у каждого свой набор скриптов. Дублирование, отсутствие обмена практиками и повторное изобретение колеса приводит к тому, что команды тратят много времени на построение своего CI/CD. И все это поддерживает микросервисную архитектуру, где автоматизации нужно уделить особое внимание.

Меня зовут Владимир Цыбров, я релиз-инженер Леруа Мерлен и сегодня расскажу, какие в компании были подходы к построению пайплайнов и улучшению качества их кода. Спойлер: мы использовали подход InnerSource и предоставили командам self-service-инструменты.

Меня зовут Алексей Шарапов. Я занимаюсь построением процессов и командами в AkBars Digital. В нашем формате работы девопсы погружены в продуктовые команды, то есть у нас не сервисная модель. Еще я разрабатываю наше внутреннее облако, автоматизирую и запускаю проекты на Kubernetes. В статье рассмотрим оба аспекта моей работы: немного поговорим про командное взаимодействие и немного про инструментарий.

Одни из самых частых вопросов от инженеров, которые я слышу: «Есть проект 10 микросервисов, пора ли запускать его в K8s или нет?» или «У нас есть проект, мы хотим поехать в K8s — надо ли нам это делать или нет?». Мы много занимались его решением, в том числе, с компаниями в формате аудита. Из этого опыта и родилась статья.

Логов много не бывает, а если бывает?! Расскажем, как мы внедряли новую систему логирования на основе EFK (Elasticsearch-Fluetnd-Kibana), как страдали, когда FluentD перестал держать нагрузку, как мы переходили на Fluentbit (спойлер: неудачно) и почему смогли найти свой Vector. А в конце дадим пару советов о культуре логирования: как к ней относиться, чтобы не страдали вы, ваши коллеги, тестировщики и разработчики. 

Этот пост — расшифровка доклада, который мы представили на конференции HighLoad++ Foundation 2022 в Москве. Видео можно найти по ссылке, а здесь — почитать доклад и посмотреть слайды из презентации. 

Привет, меня зовут Никита, я backend-разработчик в компании ИНТЕРВОЛГА. Работаю в компании уже 3 года, и за этот срок достаточно часто мне приходилось возиться с установкой и конфигурированием собственного почтового сервера для разных задач (см. далее) клиентов. 

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

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

Путь начинается с того, как с нуля, по вводным условиям определить объем работ, и заканчивается финальной реализацией почтового сервера и его тестированием.  

Я не видел в Сети и на Хабре цельной инструкции такого рода — и решил написать свою.

Статья не претендует на то, чтобы рассказать про всё сразу и максимально подробно (сомневаюсь, что это реализуемо). Наоборот, я стремился описать сложные и комплексные вещи простым языком. Слишком обширные темы, уже давно разобранные сообществом, я опускал. Главной целью было дать новичку, который закопается в дебрях “почтовых интриг”, указатель, в какую сторону копать при возникновении типовых вопросов и проблем. Надеюсь, что эта статья окажется полезной и найдет своего читателя. Приступим!

Всем привет! Меня зовут Евгений Симигин, я занимаюсь внедрением DevOps-практик в Центре компетенций по разработке облачных и интернет-решений МТС Digital. В этой статье – обзор Argo Rollouts, я покажу несколько примеров применения и отмечу интересные места в документации. Хотите быстро освоить Argo Rollouts и разобраться в этом решении? Тогда жмите кнопку «Читать далее»!

Помните, как вы пытались записать демонстрацию CLI-инструмента? К старту нашего курса по DevOps делимся материалом о том, как записывать гифки с консоли кодом, чтобы тестировать сборки ПО и показывать ваши консольные инструменты.

Итак в вашем репозитории накопилось количество сборок превысившее число 1. Настало время задуматься о DevOps(е). Как же уследить за всеми этими сборками?

Классическое решение это запустить сервер сборки. Есть готовая технология, называется Jenkins.

Идея проста. Сервер сборки это инфраструктурный прикладной процесс, который периодически запускает скрипты построения конкретных программных проектов и затем сохраняет *.bin(ари) в конкретную папку или архив. Обычно сервер сборки работает автономно 24/7 и собирает артефакты из репозитория с кодом.

В этом тексте я написал инструкцию-методичку для разворачивания Jenkins на Windows компьютере.