company_banner

Как мы сайт Republic на Kubernetes переводили



    Скандальные, важные и просто очень крутые материалы выходят в СМИ не каждый день, да и со 100% точностью спрогнозировать успешность той или иной статьи не возьмётся ни один редактор. Максимум, чем располагает коллектив — на уровне чутья сказать, «крепкий» материал или же «обычный». Все. Дальше начинается непредсказуемая магия СМИ, благодаря которой статья может выйти в топы поисковой выдачи с десятками ссылок от других изданий или же материал канет в Лету. И вот как раз в случае публикации крутых статей сайты СМИ периодически падают под чудовищным наплывом пользователей, который мы с вами скромно называем «хабраэффектом».

    Этим летом жертвой профессионализма собственных авторов стал сайт издания Republic: статьи на тему пенсионной реформы, о школьном образовании и правильном питании в общей сложности собрали аудиторию в несколько миллионов читателей. Публикация каждого упомянутого материала приводила к настолько высоким нагрузкам, что до падения сайта Republic оставалось совсем «вот столечко». Администрация осознала, что надо что-то менять: нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.

    По итогам совместного со специалистами Republic обсуждения различных вариантов реализации озвученных хотелок мы решили перевести сайт издания на Kubernetes*. О том, чего нам всем это стоило, и будет наш сегодняшний рассказ.

    *В ходе переезда ни один технический специалист Republic не пострадал

    Как это выглядело в общих чертах


    Началось всё, само собой, с переговоров, как всё будет происходить «сейчас» и «потом». К сожалению, современная парадигма на IT-рынке подразумевает, что как только какая-либо компания отправляется на сторону за каким-то инфраструктурным решением, то ей подсовывают прейскурант услуг «под ключ». Казалось бы, работы «под ключ» — что может быть приятнее и милее условному директору или владельцу бизнеса? Заплатил, и голова не болит: планирование, разработка, поддержка — все находится там, на стороне подрядчика, бизнесу же остаётся лишь зарабатывать деньги на оплату столь приятного сервиса.

    Однако полная передача IT-инфраструктуры не во всех случаях целесообразна для заказчика в долгосрочной перспективе. Правильнее со всех точек зрения работать одной большой командой, чтобы после завершения проекта клиент понимал, как жить с новой инфраструктурой дальше, а у коллег по цеху со стороны заказчика не было вопроса «ой, а что это тут наворотили?» после подписания акта выполненных работ и демонстрации результатов. Того же мнения придерживались и парни из Republic. В итоге мы на два месяца высадили десант из четырёх человек к клиенту, которые не только реализовали нашу задумку, но и технически подготовили специалистов на стороне Republic к последующей работе и существованию в реалиях Kubernetes.

    И выиграли от этого все стороны: мы быстро выполнили работу, сохранили своих специалистов готовыми к новым свершениям и получили Republic в качестве клиента на консультативной поддержке с собственными инженерами. Издание же получило новую инфраструктуру, приспособленную к «хабраэффектам», собственный сохранённый штат технических специалистов и возможность обратиться за помощью, если она потребуется.

    Готовим плацдарм


    «Разрушать — не строить». Поговорка эта применима вообще к чему угодно. Конечно, наиболее простым решением кажутся упоминаемый ранее захват инфраструктуры клиента в заложники и приковывание его, клиента, к себе цепью, ну или разгон имеющегося штата и требование нанять гуру в новых технологиях. Мы пошли третьим, не самым популярным нынче путём, и начали с обучения инженеров Republic.

    Примерно такое решение по обеспечению работы сайта мы увидели на старте:


    То есть, у Republic было просто два железных сервера — основной и дублирующий, резервный. Самым важным для нас было добиться смены парадигмы мышления технических специалистов клиента, потому что ранее они имели дело с весьма простой связкой из NGINX, PHP-fpm и PostgreSQL. Теперь же им предстояло столкнуться с масштабируемой контейнерной архитектурой Kubernetes. Так что вначале мы перевели локальную разработку Republic на docker-compose окружение. И это был только первый шаг.

    До высадки нашего десанта разработчики Republic держали свое локальное рабочее окружение в виртуальных машинах, конфигурируемых через Vagrant, либо же работали напрямую с dev-сервером по sftp. Исходя из общего базового образа виртуальной машины, каждый разработчик «доконфигурировал» свою машинку «под себя», что порождало целый набор различных конфигураций. Как следствие подобного подхода, подключение в команду новых людей экспоненциально увеличивало время их входа в проект.

    В новых реалиях мы предложили команде более прозрачную структуру рабочего окружения. В ней декларативно описали, какое ПО и каких версий нужно для проекта, порядок связей и взаимодействия между сервисами (приложениями). Это описание залили в отдельный git-репозиторий, чтобы им можно было удобно централизованно управлять.

    Все нужные приложения стали запускаться в отдельных docker-контейнерах — а это обычный php-сайт с nginx, много статики, сервисы для работы с изображениями (ресайз, оптимизация и т д), и… отдельный сервис для веб-сокетов, написанный на языке D. Все файлы конфигураций (nginx-conf, php-conf…) тоже стали частью кодовой базы проекта.

    Соответственно, было «воссоздано» и локальное окружение, полностью идентичное текущей серверной инфраструктуре. Таким образом была снижены времязатраты на поддержание одинакового окружения как на локальных машинах разработчиков, так и на проде. Что, в свою очередь, сильно помогало избегать совершенно ненужных проблем, вызываемых самописными локальными кофигурациями каждого разработчика.

    В результате в docker-compose среде были подняты следующие сервисы:

    • web для работы php-fpm приложения;
    • nginx;
    • impproxy и cairosvg (сервисы для работы с изображениями);
    • postgres;
    • redis;
    • elastic-search;
    • trumpet (тот самый сервис для web-сокетов на D).

    С точки зрения разработчиков работа с кодовой базой осталась неизменной — в нужные сервисы она монтировалась из отдельной директории (базовый репозиторий с кодом сайта) в нужные сервисы: public-директория в nginx-сервис, весь код php-приложения в php-fpm-сервис. Из отдельной директории (в которой содержатся все конфиги compose-окружения) в nginx- и php-fpm- сервисы монтируются соответствующие файлы конфигураций. Директории с данными postgres, elasticsearch и redis также монтируются на локальную машину разработчика, чтобы в случае, если все контейнеры придётся пересобрать/удалить, данные в этих сервисах не были потеряны.

    Для работы с логами приложений — также в docker-compose окружении — были подняты сервисы ELK-стека. Раньше часть логов приложений писались в стандартные /var/log/…, логи и эксепшены php-приложений писались в Sentry, и такой вариант «децентрализованного» хранения журналов был крайне неудобен в работе. Теперь же приложения и сервисы были сконфигурированы и доработаны для взаимодействия с ELK-стеком. Оперировать логами стало гораздо проще, у разработчиков появился удобный интерфейс для поиска, фильтрации логов. В дальнейшем (уже в кубике) — можно смотреть логи конкретной версии приложения (например, кронжобы, запущенной позавчера).

    Далее у команды Republic начался небольшой период адаптации. Команде нужно было понять и научиться работать в условиях новой парадигмы разработки, в которой необходимо учитывать следующее:

    1. Приложения становятся stateless, и у них в любой момент могут пропасть данные, поэтому работа с базами данных, сессиями, статичными файлами должна быть построена иначе. PHP-сессии должны храниться централизованно и шариться между всеми инстансами приложения. Это могут продолжать быть файлы, но чаще для этих целей берут redis из-за большего удобства управления. Контейнеры для баз данных должны либо «монтировать в себя» датадиру, либо БД должна быть запущена вне контейнерной инфраструктуры.
    2. Файловое хранилище из порядка 50-60 Гб картинок не должно находиться «внутри веб-приложения». Для таких целей необходимо использовать какое-либо внешнее хранилище, cdn-системы и т.д.
    3. Все приложения (базы данных, аппликейшен-серверы…) теперь являются отдельными «сервисами», и взаимодействие между ними должно конфигурироваться относительно нового пространства имен.

    После того, как команда разработки Republic освоилась с нововведениями, мы начали перевод продовой инфраструктуры издания на Kubernetes.

    А вот и Kubernetes


    На основе построенного для локальной разработки docker-compose окружения мы начали переводить проект в «кубик». Все сервисы, на которых проект построен локально, мы «запаковали в контейнеры»: организовали линейную и понятную процедуру сборки приложений, хранения конфигураций, компилирования статики. С точки зрения разработки — вынесли нужные нам параметры конфигураций в переменные окружения, стали хранить сессии не в файлах, а в редисе. Подняли тестовую среду, где развернули работоспособную версию сайта.

    Так как это бывший монолитный проект, очевидно, что имела место быть жёсткая зависимость между версиями фронтенда и бекенда — соответственно, и деплоились эти два компонента одновременно. Поэтому поды web-приложения мы решили построить таким образом, чтобы в одном поде крутилось сразу два контейнера: php-fpm и nginx.

    Мы построили также автоскейлинг, чтобы web-приложения масштабировались максимум до 12 в пике трафика, поставили определённые liveness/readiness пробы, потому что приложение требует как минимум 2 минуты на запуск (поскольку нужно прогреть кэш, сгенерировать конфиги…)

    Тут же, конечно, нашлись всякие косяки и нюансы. Например: скомпиленная статика была необходима как web-серверу, который её раздавал, так и application-серверу на fpm’е, который где-то на лету генерировал какие-то картинки, где-то прямо кодом отдавал svg. Мы поняли: чтобы два раза не вставать, нужно создать промежуточный build-контейнер и финальную сборку контейнеризировать через multi-stage. Для этого мы создали несколько промежуточных контейнеров, в каждом из которых зависимости подтягиваются отдельно, потом отдельно собирается статика (css и js), и после в два контейнера — в nginx и в fpm— они копируются из промежуточного build-контейнера.

    Стартуем


    Для работы с файлами первой итерацией мы сделали общую директорию, которая синхронизировалась на все рабочие машины. Под словом «синхронизировалась» я тут подразумеваю именно то, о чём с ужасом можно подумать в первую очередь — rsync по кругу. Очевидно неудачное решение. В итоге всё дисковое пространство мы завели на GlusterFS, настроили работу с картинками так, что они всегда были доступны с любой машины и ничего не тормозило. Для взаимодействия наших приложений с системами хранения данных (postgres, elasticsearch, redis) в k8s были созданы ExternalName-сервисы, чтобы в случае, например, срочного переключения на резервную базу данных обновить параметры подключения в одном месте.

    Всю работу с cron’ами вынесли в новые сущности k8s — cronjob, которые умеют запускаться по определённому расписанию.

    В итоге мы получили такую архитектуру:


    Кликабельно

    О трудном


    Это был запуск первой версии, потому что параллельно с полным перестроением инфраструктуры сайт ещё проходил редизайн. Часть сайта собиралась с одними параметрами — для статики и всего остального, а часть — с другими. Там приходилось… как бы помягче сказать… извращаться со всеми этими multistage-контейнерами, копировать данные из них в разном порядке и т.д.

    Также нам пришлось потанцевать с бубнами вокруг CI\CD системы, чтобы научить всё это деплоить и контроллить с разных репозиториев и из разных окружений. Ведь нужен постоянный контроль над версиями приложений, чтобы можно было понять, когда произошёл деплой того или иного сервиса и с какой версии приложения начались те или иные ошибки. Для этого мы наладили правильную систему логирования (а также саму культуру ведения логов) и внедрили ELK. Коллеги научились ставить определённые селекторы, смотреть, какой cron генерирует какие ошибки, как он вообще выполняется, ведь в «кубике» после того, как cron-контейнер выполнился, ты в него больше не попадёшь.

    Но самым сложным для нас было переработать и пересмотреть всю кодовую базу.

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

    Без фейлов никуда


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

    Как справлялась команда девелоперов Republic


    Изменений наша деятельность принесла немало, и мы это понимали. По сути, мы не только перекроили инфраструктуру издания, вместо привычной связки «основной-резервный сервер» внедрив контейнерное решение, которое по мере необходимости подключает дополнительные ресурсы, но и полностью изменили подход к дальнейшей разработке.

    Спустя некоторое время ребята начали понимать, что это не напрямую работа с кодом, а работа с абстрактным приложением. Учитывая процессы CI\CD (построенные на Jenkins), они начали писать тесты, у них появились полноценные dev-stage-prod-окружения, где они могут в реальном времени тестировать новые версии своего приложения, смотреть, где что отваливается, и учиться жить в новом идеальном мире.

    Что получил клиент


    Прежде всего, Republic наконец-то получил контролируемый процесс деплоя! Раньше как происходило: в Republic был ответственный человек, который шёл на сервер, запускал всё вручную, затем собирал статику, проверял руками, что ничего не отвалилось… Сейчас процесс деплоя выстроен так, что разработчики занимаются именно разработкой и не тратят время ни на что другое. Да и у ответственного теперь одна задача — следить за тем, как прошёл релиз в общем.

    После того, как происходит пуш в мастер-ветку, либо автоматически, либо деплоем «по кнопке» (периодически из-за определенных бизнесовых требований автоматический деплой отключается), в бой вступает Jenkins: начинается сборка проекта. Первым делом собираются все docker-контейнеры: в подготовительных контейнерах устанавливаются зависимости (composer, yarn, npm), что позволяет ускорить процесс сборки, если при деплое список необходимых библиотек не изменился; затем собираются контейнеры для php-fpm, nginx, остальных сервисов, в которые, по аналогии с docker-compose окружением, копируются только нужные части кодовой базы. После этого запускаются тесты и, в случае успешного прохождения тестов, происходит пуш образов в приватное хранилище и, собственно, раскатка деплойментов в кубере.

    Благодаря переводу Republic на k8s мы получили архитектуру, использующую кластер из трёх реальных машин, на которых может одновременно «крутиться» до двенадцати копий веб-приложения. При этом система сама, исходя из текущих нагрузок, решает, сколько копий ей нужно прямо сейчас. Мы увели Republic от лотереи «работает – не работает» со статичными основным и резервным сервером и построили для них гибкую систему, готовую к лавинообразному росту нагрузки на сайт.

    В этот момент может возникнуть вопрос «ребята, вы сменили две железки на те же железки, но с виртуализацией, какой выигрыш, вы там вообще в порядке?» И, конечно, он будет закономерен. Но лишь отчасти. По итогу мы получили не просто железки с виртуализацией. Мы получили стабилизированное рабочее окружение, одинаковое как в проде, так и на деве. Окружение, которое управляется централизованно для всех участников проекта. Мы получили механизм сборки всего проекта и выкатки релизов, опять же, единый для всех. Мы получили удобную систему оркестрации проекта. Как только команда Republic заметит, что им в целом перестаёт хватать текущих ресурсов и риски сверхвысоких нагрузок (либо когда уже стряслось и всё легло), они просто берут ещё один сервер, за 10 минут раскатывают на нём роль узла кластера, и оп-оп — всё снова красиво и хорошо. Предыдущая же структура проекта вообще не предполагала такого подхода, там не было ни медленных, ни быстрых решений подобных проблем.

    Во-вторых, появился бесшовный деплой: посетитель либо попадёт на старую версию приложения, либо на новую. А не как раньше, когда контент мог быть новый, а стили старые.
    В итоге, бизнес доволен: всякие новые вещи теперь можно делать быстрее и чаще.
    Суммарно от «а давайте попробуем» до «готово» работа над проектом заняла 2 месяца. Команда с нашей стороны — героический десант в четыре человека + поддержка «базы» на время проверки кода и тестов.

    Что получили пользователи


    А посетители, в принципе, изменений не увидели. Процесс деплоя на стратегии RollingUpdate построен «бесшовным». Выкатывание новой версии сайта НИКАК не задевает пользователей, новая версия сайта, пока не пройдут тесты и liveness/readiness пробы, не будет доступна. Они просто видят, что сайт работает и вроде не собирается падать после публикации крутых статей. Что, в общем-то, и нужно любому проекту.
    ITSumma
    412,88
    Собираем безумных людей и вместе спасаем интернет
    Поделиться публикацией

    Похожие публикации

    Комментарии 57

      0
      сожрав попутно ресурсы всего кластера

      Т.е. ваш десант профессионалов до работы с Republic не знал, что надо лимиты проставлять?
        +3
        Для этого и есть раздел «фейлы»:)

        Конечно знал, как же иначе. Но от кронджобов на тот момент не ожидали такой прыти:) Всё было заранее омониторено, так что никто особо не пострадал.
          +1
          с кронджобами еще немало граблей есть.
          посмотрите и помедитируйте над
          .spec.startingDeadlineSeconds
          .spec.concurrencyPolicy
          .spec.successfulJobsHistoryLimit
          .spec.failedJobsHistoryLimit
        +6

        Меня интересует то, что осталось за кадром.


        1. Куб поверх bare metal?
        2. Как подам назначают ip? Или есть overlay сеть?
        3. Безопасность: докеры с рутом внутри? Egress/ingress/podpolicy/namespaces?
        4. Что с pvc? Хранилище? Это на тех же нодах? А добавлять тогда ещё ноду? Хранилище ведь тоже придется растягивать, иначе привет локальность данных?
        5. Как сделан LB снаружи? Понятно, что если облако, то все круто. А если куб на баре метал (ведь именно так?)? Vrrp? Балансировка по Dns?
        6. Почему не взяли openshift? В нем очень удобно строить пайплайны через встроенный Дженкинс. Ну, и получаете все возможности куба, если нужно.
        7. Как я понял, проект пока не дорос до Истио и сквозного трейсинга запросов (jaeger, например) — нету?
          +2
          Куб поверх bare metal?

          ага

          Как подам назначают ip? Или есть overlay сеть?

          сеть на Calico

          Безопасность: докеры с рутом внутри? Egress/ingress/podpolicy/namespaces?

          сколько всего в одном вопросе собрали) Egress нет, Ingress да, podPolicy нет, неймспейсы да. Внутри контейнеров есть вещи, крутящиеся от рута, да.

          Что с pvc? Хранилище? Это на тех же нодах? А добавлять тогда ещё ноду? Хранилище ведь тоже придется растягивать, иначе привет локальность данных?

          Хранилище на гластере, пока на тех же нодах, да. Придётся, что поделать:) Возможно, в будущем придём к другому варианту с хранилкой.

          Как сделан LB снаружи? Понятно, что если облако, то все круто. А если куб на баре метал (ведь именно так?)? Vrrp? Балансировка по Dns?

          DNS, да

          Почему не взяли openshift? В нем очень удобно строить пайплайны через встроенный Дженкинс. Ну, и получаете все возможности куба, если нужно.

          С кубом больше опыта, банально. Ну а пайплайнами из дженкинса, в целом, без разницы, куда тыкать:)

          Как я понял, проект пока не дорос до Истио и сквозного трейсинга запросов (jaeger, например) — нету?

          Не, не было пока нужды, правильно понимаете
            +1

            По LB и DNS интересно подробнее.
            Смотрите. Речь идёт про веб-сайт, конечными пользователями… являются юзеры (простите, за тавтологию). Не мобильное приложение, десктопное приложение и пр., а именно, что живые люди. Живым людям надо отдать DNS. Единый адрес сайта, независимо от того, какая из год живёт. А здесь могут быть варианты. Либо мы назначаем А запись на некий фиксированный плавающий ip между нодами (vrrp?). Либо нам нужно оперативно править DNS. Либо у нас есть свой LB перед озвученными нодами, но он тогда становится сам точкой отказа. В общем — прошу больше подробностей, вряд ли эта реализация является коммерческой тайной и ноу-хау.


            Второй момент. Сейчас две ноды в кубе. Положим, получается история, что они друг друга не видят. И обе думают, что единственные живые ноды. Как планируете решать? Тем более, что, как я понимаю, новостной сайт подразумевает какое-то состояние, которое должно разделяться (реплицироваться) между нодами — зарегистрированные пользователя, комментарии к статьям и пр. Или этого всего нет и сервис ТОЛЬКО и делает, что отдает предварительно подготовленный контент ?


            И что тогда с CDN, чтобы побыстрее статику отдавать клиентам? Нет его?

              +2
              Либо нам нужно оперативно править DNS

              Именно так, балансировка исключительно днсами в данный момент выполняется.

              Сейчас две ноды в кубе.

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

              состояние в БД, которая подключена внешним сервисом, что тоже отмечено на схеме.
              И что тогда с CDN, чтобы побыстрее статику отдавать клиентам? Нет его?

              нет, в данный момент CDN не используется. Но в целом, при выкатке нового релиза ничего не мешает статике так же компилить и заливать в CDN, в целом.
                0
                Получается DB является «бутылочным горлышком» системы? Если не секрет, как планируете решать? Или считается, что DB никогда не упадёт/перенагрузится?
                  0
                  Даа, пока основным камнем преткновения, если что, будет база. Не секрет, прямо сейчас никак не планируем решать, запас мощности сильно достаточный, есть резервирование. Но в целом да, это будет ещё отдельная головная боль.
                  0
                  Почему не поставите ucarp?
                  +1
                  >А здесь могут быть варианты. Либо мы назначаем А запись на некий фиксированный плавающий ip между нодами (vrrp?).

                  Можно сделать две-три А-записи для нескольких IP, по крайней мере, браузеры понимают, что если один IP-адрес недоступен, нужно пойти на второй (или на третий).

                  nslookup также показывает все адреса.
                    0
                    Понимать-то понимают, но запрос уже может быть потерян. Т.е. условно у Вас пул из 5 IP и вы создаете 5 A записей на них. Один хост падает. Итог — в среднем теряется 1/5 всех запросов. Безвозвратно. В случае, если клиент приложение, а не браузер клиента — ок, можем сделать ретрай. А если нет?
                      0
                      А если хост падает, разве можно как-то «сохранить» уже отправленный ему по http(s) запрос?
                        0
                        Отправленный — нет, конечно. Но речь про то, чтобы последующие запросы попадали в правильные места.
                        «Правильные» http-клиенты тупо при нескольких A записях шлют запросы по раунд-робину. И я уж не говорю про те случаи, когда пользователь сидит дома за роутером и вопрос — сколько уровней кэша у его ДНСа? Это я к «править ДНС вручную при отказе узла» (даже если TTL маленький).
                          0
                          Мы делали эксперимент на swarm с тремя нодами, traefik в качестве reverse proxy. Одну ноду останавливаем, после этого один раз chrome (который браузер) кашляет (не всегда), далее работает нормально.
                      –1
                      Или поставить ucarp, убив на установку, осознание и настройку полчаса.
                        0
                        Расскажите кратко, пожалуйста, чем ucarp примечателен в отличие от pacemaker, например.
                          0
                          Это поддержка виртуального IP на нескольких серверах с переопределением ролей в зависимости от выставленного приоритета и доступности сервера.
                            0
                            Ну, как бы Вы ничего нового не сказали. keepalived/pacemaker решают абсолютно ту же задачу.
                +2
                А чем куб разворачиваете? Kubspray'ем?
                  +2
                  Да, ещё отдельный вопрос. Наличие куба отчасти заменяет необходимость тащить scm для управления целевыми серверами. Ну, тем более scm на два сервера — оверкилл, проще ансиблом тогда описать среду )
                  Но вот сам куб предполагает подготовку ноды. А у вас там ещё гластер, БД и прочее. Что нужно для начала бутстрвппить, а потом поддерживать. Вот и интересно, что сделано для этого.
                    0
                    Для куба у нас есть пучок готовых плейбуков ансибловых, поэтому докидывать новые выч.мощности можно очень быстро. БД отдельным внешним сервисом сделана, про неё в ветке выше отметил. Гластер пока руками, если что, менеджерить придётся, да.
                      +2
                      А что мешало им всю оркестрацию на Ansible тогда сделать? Получилось бы тоже самое, но с большей производительностью (если bare-metal активнее использовать) и переезд в «облако» будет гораздо дешевле в будущем (например, на OpenStack или AWS). Притом не было бы такого лютого vendor-lock на k8s.
                  +3
                  Благодаря переводу Republic на k8s мы получили архитектуру, использующую кластер из трёх реальных машин, на которых может одновременно «крутиться» до двенадцати копий веб-приложения. При этом система сама, исходя из текущих нагрузок, решает, сколько копий ей нужно прямо сейчас

                  Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?

                  Ведь в «кубике» после того, как cron-контейнер выполнился, ты в него больше не попадёшь.

                  Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.
                    0
                    Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?

                    Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности
                    Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.

                    Собственно, всем. Для кронджобов есть отдельная инфраструктура проверок, перезапусков и прочего, в рамках самого k8s. Нет нужды залезать внутрь самого контейнера вообще. Для управления периодическими задачами в кластере сильно удобнее, чем вылавливать, где там запустился обычный контейнер, ходить в него, что-то там внутри самому проверять и пр.
                      +3
                      Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности


                      Честно говоря, не уловил. Вот, например, вариант 1. Запускаем сразу двенадцать копий, сразу резервируем им память, и уверены, что в случае чего, они не подведут. По телеметрии смотрим загрузку, ее динамику и так далее. Т.е. как раз понимаем реальное потребление.

                      Теперь вариант 2. Запускаем четыре копии, на пике — двенадцать. Памяти-то хватит на пике? Непонятно. Какие конкретно преимущества имеет этот вариант по пониманию реального потребления?
                        0
                        В первом варианте потребление ресурсов неявное. 12 запущенных контейнеров, половина из которых простаивает, потребляют ресурсов больше, чем 6 запущенных и активно работающих, но меньше, чем 12 активно работающих. Вот я о чём. И для большей точности данных мы бы предложили не плодить висящие контейнеры.
                          0
                          12 запущенных контейнеров, половина из которых простаивает, потребляют ресурсов больше, чем 6 запущенных и активно работающих, но меньше, чем 12 активно работающих.


                          Это понятно. Но сэкономленные ресурсы все равно нельзя использовать в другом месте — иначе будет трудно запустить 12 контейнеров, когда наступит время и придут миллионы читателей.

                          К чему тогда экономия, раз она ставит по удар функционирование системы на пике нагрузки? Запустил 12 контейнеров, и все. Если остались ресурсы — можно еще что-то запустить на постоянной основе. Смысл масштабирования в рассматриваемом примере неясен.
                            0
                            Но сэкономленные ресурсы все равно нельзя использовать в другом месте

                            Всё так, да. В идеале подобный подход был придуман под облака, когда машины можно брать мгновенно у того же хостера за почасовую оплату. И когда у вас дикий пик х100, то вы красивый выезжаете на белом коне, заплатив чуть больше обычного месячного прайса. GKE, Heroku, вот это про них про всех.

                            Но пока что их месячный прайс оказывается уж слишком неприятным в сравнении с покупкой железок и определённой вознёй с простаиванием/наращиванием мощностей.

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


                              Как говорилось в «Лачуге должника» — благ-за-ин!
                                0
                                Можно ссылочку на упомянутый материал?
                                Я, видимо, что-то в этой жизни пропустил ))))
                                  0
                                  Это Вадим Шефнер, советская фантастика.

                                  Тынц
                                  — Павел Васильевич Белобрысов,- отрекомендовался мой странный сосед.-
                                  Родился в Ленинграде в две тысячи сто седьмом году.- Произнеся это, он
                                  почему-то покосился в мою сторону.- Имею много специальностей, которые
                                  могут пригодиться где угодно. Здоровье — двенадцать баллов с гаком.
                                  — Не все понял я, уважаемый Павел Васильевич,- почтительно произнес
                                  секретарь.- Что вы имеете честь подразумевать под словом «гак»?
                                  — Гак — металлический крюк на древних кораблях, служивший для подъема
                                  грузов и шлюпок,- пояснил я элмеху.
                                  — Благ-за-ин! — поклонился мне элмех. Затем, обернувшись к Белобрысову,
                                  спросил: — Значит, могу зафиксировать и доложить Терентьеву я, что вы
                                  можете заменить собой металлический крюк и персонально осуществлять
                                  передвижение тяжелых предметов?
                                  — Да нет, это дядя шутит… Вернее, я шучу,- пробурчал Белобрысов.


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

                                А если не секрет, что за сервера используются в варианте bare-metal-а?
                                Просто если учесть стоимость работ по обслуживанию, простоям из-за сбоев и всякие особенности контрактов на свое железо, а так же невозможность масштабирования не должно очень большой разницы получаться, особенно со stateless приложениями, где можно preemptible/spot nodes использовать и прочие трики.
                                  0
                                  Интересно, в каком сценарии можно использовать spot nodes, кроме каких-то распределенных вычислений? Кэширование статического контента?
                                    0
                                    Да почти во всех, где надо много емкости на некоторое время и есть устойчивость к перезапускам отдельных элементов, или хочется экономить (а кому не хочется) и архитектура позволяет.
                                    То есть от обработки пользовательских запросов nginx-ом до бигдаты, да.
                                    Не рекомендуется только для баз по понятным причинам, но с исключениями — можно даже ClickHouse какой нибудь поверх этого крутить, если юзкейс поволяет. По крайней мере частично, что уже даст ощутимую экономию средств.
                                    На самом деле очень много систем и проектов живут на спотах в AWS, потому что выгодно. Некоторые кейсы можно найти допустим тут. Сходу — Yelp вот пользуется и радуется, вот их доклад на сайте Mesosphere.
                                    У меня самого почти все машинки на проектах — это spot/preemptible (чаще второе, потому что почти все в GKE) и практически все, что касается разработки на них, включая Jenkins и Gitlab (за исключением непосредственно gitaly, т.к. он пока не умеет в HA) и все энвайременты продуктов (там конечно не все ноды preemptibe, но большинство).
                                +1
                                Смысл масштабирования в рассматриваемом примере неясен.

                                Согласен с вами, тоже почитал и не очень понял зачем. HPA без автоскейлинга на уровне нод весьма бесполезны. Есть конечно исключения, можно к примеру сделать кастомный scheduler и что-то вроде контроллера и реализовать что-то вроде вытеснения некритичной нагрузки в момент пиков в пользу критичной, но тут явно не тот случай.
                        –1
                        -
                          +2
                          Я не вижу какой CI/CD pipeline tool используется?

                          Сколько по времени занял проект?

                          А вообще, когда понимаешь о чем все это, то это конечно классический пример.
                          Думаю если это взлетело, вы можете гордиться что обратили в новую веру обучили еще одну команду современным методам разработки, доставки и мониторинга веб приложений. Это важно. Надеюсь все разрабочики клиента сказали вам за это спасибо.
                            +2
                            Сори, увидел Jenkins.
                            +1
                            Нифига себе небольшой период адаптации! Очень ценно, что Вы описали необходимые архитектурные изменения, но они в большинестве, как мне кажется, случаев подобных систем, потребуют той или иной степени кардинальных массовых и глубоких переделок!
                              +5
                              Не понимаю два момента. Какой все же RPS потребовал всей этой инфраструктуры, и второй — как я понимаю — сайт новостной, 99% нагрузки мог бы забрать CDN. Как это «впаривали» нетехническому руководству? Судя по данным там в день 75к хитов с 31к посетителей — выглядит как откровенная стрельба из пушки по воробьям.
                                +1
                                Согласен, что чистые выгоды не очень большие и не связанны напрямую с К8.

                                Но внедрить нормальный CI/CD pipeline и просто переучить команду думать на «современный лад» это все равно вполне достойный побочный эффект.

                                Плюс я так понял им внедрили мониторинг всего этого зоопарка на базе ELK — это тоже весьма ценный бонус.
                                  +3
                                  У меня такое чувство, что это не ресурс, а полигон для тестирования. Вебсокеты на D, K8s на такой нагрузке, ELK — помилуйте, там вообще CTO адекватный есть? И при чем здесь хайлоад?
                                    0
                                    И при чем здесь хайлоад?

                                    По-моему, ни я ни автор не упоминали хайлоад. Поэтому вопрос не очень понятен.
                                      0
                                      статья в хабе «Высокая производительность»
                                        0
                                        Понятно
                                      0
                                      Вебсокеты на D — наследие старины глубокой, ещё предыдущим поколением разрабов было притащено:)

                                      А вот что не так с ELK, не вполне понимаю, если честно. Как бы вы предложили агрегировать логи со всех этих подов?
                                      0
                                      мониторинг всего этого зоопарка на базе ELK

                                      мониторинг на ELK? Ну-ну.
                                      Вы имели в виду может быть сбор логов и алертинг, если какие-то определенные сообщения попадают в логи?
                                      или «ёлка» под метрики тоже?
                                        0
                                        dzsysop нене, ребят, вы чего. Ёлка для сбора и анализа логов только. Мониторинг там вообще отдельно идёт наш собственный.
                                    +7

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


                                    Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…


                                    Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого "раз и подкинули сервер" пропагандируете?
                                    Для идиотов?

                                      0
                                      Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…

                                      Как это ничего не сказано? Сразу в нескольких местах:

                                      нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.


                                      Мы получили удобную систему оркестрации проекта. Как только команда Republic заметит, что им в целом перестаёт хватать текущих ресурсов и риски сверхвысоких нагрузок (либо когда уже стряслось и всё легло), они просто берут ещё один сервер, за 10 минут раскатывают на нём роль узла кластера, и оп-оп — всё снова красиво и хорошо. Предыдущая же структура проекта вообще не предполагала такого подхода, там не было ни медленных, ни быстрых решений подобных проблем.

                                      и даже отдельно в комментариях обсудили компромисс между полноценными облаками и собственным кубом на железках
                                        +1
                                        Ок, допустим будем считать что сказано.

                                        Но смотрите.
                                        Оркестрация помогает и нужна тогда, когда имеется ряд повторяющихся (!) действий с инфраструктурой, который требует большого количества усилий технических специалистов.
                                        Например, каждый деплой занимает человеко-дни, а хотелось бы минуты или в крайнем случае часы с учетом подготовки.
                                        Добавление нового сервера — боль.
                                        И т.д. и т.п.
                                        И занимается этим всем штат в Н человек.

                                        Что же мы видим:
                                        • Что у вас есть? У вас есть on premise решение на фиксированном и маленьком (!) числе серверов.
                                        • Какие проблемы и сложности вы испытывали? Нагрузка. Об остальном ни слова
                                        • Сколько типов различных нагрузок у вас есть? Скорее всего ровно 3 — посетители, обновление контента, какая-нибудь статистика.
                                        • Какое поле для маневра имеется? А никакого. Вы не можете отрезать мощности, например, от расчета статистики в тот момент когда она у вас не считается… Все что вы можете это подстраивать обновление и статистику под основную нагрузку которую вам создают пользователи.


                                        Вам точно тут прямо кровь из носу нужна оркестрация ценой 8 человеко-месяцев (это без учета усилий команды)?
                                        И ваши специалисты стоят явно не дешевле типового мидла на фултайм, верно?

                                        Так что мы имеем в итоге?
                                        Какую техническую проблему вы решили?
                                        А какую проблему бизнеса?

                                        P.S. чисто для справки CDN снижает до 90% нагрузку на типичный новостной сайт/блог.
                                        Заводится за пару дней усилиями 1.5 землекопов
                                        А это означает что в общем случае существовавшего решения продукту хватило бы еще на годы с учетом развития (если там действительно 75к хитов в сутки)
                                          0
                                          aghast 4umak
                                          impproxy

                                          imgproxy?
                                          Fortop
                                          согласен, что я из статьи не понял — у кого был запрос на частые изменения.
                                          Сколько в команде Republic разработчиков. По моим оценкам это должно быть отдел из 5-10 разработчиков минимум, чтобы была выгода от k8s. Ну, понятно, что еще изменения могут быть из серии: утром поменяли конфиг nginx, пересобрали образы, перезапустили контейнеры, а вечером все сделали в обратном порядке (у нас же теперь конфигурация = часть образа?), но такое себе.
                                          обновление контента

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

                                          Плюс переезда на k8s я вижу хотя бы в том, что парни смогут масштабироваться в публичное облако, если им не будет хватать ресурсов, но для этого все остальные части системы должны быть для этого подготовлены (файловое хранилище, LB и пр.)
                                        0
                                        Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого «раз и подкинули сервер» пропагандируете?
                                        Для идиотов?

                                        Я бы не стал, конечно, так резко развешивать ярлыки, но если ваш хостер ставит вам сервера по нескольку недель, то, возможно, стоит о чём-то в жизни задуматься.
                                        +1
                                        Мне кажется, или все то же самое можно было бы сделать на чистом compose и с consul для dns lb, к примеру. Даже с учетом переезда в облака и автоскейлинга в них.
                                        Есть ли какой-либо дополнительный профит от усложнения системы сборкой k8s и виртуальными сетями?
                                          0
                                          compose — какой? Мне очень не нравится, что это слово используется к делу и не к делу в разных (совершенно разных) продуктах. Предполагаю, что речь про docker-compose — ну, так его так и называйте. Ну, и он все-таки не для production-использования. Понятно, что можно деплоить прод и через scp. Так же можно использовать и docker-compose «в проде». Но основное его применение — для тестов и для разработки.
                                          Consul — да, неплохая идея ) Но все-таки тут нужно хорошо подумать про механизм LB.
                                          0
                                          Статьи — это статика, комментарии обычно сторонние подключены, и большая часть пришедших, прочитав статью, сайт закроет. Почему обычная cdn с этим не справится?

                                          UPD. Не заметил комментарий выше. В общем, мне это напомнило статью о том, что mongoDB не справлялся с нагрузкой Guardian (что очень сомнительно).

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое