DevOps *

Привет новичкам в Kubernetes и тем, кто не знаком с этой технологией!

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

Еженедельно бизнес-юнит ставит задачи и распределяет их между департаментами, а также делает отчеты для дирекции компании. Таким образом, у всех получается достигать поставленных бизнес-целей. Перед каждым юнитом стоят одинаковые задачи — распределение обязанностей, наем или увольнение сотрудников. Дирекция контролирует все происходящие процессы в бизнес-юнитах, распределяет затраты и отвечает за принятие финальных решений. Также в крупных компаниях нужны различные менеджеры, сейлы и еще множество других сотрудников.

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

Хабр, привет! Меня зовут Алексей Быков, и я занимаюсь развитием Cloud Native платформы для обработки, хранения, анализа и управления данными Arenadata One в компании Arenadata. Современные высоконагруженные системы требуют гибкого масштабирования и отказоустойчивости для обеспечения стабильной производительности в условиях постоянно растущих объёмов данных. Когда речь идёт о PostgreSQL, развёрнутом в Kubernetes, перед инженерами встают особые вопросы: как упорядочить реплики для отказоустойчивости, каким образом настроить бэкапы и мониторинг, а главное — как корректно масштабироваться в облачной среде.

В этой статье мы рассмотрим, почему «ванильный» PostgreSQL в контейнерной среде может работать ненадёжно и какие механизмы применяются сегодня, чтобы сделать базу данных по-настоящему Cloud Native. Разберём ключевые аспекты классических инсталляций Postgres, проанализируем, в чём заключаются основные сложности их переноса в Kubernetes.

Долго ли, коротко ли, служил я java-разработчиком, да судьба-злодейка, крутанула меня в Platform Engineer’ы. Овладел я ремеслом devops’ским да сисадминским, но по ночам снится мне low-level Java, но быль моя совсем чуть-чуть об этом будет - поглаголю о JVM опциях, дабы приложение в k8s без дури запускать. Расскажу, как доблестно (а может, и безрассудно) SeaweedFS S3 storage выбирал, как кластер k8s поднимал, не щадя живота своего. Читай сии записки, запивая иван-чаем или медовухой: авось, умная мысль глянет меж строк. Не глянет — так хоть посмеёшься над моим devops экспириенсом.

Хотите защитить данные в сетях с использованием NFS? Мы расскажем, как настроить шифрование трафика с помощью RPC-with-TLS — от работы с сертификатами до диагностики ошибок. Узнайте о преимуществах технологии, её ограничениях и о том, как она может стать альтернативой VPN или Kerberos для повышения безопасности ваших данных.

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

В этой статье я, насколько могу, подробно расскажу вам, как настроить SSH для подключения к виртуальной машине (VM) и интегрировать процесс CI/CD для вашего проекта с использованием Docker и GitLab/GitHub. Мы пройдем через все необходимые шаги, чтобы вы могли легко развернуть ваше приложение.

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

Расскажем, как мы сделали отказоустойчивый WireGuard-сервер в Yandex Cloud, раскинув его на три зоны доступности. Получилось просто, надёжно и без сложных кластеров.

Мы не рассматриваем настройку самого WireGuard, конфигурацию групп безопасности, настройку VPC, NLB и прочее. Вся логика сосредоточена на том, чтобы обеспечить автоматическое переключение между зонами при сбоях. Сеть VPN-клиентов — 172.28.90.0/24 — должны быть доступна с любой из трёх зон.

Вы думаете, что развернуть Kubernetes без интернета — это просто kubeadm init плюс пара манифестов? Посмотрим, как скрипты решают проблемы, о которых вы даже не задумывались. Спойлер: здесь есть чему удивиться.

Всем пример, меня зовут Даниил Миронюк, DevOps в команде Polymatica EPM. Сегодняшняя статья для тех, кто считает, что оффлайн‑установка Kubernetes — это скучно.

Всем доброго дня! Пишу здесь впервые. На написание меня этой статьи побудило желание рассказать людям об эффективном способе миграции от внутренней базы данных Sqlite3 к внешней БД PostgreSQL. Подобной статьи на Хабре я не нашел, поэтому надеюсь будет полезно.

Представьте, что вы разрабатываете новую функцию в приложении, но пока не готовы открыть её всем пользователям. Хочется выложить код на продакшн, но оставить функцию «под замком» до поры до времени. В таких случаях на помощь приходят feature flags (по-русски часто говорят «фича-флаги») — специальный механизм переключения функциональности. Проще говоря, фича-флаг – это пара «ключ – значение (обычно булевое)», которая определяет, активна ли та или иная возможность в приложении. В коде это проявляется как условие: если флаг включён, выполняется новая логика, а если выключен – используется старое поведение. С помощью фича-флагов можно не только скрывать незавершённые функции за условными операторами, но и гибко управлять их постепенным запуском для аудитории (например, включать новую фичу только для X% пользователей).

На первых порах разработчики часто реализуют флаги «локально» – в виде переменных конфигурации, констант или параметров в коде приложения. Такой локальный флаг хранится и меняется непосредственно в приложении (или на сервере, где оно запущено). Этот подход может сработать в небольшом проекте, но в масштабе команды и множества окружений у него быстро обнаруживаются недостатки. Во-первых, если значение флага жёстко прописано в конфигурации или коде, для его изменения зачастую требуется выкатывать новую версию приложения (то есть делать повторный деплой). Возможность динамически «покрутить тумблер» теряется, и смысл фич-флагов частично сводится на нет. Во-вторых, появляется рассинхрон между окружениями: например, в продакшене новый флаг включён через удалённую конфигурацию, а в тестовой сборке по умолчанию выключен. В итоге тестировщикам приходится вручную приводить локальные значения флагов в соответствие с продакшеном, что неудобно и чревато ошибками. Кроме того, без общего подхода трудно отслеживать, какие флаги существуют в системе, кто и когда их включал, и на что они влияют.

Тема BUM трафика имеет огромное значение в современном мире сетевых технологий. И не важно L3-only у вас, или единый L2 навсю корпорацию. BUM - используется в любом случае. Тем более, это имеет огромное и внутри сетей центров обработки данных. Вот хочу поговорить про это чуть побольше и подетальней, и естественно в разрезе EVPN-VXLAN.

Добро пожаловать, надеюсь будет интересно

Nelm — это свободная Open Source CLI-утилита для управления Helm-чартами и их развёртыванием в Kubernetes. Взяв за основу кодовую базу Helm 3, Nelm не только делает почти всё то, что может делать Helm, но делает это лучше, а также предлагает дополнительную функциональность. 

Nelm обратно совместим с Helm-чартами и Helm-релизами, что сильно упрощает процесс миграции для пользователей Helm. Если вы уже работали с werf, то Nelm — это werf, но без гитерминизма, сборки, доставки и очистки образов.

Под катом вас ждут подробности о преимуществах Nelm по сравнению с Helm 3.

Elasticsearch — это распределённая поисковая и аналитическая система для обработки больших объёмов данных в реальном времени. В этом посте будет рассмотрено развертывание Elasticsearch в Kubernetes через оператор ECK (Elastic Cloud on Kubernetes), который упрощает управление жизненным циклом кластера. Для эффективного мониторинга работы Elasticsearch будет использоваться связка Prometheus и специального экспортёра метрик. Экспортёр собирает ключевые показатели (индексация, поисковые запросы, использование ресурсов) и делает их доступными для Prometheus через ServiceMonitor. Конфигурация включает настройку аутентификации, SSL-сертификатов для безопасного соединения и томов для хранения данных. Так же будет рассмотрен бекап и восстановление индексов.

Список необходимых инструментов.

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

И на этом сервере, мы можем выполнять любой набор команд для автоматизации.🫡

Но самый важный момент на этом этапе – какие настройки должны быть на этом сервере? Какие программы, пакеты или библиотеки, должны быть установлены? В конце концов, какую операционную систему использовать? ⚠️

Мы уже определили набор команд, которые хотим запускать. Давайте разберемся, что нам нужно для их успешного выполнения? Это будет вторым важным и сложным на первых порах моментом, который следует разобрать.

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

eslint . –fix

npm run build

Если попробовать перечислить, то получится следующий список

Привет, Хабр! Продолжу серию третьей статьей об эффективном использовании Ansible для развертывания больших инфраструктур в компаниях. В этом тексте я расскажу, какую архитектуру приложения на основе Ansible мы сформировали, и остановлюсь на модулях Deployer и Inventory.

Языки программирования расходятся во мнении, что такое ошибки или исключения и как их обрабатывать. Возникает вопрос: что использовать, если нужны стандартизированная телеметрия и отчёты об ошибках для написанных на этих языках микросервисов? Ответом может быть OpenTelemetry.

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

Kubernetes — это не просто оркестратор контейнеров, а целая экосистема инструментов, которые позволяют построить PaaS без написания кода. Helm, ArgoCD, Crossplane, Knative и другие решения делают управление приложениями и инфраструктурой настолько простым, что разработка собственной платформы превращается в задачу конфигурации, а не программирования. Меня зовут Сергей Емельянов, я техлид команды в VK Tech, которая занимается созданием PaaS-платформы на базе Kubernetes для упрощения работы с данными. В серии статей разберем, как создать PaaS, используя мощь Kubernetes и его экосистему.

Всем привет. Наверняка каждый, кто так или иначе связан с IT сферой, слышал модную аббревиатуру CI/CD. Везде мы слышим про необходимость ее использования, преимущества автоматизации процессов и т.д.

В вакансиях все чаще требуется опыт работы с одним из инструментов в этой инфраструктуре – Jenkins, Travis, AWS, Gitlab CI/CD.

⚠️Я предлагаю вам посмотреть на этот процесс, глазами простого разработчика. Чем ему может помочь автоматизация. Что в конечно итоге скрывается под этой аббревиатурой, и как уже начать получать дивиденды в своей ежедневной рабочей практике.

Первые шаги

Мы рассмотрим внедрение инструментов автоматизации в приложение, построенное на базе React. В целом разберем именно основные подходы и моменты, на которые стоит обратить внимание в самом начале.

В целом, это будет актуально для любого стека.
Чаще всего я использую для хранения кодовой базы и групповой работе над проектами Gitlab. Очень кстати, что эта площадка предоставляет инструментарий CI/CD.

Я пытался пару лет подступиться к этому вопросу. Стильно, модно, молодежно. Да, дает кучу преимуществ. Но все попытки переварить официальную документацию, заканчивались неудачей. А видео уроки или материалы в общем доступе – чаще всего давали рецепт автоматизации какого-то конкретного кейса, который либо частично, либо полностью отличался от моего приложения.

Мне не хватало именно взгляда на основные шаги – что, зачем и как мы делаем. А уже потом реализации практических задач.

CI – continuous integration

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

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

Привет. Расскажу, как мы решили проблему с переносом релизов из Test в Prod в Qlik Sense. Сначала немного истории. Выбор архитектуры с изолированными средами Test и Prod в Qlik Sense для нас был обусловлен следующими преимуществами:

Производственная среда высокой степени готовности, надежности за счет исключения влияния разработки, ситуации с нештатными и штатными перезагрузками системы и сервисов минимизированы. Все пользователи имеют одинаковый профиль нагрузки, использования (load pattern, usage pattern), линейная зависимость утилизации ресурсов от количества пользователей, управляемая модель планирования роста производительности и масштабируемости системы. Все пользователи, аналитики и разработчики имеют права «только чтение», вероятность ошибочных изменений объектов в системе исключена. В Prod обеспечивается подключение к источникам данных только продуктивного контура в соответствии с правилами информационной безопасности.

Среда разработки и тестирования Test, в силу решаемых задач, предусматривает менее строгие требования к доступности и надежности системы. Таким образом, не создают неудобства для основного бизнеса и допускаются ошибки при разработке, приводящие к неработоспособности системы, узлов, сервисов или деградации производительности, например, в силу разной квалификации разработчиков. Для команд внутренней разработки Компании и подрядных организаций обеспечивается возможность изолирования проектов и ресурсов на уровне групп ActiveDirectory и сетевого доступа. В Test источниками данных для Qlik являются, соответственно, КХД и другие АС в тестовом контуре. Это позволяет командам разработчиков QS и БД вести совместные разработку в соответствии с правилами сетевой связанности и информационной безопасности. Также могут решаться задачи обучения разработчиков и аналитиков на временных площадках SandBox и SelfSense.