СберИндекс — статистика, которой нам не хватало.
Часть 3/3: про инфраструктуру
#release #sber #devops #docker #swarm #gluster
Мы уже рассказали про фишки frontend и backend реализации проекта «СберИндекс».
Где все это работает? 🤔 Конечно же, в SberCloud.
Мы подготовили автоматизированную сборку необходимых сервисов в Docker-образы, которые в промышленной инфраструктуре разворачиваются и масштабируются в режиме Docker Swarm.
Для работы продукта предусмотрен Swarm-стек.
Frontend-приложение состоит из двух сервисов:
— nginx-proxy-frontend. Строится на образе Nginx и работает как http-прокси перед контейнером с основным приложением на Node.js.
— frontend-app. Сервис основного приложения клиентской части на Next.js. Обрабатывает http-запросы от nginx-proxy-frontend и взаимодействует с backend-сервисом nginx-fastcgi-api по RESTful API.
Backend-приложение содержит следующие сервисы:
— nginx-fastcgi-api. Работает в режиме fastcgi-прокси для php-fpm-сервиса, отвечающего за RESTful API для клиентского приложения. Основывается на образе Nginx.
—nginx-fastcgi-admin. Отвечает за взаимодействие с сервисом административной панели по протоколу fastcgi. Основывается на образе Nginx.
— backend-app. Сервис основного php-приложения на Yii, предоставляющий fastcgi-интерфейсы с административной панелью и RESTful API. Основан на кастомизированном образе php-fpm.
— queue-app. Отдельный сервис с очередью, реализующий обработку фоновых процессов импорта данных. Основан на php-fpm-образе и использует функциональность Yii для работы с очередями.
Конечно, при сборке каждого образа мы добавляли необходимые дополнительные пакеты и библиотеки. Например, расширения для PHP и конфигурационные файлы для Nginx.
Все сервисы стека описаны в
Стоит отметить, что Redis и СУБД MariaDB не контейнеризированы и развернуты как отдельные инстансы в инфраструктуре SberCloud с учетом репликации и масштабирования.
Управлением общими файловыми ресурсами, которые монтируются к виртуальным машинам в качестве подключаемых томов для Docker-контейнеров, занимается распределенная файловая система GlusterFS.
Одна из важных составляющих качественного продукта — грамотная система менеджмента и постановки задач со стороны клиента. Мы рады, что работаем в тесном симбиозе с командой Сбера и делаем продукты такого уровня.
Спасибо, Сбер 🎉
Chulakov Dev
Часть 3/3: про инфраструктуру
#release #sber #devops #docker #swarm #gluster
Мы уже рассказали про фишки frontend и backend реализации проекта «СберИндекс».
Где все это работает? 🤔 Конечно же, в SberCloud.
Мы подготовили автоматизированную сборку необходимых сервисов в Docker-образы, которые в промышленной инфраструктуре разворачиваются и масштабируются в режиме Docker Swarm.
Для работы продукта предусмотрен Swarm-стек.
Frontend-приложение состоит из двух сервисов:
— nginx-proxy-frontend. Строится на образе Nginx и работает как http-прокси перед контейнером с основным приложением на Node.js.
— frontend-app. Сервис основного приложения клиентской части на Next.js. Обрабатывает http-запросы от nginx-proxy-frontend и взаимодействует с backend-сервисом nginx-fastcgi-api по RESTful API.
Backend-приложение содержит следующие сервисы:
— nginx-fastcgi-api. Работает в режиме fastcgi-прокси для php-fpm-сервиса, отвечающего за RESTful API для клиентского приложения. Основывается на образе Nginx.
—nginx-fastcgi-admin. Отвечает за взаимодействие с сервисом административной панели по протоколу fastcgi. Основывается на образе Nginx.
— backend-app. Сервис основного php-приложения на Yii, предоставляющий fastcgi-интерфейсы с административной панелью и RESTful API. Основан на кастомизированном образе php-fpm.
— queue-app. Отдельный сервис с очередью, реализующий обработку фоновых процессов импорта данных. Основан на php-fpm-образе и использует функциональность Yii для работы с очередями.
Конечно, при сборке каждого образа мы добавляли необходимые дополнительные пакеты и библиотеки. Например, расширения для PHP и конфигурационные файлы для Nginx.
Все сервисы стека описаны в
docker-compose.yml.Стоит отметить, что Redis и СУБД MariaDB не контейнеризированы и развернуты как отдельные инстансы в инфраструктуре SberCloud с учетом репликации и масштабирования.
Управлением общими файловыми ресурсами, которые монтируются к виртуальным машинам в качестве подключаемых томов для Docker-контейнеров, занимается распределенная файловая система GlusterFS.
Одна из важных составляющих качественного продукта — грамотная система менеджмента и постановки задач со стороны клиента. Мы рады, что работаем в тесном симбиозе с командой Сбера и делаем продукты такого уровня.
Спасибо, Сбер 🎉
Chulakov Dev
Nginx: PHP и Node.js под одним доменом
#devops #backend #frontend
Планируя архитектуру веб-сервиса с SPA и RESTful API, мы часто применяем несколько разноуровневых доменных имен. Например, на домене some-site.ru размещаем основное клиентское приложение, а на поддомене api.some-site.ru — backend-приложение с API. Это могут быть два различных веб-сервиса на абсолютно различном стеке.
Рассмотрим, как организовать общую маршрутизацию http-запросов между двумя сервисами под одним доменом. Разделять запросы по сервисам будем с помощью префиксов в части URI. Например, http-запросы, поступающие на адрес some-site.ru/api/some-method-route, будут проксироваться на сервис php-fpm, остальные запросы, без префикса api, будут уходить на upstream c Node.js.
Для решения такой задачи необходимо написать правила для веб-сервера Nginx, который должен выступать в виде fastcgi- и http-прокси-сервера одновременно, а также маршрутизировать соответствующие запросы по двум различным upstream-целям.
Для наглядности и понимания общей архитектуры мы собрали небольшой проект. В директории ci располагаются инструкции по сборке Docker-образов для доставки их, например, на серверы с Docker Swarm.
Отдельного внимания заслуживает файл конфигурации Nginx.
Для того чтобы роутинг и окружение в PHP работали верно, нам необходимо произвести модификацию некоторых fastcgi-параметров, которые впоследствии становятся ключами суперглобального массива
Стоит отметить, что представленный проект лишь демонстрирует возможность объединения разнородных апстримов под одним доменным именем и не несет большой прикладной пользы.
Все исходники проекта располагаются в директории src, внутри которой они делятся на два изолированных типа, которые впоследствии будут собраны в два различных образа — PHP и Node.js. Таким образом, финальная поставка продукта будет состоять из трех образов: Nginx, PHP-FPM и Node.js.
Chulakov Dev
#devops #backend #frontend
Планируя архитектуру веб-сервиса с SPA и RESTful API, мы часто применяем несколько разноуровневых доменных имен. Например, на домене some-site.ru размещаем основное клиентское приложение, а на поддомене api.some-site.ru — backend-приложение с API. Это могут быть два различных веб-сервиса на абсолютно различном стеке.
Рассмотрим, как организовать общую маршрутизацию http-запросов между двумя сервисами под одним доменом. Разделять запросы по сервисам будем с помощью префиксов в части URI. Например, http-запросы, поступающие на адрес some-site.ru/api/some-method-route, будут проксироваться на сервис php-fpm, остальные запросы, без префикса api, будут уходить на upstream c Node.js.
Для решения такой задачи необходимо написать правила для веб-сервера Nginx, который должен выступать в виде fastcgi- и http-прокси-сервера одновременно, а также маршрутизировать соответствующие запросы по двум различным upstream-целям.
Для наглядности и понимания общей архитектуры мы собрали небольшой проект. В директории ci располагаются инструкции по сборке Docker-образов для доставки их, например, на серверы с Docker Swarm.
Отдельного внимания заслуживает файл конфигурации Nginx.
Для того чтобы роутинг и окружение в PHP работали верно, нам необходимо произвести модификацию некоторых fastcgi-параметров, которые впоследствии становятся ключами суперглобального массива
$_SERVER на уровне PHP.Стоит отметить, что представленный проект лишь демонстрирует возможность объединения разнородных апстримов под одним доменным именем и не несет большой прикладной пользы.
Все исходники проекта располагаются в директории src, внутри которой они делятся на два изолированных типа, которые впоследствии будут собраны в два различных образа — PHP и Node.js. Таким образом, финальная поставка продукта будет состоять из трех образов: Nginx, PHP-FPM и Node.js.
Chulakov Dev
💩1
7 важных факторов PHP-приложения
#backend #devops #php
Инженеры платформы Heroku на основе собственного опыта создали методологию для разработки SaaS-приложений.
Эта методология учитывает три важных аспекта:
— расширяемость — развитие кодовой базы и функционала;
— сопровождаемость и возможность командной работы над проектом;
— масштабируемость.
12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.
Кодовая база. Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.
Зависимости. Используйте менеджер зависимостей Composer и его основные операции
Конфигурация. Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv.
Параллелизм. Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ.
Паритет разработки/работы приложения. Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.
Журналирование. Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog или компоненты фреймворков.
Задачи администрирования. Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console. Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения и команды.
Chulakov Dev
#backend #devops #php
Инженеры платформы Heroku на основе собственного опыта создали методологию для разработки SaaS-приложений.
Эта методология учитывает три важных аспекта:
— расширяемость — развитие кодовой базы и функционала;
— сопровождаемость и возможность командной работы над проектом;
— масштабируемость.
12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.
Кодовая база. Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.
Зависимости. Используйте менеджер зависимостей Composer и его основные операции
install и update для манипуляций c composer.json и composer.lock.Конфигурация. Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv.
Параллелизм. Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ.
Паритет разработки/работы приложения. Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.
Журналирование. Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog или компоненты фреймворков.
Задачи администрирования. Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console. Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения и команды.
Chulakov Dev
💩2