Для гиков: внешний вид
В Google Cloud Platform вы не работаете с привычным сервером с панелью управления или доступом по SSH. Вместо этого проект отправляется в „облако“ Google с помощью функции Deploy приложения Google App Engine Launcher.
Статистику, трафик, количество запущенных экземпляров машины или базы можно посмотреть в Google Cloud Console.
Общий вид Google Cloud Console
Как видно, из-за географической удалённости дата-центра, на котором запущена база Google Cloud SQL, и дата-центра, в котором работает мой проект на Google App Engine, задержки при открытии очень большие:
Google App Engine – латентность
Несмотря на задержки, сами страницы отдаются быстро и без проблем:
Google App Engine – трафик
Если правильно настроить кэширование, ежедневный трафик легко можно удержать в пределах бесплатного гигабайта. Можно вынести картинки в CDN (например, Photon из WordPress JetPack), снизив тем самым нагрузку на сайт.
Если нагрузка на сервер увеличивается, GAE запускает новые экземпляры машины-обработчика скриптов:
Google App Engine – работающие экземпляры
Поскольку запуск дополнительных инстансов отражается на тарификации, у GAE суммарное время рабочего состояния может быть больше 24 часов в сутки. Бесплатное время составляет 28 часов в сутки.
Доработка WordPress „напильником“
Для того, чтобы WordPress нормально функционировал в Google App Engine, нужно не только подключить bucket Google Cloud Storage и базу Google Cloud SQL, но и сделать ещё несколько важных фиксов.
php.ini
В файле проекта php.ini дописать:
upload_max_filesize = '500M'
post_max_size = '500M'
Это позволит загружать в WordPress фото и другие медиафайлы размером больше, чем смехотворные 256 Kb. Замените ‘500M‘ на максимальное значение, которое подходит вам. Я поставил сразу 500 Mb – чего уж мелочиться (:
HTTPS
По умолчанию плагин Google App Engine for WordPress разрешает авторизацию и работу в админке только по HTTPS. Строго говоря, это правильно, но если вы не готовы платить дополнительно за установку своего сертификата и трафик SSL, то потребуется отыскать в файле
/wp-content/plugins/google-app-engine/modules/core.php
строки, отвечающие за авторизацию, и заменить там HTTPS на HTTP.
URL Rewrite
Соответствие URL загруженным в Google App Engine статическим файлам и скриптам устанавливается в app.yaml. Там можно использовать регулярные выражения, и это очень удобно по сравнению с записями в .htaccess для Apache. Но зато GAE не умеет делать HTTP Redirect. Поэтому я передал всю переадресацию и обработку переписанных URL отдельному скрипту PHP.
Директивы .htaccess :
RewriteCond %{HTTP_HOST} ^.*$
RewriteRule ^blog\/2013\/01\/spbsu-2013-bio-geo-calendars\.html?$ "http\:\/\/www\.pozhvanov\.com\/blog\/\?p\=8343" [R=301,L]
в обработчик редиректов reditector.php :
$redirect_type = 'HTTP/1.1 301 Moved Permanently';
#Δ тут удобно указать тип редиректа:
#HTTP/1.1 301 Moved Permanently
#или
#HTTP/1.1 302 Moved Temporarily
if (preg_match('/belogorie-2010-contact-sheet\.html$/', $_SERVER['REQUEST_URI'])) {
header($redirect_type);
header('Location: http://' . $_SERVER['HTTP_HOST'] . '/?p=42');
exit();
} else if {
#далее следуют обработчики других условий редиректа
}
Строки из файла .htaccess можно извлечь с помощью регулярного выражения:
\r^RewriteRule.\^blog\\/\d+\\/\d+\\/(.*)\\\.html\?\$.+".*\\\?p\\=(\d+)" \[R=301,L\]$\r
и преобразовать в код PHP:
else if (preg_match('/\1\\.html$/', $_SERVER['REQUEST_URI'])) {
header($redirect_type);
header('Location: http://' . $_SERVER['HTTP_HOST'] . '/?p=\2');
exit();
}
Всё это нужно для поддержки старых адресов, которые когда-то могли быть опубликованы и остались в интернете, а также затем, чтобы проинформировать поисковые системы о смене схемы адресации на сайте.