Проблемы объектного хранилища, Yandex Cloud и SPA. Почему я ушел с Облака
Опубликовано 24 мар. 2024 г.
У меня есть целая серия статей, посвященная тому, как я ставил свой сайт на Яндекс Облако. Сайт изначально задумывающийся как статический, серьезных требований к инфраструктуре не предъявляет, поэтому объектное хранилище Yandex Cloud представлялось отличным решением. Особенно если учесть, что аналогов Vercel, Cloudflare Pages или Netlify в России в нет, а хостить сайт хотелось именно с серверов, находящихся в нашей стране. Собственно говоря, эти статьи были выстраданы кровью и потом - все проблемы, что в них описаны, преодолевались мной на практике, а решения удовлетворяли конечным требованиям.
Безусловно Яндекс Клауд позволяет настроить окружение как вам нужно - установить нужные приложения, базы данных, инструменты для работы и не трогать объектное хранилище вовсе. Но цена за подобную конфигурацию была бы не малая и примерно столько же потребовала бы усилий на настройку. Без нужных знаний и денег - это то еще приключение. Поэтому, в том числе, мой выбор пал на статический сайт и объектное хранилище на Облаке Яндекса для его хостинга.
Прощай Облако
Ну, и сразу два важных вопроса, которые вы могли бы задать - как мой сайт чувствует себя в Yandex Cloud и доволен ли я статикой? Ответы такие: никак и нет. Дело в том, что мой сайт, на котором вы читаете сейчас эту статью - не статический. И хостится он не у Яндекса. По сути, когда вышла первая статья из серии про установку статического сайта в Cloud он уже не находился там. Дело в том, что статьи в этой серии писались во время настройки сайта, а публиковались позже. Но когда я запустил этот проект в продакшн, понял, что все ни то, и все ни так, и ушел сначала с Яндекса, а потом и со статики. Однако статьи были написаны и кому-то безусловно смогут помочь, поэтому не публиковать их было бы плохой идеей.
Теперь постараюсь вкратце объяснить почему я принял такое решение. Начну с причин своего отказа от Yandex Cloud.
Несмотря на то, что нам удалось решить ряд проблем при установке и хостинге сайта из объектного хранилища, данный сервис все таки не очень подходит для проектов, которые по сути являются SPA-сайтами. В современном мире грань между SPA и обычной статикой очень тонка и Яндекс Облако совсем не стремится ее нивелировать. Да и не должен.
Работа с Облаком оставляет двоякое впечатление. С одной стороны у вас есть классный интерфейс, куча функций, обозначена поддержка, в общем все как у людей. Но с другой стороны управление всеми этими функциями не самое простое, документация не подробная, а порой и противоречивая, а поддержка часто самоустраняется рассказывая о том, что Object Storage не предназначен для того и для этого, а вы, как пользователь, должны обладать сами всеми необходимыми знаниями, если уж полезли в эти дебри.
С ценой разобраться сложно. Слышал, что сайт в объектном хранилище вообще стоит копейки, но сколько мне станет его работа, если будет сильно расти трафик? Тарификация у каждого сервиса, привязываемого к облаку, своя, и сколько в итоге обойдется один месяц хостинга там, одному Богу известно. По-странному дороговато стоит Cloud DNS, поэтому привязка домена с условием, что сайт будет расти в копеечку выльется.
Справедливости ради, стоит отметить, что Yandex Cloud развивается семимильными шагами, обошел всех своих российских конкурентов в большинстве аспектов, и безусловно заслуживает внимания. По крайней мере, если ваш сайт обычная статика - набор файлов - то бакеты в объектном хранилище - отличное место для его хостинга. Но со SPA-статикой дела обстоят совсем иначе.
Прощай SPA
Почему я отказался от своего сайта в виде статики? Дело в том, что фреймворки, вроде Svelte, на котором сделан мой сайт, превращают статику в одностраничное приложение. Облако типа AWS S3 не имеет специальной инфраструктуры, которая могла бы должным образом развернуть это приложение, чтобы оно нравилось не только посетителям.
Если источник трафика вашего приложения или сайта - это целевая публика, народ, зашедший по прямым ссылкам, через рекламу или еще как-то, то SPA - это отличный выбор. Но если у вас, как у меня, блог/портфолио/лендинг, то вам бы хотелось привлекать людей еще и органически - через поиск в том же Яндексе, например. А в этом случае SPA - не лучший выбор. И вот ряд причин этого:
- Несмотря на то, что технология SPA существуют уже достаточно давно, поисковики до сих пор работают с ними крайне плохо. Гугл, говорят, справляется лучше, а Яндекс предлагает какие-то танцы с бубном, которые не факт, что помогут.
- Код вашего сайта содержит только базовую HTML-разметку и скрипты, которые генерируют все остальное. Из-за этого всякие парсеры не видят ваших метатегов, картинок для соцсетей, да и самих страниц подчас не видят, из-за чего у вас могут быть большие проблемы с SEO.
- Существуют люди, которые отключают в браузере JavaScript, а еще иногда, из-за проблем с интернетом и его скоростью, SPA-сайт может не отображаться у пользователя, что может навсегда оттолкнуть его от вашего продукта.
Здравствуй и прощай Pages
Уход с Yandex Cloud начался с миграции этого сайта на Cloudflare Pages - это тоже хостинг статических сайтов, но обладающий необходимой внутренней инфраструктурой, соответствующей фреймворку, на котором сайт собирался. Я даже не менял адаптер в файле svelte.config.js
, просто привязал к проекту свой репозиторий в Гитхабе, выбрал конфигурацию для Sveltekit и задеплоил. Потом привязал домен и при каждом пуше в Гит получал на Cloudflare новое развертывание. В Pages мой SPA развернулся как положено - код страниц содержал все нужные теги, поэтому проблем с SEO, как виделось мне, возникнуть не должно было.
Но Cloudflare Pages - не российский сервис. А это было одним из условий, из-за которых я и начал свой поиск нормального хостинга для своего проекта. Хотя, намучавшись с облаками и статикой, я готов был смириться с этим, тем более что, мой сайт вряд ли когда-нибудь будет собирать миллионы посетителей, да и пользовательских данных никаких не коллекционирует, поэтому внимание госструктур привлекать не должен. Но уже в первый день после размещения этого сайта там я столкнулся с проблемами - сайт просто не открывался без VPN. Спустя час-другой эти проблемы прошли, но на следующий день возникли снова. В общем в этой борьбе за суверенный интернет мне принимать участие не хотелось, и на следующий день я нашел решение.
Спасибо интернету. Нашел прекрасное видео Станислава Хромова, который создал на собственном VDS self-hosted решение для сайта на Sveltekit с блэкджеком и автоматическим развертыванием проекта из Гитхаба. То есть практически так, как я и мечтал. Для этого пришлось отказаться от статики и включить в svelte.config.js
адаптер для развертывания сайта на NodeJS, а также настроить конфигурацию, установив на VDS Caprover, Docker, подключив туда Github Actions, привязав домены и проделав еще ряд, необходимых для безопасности и удобной работы, манипуляций.
Справедливости ради нужно отметить, что Sveltekit настолько удобен, что в буквальном смысле коренное преобразования проекта - его превращение из статического сайта в обыкновенный - не стоило практически ничего по временным затратам. Кроме того, вначале я развертывал свой сайт на VDS как статику, и проверял его по скорости на Page Speed Insights, и получил даже меньше баллов за производительность, чем за сайт с нод-адаптером на том же VDS.
При этом мне удалось сохранить преимущества статического сайта, за счет того, что я оставил пререндеринг страниц. Опция export const prerendering = true
, прописываемая в корневом макете сайта, создает html-страницы в процессе сборки, то есть когда запускается команда npm run build
. Посетителю сайта при этом отдается уже готовая страница, что естественно сокращает время ожидания пользователем ответа, хотя и немного увеличивает время самой сборки проекта. Также я добавил сжатие сайта для скорости, и опции безопасности, чтобы быть спокойнее.
Sveltekit, VDS, Docker, Caprover и Github Actions
Вкратце обрисую, чем мы будем заниматься в этой серии статей. Нам предстоит освоить стек технологий из пяти частей:
- Node-адаптер для хостинга Sveltekit-сайта на своем сервере.
- VDS в качестве такого хостинга.
- Docker в виде движка для создания образов, которые будут экспортироваться на хостинг.
- Caprover в качестве платформы для приема образов на VDS и создания сайта.
- Github Actions, позволяющий удобно привезти всю эту массу технологий в движение.
Я до этого никогда не работал с Docker и Caprover, и имел очень опосредованные отношения с Actions. Но желание создать независимый продукт с отличной автоматизацией рабочего процесса перевесило неуверенность при знакомстве с новыми технологиями. Оказалось, что все вышеперечисленное совсем не страшное, а очень даже дружелюбное. А кое-что даже удивляет своей простотой. Но обо всем этом попорядку я расскажу в новой серии своих статей.Следующий пост, совсем скоро. Подключайтесь!