16 сентября 2013 в 16:59
Бывает, что ресурсы нужно экономить, например, если имеем VPS с ограниченным кол-вом памяти, где томкат, или полная версия jetty, или еще кто могут оказаться слишком громоздкими, в этом случае можно использовать обрезанную версию jetty, находящуюся прямо в архиве с солром. В гугле подобной информации довольно много, однако вся она разрознена, в общем в свое время приходилось собирать по кусочкам.
ставим яву
если таковой еще не имеется
sudo apt-get install openjdk-6-jdk
6 для примера, является минимальным требованием, на dev лучше ставить 7, особенно если используете NetBeans ибо, в свою очередь, является его минимальным требованием
Качаем солр
wget http://archive.apache.org/dist/lucene/solr/3.6.2/apache-solr-3.6.2.tgz
tar -zxf apache-solr-3.6.2.tgz
sudo mv apache-solr-3.6.2.tgz/example /usr/share/solr-jetty
Версия 3.6.2 взята для примера, с 4 версией раньше были проблемы со схемами для друпал, сейчас они вроде как есть, сам их пока не пробовал - на данный момент не вижу смысла, затем засовываем папку example куда-нибудь в более подходящее для него место, в этой папке содержатся обрезанный вариант Jetty6, копия Солра, и примеры конфигов для обоих, все остальное скорее всего не понадобится(если, конечно, Вам не нужны какие-нибудь особенные плагины и т.д., правда, на сколько помню, для некоторых плагинов его все равно придется перекомпилировать, так что в этом случае проще будет скачать сразу сырцы., могу ошибаться в данном вопросе).
Создаем пользователя
Лично я не люблю когда софт лазит под рутом, потому создадим для Jetty системного юзера.
sudo addgroup --system jetty
sudo adduser --system --home /usr/share/solr-jetty jetty
sudo usermod -g jetty jetty
sudo chown -R jetty:jetty /usr/share/solr-jetty
sudo mkdir /var/log/solr
sudo chown jetty:jetty /var/log/solr
под юбунтой не дает назначить системному пользователю группу, по крайней мере по имени, а по гиду с копипастом не прокатит, потому с юзер модом, затем отдаем директорию с jetty соответствующему пользователю, создаем папку для логов, т.к. по большей части писать в логи будет именно солр, то и название соответствующее(основное отличие системного юзера - под ним нельзя залогиниться и не мешается при выборе пользователя на входе в систему на dev).
Включаем логи
Если нужны логи, создаем файлик(вообще он учитывается в стандартном скрипте запуска) /usr/share/solr-jetty/etc/jetty-logging.xml со следующим содержимым:
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure id="Server" class="org.mortbay.jetty.Server">
<New id="ServerLog" class="java.io.PrintStream">
<Arg>
<New class="org.mortbay.util.RolloverFileOutputStream">
<Arg><SystemProperty name="jetty.logs" default="."/>/yyyy_mm_dd.stderrout.log</Arg>
<Arg type="boolean">false</Arg>
<Arg type="int">90</Arg>
<Arg><Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call></Arg>
<Get id="ServerLogName" name="datedFilename"/>
</New>
</Arg>
</New>
<Call class="org.mortbay.log.Log" name="info"><Arg>Redirecting stderr/stdout to <Ref id="ServerLogName"/></Arg></Call>
<Call class="java.lang.System" name="setErr"><Arg><Ref id="ServerLog"/></Arg></Call>
<Call class="java.lang.System" name="setOut"><Arg><Ref id="ServerLog"/></Arg></Call>
</Configure>
Скрипт запуска
Создаем файл конфигурации для скрипта запуска /etc/default/jetty со следующим содержимым:
JAVA_OPTIONS="-Dsolr.solr.home=/usr/share/solr-jetty/solr $JAVA_OPTIONS"
JETTY_HOME=/usr/share/solr-jetty
JETTY_USER=jetty
JETTY_LOGS=/var/log/solr
Путь до jre может отличаться(вероятнее всего), JAVA_OPTIONS используется скриптом запуска для указания опций при запуске ява машины, остальное вроде интуитивно понятно
Теперь берем стартап скрипт от полной версии:
wget http://svn.codehaus.org/jetty/jetty/branches/jetty-6.1/bin/jetty.sh
sudo mv jetty.sh /etc/init.d/jetty.sh
sudo chmod 0755 /etc/init.d/jetty.sh
качаем, засовываем в init.d и выставляем права на запуск, затем проверяем на работоспособность с помощью
sudo service jetty.sh check
если все нормально, должно всплыть что-то вроде
JETTY_HOME = /usr/share/solr-jetty
JETTY_CONF =
JETTY_RUN = /var/run
JETTY_PID = /var/run/jetty.pid
JETTY_PORT =
JETTY_LOGS = /var/log/solr
....
В противном случае ошибка с указанием причины, на скрипт будет матюкаться update-rc.d ввиду отсутствия тегов, можно дописать(на вариант с тегами выходит 404).
если все ОК, добавляем скрипт в автозагрузку с помощью update-rc.d jetty.sh defaults
Про настройку солр-джетти полезно будет почитать http://wiki.apache.org/solr/SolrJetty
Вообще скрипт jetty.sh можно переименовать как угодно, например в solr и обращаться к нему через sudo service solr start и т.д.
Теперь прикручиваем друпал:
Клиент для PHP:
wget https://solr-php-client.googlecode.com/files/SolrPhpClient.r60.2011-05-0...
tar -zxf SolrPhpClient.r60.2011-05-04.tgz
rm -R SolrPhpClient/phpdocs
mv SolrPhpClient/phpdocs /var/www/drupal/sites/all/libraries
Скачиваем, распаковываем, убираем из него примеры(иначе будут доступны третьим лицам через HTTP), и переносим в sites/all/libraries Вашего сайта.
Модуль для друпал
ставим модуль для работы с солром, например, search_api и search_api_solr
drush dl search_api_solr search_api
drush en search_api_solr search_api_views
Конфиги и индексы
мне удобнее хранить ядро в отдельном месте
sudo mkdir /var/lib/solr/drupal/data
sudo mkdir /var/lib/solr/drupal/conf
sudo cp /var/www/drupal/sites/all/modules/search_api_solr/solr-conf/3.x/* /var/lib/solr/drupal/conf
sudo chown -R jetty:jetty /var/lib/solr/drupal
создаем папку для индексов друпала, создаем папку для конфигов, копируем конфиги из модуля друпала, отдаем папку солра, далее правим файл /usr/share/solr-jetty/solr/solr.xml, заменяем настройки ядра на что-то типа этого
<cores adminPath="/admin/cores" defaultCoreName="drupal"><core name="drupal" instanceDir="/var/lib/solr/drupal" /></cores>
instanceDir должно указывать на расположение конфигов и индексов, при этом их можно разносить по разным местам, например, следующий вариант позволит вынести в отдельное место только индексы
<core name="drupal" instanceDir="." dataDir="/var/lib/solr/drupal/data"/>
тогда конфиги придется копировать прямо в папку конфигов солра с заменой
sudo cp /var/www/drupal/sites/all/modules/search_api_solr/solr-conf/3.x/* /usr/share/solr-jetty/solr/conf
вместо /var/www/drupal везде подставлять свой путь к друпалу, у других аналогичных модулей для солра должны быть свои схемы.
запускаем Solr через sudo service jetty.sh start (или restart если уже был запущен(для перезагрузки))
Проверяем, заходим браузером по адресу http://localhost:8983/solr/admin/ или http://мойдомен.ком:8983/solr/admin/
обращаем внимание на заголовок, если конфиги встали, в нем можно будет увидеть drupal.
Закрываем Jetty
Если все это дело развернуто на продакшене, то солр лучше изолировать от внешней среды, в этой версии jetty сие можно сделать следующим образом, в файле /usr/share/solr-jetty/etc/jetty.xml находим:
<Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>
и в свойствах host добавляем атрибут "по умолчанию", должно получиться так
<Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>
и перезагружаем jetty: sudo service jetty.sh restart
Описано только самое основное, как видите, с томкатом все гораздо проще. Писал по памяти, так что могут быть ошибки. Надеюсь эта компиляция кому-нибудь поможет. Томаты и прочая критика приветствуется.
Комментарии
Спасибо за статью!
Будем пробовать 
Пара замечаний.
Когда ставил модуль search_api_solr - там есть схема под 4-ку, работает отлично. И вот тот клиент для php я не ставил, работает без него.
спасибо, в закладки
подтверждаю: с 4м солром у друпала всё ок
Могу еще выложить конфиг для nginx+php-fpm+boost(впрочем он годен и на проксирование апача), недавно понадобилось прикрутить к энжинксу буст, выяснилось, что по всему гуглу только 1 полностью рабочий конфиг(на д.орге кривой) и тот весьма специфичный и громоздкий, так что не подошел, пришлось вспоминать как писать правила для энжинкс и изобретать велосипед, надо кому? Хотя буст к энжинксу прикручивать может понадобиться разве что на новостном портале.
Конечно лучше выложите. Может сейчас не надо никому, но потом нагуглят, спасибо скажут
Для некоторых модулей или способов интеграции солра может понадобится, так что считаю, что лишним он не будет.
Добрались наконец руки снести томкат и воспользоваться Jetty
Огромное спасибо за статью, всё получилось!!! Однако, проблемы были. Обо всём по порядку.
Ставил сразу 7-ку, работает, всё ок.
Вот ещё интересная статья, посвежее мною найденной до этого:
http://pietervogelaar.nl/ubuntu-12-04-install-solr-4-with-jetty-9/
Опробовал - работает, рекомендую к прочтению
Только они не заменили в строке
JAVA_OPTIONS="-Dsolr.solr.home=/opt/solr $JAVA_OPTIONS"переменную $JAVA_OPTIONS. Должно быть вот так:
JAVA_OPTIONS="-Dsolr.solr.home=/opt/solr -Xms16M -Xmx64M -XX:MaxPermSize=32M"там вроде используется Jetty8
В любом случае, для Jetty7(в какой-то из 4х версий солра должна лежать именно 7рка, но в последней, на сегодняшний день, точно 8рка) стартовый скрипт можно взять тут, для 8рки в открытом доступе не попадалось, впрочем, можно скачать jetty-full и взять его от туда, либо попробовать от 7рки, вроде бы должен подойти.
с Вашим конфигом jetty будет работать от рута, ну и еще кое-какие мелочи, впрочем, если написать скрипт со всеми этими возможностями смены юзера, проверкой конфигов и т.д., то в итоге получится тот самый jetty.sh
Кроме того, /etc/default/jetty это конфиг для jetty.sh, если Вы не используете стандартный скрипт, то этот конфиг не нужен.
стоит учесть, что конфиг jetty6 отличается от более поздних версий, в особенности настройка хостов, так что следует убедиться, что этот способ действительно работает.
Действительно, в solr 4.4 и выше, solr.xml полностью поменялся
Из всего этого следует, что топик верен только для версии Apache Solr 3.6.x, правда пока мне не до изучения последней версии солра.
это вариант с jetty full, то есть в данном случае не сильно отличается от tomcat
это уже вопрос оптимизации, кроме того, указанные значения, на сколько помню, заданы по умолчанию, т.е. в данном случае эти строки дадут одинаковый результат.
обоим плюсик в репу
Да-да, так и есть! Попробую сейчас.
Чтобы люди не искали - уточняю:
http://download.eclipse.org/jetty/stable-8/dist/
файл в архиве лежит тут: jetty-distribution-8.1.13.v20130916/bin/jetty.sh
Так... Уже попробовал
Заменил jetty.sh из 8-ки - ошибки остались, о которых пишу выше. Но вспомнил про вторую статью, что свежее. Беру /etc/default/jetty с их параметрами и чуть правлю:
NO_START=0 # Start on boot
JETTY_HOST=0.0.0.0 # Listen to all hosts
JETTY_ARGS=jetty.port=8983
JETTY_USER=jetty # Run as this user
JAVA_OPTIONS="-Dsolr.solr.home=/usr/share/solr-jetty/solr $JAVA_OPTIONS"
Работает!!! Ура!!!
Каковы принципиальные различия с Вашим конфигом:
Не запускается по этому пути, пишет ошибку. Цифру 7 под себя ставил, соответственно. А со статейным /usr/bin/java - работает.
С этой переменной начинает орать, что не может зайти в папку, найти там нужные файлы и так далее. Если убрать - в баш-скрипте прописан алгоритм поиска директории по заданным вариантам. Скрипт сам успешно находит и запускается.
Вот это и мешало вчера, выходит.
По-моему, всё: добили таки мы Вашу статью под solr 4.4.0 и jetty 8
Это, конечно, был облом для меня
Так как я утром был уверен, что скачанный jetty 9 моё спасение 
Я даже сравнил из солра папку example, которую мы используем, с дистрибутивом jetty. Как минимум, очень похожи 
Потому я и подумал, что это решение тоже имеет место быть. Выходит, с солром идёт облегчённый вариант jetty? И с учётом моих соображений выше - я всё сделал правильно?
Это я виноват. У меня сначала не запускался скрипт с $JAVA_OPTIONS и я заменил на чистые параметры. Потому написал так. А сейчас прочитал Ваш ответ и вернул переменную назад - запустилось. Чудеса. В общем, беру свои слова обратно
судя по записям в jetty.sh, можно просто указать JETTY_PORT=8983, вообще, если не указывать, то порт будет взят из jetty.xml, но опять же, это точно работает для Jetty6, для остальных не уверен(про необязательность указания порта), JETTY_ARGS нужен для указания дополнительных агрументов, не поддерживаемых в jetty.sh
Jetty вообще - полноценный веб сервер, соответственно, как и любой другой веб сервер имеет кучу "плагинов" и параметров, при этом, он компилируется сразу вместе с ними, а в том виде, в котором jetty идет в комплекте с солром, он попросту скомпилирован с минимальным набором, рассчитанным на то, что работать с Jetty будет только Solr.(кроме того, никто Вам не мешает скомпилировать его самостоятельно под конкретный проект, но это уже другая тема, и боюсь с разбором внутренностей jetty и самого solr в одну тему форума не уложиться)
для того, чтоб добить, надо как минимум еще разобраться с нововведениями в solr.xml для версии 4.4.0 и выше, т.к. изменили они его почти полностью.
По поводу оптимизации ява машины, где-то то ли на сайте солра, то ли в его ридми(словом, где-то в официальных источниках), почему-то крайне не рекомендовалось использовать параметр -XX, не разбирался почему
Тут ошибочка. Я ж забыл по второй статье убрать папку /opt/jetty - баш-скрипт находил jetty там, а не в /usr/share/solr-jetty/solr, потому работало
Опять же: если указать
JETTY_HOME=/usr/share/solr-jetty
он ругается. Убрать - он не находит, так как в лучшем случае директорию придётся назвать
JETTY_HOME=/usr/share/jetty
вот такую найдёт.
Но я сделал другие пути, как во второй статье - /opt/jetty и /opt/solr, раскидал jetty и solr по ним. Тогда параметр станет таким:
JAVA_OPTIONS="-Dsolr.solr.home=/opt/solr $JAVA_OPTIONS"
В общем, пусть каждый делает тут так, как ему будет удобно
Проверил - так и есть. Можно убрать параметр
JETTY_ARGS=jetty.port=8983
так как дефолтный как раз нужный мне - 8983.
То что и нужно
Понял, спасибо!
Это да. Главное, что удалось запустить и оно работает
А остальное - по ходу пьесы 
А я их убрал, выше написал, что это я виноват, сначала не работало без них просто
Кстати, ещё один момент, из-за которого могут быть проблемы с солром: нужно скопировать из архива с ним папки dist и contrib в папку, где лежит солр на сервере. Просто, например, в cores могут быть в конфигах ссылки на файлы из этих папок. В общем, имейте в виду, кто займётся всей это кухней.
помню делал заглушку для почты в виде самописного скрипта, так он умудрялся текст письма исполнять как баш скрипт, видимо в этом случае тоже считает - за спецсимвол, соответственно необходимо экранирование, скорее всего, кавычек будет достаточно, JETTY_HOME="/usr/share/solr-jetty", хотя на Jetty 6 + Debian(6\7)\Ubuntu12.04 работает и без экранирования...
еще один "прикол" от версии 4.4+
И да, лично я бы отделять jetty от solr не стал, все же этот jetty не предназначен для работы с чем-то еще помимо солра, а если его отделить, то у 3го лица может сложится мнение, что там живет полноценный jetty(пример разделения, как я понимаю, Вы взяли как раз от полной версии jetty)
размещая все в одной среде можно ограничить коннект только локалхостом (в конфиге jetty).
иначе, уж лучше томкат7 с авторизацией.
авторизацию можно сделать так же через nginx, пример описан тут
Увы, я тоже думал об этом и проверял = не помогло. Даже переименовал папку в просто solr:
: Нет такого файла или каталога: /usr/share/solr
** ERROR: Oops! Jetty doesn't appear to be installed in /
** ERROR: //etc/jetty.xml is not readable!
Ну вот конфиги солра из модуля search_api_solr по пути
/solr-conf/4.x/solrconfig.xml
имеют такие строки:
<lib dir="../../../contrib/clustering/lib/" />
Это для них придётся копировать как минимум contrib.
Ну да, во второй статье. Согласен с Вашими доводами, верну в одну папку, но тогда придётся сделать такую:
/usr/share/jetty
чтобы баш сам её из заготовленного списка нашёл и выбрал.
Кстати, про изоляцию. Как она работает? Немного не понял
Вот сейчас я могу из любого браузера попасть на страницу
site.ru:8983/solr
Если я выгружу на хостинг - как можно будет туда попасть и как не попадут другие?
а никак не попадут, jetty будет откликаться только на запросы со своего же сервера, всех остальных будет игнорировать.
Но есть 3 способа как этого избежать(правда не совсем понимаю зачем оно надо):
1. добавить авторизацию в jetty(не уверен поддерживает ли авторизацию солровский джетти, по идее должен, впрочем, опять же можно скомпилировать джетти под свои нужды)
2. вариант с проксированием через nginx, т.е. jetty откликается только на localhost, а авторизацией управляет уже nginx.
3. авторизация через друпал, если обязательно нужен доступ к админке солра извне с максимальным уровнем безопасности, но это будет тот еще костыль(секса много - толку мало).
Вообще я не думаю, что кому-то это вообще может понадобиться, разве что для организации solr хостинга(но это уже к друпалу не относится), либо очень сильно надо посылать прямые запросы солру на продакшене(даже не могу представить для чего, и что об этом подумает друпал), на мой взгляд, для типичного случая, логов будет достаточно и солр лучше будет полностью закрыть.
да, причем их копировать нужно относительно инстанса(до версии 4.4), надо будет подправить это дело.
Кстати, не совсем по теме статьи, но заголовок про solr и слабые vps немного издевательски выглядит.
Java приложение со всей оснасткой для запуска довольно прожорливо, для слабой vps.
Так что как мне кажется, тут стоит ещё рассмотреть альтернативу в виде того же sphinx, например.
в том то и вся соль, чтоб заставить её работать на 64х метрах
Сфинкс - отдельная тема, смысла на vps его разворачивать не много, проще взять какой-нибудь тариф у патруля где уже все нормально настроено, разве что кроме сфинкса необходимо еще что-то, ну и про потребление ресурсов тут тоже весьма спорно, возможность "отвалить" от базы данных дорогого стоит. ИМХО
Хотя, если вдуматься... понятие "слабый" весьма относительно, подразумевался VPS с 512 метрами(вообще дедики такие же бывают), ниже уже не прокатит.
Отлично, то, что и нужно
Доступ мне лично действительно туда не нужен, один раз добавил core и забыл. А логи можно и без того посмотреть, согласен.
Эм, ну не знаю, у меня сейчас на виртуальной тачке процесс java кушает больше 100 метров. После запуска сервера - 75.
12 гигов при переиндексации(больше ему "соседи" не дали), словом, подъедает всю свободную память, хотя не должен...
По крайней мере, я пока для себя понял, что если стоят php + nginx + apache/php-fpm + apc + mysql и сюда мы ещё добавляем солр, который работает на java через jetty, то 512-метровый сервер будет маловат
Ибо начинает лезть в swap. Ставлю гиг памяти - 600 метров занимается при лазании по сайту. Понимаю, что тут ещё настроить всё можно по-разному, но солр реально кушает многовато 
В общем, я пока учусь, как вы все поняли 
И мне это всё очень интересно!
а сама операционка у Вас с иксами или без? В убунтовском gnome вроде 512 метров надо только на то чтоб запустилось.
я интерса ради запускал солр на старом ноуте - celeron mobile 2Hz 512M, рядом с LAMPом, под Ubuntu server, без иксов
работало, но, блин мееееедленно
Без. Ставил Debian 7.2 (Linux 3.2.0-4-amd64). Это я ещё и x64 скачал, выходит. Просто сначала не подумал, что лучше тестировать по минимальному количеству памяти. Интересно, сильная ли разница от x32 по кушанию памяти будет в таком случае...
на интеловском i3(Ubuntu) относительно i5(вируталка с разными ОС, правда все то же семейство debian в разных вариантах) mysql работает в разы медленнее, а пых без акселератора так вообще застрелиться. Впрочем, солр у меня летает что на i3 что на ксеонах, особой разницы не заметил(что, кстати, странно).
Вот это уже не хорошо, значит действительно 512 маловато будет, но x64 не имеет смысла ставить на железе с оперативной памятью ниже 4 гигабайт, по идее 32х битная система должна есть чуть меньше ресурсов, но опять же не на много.
Тогда и правда интереснее становится сфинкс... По идее на слабом впс ляжет субд при большом числе "искателей", но по крайней мере он в своп не должен лезть, хотя тут спорно, кроме того, как я писал Выше, тот же mysql просто офигевает от целерона, потому лучше посмотреть как оно будет работать да сравнить. Словом, надо будет как-нибудь провести сравнение сфинкса с солром на одинаковом недожелезе.
Я бы изначально с большим удовольствием бы его выбрал, и даже на патруле им пользуюсь, но, блин, большинство модулей из "семейства" search api заточены на solr
Sphinx интереснее и скоростью, и более скромным потреблением ресурсов при прочих равных - это нативное приложение на C.
По возможностям он, конечно, уступает Solr, но чего не хватает применительно к поиску в drupal?
Search API с ним работает, соответственно, и модули работающие с Search API должны, они же работают уже не на прямую с бекэндом поиска...
Ну и лечь база не должна - с чего бы. Сфинкс работает со своими RT индексами, в Search API, а не совместно с mysql, и базу не положит, ни при поиске активном, ни если упадёт сам.
Это да. В общем, надо будет попробовать, конечно, потестировать - всё ли будет также, как с солром.
то что сфинкс как нативное приложение будет поедать меньше ресурсов это очевидно, однако, взаимодействуя с и без того перегруженной субд, не выйдет ли у него большее потребление чем у солра? Я как-то не особо разбирался со сфинксом(если быть точнее, вообще не вдавался в подробности), но разве он индексы хранит не в БД?
Из темы, видимо, как минимум нужно убрать "для слабых"
Патролу нужно развернуть один сервак чисто под Solr, более там ничего не разворачивая. И продавать услугу "Solr-index" как опцию к тарифным планам. Будет заебаче ЯЩЕТАЮ.
Нет, не в БД. Я выше об этом писал.
В нашем применении сфинкс вообще с БД напрямую не связан - Search API кормит его текстами. Sphinx строит индексы(они хранятся в файлах, в специальном формате). Потом Search API делает к нему запросы.
А как их корректно выключить? Просто не создавать этот файл, что Вы описываете - не прокатывает
Нагуглить ничего полезного не смог. Информация как бы и есть, а что и куда - не разобрался 
Описывают какие-то все разные способы...
Просто с того момента, как я настроил поиск, у меня набралось логов на... 13 гигов!!! Грубо говоря, это за год. А я ещё сижу и думаю: да кто столько места занял-то... Начал уже размер каждой папки смотреть и вывел. Удалил - сразу стало дышать легче