company_banner

VIM + screen. Организация удаленной среды web-разработки

    Миллион статей написано об организации рабочего процесса, редакторах кода, удобстве и стабильности работы. Я, не претендуя на «самый расчудесный способ», хочу рассказать, как организована среда web-разработки у нескольких человек из нашей команды. Сразу оговорюсь, если вы используете только локальные GUI-шные редакторы кода, Notepad++, Eclipse и т.п., то эта статья не для вас. Мы очень много работаем в консоли, и поэтому, в результате многолетнего естественного отбора, многие пришли к VIM, а консоль является практически отдельным табом в среде разработки, т.к. в процессе работы надо смотреть логи, писать запросы к базе, перезапускать сервисы и т.п. Поэтому, я хочу поделиться конкретным практическим рецептом организации среды web-разработки для программиста или админа, который много времени работает в стандартной удаленной консоли.


    С использованием данной схемы, наша рабочая среда на любом компьютере — это просто PuTTY и браузер, при этом мы имеем все радости многоэкранного, защищенного от сбоев средства разработки, которое целиком находится на стороне сервера. Когда внезапно мигает свет, все компы уходят в перезагрузку и со всех сторон доносятся популярные непечатные выражения, я просто заново соединяюсь с сервером и оказываюсь прямо посередине выражения, которое правил до перезагрузки. Это очень удобно, учитывая то, что на локальном компе у меня нет ничего, кроме PuTTY, браузера и WinAmp, и я могу спокойно сделать то же самое через 5 минут после того, как выкину свой комп из окна и возьму новый.

    Ну а если формально, то требования к среде разработки такие:
    • Текстовой редактор VIM
    • Windows на локальном компе (любая другая ОС с терминалом тоже подойдет)
    • Полное отсутствие рабочих настроек на локальном компе
    • Несколько параллельных полноценных консолей (логи, консоль БД, конфиги всякие, код, шаблоны и т.д.)
    • Каждая консоль — это таб, переключение между которыми осуществляется при помощи Shift + <стрелки вправо-влево>
    • Сохранение состояния всех консолей (табов) при отключении от сервера


    Есть и минусы:
    • Нет сети — нет работы. Ни буковки. Хотя, для web-разработчика, трудящегося на тестовом сервере, без сети работать все равно нереально, так что я не считаю это серьезным недостатком
    • Только консольные редакторы кода. Как я уже упоминал, все нижеописанное будет касаться работы в консолях, т.к. главной рабочей лошадкой будет linux-овый screen
    • Т.к. у PuTTY свой текстовой буфер, а у screen свой, и они не знают друг о друге, то для того, чтобы промотать наверх вывод какого-нить длинного SELECT-а, придется нажать Сtrl+A и затем ESC, после чего можно курсором и PgUp, PgDown ходить по буферу screen-a вверх и вниз, а нажатием «Enter» выйти из режима перемещения по буферу screen-a


    Я человек ленивый, вычитывать кучу конфигурационных опций и вникать в тонкости работы используемых программ мне не слишком интересно, поэтому многие куски конфигов я просто скопировал из нескольких разных статей, авторам которых респект и глубокое человеческое спасибо.

    Для начала, два скриншота из PuTTY, точнее, её модификации, begPuTTY. Я использую begPuTTY только для одной цели: она корректно передает в консоль сочетание клавиш Shift + Arrow Left и Shift + Arrow Right, которые мне нужны для переключения между консолями «а-ля» xterm. Скачать её и поблагодарить автора, можно тут. Если вы готовы использовать другое сочетание клавиш для смены таба, то можете использовать обычную PuTTY. Вот, собственно, и всё, что мне нужно для работы над проектом. Portable, не правда-ли?

    Итак, скриншоты:

    image

    image

    Самое интересное тут — нижняя строка, там, где AUTO1, AUTO2 и т.д. Это табы, я переключаюсь между ними при помощи того-самого вожделенного Shift+Arrow Left/Right, при этом каждый из них является полноценной отдельной консолью, состояние которой бережет отдельный screen. Например, в AUTO2 обычно висит открытая консоль mysql, а в AUTO3 и AUTO4 код. Рекомендую не жадничать с количеством табов, т.к. человек может эффективно держать в памяти, не путаясь, от 6 до 9 сущностей. Такое количество табов можно без проблем держать в голове и помнить, что в каком происходит. Если сделать больше, то придется тратить время на то, чтобы вспомнить что где. Но это так, экскурс в начала когнитивной психологии…

    Зайдя на сервер, я запускаю команду подключения к нужному проекту, и screen либо создаёт мне восемь новых независимых консолей с табами в строке состояния, либо подключается к текущим, восстанавливая состояние каждой отдельной консоли.

    Пусть у меня есть два проекта, например, «auto» и «moto», в каждом из них своё окружение и свой набор screen-ов. У меня один .bashrc, в котором прописано разное окружение и разные alias-ы для каждого проекта в зависимости от переменной окружения $PROJ. Вот этот .bashrc:

    # .bashrc
    
    # здесь то, что обычно лежит в .bashrc и не относится к нашей проблеме
    # …
    
    # ВОТ ГЛАВНОЕ – алиасы, которые запускают screen с параметрами,
    # говорящими ему подключаться к существующим скринам, если они есть, или создать новые
    
    alias auto='screen -AadRRS auto_screen -c /home/supergdeto/WORK/.screenrc_auto'
    alias moto='screen -AadRRS moto_screen -c /home/supergdeto/WORK/.screenrc_moto'
    
    # теперь так, если $PROJ == ‘auto’ – готовлю ENV для проекта “auto”
    If [ "$PROJ" = 'auto' ]; then
    export PROJECTPATH="/home/supergdeto/auto/"
    alias chik_chik_i_v_production='echo “yupi”'
    cd /home/supergdeto/auto/
    # куча всего по проекту auto
    fi
    
    # для ‘moto’ – свои настройки 
    If [ "$PROJ" = 'moto' ]; then
    export PROJECTPATH="/home/supergdeto/moto/"
    alias chik_chik_i_v_production='echo “yupi”'
    cd /home/supergdeto/moto/
    # куча всего по проекту moto
    fi
    
    


    Отдельный screen (один из табов) запускается очень просто — скриптом из пары строк. Два таких простых файлика для «auto» и «moto»:

    $ cat /home/supergdeto/WORK/dev_env_auto
    export PROJ=auto
    bash
    


    $ cat /home/supergdeto/WORK/dev_env_moto
    export PROJ=moto
    bash
    


    Ну и наконец, главное: .screenrc_auto (.screenrc_moto сделанпо аналогии)

    $ cat /home/supergdeto/WORK/.screenrc_auto

    # Turn off start message:
    startup_message off
    
    # Set messages timeout to one second:
    msgwait 1
    
    # keep scrollback n lines
    defscrollback 5000
    
    hardstatus             alwayslastline
    
    termcapinfo xterm*|rxvt*|kterm*|Eterm* 'hs:ts=\E]0;:fs=\007:ds=\E]0;\007'
    termcapinfo xterm ti@:te@7 
    
    # эта строка как раз рисует табы внизу, в строке состояния, подсвечивает текущий и т.п.
    hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{y}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
    
    nethack on
    vbell off
    
    #  Здесь комбинациям Shift+Arrow Left/Right назначается переключение между табами
    bindkey ^[[1;2C next
    bindkey ^[[1;2D prev
    
    # ну а здесь я создаю 8 скринов AUTO1 – AUTO8
    
    screen -t AUTO1 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO2 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO3 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO4 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO5 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO6 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO7 /home/supergdeto/WORK/dev_env_auto
    screen -t AUTO8 /home/supergdeto/WORK/dev_env_auto
    


    В конце файла как раз те 8 скринов-табов с их названиями. Чтобы к ним подключиться, я логинюсь, набираю «auto», запускается screen -AadRRS auto_screen -c /home/supergdeto/WORK/.screenrc_auto, который либо создает новые скрины, либо коннектится к существующим. По нашему опыту, новые скрины обычно создаются только тогда, когда девелоперский сервер перегружается или какой-нибудь бинарный вывод «взорвал» screen. Бывает это крайне редко, так что обычно мы не волнуемся даже за несохраненные файлы.


    Ну а теперь бонус! То, чего мне, ленивому, ужасно не хватало во всех статьях, чтобы по-быстрому попробовать эту штуку в деле. Хоть тресни, неохота разбираться в тонкостях работы screen, передаче кодов клавиш в PuTTY, рисовать форматы строки состояния. Тот, кому это по душе, уже давным-давно все сделал лучше меня, поэтому, внимание, пошаговая инструкция для желающих попробовать. Если проектов несколько, то просто повторите шаги 3-8 для нового проекта. Пусть user: avatar, проект: projectone

    1. Скачайте себе begPutty отсюда и используйте его
    2. Создайте каталог /home/avatar/WORK
    3. создайте в WORK исполняемый файлик dev_env_projectone, (он запускает отдельный таб) и запишите туда две строки
      export PROJ=projectone
      bash
      

    4. там же создайте файл .screenrc_projectone (он стартует пачку скринов, запуская в каждом из них файлик dev_env_projectone ), скопируйте в него содержимое листинга .screenrc_auto из данной статьи
    5. переименуйте в нем строки типа «screen -t AUTO1 /home/supergdeto/WORK/dev_env_auto» в «screen -t PROJECTONE1 /home/avatar/WORK/dev_env_projectone» и сделайте количество этих строк равным необходимому числу табов
    6. в .bashrc, если вам нужно различное окружение для разных проектов, добавьте раздел для PROJ==”projectone”, типа так:
      If [ "$PROJ" = 'projectone' ]; then
      	# Здесь всё, что относится к настройке окружения при работе с проектом projectone
      fi
      

    7. там же, в .bashrc добавьте alias
      alias projectone='screen -AadRRS projectone_screen -c /home/avatar/WORK/.screenrc_projectone'
    8. перелогиньтесь, либо выполните .bashrc


    Теперь соединяйтесь с сервером, набирайте в консоли «projectone», и у вас появятся ваши табы. В каждом из них будет консоль с окружением для проекта “projectone”;

    Начните набирать «SPASI...» и внезапно выдирайте LAN или питание из разъёма, или вырубайте WiFi. Затем повторите операцию, и допишите, наконец, волшебное слово…
    Mail.ru Group
    1515,00
    Строим Интернет
    Поделиться публикацией

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

      +7
      Рекомендую вместо screen — tmux

      screen настолько жестого захардгажен, что его уже не поддерживают. А tmux няшен
        +1
        да, народ хвалит, обязательно заценю, спасибо
          0
          Пробовал пересесть на tmux — имхо, коробочный вариант не удобен, а допиливать каждый раз становилось влом, проще перейти обратно на screen :)

          Ещё полезная фишка мультиплексеров — это возможность копирования между окнами. В скрине <C-A><C-[> или <C-A><Еsc> для перехода в режим копирования, <Space> для перехода в аналог visual mode, vim'овского, для собственно копирование и <C-A><C-]> для вставки (в tmux это всё тоже есть, но не помню биндинги, плюс там нет из коробки навигации в стиле vim).
            +1
            Долго пользовался screen, но потом начал упираться в возможности. Переход на tmux был в основном сложен только хоткеем, вместо ctrl + A надо нажимать ctrl + b. Пару дней помучился и привык. Пользую только коробочный вариант без переделок. Tmux у меня штатно на всех машинах, коих больше 2х десятков. Разрабатываю через удаленную консоль, всегда в tmux. Для продакшина пользую в виде дашборда.

            Дашборд на LAMP кластере из 10 машин
            habrastorage.org/storage3/cdf/ae7/5d4/cdfae75d485bbbcaf671b466464b6b14.png

            Разработка
            habrastorage.org/storage3/235/a68/3be/235a683be7c196698d20b287ddfbd3ec.png
              0
              чистейший хардкор!
                0
                awesome прекрасен!
                  0
                  awesome потрясающ!
                  0
                  объясните мне зачем разрабатывать на удалённой машине когда у вас локально есть awesome? я не понимаю :)
                    0
                    Awesome — это для души. А для разработки только хардкор — vim + tmux
                      0
                      По мне так гораздо удобнее организоывать окошки в awesome чем где бы то ни было.

                      Я предпочитаю awesome + gvim :)
                        0
                        awesome + gvim хорошо работают когда одновременно работаешь над одним проектом. Я же курирую несколько десятков и все идут одновременно. Поэтому держу много изолированных tmux + vim c соответствующими консолями и tail -f логами, поэтому же и работаю в основном на удаленных серверах.
                          0
                          ну разные проекты я раскидываю по разным эээ, воркспейсам? рабстолам?
                          но вот tail -f, конечно, имеет смысл.

                          Спасибо.
                            0
                            Извините, а вы не могли бы мне в скайп какой постучаться. Я бы у вас спросил немного разного про организацию вашего рабочего места.
                              0
                              Tmuxinator?
                  0
                  > Когда внезапно мигает свет, все компы уходят в перезагрузку и со всех сторон доносятся популярные непечатные выражения…

                  Ноутбуки в мейлру не выдают?
                    0
                    выдают, просто многие предпочитают стационарные компы
                      +1
                      А бесперебойники?)
                        +3
                        У нас один очень большой бесперебойник на всех :)
                    0
                    Windows на локальном компе (любая другая ОС с терминалом тоже подойдет), как требование к среде разработки вызывает восхищение. Хорошо бы, на мой взгляд, раскрыть тему шире и написать еще о переадресации портов (port forwarding) позволяющем например потрогать боевой SQL сервер локально и разделяемом соединении (connection multiplexing) позволяющем обратиться к серверу из разных консолей, программ в рамках одного соединения.
                      +1
                      Спасибо, подумаю, надо только выбрать какой-нибудь кейз поконкретней. Вообще за «потрогать боевой SQL сервер» у нас расстреливают уже давным-давно, доступ есть только к read-only реплике, а multiplexing вообще что-то не могу сообразить к чему прикрутить в процессе разработке
                        0
                        Хорошо бы, на мой взгляд, раскрыть тему шире и написать еще о переадресации портов (port forwarding) позволяющем например потрогать боевой SQL сервер локально


                        Но ведь впн проще и мобильнее :)
                        0
                        спасибо, реализовал — оч. удобно.
                        всяо-разно лучше, чем держать по пять-восемь открытых патти окон.
                        чуть допилили ваш автоскрипт, сразу прописали запуск баша на 8 окон
                        # ну а здесь я создаю 8 скринов AUTO1 – AUTO8

                        screen -t AUTO1 /bin/bash
                        screen -t AUTO2 /bin/bash


                        можно сразу прописывать открытие консольного мускуля с нужной БД (через баш)
                          0
                          а можно как-то подписывать вкладки?
                            0
                            Да, здесь:
                            screen -t AUTO1 /bin/bash
                            ты именуешь табы (AUTO1, AUTO2 и т.п, например:

                            screen -t CONSOLE1 /bin/bash
                            screen -t MYSQL1 <запуск bash с открытием консоли>
                            screen -t PERL1 /bin/bash
                            screen -t PERL2 /bin/bash

                            а если тебе надо, чтобы в названиях табов было больше всякой полезной инфы(пути может, серваки, и т.п.), возишься вот с этой строкой в .screenrc_<твойпроект>

                            # эта строка как раз рисует табы внизу, в строке состояния, подсвечивает текущий и т.п.
                            hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{y}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'

                            для этого читаешь доку по «hardstatus» в screen. Как я сказал, я ленивый и стырил эту строку у отцов
                              0
                              спасибо
                                0
                                /bin/bash нужно указывать только если у вас дефолтовый шелл не bash.
                                Плюс, не понял чем Ctrl+A Space и Ctrl+A Backspace не устроили в обычном PuTTY? Количеством кнопок?
                                  0
                                  Угу, именно так. Если писать код, прыгать с шаблона в код и обратно тремя кнопами мне, например, не очень удобно. Субъективно, конечно, но очень хотелось эдакий xterm под Windows
                              0
                              Открытие мускуля у меня сделано алиасом, и реализовано как раз в разделах «if PROJ=='auto'», я не стал приводить их из соображений безопасности. И одна и та же команда открывает в разных проектах разные консоли.

                              0
                              В тегах можно смело добавить «администрирование», screen очень полезен, спасибо за статью. Хотя всегда хватало fg, bg, jobs.
                                +1
                                для того, чтобы промотать наверх вывод какого-нить длинного SELECT-а, придется нажать Сtrl+A и затем ESC, после чего можно курсором и PgUp, PgDown ходить по буферу screen-a вверх и вниз

                                Удобно настроить pager в ~/.my.cnf

                                [mysql]
                                pager = less -FSinXR

                                А можно еще и вывод раскрасить с grcat
                                  0
                                  Спасибо, ух полезная тема! Чувствую, что почитав комментарии к своей статье, легко сгенерирую новую :)

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

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