Kinsta — отличный хостинг для любых WordPress проектов, предоставляющий мощную инфраструктуру для управления сложными решениями. Он быстрый «из коробки», с хорошей поддержкой 24/7 и возможностью масштабирования. Kinsta действительно снимает бОльшую часть головной боли и позволяет не волноваться о серверном администрировании, а сосредоточиться на развитии сайта. Основные преимущества платформы хорошо описаны на официальном сайте, причем можно посмотреть их в сравнении с другими решениями, например Wp Engine. Маркетинг у Kinsta на уровне, этого не отнять. Но и совершенной эту компанию назвать нельзя.
Помимо очевидных вещей, таких как кэширование на уровне nginx или автоматические бекапы, есть немало нюансов, которые незаметны при беглом тестировании. Давайте разберемся, что еще хорошо, а что не очень у Kinsta.
Что сделано хорошо
Независимые окружения для каждого сайта: live & stage
Работа с окружениями в целом сделана хорошо (за исключением одного нюанса). Для любого сайта можно создать тестовое окружение одним кликом. Оно будет полностью повторять оригинал, но работает полностью независимо и имеет отдельный домен и базу данных. Можно не использовать свой домен, тогда будет взят автоматически сгенерированный поддомен в kinsta. Фактически, это просто еще один сайт, развернутый на этом же сервере.
Интересно, что при этом все доступы к stage-версии сайта идентичны live-версии, за исключением номера порта.
Stage-версии сайтов удобно использовать для тестирования новых фич. Например, можно в них деплоить все, что попадает в ветку stage и сразу же отправлять ссылку ребятам в QA для проверки. Будет работать так же, как на и обычном сайте, включая SSL-сертификаты. По запросу в поддержку для тестовых сайтов можно отключить кэш nginx, чтобы он не мешал при разработке.
phpMyAdmin
Часто managed-решения WordPress хостинга не предоставляют никакого инструментария доступа к базе. Здесь Kinsta приятно удивила, включив возможность быстрого просмотра содержимого базы данных прямо из панели сайтов (с помощью phpMyAdmin). Возможность доступна как для продакшн сайтов, так и для тестовых версий, что порой бывает крайне полезно.
С точки зрения безопасности, возможно, это не очень правильное решение, но я не раз видел как отсутствие встроенного инструмента для работы с базой побуждало разработчиков устанавливать его самостоятельно, что приводило к самым разным результатам.
Кстати, для просмотра паролей, скрытых за «звездочками» нужно дополнительно ввести пароль от аккаунта Kinsta. Мелочь, но приятно что они подумали о любителях оставлять открытые вкладки браузера без присмотра.
Базовая авторизация
Для любого сайта в Kinsta, будь то рабочая версия или тестовая копия, можно быстро включить базовую http-авторизацию по паролю и закрыть его ото всех. Пожалуй, здесь реализация этого простейшего функционала мне понравилась больше всего.
CDN «из коробки»
Все тарифные планы в Kinsta включают в себя возможность отдавать все статические файлы из папок wp-content и wp-includes. Все картинки, CSS и JS размером до 100Мб. Kinsta использует мощности провайдера KeyCDN и для своих пользователей фактически предоставляет их бесплатно. Удобно, потому что как минимум не нужно подключать CDN в другом месте. Обновление файлов в CDN Kinsta происходит автоматически, проблем замечено не было.
Activity Log
Записываются все действия в панели администрирования хостинга, включая обращения в тех. поддержку и их действия по разрешению вопросов. Все обновления плагинов, смены доступов, включение/выключение функций сервера, обновление сертификатов и даже сброс кэша попадает в этот лог. Всегда можно зайти и посмотреть, кто, что, когда и с каким именно сайтом делал на хостинге.
Недостатки Kinsta
Плохая работа функции очистки кеша
Все сайты на kinsta по-умолчанию работают с включенными кэшем nginx. Это очень хорошо для скорости, но очищать такой кэш непросто. А делать это надо часто, особенно в период активной разработки, создания новых страниц или обновления старых. Сбросить кэш в Kinsta можно двумя способами:
- в панели управления сервером
2. в панели WordPress
Причем вторая часто не работает и фактически не сбрасывает кэш, для чего приходится идти в панель kinsta. Согласитесь, каждый раз заходить туда для очистки кеша — не самое удобное решение.
Нельзя очищать кеш автоматически или выборочно
Но и это еще не все. Автоматически очищать кеш невозможно, и это ломает любой процесс CD/CI. Можно правильно настроить локальное окружение, использовать Git для контроля версий и деплоить с помощью Github Actions, но это все не имеет значения потому что для очистки кэша все равно придется зайти в админку сервера или по адресу https://site.com/wp-admin/?kinsta-cache-cleared=true.
Поддержка мультисайтов также реализована не очень качественно: сбросить кэш всей сети можно только из панели сервера, иначе приходиться заходить в админку каждого сайта и сбрасывать его там.
Вообщем — крайне неудобный механизм.
Невозможность скопировать базу с боевого сайта на stage
Большинство проектов, с которыми я работал, имеют контентную составляющую и постоянно обновляются. Новости, статьи, матчи, товары, комментарии — постоянно что-то добавляется и часто это требует нового функционала. На боевом сайте постоянно что-то меняется, и часто эти изменения хочется получать на локальных и тестовых версиях. Здесь бы не помешала функция синхронизации стейдж-версии с боевой базой продакшена, но ее-то как раз и нет в Kinsta.
Можно полностью скопировать стейдж-окружение в live. Зачем? Мне непонятно. Скопировать live в стейдж нельзя, что сильно нивелирует ценность тестового окружения. Единственный доступный вариант — каждый раз удалять/создавать тестовую копию заново, но это, согласитесь, не очень удобно.
Конечно, можно написать собственные скрипты миграций базы для таких случаев, wp cli есть и там и там, но мне кажется такой механизм должен быть в панели управления сервером по-умолчанию.
Search and replace по базе работает с ошибками
В разделе Tools управления сайтом в Kinsta есть механизм, позволяющий делать быстрые Поиск и Замену по базе данных. Теоретически — очень полезная функция, которая вкупе с наличием phpMyAdmin могла бы упростить процесс разработки сайтов на этом хостинге. Но как ни странно, работает он через раз и были замечены случаи повреждения данных, пропуска строк или вообще зависания процесса замены. Не рекомендуется пользоваться им на рабочих версиях сайта, особенно в коммерческих сайтах, где простои могут стоить дорого.
Высокая стоимость объектного кеширования
По умолчанию все сайты на kinsta работают без объектного кеширования. Причем можно перейти на более дорогой тариф, а его все равно не будет. Аргументируют тем, что у нас итак все быстро и оно не нужно. Да, наличие серверного кэширования на уровне nginx минимизирует влияние скорости базы данных на фронте, но админка работает значительно медленнее без Redis. Странно, что это не включено по-умолчанию.
Подключить его можно, за $100 в месяц для каждого сайта. Мультисайт считается за один сайт, но все равно, $100 ежемесячно просто за возможность иметь Redis?
Отсутствие средств локальной разработки
Для обычных хостинг-провайдеров отсутствие средств локальной разработки не является недостатком. Но Kinsta позиционирует себя как хостинг класса А, и поэтому здесь есть к чему придраться.
В то время когда Flywheel или WP Engine активно работают над созданием более привычной для разработчиков инфраструктуры (Local от Flywheel — отличная альтернатива Докеру и Вагранту), в Kinsta нет практически ничего, кроме SSH доступа. Все остальное буквально нужно настраивать вручную. Вот, например, официальная инструкция по настройке Git в Kinsta.
