Всем привет. На этот раз хотел бы поделиться материалом, связанным непосредственно с devops работой. Недавно возникла потребность раскатить kafka кластер в kubernetes. В ходе развертывания возникло очень много сложностей, встречено множество подводных камней, и, естественно, в большинстве случаев рецепта в интернете найдено не было, поэтому приходилось искать решения самостоятельно методом проб и ошибок. Все, что здесь будет описано это сугубо личный опыт на одном из проектов. Сегодня я расскажу как с нуля раскатить dev контур bitnami/kafka кластера с помощью helm чартов, как обезопасить ваш кластер kafka и какие сложности могут вам встретиться.
Пользователь
Защищаем сервис от перегрузки с помощью HAProxy
Если вам доводилось использовать HAProxy для балансировки трафика, вы наверняка как минимум слышали, что этот продукт умеет отслеживать показатели активности сервиса и пользователей и реагировать на них по предопределённым условиям. Обычно в статьях на эту тему приводится пример ограничения пользователя по исходному IP-адресу, если частота запросов с него превышает некоторый предопределённый заранее лимит. Вот, к примеру, такая статья с сайта разработчиков.
Я бы хотел немного углубиться в тематику использованного механизма stick tables, но поговорить не про пользователей, активно интересующихся вашим сайтом, а про нагрузочную способность, или ёмкость, всего сайта (ну или каких-то его путей). Во-первых, любой сервис ограничен в количестве одновременных запросов, которые возможно обслужить на существующих ресурсах. Во-вторых, чаще всего у сервиса не одна площадка или хотя бы не один экземпляр балансёра. А это значит, что поймать одинокого пользователя — это, конечно, здорово, но хотелось бы решить и другую интересную задачу: защитить сервис от перегрузки в целом и в случае, если балансёров более одного. Бонусом поговорим о проблеме умного перераспределения нагрузки между локациями.
Ивентная модель данных с использованием Kafka и Kafka Connect: Построение гибкой и распределенной архитектуры
Привет, Хабр! В наше время при постоянном росте объемов данных и необходимостью более быстрой и надежной обработки информации, мы сталкиваемся с требованием к эффективному обмену и синхронизации данных между различными системами. Отслеживание и обработка данных в реальном времени стало жизненно необходимым для современных приложений.
В этой статье мы рассмотрим, как Kafka Connect – мощный инструмент из экосистемы Apache Kafka – приходит на помощь при решении сложной задачи синхронизации данных между базами данных. Мы рассмотрим, как используя Kafka Connect, мы можем эффективно следить за изменениями в одной базе данных, обрабатывать их в нашем Java приложении и мгновенно записывать их в другую базу данных, обеспечивая надежность и безопасность данных.
Построим гибкую и масштабируемую архитектуру, которая позволит нам забыть о проблемах связанных с несогласованными данными и наслаждаться мгновенным доступом к актуальной информации для наших бизнес-процессов.
Создаём виртуальную сеть, как это делает Docker
Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.
Квоты в Kubernetes: очевидные, менее очевидные и совсем не очевидные
Привет, Хабр! Я Виктор, техлид продукта CI/CD в Samokat.tech. А это, :(){ :|:& };: fork-бомба, которая создаёт свои дочерние процессы бесконечно. Запуск такой штуки в контейнере без ограничений роняет всю ноду. Не используйте в проде! Если запустить в WSL, то винду тоже укладывает. Как же избежать запуска такой штуки на проде? Помогут квоты.
Давайте разберемся как работают квоты в Kubernetes. Там есть немало граблей. В этой статье поделюсь своим опытом по работе с квотами – расскажу, чем квоты хороши, что у них под капотом, в каких задачах используются и почему нужны даже в среде single-tenant.
Nginx: шпаргалка
Шпаргалка по основным секциям Nginx, которые следует держать под рукой. Ниже приведены самые частые функции: включение SSL, переадресация, раздача статики и т.д.
Мониторинг HTTP и SSL через Prometheus blackbox_exporter
Автор: DevOps компании Hostkey Никита Зубарев
Инфраструктура нашей компании поддерживается на высоких уровнях SLA, что требует от нас измерять, наблюдать и отправлять отчеты, которые фиксируют метрики производительности систем.
В одной из прошлых статей мы рассмотрели варианты установки федерации Prometheus, Alertmanager и Node Exporter, но у нас также есть задача мониторинга задержки производительности наших приложений и точного выявления проблемных конечных точек. Мы отслеживали время отклика всех конечных точек, которые использовались в потоке приложения, и с помощью BlackBox Exporter обнаружили наши конечные точки, вызывающие задержку. Соответственно, перед нами возникла задача наладить мониторинг статус-кодов ответов наших web-сервисов, а также сроков действия SSL-сертификатов.
System Design 101
О сложных системах простыми словами.
В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.
Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.
Возможно, немного другой формат шпаргалки покажется вам более удобным.
Безотказные очереди в RabbitMQ: Гарантированная доставка сообщений
RabbitMQ - это открытая реализация протокола AMQP (Advanced Message Queuing Protocol), является мощным и гибким брокером сообщений. Он обеспечивает надежное и эффективное взаимодействие между компонентами системы, предоставляя разработчикам инструменты для создания гибких и масштабируемых архитектур.
В мире современной разработки программного обеспечения, где взаимодействие между различными компонентами системы становится неотъемлемой частью архитектуры, обеспечение гарантированной доставки сообщений становится вопросом первостепенной важности. На переднем плане таких инструментов стоит RabbitMQ, мощный брокер сообщений, предоставляющий гибкость и эффективность в обработке сообщений.
В этой статье мы сосредоточимся на безотказных очередях в RabbitMQ, исследуя их применение в конкретных сценариях разработки, не углубляясь в общие механизмы работы брокера сообщений.
Операторы в Kubernetes
Ручные изменения в кластере доставляют одну лишь головную боль. А чтобы от них избавиться, используются операторы, в частности K8s. Что это такое? И самое главное, как его написать?
Меня зовут Дмитрий Самохвалов, я архитектор в компании КРОК. Пробовал себя в разработке, инфраструктуре и тимлидерстве. Расскажу про архитектуру и внутреннее устройство оператора и покажу как создать свой оператор на Go. Все остальные вопросы можно задать мне в Телеграм.
Kubernetes Scheduler в Деталях: Важные Аспекты. Часть 1
Хотите узнать, как Kubernetes оптимально распределяет ваши контейнеры по нодам и каким образом можно этот процесс настроить или даже модифицировать?
В этой статье мы погружаемся в недра Kubernetes Scheduler — ключевого компонента, отвечающего за эффективное распределение ресурсов в вашем кластере. От базовых принципов и этапов планирования до возможностей расширения с помощью плагинов - здесь вы найдете всё, чтобы стать настоящим экспертом в этой области.
Не пропустите!
Планирую идти от простого к сложному, так что прошу отнестись с пониманием. Если вы уже знакомы с базовыми концепциями k8s scheduler, не стесняйтесь пропустить первую часть и перейти сразу ко 2-й (ссылка будет опубликована позже).
Поднимаем кластер PostgreSQL в Docker и Testcontainers
Ранее я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.
Сегодня я покажу, как запустить уже целый кластер PostgreSQL в Docker, а также в тестах через Testcontainers, и как вручную инициировать смену мастер-хоста.
Продвинутая работа с логами в Linux
Журнал событий, это компонент systemd, который захватывает сообщения Syslog, логи ядра, все события при инициализации системы (RAM, диск, boot, STDOUT/STDERR для всех сервисов), индексирует их и затем предоставляет удобной пользовательский интерфейс для поиска и фильтрации логов. Журнал (systemd journal) можно использовать вместе или вместо syslog или syslog-ng.
Утилита командной строки journalctl, если сравнивать ее с традиционным инструментами для работы с логами в UNIX (tail, grep, sed, awk) более широкие возможности.
Давайте рассмотрим основные возможности которые предоставляет журнал systemd и способы их применения.
Чеклист для запуска или миграции приложений в Kubernetes
Привет! Меня зовут Сергей Птушкин, в этом посте я поделюсь с вами нашим чеклистом для оперативного и безболезненного переезда в Kubernetes. У SM Lab очень много разных продуктов, а как следствие — разных команд разработчиков и администраторов. У всех своя архитектура, стек, любимые языки программирования, SLA и требования по нагрузке.
Поэтому при переезде приложений в Kubernetes нам нужно готовить их с учетом всех особенностей и требований, а также передавать компетенции devops-инженерам и разработчикам. В процессе получается еще и выяснить их собственные потребности при эксплуатации этих приложений.
Итак, давайте разберем на примере нашей ситуации. Мы переезжали в Kubernetes из Mesos и Oracle Weblogic и знали, что разработчики тестируют приложения при помощи docker-compose или локально на станциях. Нам нужно было придумать единый подход для следующих возможностей:
Как пользоваться CSI Provider: доставляем секреты из Vault в Kubernetes
Добрый день, Хабр! Мы — Михаил Панов и Евгений Прудченко, DevOps‑инженеры из команды МТС Digital, работаем на проекте External WebSSO. Мы занимаемся внедрением DevOps практик и инструментов в рамках нашего проекта. В этой статье расскажем о интеграции и доставке секретов из Vault в Kubernetes с помощью Vault CSI Provider.
Изучив вопрос доставки секретов, мы выяснили, что мало кто использует Vault CSI Provider. Нам это показалось несправедливым, ведь, на наш взгляд, это отличный инструмент. Поэтому мы и решили поделиться нашим опытом.
Основная проблема которую хотелось решить — как получить секреты из Vault, меняя всего лишь несколько строк в values.yaml файле нашего helm‑chart. Задача грандиозная, поэтому нам пришлось пройти длинный путь к ее решению.
Восстановление данных PostgreSQL после потери pg_control
Для обеспечения отказоустойчивости СУБД PostgreSQL, как и многие базы данных, использует специальный журнал, в котором ведет историю изменения данных. Перед тем как записать данные в файлы БД, сервер PostgreSQL аккумулирует изменения в оперативной памяти и записывает в последовательный файл журнала, чтобы не потерять их из-за непредвиденного отключения питания.
Данные в журнал пишутся до того как пользователь базы данных получит сообщение об успешном применении изменений. Этот журнал называется журналом упреждающей записи (Write-Ahead Log или просто WAL), а файлы журнала хранятся в каталоге pg_xlog. Также периодически PostgreSQL сбрасывает измененные аккумулированные данные из оперативной памяти на диск. Этот процесс согласования данных называется контрольной точкой (checkpoint). Контрольная точка выполняется также при каждом штатном выключении PostgreSQL.
Информация о том, с какими внутренними значениями завершилась контрольная точка, хранится в файле global/pg_control и потому этот файл должен быть доступен СУБД еще до момента восстановления данных. Если PostgreSQL отключается нештатно, то изменения из файлов журнала (pg_xlog) применяются к файлам БД, начиная с позиции последней контрольной точки. Этот процесс называется восстановлением данных.
В файле pg_control находится информация:
- версия формата control-файла,
- контрольная сумма записанных в этот файл данных,
- версия формата файлов БД,
- уникальный идентификатор экземпляра БД,
- текущее состояние: работает/остановлен,
- позиция в журнале, соответствующая запущенной и предыдущей контрольным точкам,
- текущая ветвь времени (timeline),
- максимальный видимый номер транзакции (xid),
- максимальный номер внутреннего счетчика объектов (oid),
- время создания,
- и многое другое.
Посмотреть содержимое pg_control можно при помощи утилиты pg_controldata:
$ pg_controldata /var/lib/pgsql/9.5/data
pg_control version number: 942
Catalog version number: 201510051
Database system identifier: 6242923005164171508
Database cluster state: in production
pg_control last modified: Fri Apr 29 01:00:00 2016
Latest checkpoint location: EEAF/BAA5520
Prior checkpoint location: EEAF/BAA5440
...
Latest checkpoint's NextXID: 7/876524573
Latest checkpoint's NextOID: 264355612
Latest checkpoint's NextMultiXactId: 134512401
Latest checkpoint's NextMultiOffset: 547842659
...
Изучаем Docker, часть 5: команды
→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными
NAS за шапку сухарей
Привет коллеги! На связи системный администратор Cloud4Y Денис Генералов (или тот самый чел, который искал уязвимости биоса в прошлых статьях на ноутбуках, статья тут).
Сегодня предлагаю рассмотреть вариант сборки домашнего NAS дендральным методом.
Всё описанное в статье является результатом деятельности моего воспаленного мозга поиска оптимальной конфигурации для своего домашнего файлохранилища и не является призывами к прямому действию. Представляет из себя изыскание того самого продукта, который может максимально покрыть мои потребности за сравнительно небольшую плату. Не поднимает вопрос о подлинности и законности использования указанного решения на территории предприятия, для всего остального – есть GPL v2.
О SAN (Storage Area Network) на пальцах
В деле познания SAN столкнулся с определённым препятствием — труднодоступностью базовой информации. В вопросе изучения прочих инфраструктурных продуктов, с которыми доводилось сталкиваться, проще — есть пробные версии ПО, возможность установить их на вирутальной машине, есть куча учебников, референс гайдов и блогов по теме. Cisco и Microsoft клепают очень качественные учебники, MS вдобавок худо-бедно причесал свою адскую чердачную кладовку под названием technet, даже по VMware есть книга, пусть и одна (и даже на русском языке!), причём с КПД около 100%. Уже и по самим устройствам хранения данных можно получить информацию с семинаров, маркетинговых мероприятий и документов, форумов. По сети же хранения — тишина и мёртвые с косами стоять. Я нашёл два учебника, но купить не решился. Это "Storage Area Networks For Dummies" (есть и такое, оказывается. Очень любознательные англоговорящие «чайники» в целевой аудитории, видимо) за полторы тысячи рублей и "Distributed Storage Networks: Architecture, Protocols and Management" — выглядит более надёжно, но 8200р при скидке 40%. Вместе с этой книгой Ozon рекомендует также книгу «Искусство кирпичной кладки».
Что посоветовать человеку, который решит с нуля изучить хотя бы теорию организации сети хранения данных, я не знаю. Как показала практика, даже дорогостоящие курсы могут дать на выходе ноль. Люди, применительно к SAN делятся на три категории: те, кто вообще не знает что это, кто знает, что такое явление просто есть и те, кто на вопрос «зачем в сети хранения делать две и более фабрики» смотрят с таким недоумением, будто их спросили что-то вроде «зачем квадрату четыре угла?».
Попробую восполнить пробел, которого не хватало мне — описать базу и описать просто. Рассматривать буду SAN на базе её классического протокола — Fibre Channel.
CLI инструменты, которые облегчат времяпровождение в терминале и сделают его приятнее
Многие из вас каждый день работают в терминале, так давайте улучшим это времяпровождение вместе. Существует множество полезных инструментов CLI, которые могут сделать вашу жизнь в командной строке проще, быстрее и в целом веселее.
В этом посте описан мой топ-25 обязательных инструментов CLI, на которые я привык полагаться. Если тут нет вашего любимого - дайте мне знать в комментариях :)
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity