DevOps *

Если у вас 1-2 проекта, а в каждом до 5 приложений, и вы раз в полгода создаете новый чарт в Helm, вы можете просто копировать старые чарты или создавать новые с нуля. Но что делать, если у вас 5 проектов, в каждом по 20 микросервисов, и каждые 2 недели ваши разработчики выкатывают новые и выкидывают старые? А еще надо постоянно что-то обновлять. А если проектов 20 или 50, что делать в этом случае? Тогда вы копируете одни и те же паттерны и шаблоны с общим костяком. Мы заметили это на одном из проектов, в котором нужно было запустить 15 микросервисов, и подумали, а почему бы не запилить единый чарт, через который будет запускаться вообще всё?

Меня зовут Роман Андреев, я DevOps инженер Nixys. Расскажу о практическом применении универсального чарта. На теории останавливаться почти не будем, только в общих чертах, потому что о ней мы уже говорили в предыдущих статьях.

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

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

Однако, в связи с известными событиями, лавочка по сдаче экзаменов у AWS закрылась, а если говорить точнее - то с переводами оплаты стало сложнее. А так как нам от многих компаний начали поступать запросы на миграцию в Яндекс, было принято решение поголовно пройти бесплатный курс от Яндекс.Практикум «Инженер облачных сервисов» для более близкого ознакомления с облачными ресурсами Яндекса. В первую очередь прохождение касалось именно junior-инженеров и тех, кому не доводилось работать в этом облаке.

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

Размер итогового образа контейнера получится всего лишь от 13 мегабайт.

Система контейнерной оркестрации Kubernetes де факто стала золотым стандартом в DevOps, как универсальный инструмент управления конфигурацией и автоматической поддержки ожидаемого состояния системы. Но, даже при использовании Managed Kubernetes решений (например, Amazon EKS, GKE или решений от Яндекс Облака или Mail.Ru), некоторые сервисы провайдера размещаются за пределами Kubernetes (например, S3-совместимое хранилище, брокеры очередей или базы данных) и хотелось бы иметь возможность управлять с использованием общей конфигурации. В статье мы обсудим возможности использования проекта Crossplane (входит в Incubating CNCF), а также посмотрим на код провайдера на примере управления базами данных MySQL.

Привет, Хабр! Мы в Слёрме помогаем IT-специалистам повысить квалификацию и использовать IT-инструменты более эффективно.

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

Расскажем, что это за темы, почему они важны и какую пользу принесут системным инженерам, администраторам БД, инфраструктурным разработчикам и архитекторам IT-систем.

Продолжаем говорить о безопасной разработке и Secure SDLC. Сегодня на примере платформы T1 Cloud SDP покажем, какие облачные сервисы привнесут уровень безопасности в жизненный цикл ПО. Среди них есть как ручной анализ кода, так и автоматизированная проверка надежности open source компонентов.

Небольшая статья про опыт который я получил, когда пытался подружить Packer со SberCloud.

Основная проблема - нет провайдера для SberCloud.

Helm Charts мощный и гибкий инструмент управления ресурсами в Kuberenetes.

А что если одним чартом пользуются несколько команд для деплоя своих приложений в Kubernetes? Как гарантировать, что чарт как минимум может отрендериться, прежде чем публиковать чарт в репозиторий артефактов? Как гарантировать, что новая версия чарта не "сломает" деплой приложений в критический момент(на продакшн)?

Этими вопросами задался и я при разработке такого чарта.

Дано

• кластер k8s

• много приложений, которые пишут свои логи в stdout/stderr, а контейнерный движок (в данном случае docker) складывает их в файлы

• fluent-bit, запущенный на каждой ноде k8s. Он собирает логи, фильтрует их и отправляет в Loki

• loki - хранилище логов от Grafana Labs

В чём заключается проблема

При просмотре логов через Grafana (источник - Loki) видно, что логи приходят с сильной задержкой или часть логов вообще отсутствует. При просмотре через kubectl logs все логи на месте.

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

Но после обновления графаны до девятой версии всё изменилось. Я обнаружил, что сообщения превратились в малочитаемые простыни (на КПДВ слева).

Решил сократить сообщения и повысить их читаемость, что у меня получилось можете увидеть на той же картинке справа.

При описании конфигурации инфраструктуры и развертывания информационной системы нередко случается ситуация, когда в исходные тексты или в yaml-файлы попадают секреты и ssh-ключи, которые используются для управления облачной инфраструктурой или серверами системы. Конечно же, хорошей практикой является использование систем безопасного хранения токенов доступа (например, HashiCorp Vault), но иногда, по невнимательности, секреты все же попадают в репозитории системы и хорошо, если они не являются публичными. В этой статье мы обсудим возможности инструментов SpectralOps для отслеживания и исключения таких ситуаций.

В целом компания SpectralOps (сейчас принадлежит Check Point) занимается разработкой и развитием инструментов, уменьшающих вероятность публикации чувствительной информации и предлагает целое семейство продуктов для разработчиков:

Обеспечение надежного функционирования системы при развертывании обновления системы требует запуска тестов разного уровня - от модульных тестов отдельных компонентов до интеграционных тестов, проверяющих в staging-окружении работу системы в целом. Но не менее важны для оценки готовности системы к большой кратковременной пиковой нагрузке (или злонамеренным атакам) выполнение нагрузочных тестов. В июле 2021 года компания Grafana Inc приобрела продукт k6, который изначально был ориентирован на запуск высокопроизводительных распределенных нагрузочных тестов, и это положительно повлияло на его дальнейшее развитие как встраиваемого инструмента для запуска тестов в облачных инфраструктурах или Kubernetes. В этой статье мы рассмотрим один из возможных сценариев использования k6 для тестирования сервиса в конвейере CI/CD.

За время, прошедшее с момента предыдущего стабильного релиза Deckhouse, наша Kubernetes-платформа успела получить сертификацию CNCF для версий Kubernetes v1.22 и v1.23, появилась в списках adopters у Prometheus Operator, а еще — в числе пользователей Cilium. Как раз с Cilium связано главное улучшение в новом стабильном релизе платформы.

Часто возникает ситуация, когда нужно развернуть приложение одновременно в нескольких облаках, совместить облачную инфраструктуру и управляемый Kubernetes-кластер или предусмотреть возможную миграцию сервиса в будущем. Одним из возможных решений для создания универсальной конфигурации может быть использование проекта Pulumi, который позволяет публиковать приложения в разные облака (GCP, Amazon, Azure, AliCloud), Kubernetes, провайдеры (например, Linode, Digital Ocean), системы управления виртуальной инфраструктурой (OpenStack) и в локальный Docker. В этой статье мы рассмотрим основные идеи проекта, создадим универсальную конфигурацию для простого Python-приложения с базой данных и настроим непрерывную доставку.

Итак, вы - лид , скажем, 5-6 разработчиков и 2-3 тестировщика, встает вопрос - как тестировать задачи, запускать тесты по веткам, желательно не толкаясь локтями на одном стенде и не потратив недели на настройку и поддержку инфраструктуры. Сегодня расскажу о подходе, к которому сам пришел, оказавшись в такой ситуации.
Первым делом рассмотрим опции:

Банковские сервисы по умолчанию не должны падать, и даже прилечь на секундочку, и даже когда мы обновляемся. Ведь даже секунды могут привести к потерям с множеством нулей. Чтобы этого не произошло мы используем blue-green deployment.

Простым языком blue-green deployment - способ развертывания, который позволяет обновлять приложения не отклоняя ни одного запроса, без остановок. Как это сделать, расскажу и покажу на примере. Статья подойдет DevOps-инженерам и бэкенд-разработчикам, особенно на HighLoad-проектах, а также моим будущим коллегам, как методичка по безрисковым релизам, чтобы прод не падал каждые 2 недели по графику релизов (а такое тоже бывало).

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

Всем привет! Я расскажу о том как в течении 10 минут создать личный VPN сервер в нужном регионе.

Очевидно, что для настройки потребуется доступ к Azure. Я сделал такой доступ через Azure Benefit (google 'how to activate azure benefit for msdn subscribers'). В марте-апреле этого года данная штука активировалась для жителей нашей страны, а вот в этом месяце с этим как мне сказали уже есть проблемы. В таком случае - обращайтесь к друзьям с доступом к Azure.

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