Представляю общественности утилиту RealSync (GPL). Ее призвание — облегчить работу тех, кто периодически мучается от лагов сетевой папки Samba при поиске/редактировании файлов веб-проекта. Идея RealSync в том, что вы теперь работаете с файлами сайта на локальной машине в привычной IDE, а результат, как и прежде, смотрите на удаленном разработческом веб-сервере, куда RealSync копирует изменения в реальном времени. В результате вы можете, например, запустить поиск по всем файлам в IDE — они же локальные, а не подключены через сетевую папку по Samba, так что поиск работает очень быстро; при этом ваш Ctrl+S продолжает попадать на сервер моментально, как и при работе через сетевую папку.
RealSync — утилита для Windows, MacOS и Linux, позволяющая в реальном времени содержать на удаленном сервере точную копию файлов (например, скриптов на PHP, Python, Ruby и др.) из папки на вашем локальном компьютере, даже в условиях плохой связи, когда вы работаете из дома. Все изменения, производимые в локальной папке, попадают на сервер практически моментально (задержка около 0.2 с), независимо от того, сколько этих изменений и каким именно образом они были внесены (хоть через IDE, хоть через Блокнот или Far).
Главное отличие RealSync от аналогов — в том, что он крайне устойчив к нестабильности интернет-соединения, реконнектам и тайм-аутам. При этом используется SSH-соединение, доступ через которое конфигурируется автоматически при первом запуске утилиты (т.е. не нужно возиться с ключами — настройка производится в интерактивном режиме).
Фактически, случайно «убить» RealSync почти невозможно. Вы можете держать его постоянно свернутым в трее и забыть про его существование (CPU он почти не ест). Если утилита видит, что соединение разорвалось на длительный срок, автоматически запускается знакомый многим алгоритм RSYNC для быстрого копирования большого количества различий. В режиме же реального времени применяется собственный протокол поверх SSH, чтобы при нажатии Ctrl+S в редакторе вы сразу же видели изменения на сервере. Передача файла сопровождается приятным «треньканьем» (отключаемым при необходимости в конфиге), а временная потеря связи — покраснением иконки (когда связь восстановится, иконка обратно станет серой, а RealSync «догонит» накопившиеся изменения).
И зачем этот велосипед, когда есть Samba или Денвер или XAMPP?
Вообще говоря, существует несколько способов вести разработку веб-скриптов. Первый способ — использовать локальный веб-сервер. У данного метода есть как масса преимуществ (больший контроль, улучшение переносимости и кроссплатформенности и т.д.), так и масса недостатков, как то: потенциальное отличие конфигурации локального сервера от конфигурации дев- и продакшен-зон, необходимость либо следить за синхронностью локальной SQL-базы, либо ждать, пока тормозит доступ к единой дев-базе по интернету и т.д. Мы не будем в данной статье рассматривать этот метод, хотя он, безусловно, имеет право на жизнь (и, как минимум, применяется 1 миллионом зарегистрированных пользователей того же Денвера).
Второй способ — использовать веб-сервер, установленный в офисе компании (или на тестовой машине в датацентре), обслуживаемый штатными админами. На таком веб-сервере может быть несколько директорий, по одной для каждого разработчика. Каждый программист ведет работу в своей директории, чтобы не мешать другим, и смотрит результат на своем поддомене (или на своем номере порта). Вот этот способ мы и рассмотрим.
Использование удаленной папки для веб-разработки
К директории на удаленном сервере нужно ведь как-то «доступаться». В наиболее распространенном случае ее просто подключают в качестве сетевой папки на локальную машину по Samba. Этот способ имеет сразу несколько неудобств:
- Для сносной скорости работы вы должны находиться в той же локальной сети, что и сервер.
- Но даже в этом случае вам будет довольно затруднительно запустить поиск по всем файлам большого проекта в IDE — слишком большая задержка.
- В случае разрыва соединения (или же вы не дай бог работаете из дома через интернет) — будьте готовы к странным эффектам и неприятным лагам.
Я знаю многих людей, которые для обхода неудобства (2) заходят по SSH на сервер и в консоли используют grep для поиска по файлам, причем сами работают в IDE. Мне это кажется верхом неудобства. Тем более что в phpStorm, например, поиск по всем локальным файлам даже очень большого проекта работает ощутимо быстрее grep-а и занимает 1-2 секунды (как они этого добились — для меня загадка; видимо, индексируют что-то заранее). Лично я постоянно и с комфортом пользуюсь поиском в phpStorm по локальным файлам — в среднем раз по 50 в день.
Есть еще, конечно, любители работать в VIM в SSH-консоли прямо на сервере; я их уважаю, но вряд ли когда примкну к их лагерю: все-таки удобства, предоставляемые хорошей графической IDE, для меня перевешивают.
По большему счету RealSync — это решение проблемы скорости работы IDE
Итак, чтобы решить проблему скорости поиска, нужно хранить исходники на локальном диске и искать уже по ним. И сразу же возникает вопрос, как исходники попадут на удаленный веб-сервер при нажатии Ctrl+S. Тут возможны несколько вариантов.
- Почти все IDE поддерживают передачу измененного файла (по FTP или SSH) на удаленный сервер при нажатии Ctrl+S. Но только здесь две проблемы. Во-первых, вы не сможете изменять файлы «мимо» IDE (например, сделать git pull из командной строки на локальной машине). Во-вторых, если вы на несколько дней исчезнете из
реальностиинтернета, а потом вернетесь с измененными файлами, IDE уже не сможет определить, какие файлы изменились (особенно если они еще случайно и на сервере поменялись почему-то независимо от вас), и в лучшем случае начнет полное копирование, что займет полчаса. - Запустить в вечном цикле RSYNC. Это более-менее работает, когда проект не очень большой, когда интернет хороший и когда вы сидите НЕ на Windows (в Windows RSYNC весьма медленный при запуске). Во всех остальных случаях будьте готовы к 2-3-секундным задержкам.
- Использовать специальную утилиту синхронизации, такую как RealSync, Unison, WinSCP и т.д.
RealSync задумывался как инструмент, обеспечивающий устойчивую работу в условиях плохой связи и не требующий внимания от программиста («запустил и забыл»). Именно таким он и получился, в отличие от многочисленных аналогов.
А если мне нужна двусторонняя синхронизация?
Это очень популярный вопрос, связанный с тем, что RealSync всегда затирает любые изменения, производимые напрямую в папке на сервере (если не сразу, так при очередном реконнекте точно). Только изменения в локальной папке имеют смысл и приоритет.
Но давайте задумаемся, зачем может понадобиться двусторонняя синхронизация?
- Вы хотите работать, например, с Git в консоли на сервере? Но зачем? Ведь можно поставить Git на свою машину и пользоваться всеми преимуществами локальной работы и разными GUI для Git.
- Ваши скрипты пишут в какую-то локальную папку в рамках директории документов? Добавьте эту папку в исключения RealSync (это делается легко, одной строчкой в конфиге или при самом первом запуске). К тому же делать директорию документов доступной для записи скриптами — это антипаттерн.
- Вы работаете на ноутбуке дома и на другом десктопе — на работе и хотите синхронизировать файлы через папку веб-сервера? Но ведь веб-сервер — это не средства синхронизации и контроля версий. Используйте лучше Dropbox или коммитьте в систему контроля версий.
- Вы активно используете симлинки в рабочей копии на сервере? Ну… а не пробовали перестать их использовать, это как минимум упростит поддержку и развертывание в будущем?
В целом нужно понимать, что RealSync — это не синхронизатор, это репликатор. Если перестать воспринимать папку на веб-сервере как нечто самостоятельное, а считать ее просто автоматическим «зеркалом» и перестать ходить в нее руками по SSH (действительно, зачем это делать?), все встает на свои места. И в большинстве случаев оказывается, что двусторонняя синхронизация просто не нужна (но если вы по-прежнему считаете иначе, пользуйтесь Unison-ом — если он у вас приживется, конечно.)
Установка RealSync и первый запуск
Все достаточно просто: сначала нужно скачать RealSync и скопировать его куда-нибудь, а затем где-то (в Автозагрузке или на Рабочем столе) разместить ярлык со следующей командной строкой:
"C:/Program Files/dklab_realsync/realsync.exe" ПолныйПутьДоВашейПапкиИсходников - или для MacOS и Linux - perl /opt/dklab_realsync/realsync ПолныйПутьДоВашейПапкиИсходников
При первом запуске вы получите примерно такое окно, в котором нужно будет в интерактивном режиме ввести адрес сервера, ваш SSH-логин и пароль на нем (пароль запрашивается исключительно процессом SSH и не сохраняется на локальной машине, см. ниже), имя папки на удаленном сервере и т.д.
Если вы уже имеете беспарольный доступ к серверу по SSH-ключу, пароль не будет запрашиваться вообще, даже в первый раз. Если еще не имеете — RealSync сам сгенерирует открытый+закрытый ключ, отрытый положится на сервер, а закрытый — в вашу домашнюю директорию на локальной машине (в специальную папку, которую воспринимает RealSync).
Остальные настройки конфигурации запишутся в файл ПолныйПутьДоВашейПапкиИсходников/.realsync, так что при следующем запуске уже никаких вопросов задано не будет, а просто запустится синхронизация, и программа свернется в трей (для Windows).
Теперь можно править любые исходники и убеждаться, что они моментально попадают на сервер. Если кликнуть на иконку запущенного RealSync в трее, то процесс работы можно наблюдать примерно вот в таком окне:
Дистрибутив RealSync для Windows является самодостаточным: он уже включает в себя RSYNC, SSH, мини-версию Perl и другие необходимые утилиты, так что вам достаточно будет просто запускать realsync.exe и ни о чем этом не думать. В MacOS и Linux же все эти утилиты, как правило, уже имеются в системе, поэтому они и используются.
Итак, RealSync висит в трее, вы его никогда не выключаете, поэтому у вас возникает полная иллюзия, что вы работаете на локальной машине с удаленной папкой. При этом вы имеете все преимущества производительности локального поиска и работы с IDE. Вот это и была цель разработки RealSync.
Буду рад, если утилита сделает еще чью-нибудь повседневную работу легче. Комментарии приветствуются.
Автор: DmitryKoterov
