Как быстро переносить сайты и реконфигурировать вебсервер (Облако как безотказный сервер)?
Сейчас есть несколько довольно дорогих надежных брендовых физ. серверов с гарантией (если что - мастер за сутки приезжает и заменяет диск, например), на них крутятся сотни сайтов. Большая часть сайтов - довольно типовые, похожи друг на друга. Но, важный момент - многие сайты (ecommerce) пишут данные в базу (например, оформляют продажи). бОльшая часть сайтов на делит IP адреса, не на выделенном.
Есть задумка - как-то переехать в облако. Есть уже отчасти неприятный и поучительный опыт с AWS, что даже облачный сервер иногда падает, и просто перенести все туда и забыть о проблемах - не получается. Все равно нужно иметь план на переезд или восстановление. Хочется, чтобы сайты у нас как-то были "запакованы" в какие-то "пакеты" или "контейнеры" и мы могли на другом сервере их быстро запустить (если что-то не так с прежним).
При переезде возникают четыре проблемы:
1. Сменить IP в DNS (окей, своими скриптами я могу это делать через динамический dns)
2. Получить сертификаты LetsEncrypt (окей, тоже можно сделать при старте контейнера)
3. Реконфигурировать вебсервер на хост-машине (чтобы он знал, что появился новый сайт) ??
4. База данных, как ее "таскать".
Вопрос 1
---
Как вариант - докер-контейнеры. Можно быстро перекинуть сайт на другой сервер, запустить там, но надо как-то в апаче на хост машине указать, что example.com надо проксировать на такой-то порт. Вручную это можно сделать, но надо как-то автоматически, быстро и без человеческого фактора. Вряд ли я первый, кто столкнулся с такой задачей. Есть может какой-то вебсервер/модуль или примочка для докера, чтобы при запуске контейнера у нас вебсервер на хост-машине на него начал прокидывать http/https запросы?
Вопрос 2
---
Как быть с базой? Пока что план такой, чтоб все сервера работали не каждый со своей mariadb (так оно сегодня), а с общим сервером баз данных (db.example.com). Мы если что перекидываем вебсайты, но не трогаем сервер БД. Есть ли какие-то альтернативные пути? (немного смущает, что пинг до базы будет гораздо более долгим, чем по локалхосту)
Вопрос 3
---
Ну тут уж совсем размечтался: Сайт у нас крутится на сервере А, этот сервер среди ночи умирает. Автоматом все сайты чтобы как-то запустились на сервере Б, а мы утром только где-то в UI или в почте письмо про это увидели. Для этой мечты есть какое-то готовое решение?
Все что вы перечислили не позволит дать вам какие-либо адекватные рекомендации по тому что нужно делать ассессмент текущей архитектуры, ресурсов, собирать требования к новой системе и уже смотреть в какой Клауд, зачем, для чего, нужно ли делать Hybrid Cloud и так далее
Я согласен, у меня вопрос довольно пространный, от "как обновить конфиг апача при установке докер контейнера" (то что шелл-скриптом можно решить) и до "как все переделать и переехать в облако".
Вообще, сложилось впечатление, что по стоимости ресурсов - AWS штука довольно дорогая, если сравнивать с недорогими VPS хостингами (ну и я замерял бенчмарки - не слишком-то быстрее, хотя ощутимо дороже). Полную отдачу можно получить если каждое приложение/сайт с самого начала под облако разрабатывать?
Правильно ли понимаю, что облачный хостинг особо хорошо работает для компаний-приложений вроде Netflix, когда есть ОДНО свое сложное приложение (под облако), ну или небольшой их набор, и сотни типовых виртуальных серверов. Но не очень хорошо подходит для обратной задачи - когда есть сотни-тысячи простеньких linux/apache/mysql/php сайтов и нужно их надежно хостить? (так как для каждого маленького сайта стоматологического кабинета и автомагазина нужно прорабатывать его облачную архитектуру)
Ярослав Поляков, Не совсем так. Главная проблема в сравнении стоимости это не корректный расчёт TCO. Кладу предоставляют огромное число функционала из коробки, который никто не видит и который очень дорого и долго разрабатывать и настраивать, не говоря уже о поддержке. Если реализовывать своими силами хотябы 90% того что дается просто по умолчанию - уйдут годы у опытных больших команд.
Что касается маленьких магазинов то у них нет причин ехать в облака просто по тому что самые базовые SLA, которые предоставляют облака избыточны для таких проектов. Ну а вообще надо быть сильным специалистом в облаке чтобы знать как и за счет чего там можно сэкономить - большинство сервисов имеет как скрытые косты так и способы сделать дешевле
АртемЪ, ну эту-то проблему я решил :-) Даже на хабре писал. Сайт с котиками работает даже при обесточивании дата-центра. (Сервер не работает, а сайт работает). За каждый час "умирает" два сервера, а сайт не падает.
Если в одном браузере смотреть - то из-за кеширования DNS запросов могут быть задержки, но все равно видно переключение. А если, например, в браузере, и затем в смартфоне и через сотовый интернет - то видно, что реальное переключение занимает секунды.
Правда, там ситуация проще, никакой базы, контент не меняется, ничего синхронизировать не надо, ну и все три сайта заранее подготовлены.
Ярослав Поляков, поэтому вам с Иван Шумов и говорим, что это целая история и вряд ли будет выгодна. От элементарных коллизий избавиться довольно сложно. А всякие репликациии добавят вашим проектам тормозов.
Средний
