Как стать автором
Обновить
64
0.1
Николай Богданов @n_bogdanov

DevOps-инженер

Отправить сообщение

Ныряем в готовые кластеры Kubernetes с Deckhouse и werf

Время на прочтение8 мин
Количество просмотров5.4K


Российские облачные провайдеры начали предоставлять неплохие managed-решения для Kubernetes. Однако многие из них требуют доводки до ума и установки большого количества компонентов, направленных на сбор логов, мониторинг и доступ к кластеру. Это вынуждает пользователей собирать свой собственный бандл с Prometheus, Grafana и т.д., что крайне неудобно и требует дополнительных усилий.

Вот и я, столкнувшись с Managed Kubernetes от Selectel, захотел использовать что-то готовое, желательно от российских разработчиков. Я обратил внимание на платформу Deckhouse, которую к тому моменту можно уже было ставить в готовые кластеры k8s. В этой статье я расскажу про свой путь интеграции D8 и werf в инфраструктуру Selectel и те проблемы, с которыми столкнулся в процессе.
Читать дальше →
Всего голосов 49: ↑49 и ↓0+49
Комментарии0

Опыт миграции из Gitea в GitLab. Сложно, но успешно

Время на прочтение11 мин
Количество просмотров19K

В мире существует множество различных систем для хранения кода. Различаются они как протоколом работы: Git, Mercurial, Bazaar, — так и форматом работы (cloud, self-hosted). Но есть и другой важный параметр: степень интеграции с сопутствующим инструментарием: issue tracker, CI/CD, wiki и т.д. Так сложилось, что мы в компании предпочитаем GitLab (вариант on-premise) и по умолчанию, если клиент не против, предлагаем ему это решение. В статье я расскажу про миграцию из Gitea c Jenkins в GitLab и о том, с какими сложностями пришлось столкнуться, а заодно поделюсь Python-скриптами, которые пригодились для успеха этого мероприятия.

Читать далее
Всего голосов 45: ↑44 и ↓1+43
Комментарии31

Тест производительности PostgreSQL на AWS EC2-инстансах на ARM

Время на прочтение7 мин
Количество просмотров8K

Прим. перев.: в конце января Percona опубликовала результаты своего небольшого сравнения производительности для СУБД PostgreSQL, запущенной на x86- и ARM-инстансах AWS. Результаты получились интересными даже с учетом всех допущений, сделанных самими авторами и отмеченных комментаторами оригинальной статьи. А чтобы вы могли сделать собственные выводы, предлагаем вниманию перевод этого материала.

Ожидаемый рост количества ARM-процессоров в дата-центрах уже довольно давно является горячей темой для обсуждения, и нам было любопытно узнать, как они справятся с PostgreSQL. Основным препятствием на этом пути была недоступность в целом серверов на базе ARM-чипов для тестирования и оценки. Все изменилось после того, как в 2018 году AWS представила линейку инстансов на основе ARM-процессоров. Впрочем, особого ажиотажа не последовало: многие посчитали их "экспериментальным" предложением. Мы тоже опасались рекомендовать эти инстансы для критически значимого применения и не прилагали особых усилий для их оценки. Но когда в мае 2020 было анонсировано второе поколение инстансов на основе Graviton2, решили пересмотреть свое отношение. Нужно было объективно взглянуть на показатель цена/производительность новых машин при работе с PostgreSQL.

Читать далее
Всего голосов 50: ↑50 и ↓0+50
Комментарии3

Практические истории из наших SRE-будней. Часть 3

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



Новый выпуск посвящён опыту с неожиданно затянувшейся миграцией одного Linux-сервера, знакомству с Kubernetes-оператором для ClickHouse, способу ускорить восстановление данных в сломавшейся реплике PostgreSQL и последствиями обновления CockroachDB. Если вы тоже думаете, что это может быть полезно или хотя бы просто интересно, добро пожаловать под кат!
Читать дальше →
Всего голосов 43: ↑43 и ↓0+43
Комментарии0

Обзор операторов PostgreSQL для Kubernetes. Часть 2: дополнения и итоговое сравнение

Время на прочтение8 мин
Количество просмотров11K


На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, — поступила отличная обратная связь от сообщества*.

Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, — и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы — спешим поделиться и ими.
Читать дальше →
Всего голосов 34: ↑34 и ↓0+34
Комментарии5

Обзор операторов PostgreSQL для Kubernetes. Часть 1: наш выбор и опыт

Время на прочтение11 мин
Количество просмотров27K


Всё чаще от клиентов поступают такие запросы: «Хотим как Amazon RDS, но дешевле»; «Хотим как RDS, но везде, в любой инфраструктуре». Чтобы реализовать подобное managed-решение на Kubernetes, мы посмотрели на текущее состояние наиболее популярных операторов для PostgreSQL (Stolon, операторы от Crunchy Data и Zalando) и сделали свой выбор.

Эта статья — полученный нами опыт и с теоретической точки зрения (обзор решений), и с практической стороны (что было выбрано и что из этого получилось). Но для начала давайте определимся, какие вообще требования предъявляются к потенциальной замене RDS…
Читать дальше →
Всего голосов 54: ↑53 и ↓1+52
Комментарии27

Цена tailing'а логов в Kubernetes

Время на прочтение8 мин
Количество просмотров5.5K
Прим. перев.: эту статью написал старший DevOps-инженер американской компании Olark, главный продукт которой — live chat — используют тысячи организаций. Автор делится размышлениями о проблеме потребляемых ресуров при сборе логов и результатами своего эксперимента с fluentd, что позволил ему добиться лучшей производительности для некоторых сценариев.



Журналирование – одна из тех вещей, о которых вспоминают только тогда, когда они ломаются. И это вовсе не критика. Дело в том, что логи как таковые не приносят денег. Они позволяют получать представление о том, что делают (или делали) программы, помогая поддерживать работу того, что приносит нам деньги. На малых масштабах (или при разработке) необходимую информацию можно получить, просто выводя сообщения в stdout. Но стоит перейти к распределенной системе, и сразу возникает потребность агрегировать эти сообщения и направлять в некое центральное хранилище, где они принесут наибольшую пользу. Это потребность еще более актуальна, если вы имеете дело с контейнерами на платформе вроде Kubernetes, где процессы и локальное хранилище эфемерны.
Читать дальше →
Всего голосов 28: ↑28 и ↓0+28
Комментарии9

Применение оконных функций и CTE в MySQL 8.0 для реализации накопительного итога без хаков

Время на прочтение13 мин
Количество просмотров13K


Прим. перев.: в этой статье тимлид британской компании Ticketsolve делится решением своей весьма специфичной проблемы, демонстрируя при этом общие подходы к созданию так называемых accumulating (накопительных) функций с помощью современных возможностей MySQL 8.0. Его листинги наглядны и снабжены подробными объяснениями, что помогает вникнуть в суть проблематики даже тем, кто не погружался в неё столь глубоко.

Обычная стратегия для выполнения обновлений с использованием накопительных функций в MySQL — применение пользовательских переменных и паттерна UPDATE [...] SET mycol = (@myvar := EXPRESSION(@myvar, mycol)).

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

В статье пойдет речь о двух способах ее реализации: с использованием оконных функций (канонический подход) и с помощью рекурсивных СТЕ (общих табличных выражений).
Читать дальше →
Всего голосов 27: ↑27 и ↓0+27
Комментарии1

Обновление MySQL (Percona Server) с 5.7 до 8.0

Время на прочтение8 мин
Количество просмотров16K


Прогресс не стоит на месте, поэтому причины обновиться на актуальные версии MySQL становятся всё более весомыми. Не так давно в одном из наших проектов настало время обновлять уютные кластеры Percona Server 5.7 до 8-й версии. Всё это происходило на платформе Ubuntu Linux 16.04. Как выполнить подобную операцию с минимальным простоем и с какими проблемами мы столкнулись при обновлении — читайте в этой статье.
Читать дальше →
Всего голосов 50: ↑49 и ↓1+48
Комментарии8

Loghouse 0.3 — долгожданное обновление нашей системы работы с логами в Kubernetes

Время на прочтение4 мин
Количество просмотров6.9K
У компании «Флант» есть ряд Open Source-разработок, преимущественно для Kubernetes, и loghouse — одна из самых популярных. Это наш инструмент для централизованного логирования в K8s, который был представлен более 2 лет назад.



Как мы упоминали в недавней статье про логи, он требовал доработки, и актуальность её со временем только росла. Сегодня мы рады представить новую версию loghouse — v0.3.0. Подробности о ней — под катом.
Читать дальше →
Всего голосов 50: ↑49 и ↓1+48
Комментарии26

Логи в Kubernetes (и не только) сегодня: ожидания и реальность

Время на прочтение10 мин
Количество просмотров23K


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

Однако для начала оговорюсь, что разные заказчики под сбором логов понимают очень разное:

  • кто-то хочет видеть security- и audit-логи;
  • кто-то — централизованное логирование всей инфраструктуры;
  • а кому-то достаточно собирать только логи приложения, исключив, например, балансировщики.

О том, как мы реализовывали различные «хотелки» и с какими трудностями столкнулись, — под катом.
Читать дальше →
Всего голосов 39: ↑39 и ↓0+39
Комментарии26

Не New Relic’ом одним: взгляд на Datadog и Atatus

Время на прочтение9 мин
Количество просмотров19K


В среде SRE-/DevOps-инженеров никого не удивишь, что однажды появляется клиент (или система мониторинга) и сообщает, что «всё пропало»: сайт не работает, оплаты не проходят, жизнь — тлен… Как бы ни хотелось помочь в такой ситуации, сделать это без простого и понятного инструмента бывает очень сложно. Зачастую проблема скрыта в коде самого приложения — нужно лишь локализовать её.

И в горе, и в радости…


Так сложилось, что мы уже весьма давно и сильно полюбили New Relic. Он был и остаётся отличным средством для мониторинга производительности приложения, а также позволяет инструментировать микросервисную архитектуру (с помощью своего агента) и многое-многое другое. И всё могло быть замечательно, если бы не изменения в ценовой политике сервиса: его стоимость с 2013 года выросла в 3+ раза. Вдобавок, с прошлого года для получения trial-аккаунта требуется общение с персональным менеджером, что затрудняет презентацию продукта потенциальному заказчику.
Читать дальше →
Всего голосов 38: ↑37 и ↓1+36
Комментарии10

Информация

В рейтинге
2 370-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность