Разработка программного обеспечения в любом месте: мое распределенное удаленное рабочее место

Работа удаленным фрилансером имеет много преимуществ, но создание эффективной распределенной рабочей среды может стать настоящей проблемой. Конечно, существует множество подходов, которые можно использовать, и ни один «лучший» способ не подойдет всем. Организация удаленного цифрового рабочего места — это действительно очень личная вещь, и то, что хорошо работает для одного разработчика, может совершенно не сработать для кого-то другого.

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

Мой подход в значительной степени основан на функциях, предлагаемых SSH и соответствующими инструментами в Linux. Обратите внимание, что пользователи MacOS и других Unix-подобных систем также могут воспользоваться преимуществами описанных процедур, если их системы поддерживают описанные инструменты.

Мой личный мини-сервер

Важным первым шагом в моей настройке является сервер на базе Raspberry Pi 2 в моем собственном доме, используемый для размещения всего, от моих репозиториев исходного кода до демонстрационных сайтов.

Хотя я путешествую, моя квартира служит моей удаленной «стационарной базой операций» с приличным подключением к Интернету (100 Мбит/с) и почти без дополнительных задержек. Это означает, что из моей квартиры я в основном ограничен только скоростью сети назначения. Настройка, которую я описываю, лучше всего работает с этим типом подключения, хотя это и не является обязательным требованием. На самом деле, я также использовал этот подход, когда у меня было ADSL-соединение с относительно низкой пропускной способностью, и большинство вещей работало нормально. Единственное реальное требование, по моему опыту, состоит в том, чтобы пропускная способность была либо неизмеримой, либо очень дешевой.

Как домашний пользователь, у меня есть самый дешевый домашний сетевой маршрутизатор, который мой интернет-провайдер мог купить, которого просто недостаточно для того, что мне нужно делать. Поэтому я попросил интернет-провайдера перевести маршрутизатор в «режим моста», где он служит только терминатором соединения, предлагая конечную точку PPPoE только для одной подключенной системы. Это означает, что устройство перестает работать как точка доступа Wi-Fi или даже как обычный домашний маршрутизатор. Со всеми этими задачами справляется профессиональный маленький роутер Mikrotik RB951G-2HnD. Он выполняет службу NAT для моей локальной сети (которую я пронумеровал 10.10.10.0/24) и предлагает DHCP для подключенных к ней проводных и беспроводных устройств. Mikrotik и Raspberry Pi имеют статические адреса, потому что они используются в контекстах, где требуется общеизвестный адрес. В моем случае это 10.10.10.1 и 10.10.10.10 соответственно.

Мое домашнее подключение не имеет статического IP-адреса. Для меня это лишь небольшое неудобство при удаленной работе, поскольку цель состоит в том, чтобы создать личную рабочую среду или рабочую среду SOHO, а не сайт, работающий круглосуточно и без выходных. (Для тех, кому требуется статический IP-адрес для своего сервера, стоит отметить, что стоимость статических IP-адресов продолжает снижаться, и доступны довольно недорогие варианты статического IP-адреса VPN.) DNS-брокер, который я использую, Joker.com. , предлагает бесплатную динамическую службу DNS наряду со всеми другими своими службами, поэтому один поддомен моего личного домена существует как динамическое имя. Я использую это имя для подключения извне к собственной сети, а Mikrotik настроен на передачу SSH и HTTP через NAT на Raspberry Pi. Мне просто нужно ввести эквивалент ssh mydomain.example.com , чтобы войти на мой личный домашний сервер.

Данные в любом месте

Одна важная вещь, которую Raspberry Pi не предлагает, — это избыточность. Я оснастил его картой на 32 ГБ, и в случае чего можно потерять много данных. Чтобы обойти это и обеспечить доступ к своим данным в случае сбоев в домашнем доступе в Интернет, я зеркалирую все свои данные на внешний облачный сервер. Поскольку я нахожусь в Европе, для меня имело смысл приобрести самый маленький выделенный «голый» (т.е. не виртуализированный) сервер от Online.net, который поставляется с младшим процессором VIA, предлагает 2 ГБ ОЗУ и 500 ГБ SSHD. Как и в случае с мини-сервером Raspberry Pi, мне не нужна высокая производительность процессора или даже память, так что это идеальное сочетание. (Кроме того, я помню свой первый «большой» сервер с двумя процессорами Pentium 3 и 1 ГБ ОЗУ, который, вероятно, был вдвое медленнее Raspberry Pi 2, и то, как мы с ним добились отличных результатов, что повлияло на мой интересует оптимизация)

Я делаю резервную копию своего Raspberry Pi на удаленном облачном сервере, используя rdiff-backup. Судя по относительным размерам систем, эти резервные копии дадут мне практически неограниченную историю. Еще одна вещь, которую я имею на облачном сервере, — это установка ownCloud, которая позволяет мне запускать частную службу, подобную Dropbox. ownCloud как продукт движется в сторону группового программного обеспечения и совместной работы, поэтому он становится еще более полезным, если его использует больше людей. С тех пор, как я начал его использовать, у меня буквально нет никаких локальных данных, которые не были бы скопированы ни на Raspberry Pi, ни на облачный сервер, и большинство из них скопировано дважды. Любая дополнительная резервная избыточность, которую вы можете сделать, всегда полезна, если вы цените свои данные.

«Магия» SSHFS

Большая часть моей работы в эти дни связана с разработкой материалов, которые не имеют прямого отношения к сети (знаю, это шокирует!), поэтому мой рабочий процесс часто следует классическому циклу редактирования-компиляции-запуска. В зависимости от конкретных обстоятельств проекта, у меня могут быть файлы локально на моем ноутбуке, я могу поместить их в каталог ownCloud-synced или, что более интересно, я могу поместить их прямо на Raspberry Pi и использовать их оттуда. .

Последний вариант стал возможен благодаря SSHFS, который позволяет мне локально монтировать удаленный каталог из Raspberry Pi. Это похоже на маленькое волшебство: вы можете иметь удаленный каталог на любом сервере, к которому у вас есть доступ по SSH (работающем с разрешениями, которые ваш пользователь имеет на сервере), смонтированный как локальный каталог.

У вас есть удаленный каталог проекта? Смонтируйте его локально и вперед. Если вам нужен мощный сервер для разработки или тестирования и — по какой-то причине просто пойти туда и использовать vim в консоли не вариант — смонтируйте этот сервер локально и делайте все, что хотите. Это работает особенно хорошо, когда я подключен к Интернету с низкой пропускной способностью: даже если я работаю в консольном текстовом редакторе, опыт будет намного лучше, если я запущу этот редактор локально, а затем просто передам файлы через SSHFS, а не чем работа через удаленный сеанс SSH.

Нужно сравнить несколько каталогов /etc на разных удаленных серверах? Без проблем. Просто используйте SSHFS для локального монтирования каждого из них, а затем используйте diff (или любой другой применимый инструмент) для их сравнения.

Или, возможно, вам нужно обрабатывать большие лог-файлы, но вы не хотите устанавливать инструмент для разбора логов на сервер (потому что у него бессчетное количество зависимостей) и по какой-то причине копирование логов неудобно. Еще раз, не проблема. Просто смонтируйте удаленный каталог журналов локально через SSHFS и запустите любой инструмент, который вам нужен, даже если он огромный, тяжелый и управляемый с графическим интерфейсом. SSH поддерживает сжатие «на лету», а SSHFS использует его, поэтому работа с текстовыми файлами довольно экономична.

Для своих целей я использую следующие параметры командной строки sshfs :

sshfs -o reconnect -o idmap=user -o follow_symlinks -C server.example.com:. server

Вот что делают эти параметры командной строки:

• -o reconnect — указывает sshfs переподключить конечную точку SSH, если она сломается. Это очень важно, так как по умолчанию при обрыве соединения точка монтирования либо резко завершается, либо просто зависает (что, как я обнаружил, встречается чаще). Мне действительно кажется, что это должно быть вариантом по умолчанию.
• -o idmap=user — указывает sshfs сопоставить удаленного пользователя (т. е. пользователя, под которым мы подключаемся), чтобы он совпадал с локальным пользователем. Поскольку вы можете подключиться через SSH с произвольным именем пользователя, это «исправляет» ситуацию, поэтому локальная система считает, что пользователь тот же. Права доступа и разрешения в удаленной системе применяются, как обычно, для удаленного пользователя.
• -o follow_symlinks — Хотя у вас может быть произвольное количество подключенных удаленных файловых систем, я считаю более удобным монтировать только один удаленный каталог, мой домашний каталог, и в нем (в удаленном сеансе SSH) я могу создавать символические ссылки на важные каталоги в другом месте удаленной системы, например /srv или /etc или /var/log . Этот параметр позволяет sshfs разрешать удаленные символические ссылки в файлы и каталоги, позволяя вам переходить к связанным каталогам.
• -C — включает сжатие SSH. Это особенно эффективно с метаданными файлов и текстовыми файлами, поэтому кажется, что это еще одна вещь, которая должна быть опцией по умолчанию.
• server.example.com:. - Это удаленная конечная точка. Первая часть (в данном примере server.example.com ) — это имя хоста, а вторая часть (после двоеточия) — удаленный каталог для монтирования. В этом случае я добавил «.» чтобы указать каталог по умолчанию, в котором мой пользователь оказывается после входа в систему SSH, который является моим домашним каталогом.
• server — локальный каталог, в который будет смонтирована удаленная файловая система.

Особенно, если у вас низкая пропускная способность или нестабильное подключение к Интернету, вам необходимо использовать SSHFS с аутентификацией по открытому/закрытому ключу SSH и локальным агентом SSH. Таким образом, вам не будет предложено ввести пароли (либо системные пароли, либо пароли ключей SSH) при использовании SSHFS, а функция повторного подключения будет работать, как заявлено. Обратите внимание, что если у вас не настроен агент SSH, чтобы он предоставлял разблокированный ключ по мере необходимости в рамках сеанса, функция повторного подключения обычно не работает. В Интернете полно руководств по ключам SSH, и большинство настольных сред на основе GTK, которые я пробовал, запускают свой собственный агент (или «кошелек», или как они его называют) автоматически.

Некоторые продвинутые хитрости SSH

Наличие фиксированной точки в Интернете, которая удаленно доступна из любой точки мира и подключена к высокоскоростному соединению — для меня это моя система Raspberry Pi, и это действительно может быть любой общий VPS — снижает стресс и позволяет вам делать всякие штуки с обменом и туннелированием данных.

Нужен быстрый nmap, и вы подключены через сеть мобильного телефона? Просто сделайте это с этого сервера. Нужно быстро скопировать некоторые данные, а SSHFS — это излишество? Просто используйте обычный SCP.

Другая ситуация, с которой вы можете столкнуться, когда у вас есть SSH-доступ к серверу, но его порт 80 (или любой другой) защищен брандмауэром от внешней сети, из которой вы подключаетесь. Чтобы обойти это, вы можете использовать SSH для перенаправления этого порта на ваш локальный компьютер, а затем получить к нему доступ через localhost . Еще более интересный подход — использовать хост, к которому вы подключены через SSH, для переадресации порта на другую машину, возможно, за тем же брандмауэром. Если, например, у вас есть следующие хосты:

• 192.168.77.15 - Хост в удалённой локальной сети за брандмауэром, к которому нужно подключиться на его порт 80
• foo.example.com — хост, к которому у вас есть доступ по SSH, который может подключаться к указанному выше хосту.
• ваша локальная система, локальный хост

Команда для переадресации порта 80 на 192.168.77.15 на localhost:8080 через SSH-сервер foo.example.com будет выглядеть так:

ssh -L 8080:192.168.77.15:80 -C foo.example.com

Аргумент -L указывает локальный порт, а также адрес и порт назначения. Аргумент -C включает сжатие, поэтому вы снова можете добиться экономии полосы пропускания, и, наконец, в конце вы просто вводите имя хоста SSH. Эта команда откроет простой сеанс оболочки SSH для хоста и, в дополнение к этому, прослушивает порт 8080 локального хоста, к которому вы можете подключиться.

Одним из самых впечатляющих трюков, разработанных SSH за последние годы, является его способность создавать настоящие VPN-туннели. Они проявляются как виртуальные сетевые устройства на обеих сторонах соединения (при условии, что у них настроены соответствующие IP-адреса) и могут позволить вам получить доступ к удаленной сети, как если бы вы были там физически (в обход брандмауэров). Как по техническим причинам, так и по соображениям безопасности для этого требуется root-доступ на обеих машинах, подключенных к туннелю, поэтому это гораздо менее удобно, чем просто использование переадресации портов, SSHFS или SCP. Это для опытных пользователей, которые могут легко найти учебные пособия о том, как это сделать.

Удаленный офис в любом месте

Избавившись от необходимости работать из одного места, вы можете работать буквально из любого места, где есть приличное подключение к Интернету, используя технологии и методы, которые я описал (в том числе во время ожидания вашего автомобиля у механика). Монтируйте чужие системы через SSH, перенаправляйте порты, бурите туннели, чтобы получить удаленный доступ к вашему частному серверу или облачным данным, любуясь залитым солнцем пляжем или попивая экологически чистый кофе хипстерского уровня в туманном городе. Просто сделай это!