Коротко для тех, кто спешит
Утилита FTP Deployment: написана на php, принимает в качестве параметра путь к конфигу и выкладывает файлы на удаленный сервер, довольно быстро и хорошо.
Долго и подробно для тех, кому интересно
Все мы любим классные и удобные методы деплоя с помощью capistrano, rsync или, на худой конец, git pull. А если надо выкладывать проекты на shared-хостинг?
Да, некоторые провайдеры предоставляют ssh и git. Но, прямо скажу, их немного.
Однажды я вдруг понял, что привык к хорошему, и ненавижу выкладывать проекты через (S)FTP: не залился какой-то файл; надо вспомнить, где лежат конфиги; вот эту папку не надо выкладывать вообще; вот тут надо проверить права. Думаю, многие этот список легко продолжат.
Тут еще надо сказать, что я с большим удовольствием пользуюсь символическими ссылками для минимизации места (и автоматической актуализации кода). Небольшой shell-скрипт создает контекст нового проекта, в котором уже есть библиотеки, ядро, статика и docroot с htaccess. Мне остается положить правильные конфиги и настроить всё “под клиента”.
В старые времена всё это я делал на своей локальной системе, а потом с помощью FileZilla или GnomeCommander заливал на хостинг. Сейчас перешел на небольшой выделенный сервер, и пришлось искать решение. Хотелось готовое и простое — и я его нашел!
С помощью FTP Deployment выкладка из долгого муторного занятия превращается в одну команду. Ну, на самом деле, в две — тестовый запуск никто не отменял:).
Первый этап: в папку проекта (или в любое удобное место) нужно поместить конфиг утилиты. Ini или php — на ваш выбор. Позволю себе перевести на русский комментарии в примере.
[my site] ; Может быть несколько секций
; удаленный FTP-сервер
remote = ftp://user:secretpassword@ftp.example.com/directory
; пассивный режим FTP
passiveMode = yes
; локальный путь (опционально, но я обычно указывают абсолютный путь вроде /var/www/production/project_path/)
local = .
; тестовый режим? (можно включить опцией -t или --test)
test = no
; Список игнорируемых файлов и каталогов
ignore = "
.git*
project.pp[jx]
/deployment.*
/log
temp/*
!temp/.htaccess
"
; Удалять файлы на сервере? (по умолчанию -- да)
allowDelete = yes
; скрипты, которые надо запустить до загрузки
before[] = http://example.com/deployment.php?before
; скрипты, которые надо запустить после загрузки
afterUpload[] = http://example.com/deployment.php?afterUpload
; скрипты, которые будут запущены в конце
after[] = http://example.com/deployment.php?after
; каталоги, которые надо очистить после загрузки
purge[] = temp/cache
; файлы для предобработки (по умолчанию -- *.js *.css)
preprocess = no
; Файл, в котором будут контрольные суммы загруженных файлов
deploymentFile = .deployment
В общем-то, всё достаточно очевидно и понятно. Readme проясняет некоторые неясности.
Например, в игнорируемых файлах pp[jx] — означает и ppj и ppx. Восклицательный знак — исключение из предыдущей строчки. В примере — всё, что находится в temp мы не загружаем. Но папку создаем и temp/.htaccess в нее загружаем.
И, наконец, про препроцессор. Утилита может сжимать css с помощью YUI Compressor, а js — с помощью Google Closure Compiler. Оба инструмента в дистрибутиве, но требуют Java.
Когда конфиг готов, можно провести тестовый запуск.
php deployment.php deployment.ini -t
Утилита расскажет, что она собирается делать и с какими файлами. Если вы сомневаетесь в списке игнорируемого — самое то.
Если всё хорошо — можно деплоиться:
php deployment.php deployment.ini
Поначалу внимательно читайте, что вам напишет тестовый запуск. По очевидным причинам нельзя закачивать на сервер ftp-deployment.ini. Ну, и вообще, у кого-то и config.php.bak в проектах болтается…
Мне утилита очень понравилась, с удовольствием пользуюсь и друзьям советую. Если знаете удобные альтернативы на других языках — буду благодарен.
Комментарии (20)
AlexLeonov
18.03.2016 09:15-2Все мы любим классные и удобные методы деплоя с помощью… git pull
Что? Что-что-что? )))
Реальные пацаны делают так:
- Teamcity. До 20 сборочных конфигураций бесплатно.
- Teamcity видит изменения в Git. В нужной ветке, конечно же.
- Запускает "от бедра" rsync файлов в темповую директорию на целевом сервере
- В этой директории удаленно по ssh запускает сборочный скрипт на phing
- Скрипт делает всё остальное — раскладывает файлы по местам, накладывает конфиги с параметрами, миграции запускает, прокидывает симлинки и даже перезапускает php-fpm
- бесплатно
- удобно
- один раз настроил и забыл
- легко создавать тестовые стенды
- phing умеет всё
А вы велосипед изобретаете, уважаемый. Не-нуж-ный. Ну зачем в 2016 году что-то заливать по FTP?
Andrewus
18.03.2016 09:26-1Мы на работе используем Git + Bamboo + Capistrano + Phing + Puppet, например, и тоже считаем себя реальными пацанами. Да, небесплатно, но зато отлично интегрируется друг с другом.
А почему вы обвиняете меня в изобретении велосипеда, поясните?AlexLeonov
18.03.2016 09:44Как бы вам объяснить.
Во-первых не существует той проблемы, которую вы пытаетесь решать. Хостинги без ssh есть. Но проблемы нет — не надо просто ими пользоваться. Почти никто уже это не делает.
Во-вторых решения для деплоя и сборки давно уже есть. И вы не добавили к ним ничего нового. Просто повторили, но при этом гораздо хуже. Зачем? Хотите принести пользу — добавьте новый task в phing, который будет делать что-то полезное. Вам только спасибо все скажут.
lavkasnov
18.03.2016 10:02Хостинги без ssh есть. Но проблемы нет — не надо просто ими пользоваться. Почти никто уже это не делает.
Угу, прекрасно жить в идеальном мире. В реальном же хостинг уже выбран и не вами, и php там 5.2 может быть. И прочее, прочее...AlexLeonov
18.03.2016 10:18+1Зачем вы работаете с хостингами без ssh и PHP 5.2?
Какой в этом смысл?
Я живу не в идеальном мире. Но недавно закончил перевод довольно большого проекта на PHP 7. Что удивительно — "перевод" занял от силы пару человеко-дней. Что я делаю не так? Где я упустил тот момент, когда надо рыдать о несовершенстве мира и злой судьбе?
Andrewus
18.03.2016 10:04Похоже, вы прочитали только краткую версию, "для тех, кто спешит", и сделали неверный вывод, что я — автор этой утилиты.
Я тот человек, которому иногда приходится пользоваться хостингами без ssh, потому что есть чертова уйма людей, которые их покупают и размещают на них свои проекты.
Поэтому я нашел еще одно решение для деплоя, которое умеет не так много, но зато и требует элементарного ini-конфига для работы. Зачем для простой задачи использовать сложные решения?
gwer
18.03.2016 10:34На любом сколько-нибудь терпимом хостинге есть SSH. Если SSH отсутствует, хостинг должен идти лесом, ибо с FTP вечно какие-то проблемы.
Имея SSH на хостинге, мы можем монтировать его диск к себе, используя SSHFS. Отсюда вытекает много плюсов, основные из которых:
- Возможность работать с удалённым сервером так, словно это делается локально.
- Возможность использовать любые инструменты, включая VCS (вытекает из предыдущего пункта).
Andrewus
18.03.2016 13:07Но я вижу и некоторые минусы, например:
- Ошибки сразу же оказываются на удаленном сервере
- Надо использовать обходные маневры для конфигов БД
Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?gwer
18.03.2016 13:18Ошибки сразу же оказываются на удаленном сервере
Я ж не призываю сразу на продакшоне разрабатывать. Это может быть dev-сервер. Ссылку на который можно в любой момент дать кому-либо. Плюс разрабатывать откуда угодно без лишних синхронизаций.
Надо использовать обходные маневры для конфигов БД
Механизмы миграций никто не отменял. SSH у нас есть, с ним можно творить прекрасные вещи.
Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?
Откровенно говоря, никогда не занимался замерами. Скорости всегда хватало.
Большое количество файлов, навскидку, проще сначала завернуть в архив, залить на сервер, а уже с сервера распаковать. Но это очень субъективно, с заливанием по FTP было резонно, а тут без замеров точно не сказать.
rmrevin
18.03.2016 11:26Присоединюсь к коменту выше. Нужно объяснять таким людям с хостингом без ssh и современного интерпритатора, что они делают неправильно.
Если я хочу построить карбюраторный завод и покупаю для его размещения квартиру в новостройке, то это явно не оптимальное решение. Конечно станки в квартире разместить можно, только для этого придется ломать наружнюю стену и вносить станки с помощью подъемного крана, или заносить станки по частям и собирать на месте.
Если Ваш проект требует сложной автоматизированной сборки, то и инструменты окружения должны быть соответствующими.Andrewus
18.03.2016 13:11+1А если вам нужно разместить швейную мастерскую? Она прекрасно помещается в квартиру.
Вообще, я, конечно, согласен, что нужно объяснять людям всё мракобесие хостингов без ssh, со старой версией пхп и т.п. Однако большинство людей по природе консерваторы, не любят перемен.
Для юридического лица, к тому же, смена хостинга сопряжена с бумажной работой. Особенно если он оплачен авансом на несколько лет, например.
AirWorker
18.03.2016 14:22+1Ого, какое ретро — шаред хостинг — как в 90х прямо ))
foxmuldercp
20.03.2016 01:22Кому хи-хи, а кто прошёл путь от техподдержки хостера до хостмастера.
И по итогам партии блекджека длиною в несколько лет пишет свою админ панель для вот этого всего.
И да, шаред хостинг очень популярная штука, но в реалиях СНГ рынок регистраторов доменов и хостингов адски, чертовски адски перегружен, даже не смотря на то что 90% сайтов на одном из серверов шареда раз в неделю заходят только гугль боты и раз в месяц пару живых людей — оно востребовано, да. Но прибыли приносит только у очень раскрученных крупных хостеров со своими цодами.
Но и стоит оно обычно копейки...
fzn7
И что мешает написать этот скрипт как рецепт для капистрано?
Andrewus
Принципиально — ничего, но если честно — многое: не хочется ставить ruby, не хочется писать рецепты. Да и вопрос по прожорливости — композер, например, на моей скромной VDS-ке отпадает из-за нехватки оперативной памяти.
Я худо-бедно могу разобраться и поправить чужой рецепт, но свои писать не хочется.
А тут красота — скрипт делает ровно то, что я хотел (даже немного больше) и мало требует для работы.