Для обеспечения работы всех наших внешних продуктов мы используем популярный nginx. Это быстро и это надежно. Проблем с ним почти нет. Наши продукты также постоянно развиваются, появляются новые сервисы, добавляется новый функционал, расширяется старый. Аудитория и нагрузка только растет. Сейчас мы хотим рассказать о том, как мы ускорили разработку, неплохо увеличили производительность и упростили добавление в наши сервисы этого нового функционала, при этом сохранив доступность и отказоустойчивость затронутых приложений. Речь пойдет о концепции “nginx as web application”.
А именно, о сторонних модулях (в основном LUA), позволяющих делать совершенно магические вещи быстро и надежно.
При большом количестве серверов и виртуальных машин и еще большем количестве кода в постоянном деплое, неизбежно возникают проблемы администрирования всего этого огромного хозяйства. Существует множество инструментов, позволяющих организовать continuous integration. В нашем списке точно уже есть GIT, Jenkins, Chef, Proxmox, Graylog2. Сегодня мы расскажем еще об одном удобном инструменте для автоматизации рутинных задач с помощью сценариев — rundeck. Эта статья — не подробный мануал с примерами конфигов, а скорее размышления на тему.
В своих продуктах мы используем AMQP. Это удобно, это позволяет лучше масштабироваться и позволяет добавлять в сложную систему новые модули и расширения практически без проблем. В качестве брокера используется RabbitMQ. В качестве фронтендов используется Nginx. До недавнего времени мы везде использовали связку php-amqp и librabbitmq-0.0.1 для работы с брокером. Но в некоторых частях системы это нам показалось избыточным.
Существует несколько десятков файловых систем, все из них предоставляют пользовательские интерфейсы для хранения данных. Каждая из систем хороша по-своему. Однако, в наш век высоких нагрузок и петабайтов данных для обработки, оказалось довольно непросто подыскать то, что нужно, стоит лишь задуматься о распределенных данных, распределенных нагрузках, множественном монтировании rw и о прочих кластерных прелестях.
При достаточно большом парке серверов, с тысячами крутящихся на них сервисов, демонов, скриптов, довольно непросто уследить за многочисленными ошибками внутри. Где-то кончилась память, где-то залип демон, где-то база данных ведет себя неадекватно. Уже не раз обсуждались серверы централизованного хранения логов, хочу рассказать еще об одном удобном и мощном инструменте — Graylog2.
После того, как у нас вышли в релиз еще несколько проектов, а количество тикетов в трекере на тему «создать пользователя, развернуть виртуалку, дать доступ» превысило все мыслимые пределы, назрела необходимость что-то менять. Задача: организовать рабочее окружение linux для нескольких команд разработчиков и тестировщиков. Общее количество виртуальных машин — три-четыре десятка.
В минувшие выходные в нашем городе проходила конференция разработчиков CodeFest codefest.ru
Нам посчастливилось быть там в числе организаторов и отвечать за ряд инфраструктурных задач.
Решенные задачи.
организация WiFi доступа в интернет для ~1000 пользователей в четырехэтажном здании,
обеспечение работы всей инфраструктуры: проекторы, презентации, розетки для гостей и прочее,
