Comments 25
Не совсем понял. Большинство людей путается в терминах. Поэтому я начал с них. Хотя бы для того, чтобы понимать, как я их буду применять. Далее идёт достаточно подробное руководство. Что не так?
Когда говорят 9.5 — это всегда "Правил ведения бизнеса в России".
Хотя, я думаю, на хабре это не помешало бы, закрепить где-нибудь.
Рецепт простой:
1) размещаем зону и на cloudflare, и на Яндексе (и ещё где угодно — но только не у регистратора). И ставим ns-ами их вместе.
Логика простая: падает один — отработает другой. Если кто-то начнёт бузить (что большая редкость так-то) — просто выкидываем этот ns у регистратора, и через полчасика всё нормализуется.
2) Не пользуемся shared хостингами, а пакуем всё в контейнеры. Это безопаснее и гораздо переносибельнее. В идеале сайт должен состоять из /var/docker/website/docker-compose.yml, которому делаем up и тут же всё работает вне зависимости от того, что там наверчено в образе впс у конкретного хостера.
3) Чеклист по бэкапам:
- /var/docker/website или где там ваш compose — раз в сутки
- /var/docker/website/persistence или где там ваш persistence — rsync раз в 15 минут к себе в офис
- Бэкапы БД делаются отдельно, тк. простое копирование файлов бд через rsync не обеспечивает консистентности
- /etc хоста — раз в сутки
- Логи контейнеров — лучше дублировать их куда-нибудь
- Бэкап файлов зон DNS — обязательно.
4) Дополнительный чеклист по мониторингу:
- Утекает место на диске из-за логов (в т.ч. логов докера)
- Образы жрут inodes, и не всегда отдают назад
- Логи должны быть не пустыми
- Проверять дату истечения всех сертификатов.
Вроде ничего не забыл.
1001 бесполезный совет :) Более половины веба с ужасом смотрит на "сайт должен состоять из /var/docker/website/docker-compose.yml, которому делаем up и тут же всё работает".
1001 вредный совет. Вы советуете всё повесить на точку отказа — одного специалиста? :)
Хотяяя… Лайк :))) Просто всем следует обратить внимание на пункты 3 и 4 ))))))))))))))
/var/docker/website или где там ваш compose — раз в сутки
/etc хоста — раз в сутки
смысла нет — код сайта в репозитории, настройки хоста в Ansible или чем-то подобном.
хотя все равно shared хостинги для тех кто не умеет в linux, потому что виртуалка всегда дешевле и более гибкая, а для всяких копеечных шаредов замена уровня free-tier от того-же google cloud
Настройки хоста в ансибле не нужны — он один, это усложнение.
В целом у меня есть рецепт, который заменяет именно шаред — с привычными вещами типа фтп-доступа и веб-мордой с пхпмуадмином\бэкапами, доступной через авторизацию сертификатом. Потому что не хотелось снова шаред, но и в администрирование нешареда лезть тоже не хотелось.
Нет, shared в первую очередь для тех, кто не хочет всеми этими пунктами заниматься.
connect.yandex.ru/pdd
Предыдущая версия — pdd.yandex.ru позволяла подтвердить домен при добавлении просто делегированием на сервера Яндекса. Нынешняя версия требует при добавлении для подтверждения владением — уже действующего DNS (прописать TXT запись) или сайта (разместить файлик). Стало резко неудобно :(
В остальном полёт нормальный, но есть шанс, что когда-нибудь станет платным — пошли телодвижения в сторону монетизации. Ну и за бесплатно — никто никому ничего не обязан :)
Как сменить хостинг