Назад | Перейти на главную страницу

Создание стабильного кластера серверов приложений с автоматическим масштабированием

У меня есть два сервера, на каждом из которых работает от 50 до 100 различных устаревших веб-приложений, написанных на разных языках: от PHP до Python, Ruby-on-rails и NodeJS.

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

С этой целью я хочу сделать следующее:

В конце концов, я хочу сделать что-то похожее на то, что Deis или Флинн делать, хотя ни один из них на данный момент не готов к производству.

Честно говоря, я немного ошеломлен всем этим и действительно не знаю, с чего начать. Какие-либо предложения? Стоит ли мне вообще подумать о Passenger? Докер?

Спасибо!

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

  1. С чего мне начать приобретение собственной масштабируемой инфраструктуры PaaS?
  2. Стоит ли мне вообще подумать о Passenger?
  3. Стоит ли мне подумать о Docker?

Сначала я отвечу на номер 3, так как это проще всего. Ответ - да. Если вы собираетесь создавать что-то новое, Docker поможет вам перейти в более портативный мир, что, в свою очередь, поможет вам перейти к более масштабируемой точке. Ваши устаревшие веб-приложения будут работать как собственные контейнеры со своими наборами зависимостей и, таким образом, станут более переносимыми.

Ответ на номер 2 кажется более зависимым от Ruby и приложений Ruby в целом. Вы можете управлять пассажиром? Может быть ... Это больше зависит от того, как было написано приложение и с какими серверами оно могло быть совместимо. Тем не менее, похоже, что Phusion делает все возможное, чтобы быть очень дружелюбным к Docker. У них есть образы Docker специально для запуска приложений Ruby, Python и Node.js, по крайней мере - https://github.com/phusion/passenger-docker.

Мой ответ на первый вопрос - начать с контейнеризации устаревших приложений. Сделайте приложения более совместимыми с двенадцатью факторами (http://12factor.net/), если их еще нет. Сделайте их более ориентированными на обслуживание. Вместо того, чтобы запускать такие вещи, как MySQL, Redis, Apache, PHP-FPM и т.д. в одном контейнере, разделите их на разные службы, которые подключаются друг к другу через TCP и HTTP (ссылки Docker были бы отличным местом для начала - https://docs.docker.com/userguide/dockerlinks/).

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

Если вы еще этого не сделали, ознакомьтесь с материалами, которые появятся немного раньше, чем полноценный Docker PaaS, например https://coreos.com/ или http://www.projectatomic.io/. Что-то вроде этого дает вам возможность планировать свои собственные контейнеры / модули, а не создавать для вас контейнеры приложений. Для обучения в процессе разработки вы можете использовать что-то вроде http://www.fig.sh/ или http://decking.io/. Отлично подходит для локального тестирования ваших новых сервис-ориентированных контейнеров.

Чтобы узнать больше о Docker, следите за https://stackoverflow.com/questions/18285212/how-to-scale-docker-containers-in-production. В верхнем ответе содержится довольно хороший обзор того, что в настоящее время отсутствует, и автор довольно хорошо обновляет его.