Я думаю, стоит рассказать про запуск проекта и внезапно обнаруженные подводные камни.

Итак, у нас есть сайт с минимальным, но достаточным для запуска функционалом. И вот здесь обнаружилась следующая особенность: т.к. сайт написан на Snap Framework, то для его запуска просто необходим выделенный сервер. Snap Framework не поддерживает ни FastCGI, ни просто CGI, а реализует свой http-сервер. Возможно, если бы я заметил это раньше, то выбрал бы другой фреймворк, например, Yesod.

Цены на VPS довольно высоки, а много тратить совсем не хочется, поэтому начал искать. В первую очередь заглянул на сайт active.by и обнаружил у них Cloud-хостинг. ~$20 в месяц за 1/4 процессора, 256 Mб RAM и 10 Гб на жестком диске. Неплохо, но что если поискать подобные предложения за пределами Беларуси? Так я и нашел Rackspace, за ту же конфигурацию они хотят ~$11 (1.5 цента в час). Кстати, интересная деталь: Rackspace подтверждают твою личность по телефону, т.е. звонят и задают всякие уточняющие вопросы.

Хостинг куплен, пришла пора разворачивать его.

Идея №1: извлекать сайт с GitHub, компилировать его и запускать прямо тут на сервере. Удобно, но, к сожалению, для этого требуется гораздо больше, чем 256 Мб оперативки. GHC для компиляции проекта хочет очень много памяти, особенно если в проекте большое количество подключенных библиотек. Таким образом, дело заглохло на этапе компиляции необходимых библиотек: после 10 часов ожидания я понял, что не дождусь окончания в обозримом будущем.

Идея №2: Компилируем проект на домашней машине и загружаем исполнимый файл на сервер. И почему я сразу не посмотрел на скомпилированный исполнимый файл? Он же 100 Мб весит! Это же почти половина от всей доступной памяти. К счастью, во время работы сервер съедает гораздо меньше. Но в любом случае каждый раз при обновлении передавать на сервер по 100 Мб совсем не хочется. Полез искать, как уменьшить размер исполнимого файла. Во-первых, обнаружил, что GHC по умолчанию включает присоединенные библиотеки целиком, даже если в них используется только несколько функций. Исправляется перекомпиляцией библиотек с включенным флагом split-objs в настройках cabal. Во-вторых, можно значительно уменьшить размер исполнимого файла такой командой:

strip -p --strip-unneeded --remove-section=.comment -o haskell-blog-small haskell-blog

Результат всех этих действий — 33 Mб. Теперь, если файл упаковать с помощью bzip2, то его размер станет менее 5 Мб, а столько уже не жалко передавать.

Кажется, всё рассказал. Вопросы можно задавать в комментариях.