Оптимизация взаимодействия веб-клиента и сервера - Практические задачи
В завершение мы немного поговорим о типовых задачах, с которых многие из нас и начинают впервые заниматься веб-проектами. Предложенные далее решения будут настолько просты, что вы их сможете реализовать сразу же в процессе чтения статьи, а далее и масштабировать, при необходимости.
Хотелось бы немного остановиться на вопросе запуска сервисов. Способов запуска сервисов в линукс немало - скрипты http://ru.wikipedia.org/wiki/Init:
init (сокращение от англ. initialization — инициализация) — программа в UNIX и Unix-подобных системах, которая запускает все остальные процессы.
утилита nohup:
nohup — UNIX-утилита, запускающая указанную команду с игнорированием сигналов потери связи (hangup); таким образом, команда будет продолжать выполняться в фоновом режиме и после того, как пользователь выйдет из системы.
и даже запуск в сеансе screen.
Для использования init нужны рутовые права или специальная настройка системы для запуска с правами пользователя посредством команды sudo. Два других способа не требуют ни настройки системы, ни каких-либо дополнительных прав, но после перезагрузки сервера придется запускать все вручную. Все названные методы имеют большой недостаток - если сервис по какой-либо причине завершился, перезапустить его потребуется вручную. Недостаток - это еще мягко сказано, скорее, это огромная концептуальная дыра (обычно администраторы пишут скрипты для проверки работающих сервисов и, при необходимости, их перезапуска; такие скрипты добавляются в cron). Если есть возможность, рекомендую установить суперсервер runit, который обеспечивает возможность с правами пользователя создавать сервисы и управлять ими, а кроме того, сам перезапустит сервис при необходимости. Подробнее смотрите или в англоязычной документации или в русскоязычной статье Использование runit для своих сервисов.
Файловый хостинг
Все необходимое для создания файлового хостинга рассмотрено в разделе Статический контент. Здесь лишь приведу пример конфигурационного файла для запуска с помощью супервизора runit:
run
#!/bin/sh export HOST=127.0.0.1 export PORT=6100 export ROOT=~/wwwserver cd $ROOT exec tcpserver -c 5 -R -H $HOST $PORT env -i LANG="ru_RU.UTF-8" \ /usr/sbin/fnord-idx . 2>/dev/null 1>/dev/null
Также можно средствами runit включить логирование запросов, но об этом см. в документации. Если листинг директорий не нужен, можно заменить /usr/sbin/fnord-idx на /usr/sbin/fnord. Для поддержки CGI и листинга директорий используйте /usr/sbin/fnord-cgi-idx, а только для CGI - /usr/sbin/fnord-cgi.
Система контроля версий
Все успешные проекты пользуются системами контроля версий, и для многих разработчиков установка и настройка такой системы это именно то, с чего начинается проект. Кроме того, для создания корпоративных и вики-сайтов может оказаться вполне достаточно функционала, предоставляемого версионной вики. Как видим, затронутая тема вполне практична.
Существует множество разных продуктов для управления версиями, зачастую нелегко разобраться в их преимуществах и недостатках. При выборе подходящего решения стоит обратить внимание на не-администрируемые решения с возможностью распределенной работы и веб-доступом. Весьма желательно также наличие встроенной версионной вики, что облегчает документирование и обеспечивает соответствие версий файлов и документации. В качестве такой системы я предпочитаю использовать fossil, который удовлетворяет всем перечисленным требованиям:
Fossil представляет собой простую в использовании распределенную систему управления исходными кодами (DSCM) с поддержкой доступа и администрирования через HTTP CGI или встроенный HTTP сервер, имеет встроенную вики, встроенный браузер файлов, встроенную тикет-систему (tickets system) и другие возможности.
Кроме того, поддерживается цифровая подпись всех коммитов, эффективный протокол синхронизации и множество других нужных функций, описание которых вы найдете на официальном сайте. Здесь я отмечу лишь самую замечательную особенность - репозиторий представляет собой единственный кроссплатформенный файл, содержащий хорошо упакованные исходные коды и дельты их изменений. Простым копированием этого файла можно перенести репозиторий на любую платформу и операционную систему.
Скачать бинарную сборку для вашего дистрибутива можно по адресу http://www.fossil-scm.org/download.html В debian/ubuntu дистрибутивах пакет fossil также есть в официальном репозитории. Основы работы описаны на сайте проекта, а также доступна для скачивания книга Fossil User manual. Далее мы ограничимся лишь парой примеров для облегчения начала самостоятельной работы.
Получить список всех команд:
$ fossil help Usage: fossil help COMMAND. Available COMMANDs: add close http redo sync all co info remote-url tag annotate commit leaves rename timeline artifact configuration ls revert ui branch del merge rm undo cgi descendants mv scrub unset changes diff new search update checkout extras open server user ci finfo pull settings version clean gdiff push sha1sum wiki clone help rebuild status zip This is fossil version [15cb835736] 2010-06-17 18:39:10 UTC
Получить описание отдельной команды:
$ fossil help add Usage: fossil add FILE... Make arrangements to add one or more files to the current checkout at the next commit. When adding files recursively, filenames that begin with "." are excluded by default. To include such files, add the "--dotfiles" option to the command-line.
Как видим, программа самодокументированная и разобраться с ее возможностями несложно.
Благодаря идеологии распределенной работы все версии репозитория равноправны, так что утрата любого из репозиториев, включая репозиторий на основном сервере, проблемой не является - можно скопировать репозиторий любого разработчика на сервер и синхронизировать его с остальными разработчиками, восстановив, таким образом, всю информацию. Вы еще думаете о проблеме бэкапов и центральном сервере? Забудьте, мы живем в мире распределенной информации. Если бы я решил последовать текущей ИТ-моде, то совершенно справедливо назвал бы fossil "облачной" системой контроля версий.
Вики
Ранее мы уже рассматривали систему контроля версий со встроенной вики: Система контроля версий Рассмотрим подробнее, чем же эта система нам будет полезна в новом качестве.
Начну с примера - данная статья с помощью встроенной в fossil вики в текущий момент редактируется локально в браузере, а после будет синхронизирована с ее веб-версией на сайте http://book.mobigroup.ru. Также можно сохранить файл статьи на диск, отредактировать в любимом текстовом редакторе и загрузить новую версию в локальный или удаленный fossil-репозиторий. Все ресурсы к статье (картинки, скрипты) также управляются fossil и в любой момент можно получить нужную версию статьи с соответствующими ей картинками и прочими ресурсами. Итак, есть фоссил-репозиторий на сайте и его копия (может быть сделана любым способом, каким нам больше нравится копировать файл) или клон (выполненный через HTTP командой fossil clone) на локальной машине. Изменения можно вносить в оба репозитория, а после синхронизации они снова станут идентичными. Иначе говоря, кроме стандартного функционала веб-вики мы получаем еще и вики локальную, которой можно пользоваться при отсуствии доступа в интернет и даже при отсутствии браузера. Любой пользователь может создать свою локальную копию и вносить в нее изменения, притом, если у него есть права редактирования вики-страниц в основном репозитории, то после этот пользователь сможет выполнить синхронизацию.
Заметим, что локальная версия репозитория является также бэкапом - в любой момент ее можно скопировать на сервер и запустить веб-интерфейс. Как много говорят о том, что бэкапы делать нужно, - но эта потребность возникает лишь при работе с "глупым" программным обеспечением, которое не умеет самостоятельно обеспечивать сохранность своих данных и даже неспособно объединить несколько частичных копий. fossil решает задачу сохранности информации благодаря поддержке ее распределенного хранения, причем синхронизация выполняется одной командой, а восстановление всех данных - простым копированием единственного файла репозитория или еще одной командой.
В качестве примера рассмотрим, как же нам получить копию репозитория, в котором опубликавана эта статья, в папке /tmp/book на своем компьютере:
$ mkdir /tmp/book
$ cd /tmp/book
$ fossil clone http://book.mobigroup.ru/ book.fossil
Bytes Cards Artifacts Deltas
Send: 49 1 0 0
Received: 16969 368 0 0
Send: 10025 225 0 0
Received: 850820 255 81 119
Send: 7898 176 0 0
Received: 1344313 214 60 107
Total network traffic: 9996 bytes sent, 434133 bytes received
Rebuilding repository meta-data...
367 (100%)...
project-id: c038be6d00dcad09c6cb103418aee95fea066e28
server-id: e817408496f556de59679d530e521e807d2f9045
admin-user: alexey (password is "d52atf")
Вот и все, теперь можно работать с локальной копией. Имя администратора alexey и пароль "d52atf", но авторизация по умолчанию требуется только для удаленного доступа, а локально на своем компьютере логин и пароль не потребуются.
Откроем полученный репозиторий:
fossil open book.fossil ... project-name: Статьи Mobigroup repository: /tmp/book/book.fossil local-root: /tmp/book/ project-code: c038be6d00dcad09c6cb103418aee95fea066e28 server-code: e817408496f556de59679d530e521e807d2f9045 checkout: e78a25c434cfbb6175f91a69ae9dd022498392b8 2010-07-29 14:22:15 UTC parent: 942d9890eeb8c85394c509f486558d708d8c7d08 2010-07-27 07:30:22 UTC tags: trunk
Теперь можно из консоли работать с репозиторием или запустить веб-интерфейс в браузере:
$ fossil ui В текущем сеансе браузера создано новое окно.
После выполнения этой команды запустится браузер или откроется новое окно в уже запущенном браузере, с адресом http://localhost:8080/ Веб-интерфейс достаточно удобный, так что не будем отсанавливаться подробнее на том, как создать или сохранить страницу вики или просмотреть и извлечь файлы из репозитория.
Comments