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

From Wiki4Intranet
Jump to: navigation, search

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

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

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

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

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

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

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

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

Вообще, мы в свое время сделали инструмент — Repo.php, специально заточенный для развертывания MediaWiki4Intranet, но

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

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

  • Vagrant — для эффективного руления локальными машинами.
  • Ansible — для декларативной спецификации конфигурации Centos7[6]-машин.
Итак, сначала допустим, что у вас здоровая Linux-система.
  1. Вот короткая, почти не устаревшая лекция про архитектуру MediaWiki
  2. Самый последний писк моды это «ехал докер через докер», но сейчас мы рассмотрим промежуточную версию, с виртуальными машинами и гибким обновлением через ansible. Докер тоже будет. Но потом.
  3. И не надо к нам больше обращаться с просьбой развернуть все это за две тыщи рублей на шаредхостинге!
  4. Хоть за пару баксов в год
  5. Который, кстати, появился слишком поздно, после Repo.php — иначе бы, конечно, не стали бы так «велосипедить»
  6. Как наиболее популярных в «энтерпрайзе»

[ List view ]Comments

(no items)

Please login to comment.