Это завершающая статья про Google App Engine. Я принял решение отказаться от использования GAE в своих проектах.

Сначала платформа Google App Engine мне показалась очень интересной. Я даже наваял на ней пару тестовых приложений, и когда меня все устроило, запустил несколько более-менее серьезных проектов на GAE.

Потом выяснилось, что Google стал блокировать доступ к сайтам на GAE по непонятным причинам, а спустя какое-то время даже прикрыл свой проект appgallery.appspot.com, написанный на GAE и предназначенный для популяризации этой платформы.

Такой зависимости от капризов гугла я терпеть не мог, и решил уйти с платформы Google App Engine.

Когда я забрал данные из хранилища в Google App Engine в формате sqlite3, я думал, что сконвертировать их, например в mysql, будет совсем не сложно.

Я ошибался. Данные в дампе оказались нечитаемыми, и с ними нормально работать мог только движок Google App Engine. Поэтому мне пришлось сделать реэкспорт данных из хранилища GAE в другой читабельный формат.

К счастью, bulkloader умеет экспортировать данные и в других форматах, например, CSV или XML. Про экспорт в XML есть хорошая статья на Хабре, где по полочкам и разложено, как настроить bulkloader.yaml для корректного преобразования данных в XML.

Так как сайты на платформе GAE может хостить только Google, платформа оказалась тупиковой ветвью в развитии фреймворков на Python, использовать ее стало бесполезно и даже опасно. Уж лучше писать на Django, чем бездарно тратить время на GAE.

Вот уже болльше 2-х лет я пользуюсь хостингом от FirstVDS и MiniVDS, причем для моих небольших нужд вполне хватает самых дешевых тарифов, на которых дается всего 64 Мб RAM. Свободной памяти у меня практически никогда не бывает, но все сервисы стабильно работают.

Я всерьез задумался, а есть ли смысл включать nginx. Кроме статики, у меня еще есть куча скриптов; причем php работает как модуль apache. Да и сам nginx тоже будет висеть в памяти и есть ресурсы.

Удивительно, но после того, как я у себя включил nginx, apache стал есть меньше памяти. И как выяснилось, это заслуга nginx.

Зачастую апач генерит страницу быстрее, чем отдает ее клиенту; особенно, если клиент имеет не очень хороший канал. И пока он ее отдает, процесс висит в памяти и жрет системные ресурсы. Вот тут и приходит на помощь nginx, который работает как прокси. Он мухой забирает все, что сгенерил апач, и отдает все это добро клиенту. Апач же, законив свою грязную работу, спокойно умирает.

Включить nginx в панели ISPmanager можно одним кликом мыши, и уже через пару-тройку минут можно будет видеть результат. У меня, правда, процесс не совсем корректно отработал, nginx стартовал, а апаче почему-то нет. Пришлось апач запустить вручную. И еще, если автоматически созданные поддомены сделаны вручную через mod_rewrite, возможно некорректное отоборажение картинок на сабах. В этом случае придется вручную править правила раздачи картинок с поддоменов для nginx

Платформа Blogger умеет вести блоги не только на blogspot.com, но и на своих доменах. Публикация постов представляет собой заливку готовых html-файлов на хостинг с помощью FTP или SFTP. А чтобы отсечь любителей подбирать пароли FTP, Blogger опубликовал IP-адреса серверов, с которых он может проводить публикацию постов:

66.102.15.83
216.34.7.186
64.233.166.192-207
64.233.178.192-207

Т.е. достаточно в firewall.conf дописать всего 5 строчек, чтобы отсечь брутфорсеров паролей:

add allow tcp from 66.102.15.83 to me 21
add allow tcp from 216.34.7.186 to me 21
add allow tcp from 64.233.166.192/28 to me 21
add allow tcp from 64.233.178.192/28 to me 21
add reset tcp from any to me 21

Задача: при обращении к поддомену сервер должен отдавать контент из соответствующей поддиректории для заданного VirtualHost.

Есть 2 способа решения задачи, и какой из них лучше – решайте сами.
В любом случае, сначала надо настроить WildCard DNS на домене, иначе ничего работать не будет.

Если Ваш проект хостится у firstvds или у minivds, то при добавлении домена на Ваш аккаунт файл зоны будет выглядеть примерно так:

$TTL 3600
domain.com. IN SOA ns1.minivds.com. root.mylogin.minivds.com. (2007041702 10800 3600 604800 86400)
;
domain.com. IN NS  ns1.minivds.com.
domain.com. IN NS  ns2.minivds.com.
domain.com. IN MX 10 mail
domain.com. IN MX 20 mail
domain.com. IN A XXX.YYY.ZZZ.WWW
www IN A  XXX.YYY.ZZZ.WWW
ftp IN A  XXX.YYY.ZZZ.WWW
mail IN A  XXX.YYY.ZZZ.WWW
smtp IN A  XXX.YYY.ZZZ.WWW
pop IN A  XXX.YYY.ZZZ.WWW
domain.com. IN TXT "v=spf1 a mx ~all"

Чтобы включить WildCard DNS, достаточно в файл зоны добавить всего одну строчку и поменять цифры в serial number зоны. После исправлений файл доменной зоны будет выглядеть так:

$TTL 3600
domain.com. IN SOA ns1.minivds.com. root.mylogin.minivds.com. (2007041703 10800 3600 604800 86400)
;
domain.com. IN NS  ns1.minivds.com.
domain.com. IN NS  ns2.minivds.com.
domain.com. IN MX 10 mail
domain.com. IN MX 20 mail
domain.com. IN A XXX.YYY.ZZZ.WWW
www IN A  XXX.YYY.ZZZ.WWW
ftp IN A  XXX.YYY.ZZZ.WWW
mail IN A  XXX.YYY.ZZZ.WWW
smtp IN A  XXX.YYY.ZZZ.WWW
pop IN A  XXX.YYY.ZZZ.WWW
* IN A XXX.YYY.ZZZ.WWW
domain.com. IN TXT "v=spf1 a mx ~all"

Через некоторое время можно попробовать пингануть домены abc.domain.com, asfwsegws.domain.com – доменное имя 3-го уровня должно определяться с тем же IP-адресом, что и доменное имя 2-го уровня.
Вот теперь можно переходить к настройке сабдоменов.

Способ номер 1: вносим изменения в httpd.conf
Выглядит это примерно так:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.domain.com
RewriteCond %{HTTP_HOST} !^cgi-bin\.domain\.com$ # запрещаем перенаправление для cgi-bin
RewriteCond %{HTTP_HOST} ^(www\.)?(([^\.]+)\.){1}domain.com$
RewriteCond /home/domain/data/www/domain.com/%3 -d
RewriteRule ^/(.*) /%3/$1

Перезапускаем apache и все – любая поддиректория, созданная в /home/domain/data/www/domain.com/ будет доступна как поддомен. Это самый правильный вариант создания поддоменов.

Но такой способ не будет работать на виртуалхостингах, поскольку доступ пользователю к httpd.conf никто не даст.

Способ номер 2: поддомены через .htaccess:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^subdomain1.domain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.subdomain1.domain.com$
RewriteRule ^(.*)$ http://www.domain.com/subdomain1/ [R=301,L]
RewriteCond %{HTTP_HOST} ^subdomain2.domain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.subdomain2.domain.com$
RewriteRule ^(.*)$ http://www.domain.com/subdomain2/ [R=301,L]

В этом случае при обращении к subdomain1.domain.com или к www.subdomain1.domain.com пользователь будет перенаправлен на URL http://www.domain.com/subdomain1/ и он это заметит.