2016-09-09 MediaWiki4Intranet — развертываем для разработки и в production c помощью Vagrant и Ansible

Revision as of 15:48, 10 September 2016

Как быстро бежит время! Проекту MediaWiki4Intranet уже больше десяти лет, а нашим попыткам натягивать сову на глобус MediaWiki для всех интранет-задач внутри IT компании и вовсе лет 12.

И изначально все было достаточно просто и понятно — стандартный PHP-проект, в духе «скопируй файлы в настроенный PHP-хостинг». Было не зазорно вести разработку/доработку в винде, под LAMP-окружениями типа XAMPP, а на линукс-машину выкатываться через SVN.

Поэтому мы в свое время и завели такую штуку, как Windows-сборка Mediawiki4Intranet, где обычным каталогом лежали все необходимые утилиты/фреймворки (включая TeX, Graphviz, Sphinx), и любой виндовс-пользователь мог попробовать нашу вики, и даже, не приходя в создание, править и создавать какие-нибудь расширения^[1].

Но время идет.

MediaWiki из моностекового монолитного PHP-проекта, с классической моделью «генерация страницы на сервере» постепенно превращается в мультистековый микросервисный проект с realtime UI — так, например, появившийся WYSIWYG-редактор требует специально поднятого сервиса на node.js. На подходе даже мгновенное коллаборативное редактирование в стиле «etherpad/googledocs»…

Все это уже не развернуть тупым копированием файлов, и нереально влом тащить все это под Windows — к тому же, почти все вменяемые вебразработчики ушли на Mac/Linux. Впрочем, современные тренды разработки вовсе требуют вынести за скобки систему разработчика (все это холиварно и его личное дело), а все-все-все зависимости проекта инкапсулировать и виртуализировать/контейнеризировать^[2]. Т.е. все, полноценная MediaWiki — больше не проект для shared hostingа^[3], но и shared hosting уже почти умер для нормальных проектов. Но так как цены на изолированный VPS-контейнер упали уже совсем ниже плинтуса^[4], то разница в плате за VPS/Shared уже давно не проблема.

Проблема остается только в сложности разработки и обновления нашего «бандла» — как его ставить, чтобы можно было в пару действий, с минимальной кривой обучения

• запустить что-то работающее,
• получить и
  • тестовую версию для локальной отладки коротким REPL-циклом — в смысле, чтобы можно было открыть файлы в IDE и править их по живому, отлаживаться в построчном отладчике с нормальным просмотром переменных и брейкпоинтами.
  • надежное конфигурирование удаленного сервера на production.
• легко конфигурировать свои вики-инсталляции, чтобы они использовали именно ту функциональность, которая нужна, наследовали для гибкости общие параметры и т.п..

Именно для этого, мы в свое время сделали инструмент Repo.php, специально заточенный для развертывания MediaWiki4Intranet, но…

• Он все-таки про развертывание PHP-части, где-то конкурируя с Composer^[5]
• Развернуть и раскатать систему с нуля, поставить nod-ный стек, настроить firewall и т.п. — за пределами его функциональности.
• Никто уже не хочет слышать ни о каких новых, и тем более самопальных системах развертывания, когда DevOps-зоопарк уже взрывает всем мозг, а горшочек все продолжает варить и они все лезут и лезут на свет.

…

Поэтому, мы взяли все самое распространенное-стандартное-проверенное:

• Vagrant — для эффективного руления локальными машинами.
• Ansible — для декларативной конфигурации сервера на «Centos 7»^[6]-машин. Чтобы с одной стороны, больше никогда не опускатся до простыней инструкций в духе «отредактируйте /etc/xxx, заведите каталог /var/log… ×100500 …», с другой — все это легко читаемо и понимаемо даже теми, что впервые слышит про ansible.

Т.е.

• Почти ничего учить не придется.
• Если что и придется — это полезные знания, уже ожидаемые от ITшников.

Итак, допустим, что у вас здоровая Linux-система^[7].

• Ставите Vagrant пакетным менеджером или просто RPM/DEB с сайта.
• Ставите Ansible пакетным менеджером или, если вдруг он в вашем дистрибутиве очень старый или его нет — через «pip install ansible».
• Ставите VirtualBox — обязан быть в пакетах, но если нет — можно и с сайта.

Дальше:

git clone git@github.com:mediawiki4intranet/mediawiki4intranet-vagrant-ansible.git

Пока идет развертывание, прописать в /etc/hosts

 127.0.0.1 intrawiki.local.com

Все должно кончится хорошо, без страшных слов о падениях и красной раскраски терминала. Только желтые и зеленый цвета и что-то типа

PLAY RECAP   
*********************************************************************                                                 
intrawiki                  : ok=468  changed=132  unreachable=0    failed=0     

Для очистки совести можно спросить:

vagrant port                                                        

и убедится, что форвардинг, какой-то такой:

 22 (guest) => 2222 (host)               
 80 (guest) => 15304 (host)                
 3306 (guest) => 15305 (host)

Т.е. вы получаете SSH доступ к машинке по 2222 порту, доступ к MySQL базе по 15305, ну и можете просто открыть в броузере http://intrawiki.local.com:15304/ — там вас ждет настроенная MediaWiki, с почти всеми нашими расширениями, Sphinx-поиском, IntraACLем и WYSIWYG-редактором.

Там много-много всего хорошего, я только упомянул самое главное —

• WYSIWYG-редактор нужен, чтобы привлечь к редактированию слабоITшных менеджеров, которые боятся кода, но любят таблицы — которых в вики коде редактировать непросто.
• Права на страницы, именно это делает MediaWiki пригодной для чего-то кроме энциклопедии «для всех».
• Хороший полнотекстовый поиск с русской морфологией важен русскоязычным пользователям.

Итак, логиньтесь туда админом-бюрократом WikiAdmin/Wiki1729Admin, и делайте все что угодно.

Все настроено и работает! Ну, должно работать. It works on my machine, шучу, проверял на нескольких.

Можно зайти туда по SSH:

vagrant ssh

или

ssh vagrant@0 -p 2222

или

ssh root@0 -p 2222

Можно смонтировать всю файловую систему по sshfs

 sshfs root@0:/ -p 2222 -o reconnect /mnt/intrawiki

Разумеется, проверьте («vagrant port»), что у вас именно 2222 SSH-порт и заведите каталог для монтирования (/mnt/intrawiki или где вам удобно).

И локально настроенная машина уже готова к PHP-отладке — если ваше IDE умеет PHP-xdebug-отладку — просто включите его слушать 9000 порт, и отладка пойдет, вам только стоит отмаппировать выполняемые PHP-файлы на подмонтированную по SSH файловую систему (об этом обычно спрашивает само IDE^[8]).

Ну а если хотите выкатывать наружу, правите hosts.ini, указывая IPшник и sudo-пользователя вашей VPS^[9], нужный домен и название сайта, и запускайте !intrawiki-production.

Ну, а теперь разьяснение, что и где, и зачем.

Vagrantfile

Настройки локальной виртуалки. Тут что-то менять необязательно. Хотя можно вместо монтирования по SSH сделать разделяемую папку, можно рулить выдаваемым CPU и памятью, можно сменить порты. Тут же можно отключить отладочность локальной инсталляции — может вам нужна именно производительная локальная вики для работы, а не разработки.

hosts.ini

как деплоить production-сервер, тут настраивать обязательно. Не забудьте сменить пароль к WikiAdmin, а то я приду и взломаю вас :).

group_vars/all

Настройки-константы, определяющие куда все это встанет, и в крупноблочно — что. Так, установив «tex: no», если вам не нужны формулы и поддержка LaTeX-разметки, можно отказаться от жирного TeX-стека, а задав «wysiwyg: no», отказаться от WYSIWYG-редактора VisualEditor, и жирного nodejs-стека.

roles

Сконфигурированные ansible-роли.

roles/common-root

Общие настройки минимальной центоси до более-менее вменяемой, куда будут заброшены ваши публичные ключи для беспарольного входа. Да, мы потрогаем ваш приватный ~/.ssh/id_rsa, но честно-честно, никуда его не унесем, только вытащим публичный ключ чтобы облегчить авторизацию на вики-серверах.

roles/parsoid

Развертывание nodejs-сервиса парсинга — если не нужно WYSIWYG-редактирование, можно исключить настройками в group_vars/all.

roles/wiki-root-common

Настройка PHP-NGINX-PHP-FPM стека, общего, если вы заходите держать несколько вик.

roles/intrawiki-root

Настройка конкретной вики (если нужно несколько вик, можно копировать-настроить этот каталог). Основные тонкие настройки там:

• В roles/intrawiki-root/tasks/main.yml найдете список расширений и откуда их брать. На простые бинарные настройки это не высадить, особенно если вы будете форкать расширения, или наоборот, фиксировать версии. По смыслу там все понятно. Откуда брать, куда ставить, какая версия. Если расширение потребует дополнительных библиотек через composer — они поставятся. В общем блоке LocalSettings сделано так, что автоматически подключаются все установленные расширения. Т.е. если вам что-то ненужно — просто удалите и не выкачивайте расширение. Если нужно что-то еще — просто добавьте

- include: templates/install_ext.yml item={{ item }}
  with_items:
  - {dest: '',         url: '{{prefix_github}}mediawiki4intranet/core',     version: mediawiki4intranet-core-1.26}
  - {dest: 'config',   url: '{{prefix_github}}mediawiki4intranet/configs',  version: master}
  - {dest: 'vendor',   url: '{{prefix_wikimedia}}vendor',  version: REL1_26}
  - {dest: 'extensions/googleAnalytics',   url: '{{prefix_wikimedia}}extensions/googleAnalytics',  version: master}
  - {dest: 'extensions/MediaFunctions',    url: '{{prefix_wikimedia}}extensions/MediaFunctions',  version: master}
…
  - {dest: 'skins/cleanmonobook',  url: '{{prefix_github}}mediawiki4intranet/skins-cleanmonobook',  version: master}
  - {dest: 'skins/vector',  url: '{{prefix_github}}mediawiki4intranet/Vector',  version: mw4i-1.26}
  - {dest: 'skins/monobook',  url: '{{prefix_github}}mediawiki4intranet/skins-monobook',  version: mw4i-1.26}

• В roles/intrawiki-root/templates/LocalSettings.php тонкие настройки вашей вики.

Ну вроде и все — проект этот будет поддерживаться в актуальном состоянии, будем добавлять новые роли и возможности, стараясь при этом чтобы все это не стало монструозным.

«Присоединяйтесь, барон!» © — ставьте, пользуйтесь, пишите новые интересные расширения.

1. ↑ Вот короткая, почти не устаревшая лекция про архитектуру MediaWiki
2. ↑ Самый последний писк моды это «ехал докер через докер»™, но сейчас мы рассмотрим олдскульный подход, с виртуальными машинами и гибким обновлением через ansible. Докер тоже будет. Но потом.
3. ↑ И не надо к нам больше обращаться с просьбой развернуть все это за две тыщи рублей на шаредхостинге!
4. ↑ Хоть за пару баксов в год
5. ↑ Который, кстати, появился слишком поздно, после Repo.php — иначе бы, конечно, не стали бы так «велосипедить»
6. ↑ «Centos 7» — наиболее популярный в «энтерпрайзе» серверный линукс, какой бы дистрибутив вы не любили, и как бы вы не относились к редхатоподобных дистрам
7. ↑ Если у вас Windows, попробуйте путь с cygwinом-babunом
8. ↑ Лично я люблю Komodo IDE
9. ↑ Ожидается VPSка с свежеустановленной Centos 7 — все хостеры VPS предоставляют такой шаблон