Привет!

Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.

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

Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.

История меняется прямо сейчас на ваших глазах!

Меня зовут Юрий, я руководитель группы системного администрирования в Ситимобил. Сегодня поделюсь опытом работы с технологией тонкого резервирования (thin provisioning) файловых систем Linux и расскажу, как ее можно применять в технологических CI/CD-процессах компании. Мы разберем ситуацию, когда для автоматического тестирования кода при доставке его в production нам как можно быстрее необходимы копии БД MySQL, максимально приближенные к «боевой» версии, доступные на чтение и на запись.

Подстрахуй братуху, подстрахуй...

Helmfile — обёртка для helm, которая позволяет в одном месте описывать множество helm релизов, параметризовать их чарты для нескольких окружений, а также задавать порядок их деплоя.

О самом helmfile и примерах его использования можно почитать в readme и best practices guide.

Upd. 10/06/2022: Со временем довёл до ума этот подход и получилось гораздо лучше и удобнее, чем описано в статье. При возможности напишу отдельный пост, а пока с примерами улучшенного варианта можно ознакомиться здесь и здесь.

Мы же познакомимся с неочевидными способами описать релизы в helmfile

Допустим, у нас есть пачка helm-чартов (для примера пусть будет postgres и некое backend приложение) и несколько окружений (несколько kubernetes кластеров, несколько namespace'ов или несколько и того, и другого). Берём helmfile, читаем документацию и начинаем описывать наши окружения и релизы:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml

Введение

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

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

Невозможно полноценно тестировать и отлаживать мобильные приложения без тестовых устройств. Таких устройств должно быть много, потому что один и тот же код на разных моделях ведёт себя по-разному. Но как организовать учёт устройств? Как сделать так, чтобы разработчики и тестировщики быстро и без волокиты получали конкретный смартфон в необходимой конфигурации?

Меня зовут Алексей Лавренюк. Вы можете знать меня как одного из авторов Яндекс.Танка и докладчика на тему нагрузочного тестирования. Потом я измерял энергопотребление мобильных телефонов. Теперь я делаю Яндекс.Ровер в команде беспилотных автомобилей (и иногда подрабатываю Дедом Морозом). А между телефонами и Ровером был Гиперкуб.

Пару лет назад в наш отдел нагрузочного тестирования зашёл руководитель мобильной разработки и пожаловался на ситуацию с тестовыми устройствами. Телефоны кочевали из рук в руки, выбрать и быстро найти телефон было проблемой. У нас уже был опыт работы с мобильными устройствами: мы строили цифровой амперметр, чтобы измерять их энергопотребление. Поэтому мы решили помочь коллегам и быстро сделать классную штуку: казалось, работы всего на три месяца. Смеюсь над собой, наивным, из 2020 года и рассказываю, что нас ждало на самом деле.

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