Перезд разных сайтов к одному провайдеру. Организация инфраструктуры?

Question

[Илья]

Контора, где я начал работать, выкупила несколько фирм. Географически фирмы находятся далеко друг от друга. У каждой из этих фирм есть свой сайт, которые хостятся у разных провайдеров. Всего пока 4 сайта, на разных CMS (Wordpress, Joomla). Мудрое руководство решило, что нужно мигрировать все сайты к местному региональному провайдеру и чтобы всё это управлялось через Plesk. Местный провайдер уже предоставил сервер и мощности.
Я тот счастливчик, который должен понять и провести весь процесс, вся темя для меня новая.
К сожалению просто позвонить провайдеру и сказать чтобы он перетащил все сайты к себе - не вариант. Работа организована так, что IT отдел моей конторы много делает сам.

Вопросы (далеко не все):
1. С чего нужно начинать, чтобы подготовить сайт(ы) к переезду?
2. Что нужно подготовить на новом пустом сервере?
3. Нужен ли для каждого сайта (их четыре) свой виртуальный сервер (VM)? Или как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?
5. ... какие советы дадите, что еще может всплыть?

Спасибо.

Comments

[Илья]

Если это VDS/DS, то гуглим, если это shared хостинг, то "создать сайты"

Я бы очень хотел просто нажать кнопочку "Создать сайт" и креативить в Вордпресс.

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

Попробую зайти с другой стороны, как я себе это представляю.

На 4 сайта и Plesk выделено 100Gb памяти, исходим из того, что сервер достаточно мощный, чтобы это всё тащить. Посещаемость всех четырех сайтов невелика, так что какой-нибудь Load Balancer не требуется.

Один из наших админов поднимает у провайдера VM со стандартным стеком - Linux, Apache, MariaDB, PHP.

Далее ?:
- я устанавливаю вордпресс на VM и импортирую бекапы и БД действующего сайта?
- затаскиваю "новый" сайт в Plesk, проверяю на функциональность. Всё это в режиме разработки, старый сайт еще действует.
- Если всё нормально, то говорю провайдеру перетащить доменное имя к себе и "связать" переехавший домен с новой файловой структурой и БД.

P.S. вышеназванное может и глупо звучит, по другому пока не могу

Answer 1

[Михаил Р.]

Всего пока 4 сайта, на разных CMS (Wordpress, Joomla).

1. С чего нужно начинать, чтобы подготовить сайт(ы) к переезду?

Любой хостинг (shared с поддержкой MySQL и PHP) или VDS/DS.

2. Что нужно подготовить на новом пустом сервере?

Что такое "пустой сервер"? Если это VDS/DS, то гуглим, если это shared хостинг, то "создать сайты" (так обычно называется манипуляция у хостера, которая регистрирует место для расположения файлов для сайта) и MySQL БД для сайтов.

3. Нужен ли для каждого сайта (их четыре) свой виртуальный сервер (VM)?

Не нужен.

Или как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?

Падение хостера достаточно редкое явление, чаще происходит дедос, который как раз и блокирует доступ к сайтам. Если критически важно, чтобы одновременно не легли все сайты, то нужны физически разные сервера и возможно, у разных хостеров.

5. ... какие советы дадите

Задавать более конкретные вопросы.

Answer 2

[VoidVolker]

Алгоритм примерно следующий:

1. Изучить возможности создания бэкапов, предоставляемые хостерами на всех сайтах
   
2. Сделать бэкапы сайтов и БД как возможностями хостеров, так и отдельно таким образом, чтобы в случае чего можно было все восстановить
   
3. Изучить настройки DNS и SSL для каждого сайта, а так же настройки регистраторов доменов этих сайтов
   
4. Изучить структуру, механизмы работы и настройки каждого сайта, а так же какие там используются утилиты, средства, зависимости, веб-серверы и их настройки, БД и всё прочее
   
5. Сформировать требования к серверам или серверу для размещения сайтов (диски, памяти, процессоры, порты, ОС, ПО и прочее)
   
6. Для каждого сайта подготовить список необходимого ему ПО и настроить образ для докера (просто потому что у разных сайтов могут быть требования к разным версиям одного и того же или могут быть конфликты, в случае размещения на одном сервере)
   
7. Подготовить систему развертывания сайтов из их репозиториев (напоминаю, что весь исходный код сайтов должен быть размещен в соответствующих репозиториях и минимально задокментирован, а так же настроена система автоматического тестирования)
   
8. На основе требований подготовить оборудование - сервер, ОС, ПО, административные инструменты типа мониторинга (заббикс - топ), систему бэкапов и прочее
   
9. Провести развертывание сайтов с нуля на новом сервере/серверах и проверить, что все работает как надо
   
10. Провести дополнительные работы над ошибками и недостатками, а так же исправить обнаруженные недоработки
    
11. Добавить сайты, БД и всё остальное в систему мониторинга
    
12. Подготовить и протестировать скрипты синхронизации БД и дополнительных данных на новые серверы
    
13. Подготовить перенос доменов сайтов с разных регистраторов к одному регистратору
    
14. Провести перенос доменов к одному регистратору и убедиться, что всё работает как надо
    
15. Для каждого сайта:
    
    1. В нерабочее время перевести сайт в режим обслуживания либо полностью остановить веб-сервер и вывести заглушку, что сервер в обслуживании
       
    2. Провести синхронизацию БД и всего остального нужного
       
    3. Проверить, что на новом сервере сайт полностью работающий и провести все требуемые тесты
       
    4. Привязать новый сервер к домену
       
    5. Настроить letsencrypt сертификат
       
    
    
    

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

Или как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?

Автоматизацией развёртывания и всего остального по максимуму, а так же дублирование серверов в другом ЦОД, хостинге, городе, регионе, континенте - по бюджету и требованиям.

Comments

[Илья]

Автоматизацией развёртывания и всего остального по максимуму, а так же дублирование серверов в другом ЦОД, хостинге, городе, регионе, континенте - по бюджету и требованиям.

Ну не всё так жестко.
Я не представляю каким образом размещать сайты на одном сервере. Допустим сайт рога.com на вордпресс с одной тематикой. И есть сайт копыта.com немного с другой тематикой. Их можно посадить на одну VM?

В целом алгоритм общий и у всех что-то где-то может отличаться.

Спасибо за развернутый ответ, многие пункты для меня еще темный лес.

[VoidVolker]

Илья,

Я не представляю каким образом размещать сайты на одном сервере

Все зависимости сайтов - в докере. Каждый сайт деплоится в отдельный каталог по типу /var/www/site.ru. Веб сервер - nginx, в котором отдельный конфиг для каждого сайта с прокси до контейнеров, в которых работают веб-серверы сайтов и все остальное им потребное. Сервер БД - очень желательно отдельной машиной, в идеале - для каждого сайта своя (для того, чтобы в случае проблем на одном это не влияло на другие). Если нагрузка на сайты небольшая - то можно и на одном сервере разместить.

Answer 3

[Refguser]

5. ... какие советы дадите, что еще может всплыть?

Судя по набору вопросов нужен специалист. Ибо у несведущего много чего может всплыть.
Советы из интернета могут оказаться медвежьей услугой, тк никто не знает реальностей - ни какие сайты ни какие нагрузки ни характеристики серверов ни.. много чего ещё.

Единственное, что можно показать - как правильно переносить ВП-сайты.

Answer 4

[Юрий]

как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?

У разных хостеров, желательно, на разных континентах.

Answer 5

[R3n0]

Привет.

Далее ?:
- я устанавливаю вордпресс на VM и импортирую бекапы и БД действующего сайта?
- затаскиваю "новый" сайт в Plesk, проверяю на функциональность. Всё это в режиме разработки, старый сайт еще действует.
- Если всё нормально, то говорю провайдеру перетащить доменное имя к себе и "связать" переехавший домен с новой файловой структурой и БД.

P.S. вышеназванное может и глупо звучит, по другому пока не могу

Давай упрощать. Тебе даётся, скажем, голый VPS (ОС Debian/Ubuntu), которого хватит с головой для 4 небольших сайтов на WordPress и Joomla. Если тебе нужна ПУ Plesk, то помни, что накатывать её нужно на голый сервер (после apt update), дальше всё будет зависеть от выбранного типа установки. Два популярных: а) автоматический, когда тебе нужно ввести всего одну команду; б) ручной, через браузер. Я бы рекомендовал второй способ, чтобы в процессе не устанавливать ненужные компоненты, которых Plesk предложит тебе с избытком.

После установки ПУ Plesk на сервер озаботься тем, чтобы подготовить пространства под четыре сайта. Разделяй директории, пользователей и БД - всё должно быть отдельно для каждого контролируемого через ПУ сайта. Зачем? Чтобы, например, при взломе одного в нокаут не улетели все остальные. Там же, через настройки, выбираешь версии PHP под сайты, создаёшь и подключаешь сертификаты отLet's Encrypt и прочая подобная рутина по мере необходимости. ПУ Plesk сильно упрощает выполнение всех этих задач.

Если сайты не экзотические, то можешь подготовить полные резервные копии каждого (файлы + дамп БД), затем развернуть эти резервные копии в ПУ Plesk, проверить результат переноса. Процедура обычная, несложная, но требует аккуратности. Затем меняешь настройки DNS для каждого домена, ждёшь, чтобы всё состыковалось, проверяешь итог. Это если кратко.

Нюансы:
- какие-то экзотические расширения PHP - вопрос решается через ПУ Plesk доустановкой нужных расширений;
- домены, зарегистрированные "где-то там", в перспективе тоже придётся переносить под крыло какого-то нашего регистратора, и этим вопросом лучше озаботиться заранее, так как процедура затяжная.

Совет:
- до переноса файлов и дампов БД на новый сервер, проверь их на предмет закладок и лишних пользователей - это убережёт от целого ассорти потенциальных проблем;
- оцени в общих чертах техническое состояние этих четырёх сайтов на предмет: а) свежести движка; б) используемой версии PHP для каждого сайта; в) свежести установленных плагинов (на всех сайтах); г) свежести используемых шаблонов и тем оформления (на всех сайтах).