Метод масштабирования TCP-серверов, как правило, очевиден. Начни с одного процесса, когда будет нужно — просто добавь ещё. Так делают многие приложения, включая HTTP-серверы типа Apache, NGINX или Lighttpd.
Увеличение количества обслуживающих процессов это отличный метод решения проблемы использования всего одного ядра CPU, правда, ценой возникновения других проблем.
Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!
Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.
Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.
Все мы отлично знаем, как это бывает: сначала вы заинтересовываетесь этой новой замечательной штукой, начинаете ей пользоваться, а затем начинаются неприятности.
Цель: Предоставить инструкцию по сборке динамического модуля, дать понимание принципа сборки динамического модуля для Nginx поставленного из репозитория Debian.
Целевая аудитория: Администраторы серверов, продвинутые администраторы сайтов, сео-оптимизаторы и просто те кто хочет добиться хорошей оценки от сервиса Google PageSpeed.
Статей на эту тему не мало в поиске светится, но на мой взгляд ни одна не раскрыта как надо. Да и нет толковых пояснений. Для не опытного юзера это может оказаться сложным, да и большая часть статей поясняет как собирать Nginx вместе с модулем, и только единицы показывают что можно собрать динамический.
План действий такой:
1. Арендуем vps на час.
2. Собираем на арендованной vps динамический модуль на той же самой версии Nginx что была использована на боевом (это ВАЖНО!!!. Поддержка динамических модулей у Nginx появилась с версии 1.9.11).
3. Перекидываем модуль на новый сервер.
4. Конфигурируем Nginx.
5. Применяем настройки.
6. Замораживаем версию Nginx (Если это не сделать, то при ближайшем обновлении Nginx, произойдёт падение сервера. Причина в том что скомпилированный модуль будет работать только с конкретной версией Nginx. Если захотите обновиться, скомпилируете модуль для новой версии и обновитесь).
Или следим за тем что обновляем и своевременно добавляем новый собранный модуль.
Преимущество в том что боевой сервер не подвергается изменению и если Вам к примеру не понравится ngx_pagespeed, то вы просто уберёте строчки конфигурирующие его и сам модуль. Ну и если Вы используете несколько серверов с Nginx Вы можете один раз скомпилировать модуль для них всех.
Читать полностью »
В статье описана первичная настройка сервера. Описанные действия, проводились на виртуальной машине Vagrant и VPS.
Установим Nginx последней стабильной версии (на данный момент 1.12.1).
Для настройки репозитория нужно добавить в конец файла /etc/apt/sources.list пару строк.
Открываем файл sources.list для редактирования
sudo nano /etc/apt/sources.listДописываем в конец файла строки:
deb http://nginx.org/packages/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/ubuntu/ xenial nginx
Где xenial – кодовое имя дистрибутива Ubuntu (16.04 – это xenial).
Сохраняем и закрываем файл.
Для проверки подлинности подписи репозитория nginx необходимо добавить ключ, которым были подписаны пакеты и репозиторий, в связку ключей программы apt.
Читать полностью »
Я перфекционист который любит во всём порядок. Больше всего меня радует когда вещи работают именно так, как они должны работать (в моём, разумеется, понимании). А ещё у меня уже давно есть своё персональное интернет-радио на базе IceCast-KH + LiquidSoap. И много лет мне не давал спокойно спать тот факт, что сервера потокового радиовещания не умеют отдавать обложки (artwork) проигрываемых треков в потоке. Да и не только в потоке — вообще никак не умеют. Я и на IceCast-KH (форк от IceCast2) перешёл только из-за одной его убер-фичи — он умеет отдавать mp3-тэги внутри flv потока (это нужно для отображения исполняемого трека при онлайн воспроизведении на сайте через флэш-плеер). И теперь пришло время закрыть последний вопрос — отдачу обложек проигрываемых треков — и успокоиться. Поскольку готовых решений не нашлось, я не придумал ничего лучше, чем написать свой сервер обложек для .mp3 файлов. Как? Добро пожаловать под кат.
Читать полностью »
Кратко: nginx не умеет пулить websockets, а php работает per request. Нужна прослойка которая будет держать открытыми вебсокеты и при поступлении данных соединяться с php (через тот же fastcgi) и отправлять обратно ответ.
Тема, как оказалось, не нова, исходники тянуться аж из 2014, но, тем не менее, информации о трюке, про который здесь пойдёт речь, крайне мало. Можете погуглить "websockets php". Усугубляется тема ещё тем, что найденные примеры реализации (два, точнее) не работают, включая тот, что в документации :)
Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.
Итак, начнём.
При внедрении DevOps-процесса в компании одним из возможных вариантов хранилища артефактов сборки может стать rpm-репозиторий. По существу — это просто веб-сервер, раздающий определённым образом организованное содержимое. Есть, конечно, коммерческие варианты maven-репозиториев, которые имеют плагины для поддержки rpm, но мы же не ищем лёгких путей?
Написать сервис, который будет принимать готовые rpm-пакеты по протоколу HTTP, парсить их метаданные, раскладывать файлы пакетов по каталогам в соответствии с внутренней структурой репозитория и обновлять метаданные репозитория после обработки очередного пакета. Что из этого получилось — описано под катом.
Начиная с момента появления Nginx в 2004 году, мы все задавались вопросом: когда же на nginx можно будет запускать приложения? Мы запускали PHP в php-fpm и на апаче, запускали Python через uWSGI, иногда жили с Apache, а если нам нужны были разные версии PHP — жили с зоопарком из FPM-ов.
Только что на конференции NginxConf в Портленде Nginx, Inc. объявил о запуске Nginx Application Platform. ITSumma тестировала один из его компонентов, собственно сам Application Server под названием Nginx Unit с закрытой версии. В этом посте мы расскажем о том, как выглядит Nginx Unit, и как на нем запускать приложения.
Читать полностью »
Компания Mail.Ru предложила интересный чемпионат для backend-разработчиков: HighLoad Cup. Который позволяет не только получить хорошие призы, но и поднять свой скилл backend-разработчика. Об опыте разработки и настройки окружения будет рассказано под катом.
Читать полностью »