LINUX.ORG.RU

Собственный облачный полухостинг

 


1

2

Что есть: Около десятка региональных сайтов, работающих на почти одинаковой кодовой базе. Почти - есть мелкие различия в виде разных конфигов, которые включают поддержку разного набора языков, задают разное название сайтам, ну и определяют свою тему каждому. Сайты крутятся на отдельных VPS, расположенных каждый в своём регионе. И эту ситуацию поменять нельзя, т.е. идея «а собери ка ты их в одном облаке» не рассматривается. Почему - не важно. Данность.

Что хочется: Унифицировано это распихать по контейнерам, централизованно управлять, т.е. запихивать на отдельные VPS контейнеры, заставлять там их работать. Мониторить, обновлять, в незначительной степени управлять. Т.е. выкачена бета-фича, которую теперь пора тестировать не в тестовом окружении, а в боевом, - одному или нескольких сайтам задаётся «а вот теперь бери контейнер во с этим тегом».
Ну и главное, чтобы в случае перезагрузки сайт поднимался сам, даже если в этот момент управляющий узел по какой-либо причине будет недоступен.

Вопрос в том - чем бы это таким делать? Желательно в web-gui, потому что не только я, но и ещё пара человек может с этим возиться, а они не очень с командной строкой дружат.
Сложные монстры, которые требуют пол года обучения и 10 человек команды на обслуживание - сразу идут лесом. Так что Kubernetes за бортом.
Смотрел Docker Swarm - вроде он может делать то, что надо, хотя на счёт автоподъёма без главного узла пока не ясно. Но он больше рассчитан на вариант «запустить N экземпляров одного сайта в отказоустойчивом кластере» и эксплуатировать его как мне надо - это натягивать сову на глобус.

По этому вопрос - а есть решения для простых людей с разными сервисами, а не мегакорпораций с одним огромным?

★★★★★

Сложные монстры, которые требуют пол года обучения и 10 человек команды на обслуживание - сразу идут лесом. Так что Kubernetes за бортом.

Насчет 10 человек вы сильно заблуждаетесь. К примеру, в проекте с несколькими доменами, который я сейчас поддерживаю, за весь Kubernetes-кластер (проектирование структуры, администрирование, базовые docker-образы и пр.) отвечает один человек - я :). Среда для локальной разработки на основе docker-compose тоже на мне. Программисты вообще не знают, что такое Kubernetes - просто имеют начальные, базовые представления о контейнерах и все. Их стиль работы абсолютно такой же, как и в случае VPS. Для них весь деплой в тестовое пространство кластера - это ‘git push’ и выполнение еще одной CLI-команды. Так что, 10-ти человек не надо - надо просто найти одного грамотного.

Насчет полугода обучения «с нуля» - это справедливо. Более того, даже после полугода обучения не факт, что человек придумает и развернет что-либо путное и практичное. Мне, например, чтобы обеспечить удобный стиль работы для себя и для программистов, пришлось предварительно разработать соответствующие инструментальные средства.

Если приспичило поддерживать 10 разных VPS-ок, то может быть вот это как-то посодействует и натолкнет на правильный путь:

Хотя вообще идея не очень… и чревата потенциальным геморроем по части администрирования и начального проектирования-конфигурирования. Вам же еще поди потребуется гладкий деплой без отказов в работе приложений.

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)

… когда я сказал выше про одного человека, то я естественно подразумевал использование уже существующей облачной платформы. Работа на собственном «железе» или гольных VPS-ках - +1 человек (админ нижнего уровня).

vinvlad ★★
()

Тема огромная, сомневаюсь, что её можно раскрыть в комментариях полностью.

По паре моментов выскажусь:

  1. Docker Swarm - это как бы предшественник Kubernetes, то есть по функциональному назначению они схожи. Несмотре на то, что Swarm как бы «устарел», я знаю точно (изнутри), что некоторые очень большие проекты на нём работают и сейчас.
  2. Централизованно управлять деплоем можно через GitLab: настроить CI/CD, можно сделать кнопочки, чтобы любую версию или ветку можно было деплоить на любой тестовый сервер, а релизные - на препрод или прод (ес-но, только в том случае, если проходят все тесты).

Сделать всё в одном комбайне: чтобы и деплоить и мониторить можно было из одного места - мне такие комбайны неизвестны, может быть, просто потому что не интересовался. Обычно всё строится из нескольких частей: мониторинг, скажем, состоит из Sentry, Prometheus, Grafana.

emorozov
()

Я бы nix настроил. Конфиги можно по cron проверять ну и подкачивать обновление когда оно есть. (То есть на каждом сервере разворачиваешь одну и ту же репу, там все написано, по крон она просто подтягивается и билдится.)

zerhud
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.