Деплой на shared-хостинг: боль и страдания или простая рутина?

    Коротко для тех, кто спешит


    Утилита 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
    

    Утилита расскажет, что она собирается делать и с какими файлами. Если вы сомневаетесь в списке игнорируемого — самое то.
    image

    Если всё хорошо — можно деплоиться:
    php deployment.php deployment.ini
    

    image

    Поначалу внимательно читайте, что вам напишет тестовый запуск. По очевидным причинам нельзя закачивать на сервер ftp-deployment.ini. Ну, и вообще, у кого-то и config.php.bak в проектах болтается…

    Мне утилита очень понравилась, с удовольствием пользуюсь и друзьям советую. Если знаете удобные альтернативы на других языках — буду благодарен.
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 27

      –1
      И что мешает написать этот скрипт как рецепт для капистрано?
        +1
        Принципиально — ничего, но если честно — многое: не хочется ставить ruby, не хочется писать рецепты. Да и вопрос по прожорливости — композер, например, на моей скромной VDS-ке отпадает из-за нехватки оперативной памяти.

        Я худо-бедно могу разобраться и поправить чужой рецепт, но свои писать не хочется.

        А тут красота — скрипт делает ровно то, что я хотел (даже немного больше) и мало требует для работы.
        0
        Здорово придумано и сделано хорошо!

        А нельзя такое сделать с помощью gulp?
          0
          Мне тоже понравилось. Думаю на досуге посмотреть, какие еще утилиты есть в репозитории автора.

          А gulp умеет заливать на удаленный сервер? По-моему, нет.
            0
            Вроде есть vinyl-ftp
              0
              Да, я даже нашел какие-то варианты.
              Но, по-моему, всё-таки это разные инструменты, хотя и совместить сборку с деплоем — звучит соблазнительно.
            0
            Можно. Пример https://gist.github.com/akalongman/5c9f7049ad7c534b057b
            –2
            Все мы любим классные и удобные методы деплоя с помощью… git pull

            Что? Что-что-что? )))

            Реальные пацаны делают так:

            1. Teamcity. До 20 сборочных конфигураций бесплатно.
            2. Teamcity видит изменения в Git. В нужной ветке, конечно же.
            3. Запускает "от бедра" rsync файлов в темповую директорию на целевом сервере
            4. В этой директории удаленно по ssh запускает сборочный скрипт на phing
            5. Скрипт делает всё остальное — раскладывает файлы по местам, накладывает конфиги с параметрами, миграции запускает, прокидывает симлинки и даже перезапускает php-fpm

            • бесплатно
            • удобно
            • один раз настроил и забыл
            • легко создавать тестовые стенды
            • phing умеет всё

            А вы велосипед изобретаете, уважаемый. Не-нуж-ный. Ну зачем в 2016 году что-то заливать по FTP?
              –1
              Мы на работе используем Git + Bamboo + Capistrano + Phing + Puppet, например, и тоже считаем себя реальными пацанами. Да, небесплатно, но зато отлично интегрируется друг с другом.

              А почему вы обвиняете меня в изобретении велосипеда, поясните?
                0
                Как бы вам объяснить.

                Во-первых не существует той проблемы, которую вы пытаетесь решать. Хостинги без ssh есть. Но проблемы нет — не надо просто ими пользоваться. Почти никто уже это не делает.

                Во-вторых решения для деплоя и сборки давно уже есть. И вы не добавили к ним ничего нового. Просто повторили, но при этом гораздо хуже. Зачем? Хотите принести пользу — добавьте новый task в phing, который будет делать что-то полезное. Вам только спасибо все скажут.
                  0
                  Хостинги без ssh есть. Но проблемы нет — не надо просто ими пользоваться. Почти никто уже это не делает.

                  Угу, прекрасно жить в идеальном мире. В реальном же хостинг уже выбран и не вами, и php там 5.2 может быть. И прочее, прочее...
                    +1
                    Зачем вы работаете с хостингами без ssh и PHP 5.2?
                    Какой в этом смысл?

                    Я живу не в идеальном мире. Но недавно закончил перевод довольно большого проекта на PHP 7. Что удивительно — "перевод" занял от силы пару человеко-дней. Что я делаю не так? Где я упустил тот момент, когда надо рыдать о несовершенстве мира и злой судьбе?
                      0
                      Что я делаю не так?

                      Работаете с большими проектами.
                      Описанные проблемы больше характерны для маленьких проектов и связаны с маленькими же бюджетами.
                        0
                        Да ладно.
                        И с маленькими вижу ту же картину. Объясните, зачем мне "хостинг", если я беру облачный инстанс "с рутом" за 250 рублей в месяц и сам себе хозяин — хочу PHP 7 поставлю, хочу — composer system-wide, хочу — сборочного агента TeamCity накачу?
                        "Хостинг"-то зачем?
                          +1
                          Вы можете брать себе, что вам нравится. Но у заказчиков могут быть свои предпочтения и они, как правило есть. /Какими бы странными они не казались, чаще всего они легко объясняются простотой и стоимостью эксплуатации (для заказчика, не для вас).
                          Например, их проект, для которого вы делаете только один модуль, написан на PHP4 (у меня был такой случай в конце 2015).
                          Есть масса проектов, где вы не хозяин. Примите на веру, если у вас такого опыта еще не было.
                            0
                            у заказчиков могут быть свои предпочтения

                            А) Я не работаю с такими заказчиками. Просто не стану. Зачем?
                            и Б) Я не верю, что заказчик может выбирать, к примеру, версию PHP. Ему пофигу на версию. Ему нужно, чтобы задачи решались.
                            А опыт в PHP у меня с 2004 года, уважаемый коллега. И я не припомню случаев, чтобы заказчик, обратившись ко мне и платя мне деньги, вдруг бы стал навязывать свои технические решения.
                              0
                              Я за вас рад. И ни в коем разе не агитирую за тот или иной способ деплоя.
                              Вы выразили сомнение в разумности и адекватности описанной автором методики. Я лишь подтверждаю — да, действительно, в этом году еще есть ситуации, когда используется FTP и ничего кроме.
                              У меня большинство заказчиков именно такие. Вы правы, они чаще всего не навязывают технические требования. Они сами просто не могут на них влиять. Чаще всего не имея полномочий в рамках своей организации или будучи посредниками.
                              То, что у вас все не так, это очень хорошо. Либо вам везет, либо вы как-то особенно ведете дела (поиск заказов, пресейл,… ).
                              Если второе, то расскажите об этом… может вы уже где-то писали или можете написать пост-другой?
                                0
                                Да нет, никакого везения. Просто четкая жизненная позиция — "Вы платите мне деньги за то, чтобы я определял, как сделать правильно". Если заказчик не согласен с этой максимой, он свободен в выборе другого подрядчика.
                                Я искренне не понимаю, что тут еще сказать? Хотите работать с PHP 7? Ну так начните это делать сейчас. Не хотите использовать FTP? Не используйте. Зачем из сугубо технических вопросов, решение которых входит в вашу зону ответственности, делать какую-то вселенскую трагедию?
                    0
                    Похоже, вы прочитали только краткую версию, "для тех, кто спешит", и сделали неверный вывод, что я — автор этой утилиты.

                    Я тот человек, которому иногда приходится пользоваться хостингами без ssh, потому что есть чертова уйма людей, которые их покупают и размещают на них свои проекты.

                    Поэтому я нашел еще одно решение для деплоя, которое умеет не так много, но зато и требует элементарного ini-конфига для работы. Зачем для простой задачи использовать сложные решения?
                0
                На любом сколько-нибудь терпимом хостинге есть SSH. Если SSH отсутствует, хостинг должен идти лесом, ибо с FTP вечно какие-то проблемы.
                Имея SSH на хостинге, мы можем монтировать его диск к себе, используя SSHFS. Отсюда вытекает много плюсов, основные из которых:

                1. Возможность работать с удалённым сервером так, словно это делается локально.
                2. Возможность использовать любые инструменты, включая VCS (вытекает из предыдущего пункта).
                  0
                  Но я вижу и некоторые минусы, например:

                  1. Ошибки сразу же оказываются на удаленном сервере
                  2. Надо использовать обходные маневры для конфигов БД

                  Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?
                    0
                    Ошибки сразу же оказываются на удаленном сервере
                    Я ж не призываю сразу на продакшоне разрабатывать. Это может быть dev-сервер. Ссылку на который можно в любой момент дать кому-либо. Плюс разрабатывать откуда угодно без лишних синхронизаций.

                    Надо использовать обходные маневры для конфигов БД
                    Механизмы миграций никто не отменял. SSH у нас есть, с ним можно творить прекрасные вещи.

                    Похоже, вы активно используете sshfs. Как там со скоростью? С большими файлами? С множеством мелких?
                    Откровенно говоря, никогда не занимался замерами. Скорости всегда хватало.
                    Большое количество файлов, навскидку, проще сначала завернуть в архив, залить на сервер, а уже с сервера распаковать. Но это очень субъективно, с заливанием по FTP было резонно, а тут без замеров точно не сказать.
                  0
                  Присоединюсь к коменту выше. Нужно объяснять таким людям с хостингом без ssh и современного интерпритатора, что они делают неправильно.

                  Если я хочу построить карбюраторный завод и покупаю для его размещения квартиру в новостройке, то это явно не оптимальное решение. Конечно станки в квартире разместить можно, только для этого придется ломать наружнюю стену и вносить станки с помощью подъемного крана, или заносить станки по частям и собирать на месте.

                  Если Ваш проект требует сложной автоматизированной сборки, то и инструменты окружения должны быть соответствующими.
                    +1
                    А если вам нужно разместить швейную мастерскую? Она прекрасно помещается в квартиру.

                    Вообще, я, конечно, согласен, что нужно объяснять людям всё мракобесие хостингов без ssh, со старой версией пхп и т.п. Однако большинство людей по природе консерваторы, не любят перемен.

                    Для юридического лица, к тому же, смена хостинга сопряжена с бумажной работой. Особенно если он оплачен авансом на несколько лет, например.
                    +1
                    Ого, какое ретро — шаред хостинг — как в 90х прямо ))
                      0
                      Кому хи-хи, а кто прошёл путь от техподдержки хостера до хостмастера.
                      И по итогам партии блекджека длиною в несколько лет пишет свою админ панель для вот этого всего.
                      И да, шаред хостинг очень популярная штука, но в реалиях СНГ рынок регистраторов доменов и хостингов адски, чертовски адски перегружен, даже не смотря на то что 90% сайтов на одном из серверов шареда раз в неделю заходят только гугль боты и раз в месяц пару живых людей — оно востребовано, да. Но прибыли приносит только у очень раскрученных крупных хостеров со своими цодами.
                      Но и стоит оно обычно копейки...
                      0
                      У PHPStorm хорошо это сделано. Можно указать, что деплоить а что нет. И самая полезная для меня фича — это показать, что сейчас отличается на сервере от локальной копии.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое