Меню
Что нового?

WEB DAV - как деплой-клиент.

ksnk

прохожий
Вот, мысль появилась. Вероятно не новая, может кто уже занимался чем-то подобным?
Если поставить несложный web-dav сервер на сервер, параллельно сайту, можно получить "расшаренный" на внешний мир образ внутренностей сайта.
Для отладки и деплоя проекта, при загрузке файла на сервер, в обработчике webdav сервера нужно предусмотреть загрузку файла в отдельное место и по окончании собственно загрузки, переместить файл в нужное место, восстановив необходимые атрибуты файла. Вообще, стратегия самого деплоя новой версии проекта остается на совести webdav сервера, можно в гит складывать, можно в отдельную отладочную ветку сорцов...
При этом получаем все плюсы прозрачного деплоя файлов, включая возможность редактировать "прямо на сервере", включив файлы в собственную файловую систему. И исключаем все минусы этого самого "редактирования на лету", применяя какие-нибудь умные стратегии деплоя внутри dav-сервера.

Какие вообще существуют стабильные web-дав сервера на php? Я пока нашел Sabre. Есть что-то более компактное?
 
Последнее редактирование:
antson

antson

Новичок
Партнер клуба
@ksnk, первый вопрос зачем это извращение ?
т.е. цель отладка редактируемых скриптов в реальном окружении рабочего сервера, без последствий для продакшена с версионным контролем правок.

Сие можно получить и через svn
на сервере подымается отладочный субдомен/домен
При коммите по хуку синхронизируется отладочная площадка
На продакшен экспортируешь после окончания отладки

Минус тотже, что и в вашем варианте (куча лишних коммитов с минимальными правками)
 

ksnk

прохожий
Да, для отладки на живом сервере в боевом окружении.
Плюсом, хотя и не очень убедительным, будет минимум инструментов, которые нужны на стороне разработчика. Гит поднимать не обязательно, достаточно любой системы с возможностью подключить сетевую fs. Нетбук с блокнотом, например.
 
antson

antson

Новичок
Партнер клуба
сетевая фс или фтп имеет минус в поиске по файлам нужного . В плане экономии трафика и удобства работы лучше иметь локальную копию.
Под виндовс для работы с блокнотом достаточно поставить на нетбук TortoiseSVN .
Но удобнее все же пользоваться IDE с поддержкой svn .
В результате к аккорду сохранить файл добавиться еще один . Н-р : Alt+S, Alt+C (лучше выбрать свободную и рядом расположенную кнопку с сохранением)
 

AnrDaemon

Продвинутый новичок
Проще уже rsync, если так хочется удалённого деплоя.
 

ksnk

прохожий
Ok, понятно, я неправильно сформулировал задачу.
Мне не нужно решать задачу деплоя хоть как нибудь. Я хочу понять, подходит ли для этого webdav сервер и насколько это будет накладно-удобно-применимо. Ничего не горит.

Какое решение видится по максимуму? На всякий случай - я не прошу все это написать за меня :) Задача пока на уровне исследования возможностей. Вот, примерно, весь мой поток сознания на эту тему

Начальные условия: Сайт с достаточно большой, но не бешеной, посещаемостью. ftp доступ. Доступ к админке хостинга.
Требуется: произвести достаточно сложные изменения прозрачно для пользователей сайта. Некоторые действия, требующие отладки, возможно произвести только с боевого сервера, только в боевом окружении (сервисы заточены на IP, на сертификаты, на реферер и т.д.)

При "обычном" подходе к деплою (git/rsync), дополнительно требуется доступ к консоли, привилегии для установки-работы с системой контроля версий или rsync. Хочется понять, возможно ли обойтись без этого.

Желательно получить в итоге дистрибутив, который просто грузится в отдельный каталог сервера и все остальное настраивается в админке. По окончании работ он просто удаляется вместе с каталогом... По возможности, с минимальными изменениями в остальных файлах сайта. Хотя, похоже что обойтись без дополнительного домена (более высокого уровня?) не получится. Механизм работы с атрибутами файлов - ftp аккаунт, командная строка или привилегии самого сервера.

Желательно иметь набор "стратегий деплоя" и выбирать их для каждого пользователя DAV сервера из админки.
Примеры :
  • "тупая стратегия". Загруженный файл тут же копируем в предложенное место. Стратегия оказывается удачнее, чем загрузка файлов по фтп, не нужно объяснять почему.
  • "Все храним в гите". Укладываем все изменяемые файлы в систему контроля версий. Получается возможность "отъехать" на работоспособную версию, в случае, если рабочая завалилась. Имеем возможность определить виновного, в случае чего.
  • "отладочная ветка исходников". Возможно, совместно с гитом, возможно, в отдельном домене. Формируем параллельную структуру каталогов в дереве исходников сайта. В режиме отладки, в пути доступа автолода сначала осматриваются отладочные каталоги. При этом реальных изменений в файлах боевого сайта не производится, он работает в прежнем режиме. Минус - довольно сложно отлаживать "морду" сайта, картинки и стили автолодом не ищутся...
  • ещё что-нибудь в меру разумное...
Рассмотренные пока инструменты:
Sabre-DAV. Работает с windows системой без дополнительных вопросов. Неубедительный минус - большой собственный объем, придется разбираться с системой плагинов и вписываться как плагин.

EasyCvs - отказался работать с windows клиентом. Плюсы: относительно компактный и понятный код. Утверждается, что VCS встроена в проект, пока не увидел, насколько она работоспособна...
Все равно придется сильно ковырять исходники, так что знакомство с протоколом не будет лишним.
 

ksnk

прохожий
@флоппик, Там нет webdav :) Хотя, "стратегия деплоя" там довольно удачна, нужно будет стырить, когда соберусь что-то писать.
 
флоппик

флоппик

promotor fidei
Команда форума
Партнер клуба
ksnk написал(а):
@флоппик, Там нет webdav :) Хотя, "стратегия деплоя" там довольно удачна, нужно будет стырить, когда соберусь что-то писать.
Нажмите для раскрытия...
Так зачем вебдав? Для твоего описания задачи, если выкинуть слово WebDAV - тебе нужно в нем задать 2 сервера для деплоя, но нацелить их физически на один и тот же сервер, но в разные папки, и если надо, то и деплоить разные ветки (или просто разные коммиты). так ты получишь то, что ты просишь). При этом вторая папка для отладки может даже быть привязана к веб-даву для быстрых тестов, если уж тебе так хочется вебдав )))
 
antson

antson

Новичок
Партнер клуба
@ksnk, а вместо захода в шел, можно себе вебморду сделать на запуск нужных команд
 

ksnk

прохожий
флоппик написал(а):
Так зачем вебдав?
Нажмите для раскрытия...
Как показывают ссылки - это единственное существенное отличие от серьезных "конкурентов". Так что пусть будет, иначе действительно не за что бороться ;)
antson написал(а):
а вместо захода в шел, можно себе вебморду сделать на запуск нужных команд
Нажмите для раскрытия...
Основная идея - разработчик один раз настраивает "стратегию", а потом просто работает с исходниками как с собственной fs. Не думая о мрачных шелах с гитами и коммитами со ссылками. Конечно, некоторые ключевые операции можно будет сделать только в вебморде, но не каждый раз когда изменяется очередной файл.
 

AnrDaemon

Продвинутый новичок
WebDAV как протокол давно мёртв. От него все отказываются, он слишком сложен и многословен.
 
fixxxer

fixxxer

К.О.
Партнер клуба
AnrDaemon написал(а):
WebDAV как протокол давно мёртв. От него все отказываются, он слишком сложен и многословен.
Нажмите для раскрытия...
Тут есть такой момент, что вебдавом называют в основном HTTP. ;)
PUT, DELETE - это все обычные HTTP-методы.
Вебдав задумывался вообще для другого - как этакий способ доступа к древовидным базам а-ля ldap поверх http. Использование вебдава в качестве file transfer protocol это такой хак, причем от вебдава там нужен только листинг, и тот реализуется обычно ограниченно, для частного случая depth=1.
 
Последнее редактирование:
fixxxer

fixxxer

К.О.
Партнер клуба
ksnk написал(а):
Очень вкусный набор "стратегий". Да и формат(phar) тоже довольно привлекателен. Обязательно поковыряюсь в исходниках.
Нажмите для раскрытия...
Глупая штука, если честно. Стратегии "запускаем git и composer на продакшене" мог написать только человек, никогда не работавший с проектами, которые разворачиваются более чем на одном сервере.

Вот хороший: http://magephp.com/
 

ksnk

прохожий
AnrDaemon написал(а):
WebDAV как протокол давно мёртв. От него все отказываются, он слишком сложен и многословен.
Нажмите для раскрытия...
Как удаленная файловая система - он есть из коробки (с небольшим бубном, правда), во всей линейке windows, включая Win10. В юниксах с этим тоже, вроде никаких особых сложностей не наблюдается. Доступный мне андроид тоже соединился с Саброй. В чем проявляется "давно мертв"?
fixxxer написал(а):
Вот хороший: http://magephp.com/
Нажмите для раскрытия...
MagePhp, на поверхностный взгляд, отличается от деплоера только конфигурацией на Yaml и возможность деплоя на несколько серверов сразу. Первый шаг в моем случае будет значительным утяжелением проекта, а второй пока неясно как совместить с удаленной файловой системой. Она принципиально на один сервер отображена. Хотя посмотреть будет интересно. Спасибо.
 
Войдите или зарегистрируйтесь для ответа.
Сверху