DevOps *

Kubernetes (k8s) является де-факто стандартом для развёртывания приложений. В терминах K8s приложение представляет собой набор сконфигурированных ресурсов нескольких типов — pod, service, deployment, secret, statefulset,… Конфигурация каждого ресурса задаётся унифицированно с помощью YAML (или JSON) манифеста. Kubernetes API и интерфейс командной строки позволяют манипулировать манифестами ресурсов, а сами ресурсы автоматически приводятся в состояние, соответствующее манифестам.

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

• Helm — генерация манифестов на основе строковых шаблонов + "магазин" готовых компонентов (package manager).
• Kustomize — ("Kubernetes cUSTOMIZation") — донастройка манифестов путём внесения исправлений в различные свойства.
• Jsonnet — генерация манифестов с использованием легковесного функционального языка, предназначенного для генерации JSON.

Для синхронизации проектов, хранящихся в репозитории git, с фактическим состоянием инфраструктуры в каком-либо кластере может использоваться специальное приложение, работающее в рамках концепции GitOps, например ArgoCD. Причём поддерживаются как проекты, содержащие собственно манифесты, так и проекты, основанные на вышеперечисленных генераторах/модификаторах.

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

Рассмотрим, какие требования было бы разумно предъявить к языку описания инфраструктуры. (В этой заметке излагается взгляд автора, занимающегося разработкой программного обеспечения. Другие стороны, например, команды эксплуатации, могут иметь иной взгляд на этот вопрос.)

Docker, Kubernetes, GitLab CI, «работа в классной команде», «интересные задачи», «курсы, тренинги, митапы и конференции» — эти и многие другие заманчивые слова можно встретить в вакансиях инженеров. Мы, Southbridge, занимаемся поддержкой нагруженных серверов. У нас есть несколько инженерных команд. Как и в любой компании, иногда наши коллеги увольняются. Мы решили спросить у тех, кто работал с нами раньше, как на самом деле им работалось в Southbridge.

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

Всем привет.

Я работал админом около 12 лет, за всё время для целей администрирования пользовался почти всеми известными программами для удаленного доступа, сначала TeamViewer - после внедрения их политики лицензирования и обновления, мягко говоря неудобной и жуткой дорогой (около 30 т.р. в год), пересел на AnyDesk — который был чуть хуже в плане функционала, но более терпим в плане использования, и немного меньшей ценой — около 20 т.р. за год. Но душа всё-таки не была довольна, не хватало многих функций, автоматизации, да и порой было неудобно/лень договариваться о подключении с пользователем, что бы выполнить пустяковое действие. И так пришла на ум идея создать инструмент от админа админу, что бы и интерфейс устраивал, но не был перенасыщен, и разобраться мог любой человек более менее владеющий компьютером.

Это первая часть топика, где мы поговорим о Reliability в рамках практик SRE.

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

Позвольте поделиться с вами новым стеком, состоящим из кластера Kubernetes и набора специализированных расширений, которые позволят вам реализовывать ежедневные сложные рабочие процессы. Конечно, простое развёртывание Kubernetes и его расширений само по себе не приносит большой пользы. Если у вашей команды нет навыков разработки или развёртывания в Kubernetes, не говоря уже о понимании интеграции и использования сторонних расширений с вашими приложениями, тогда какая от этого польза для вас, верно?

Решил описать свой подход построения окружения на Typescript с Nest на бекенде, Nuxt (SPA) на фронтенде. Все заворачивается в один docker‑образ и запускается как standalone приложение c nginx, healthcheck»ами, тестами и ш…широкой сферой применения.

В этом посте:

• Использование terraform модулей
• Организуем структуру каталогов с terraform модулями для terragrunt согласно вашей инфраструктуре
• Создание/Обновление/Удаление инфраструктуры одной terragrunt командой
• Настройка в gitlab ci для запуска и сохранения terraform lock и state в gitlab
• Бекап terraform state из gitlab

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

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

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

Привет, Хабр! Сегодня у меня для вас отличные новости. В последние несколько лет мы во «Фланте» внимательно следили за технологиями‑лидерами в cloud‑native. Но это вовсе не праздное любопытство: из них мы собрали кое‑что интересное и теперь готовы представить его вам. Речь о новой системе виртуализации, которая появилась в сегодняшнем релизе Deckhouse v1.43.

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

В декабре 2022 года вышло обновление Bitcoin Core 24.0, которое позволяет заменять неподтвержденные транзакции (full-RBF или replace-by-fee). Это может коснуться всех, кто принимает оплату в биткоине по неподтвержденным транзакциям из мемпула: криптоматы, криптообменники, мерчанты и тд.

В статье я описал пошаговую инструкцию: как я разворачивал свою Bitcoin ноду и проверял, действительно ли можно заменить транзакцию.

Мне представилось решать интересную задачу. Необходимо реализовать настраиваемый SaaS, где пользователь может выбрать галочками нужные ему модули и щелкнуть кнопку готово. После этого для пользователя должен быть создан отдельный кластер Kubernetes (или отдельный namespace в общем кластере в зависимости от тарифного плана) с выбранными модулями, которые представляют из себя наборы микросервисов.

В этой статье я хочу осветить мой GitOps вариант реализации этой задачи и показать, на что способен ArgoCD и Terraform.

После прохождения одного из серии собеседований на SRE мне анонсировали, что на следующем будут задачки про SLO/SLI. Задач не было, но в ходе подготовки я сделал тематический конспект нескольких материалов, посвященных этой теме. Возможно, он будет вам полезен.

Понятно, что основной источник информации по теме – это Google SRE Book, но книга была опубликована давно, и мне было интересно, что по этой теме есть нового. В основном конспект основан на четырех материалах от Google: Implementing SLO, Art of SLOs (slides), SLO Document, Setting SLO Step by Step. Впоследствии я дополнил их несколькими интересными идеями из выступления Ивана Круглова.

Буду рад замечаниям и дополнениям.

Привет, Хабр! На этапе выбора темы статьи было много идей: написать про DevOps или про платформы, а может про продуктовые команды или про практики SRE? Но пришли к выводу, что нет ничего интереснее, чем реальная увлекательная история трансформации. Мы, команды платформы разработки MOEX и экосистемы Финуслуги.ру, в лице Карапета Манасяна, Александра Барыкова, Антона Квашёнкина и Юлии Лутковской, расскажем практически про весь путь изменений и про их подводные камни. Важно отметить, что в статье затрагивается довольно много тем, местами даже будут блоки со скриптами ?. Поехалиии!

В кластере Kubernetes нам доступен любой сервис в любом пространстве имён, то есть по умолчанию pod открыт для любого трафика.

Мы можем определить сетевую политику для пространства имён или pod»а, чтобы защитить рабочие нагрузки в кластере. Например, разделить рабочие нагрузки в мультитенантном кластере по проектам, командам или организациям.