Работа като отдалечен фрийлансър има много предимства, но създаването на ефективна разпределена работна среда може да бъде истинско предизвикателство. Разбира се, има много подходи, които човек може да предприеме, и нито един „най-добрият“ начин няма да отговаря на всички. Отдалечената дигитална организация на работното място наистина е нещо много лично и това, което работи добре за един разработчик, може изобщо да не работи добре за някой друг.

Имайки това предвид, настройката, която представям тук, е просто това, което работи добре за мен лично, особено при отдалечени проекти, които включват както разработка, така и системна администрация. Вярвам, че този подход има редица предимства, но всеки читател трябва да обмисли как да го адаптира по начин, който работи най-добре за него, въз основа на комбинация от техните оперативни нужди и лични предпочитания.

комуникацията става по-лесна, когато увеличите броя на членовете на екипа

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

Моят собствен личен мини-сървър

Важна първа стъпка в моята настройка е Raspberry Pi 2 -мощен сървър в собствения ми дом , използвани за хостване на всичко от моите хранилища на изходен код до демонстрационни сайтове.

Въпреки че пътувам, апартаментът ми служи като отдалечена „фиксирана база от операции“ с прилична интернет връзка (100 Mbit / sec) и почти без допълнителна латентност. Това означава, че от моя апартамент съм основно ограничена само от скоростта на мрежата на местоназначението. Настройката, която описвам, работи най-добре с този тип свързаност, въпреки че не е изискване. Всъщност аз също използвах този подход, докато имах ADSL връзка с относително ниска честотна лента, като повечето неща работеха добре. Единственото реално изискване, според моя опит, е честотната лента или да не е измерена, или да е евтина.

Като битов потребител имам най-евтиния рутер за домашна мрежа, който ISP може да купи, което просто не е достатъчно за това, което трябва да направя. Поради това поисках ISP да постави рутера в „мостов режим“, където той служи само като терминатор за свързване, предлагайки PPPoE крайна точка към точно една свързана система. Това означава, че устройството спира да работи като WiFi точка за достъп или дори като обикновен домашен рутер. Всички тези задачи се обработват от a професионален малък рутер Mikrotik RB951G-2HnD . Той изпълнява НОЩ услуга за моята локална мрежа (която номерирах на 10.10.10.0/24) и предлага DHCP към кабелни и безжични устройства, свързани към него. Mikrotik и Raspberry Pi имат статични адреси, защото се използват в контексти, където се изисква добре познат адрес. В моя случай това са съответно 10.10.10.1 и 10.10.10.10.

Моята домашна връзка няма статичен IP адрес. За моите цели това е само леко неудобство, работещо от разстояние, тъй като целта е да се създаде личен или SOHO работна среда, а не денонощен сайт. (За тези, които се нуждаят от статичен IP адрес за своя сървър, заслужава да се отбележи, че цената на статичните IP адреси продължава да намалява и доста евтини статични VPN IP опции са налични.) DNS брокерът, който използвам, Joker.com , предлага безплатна динамична DNS услуга заедно с всички други свои услуги, така че един поддомейн от моя личен домейн съществува като динамично име. Използвам това име за свързване отвън към собствената си мрежа, а Mikrotik е конфигуриран да предава SSH и HTTP чрез NAT към Raspberry Pi. Просто трябва да напиша еквивалента на ssh mydomain.example.com за да вляза в моя личен домашен сървър.

Данни навсякъде

Едно важно нещо, което Raspberry Pi прави не офертата е съкращаване. Оборудвал съм го с карта от 32 GB и все още има много данни, които да губите, в случай че се случи нещо. За да заобиколя това и да осигуря достъп до моите данни, ако жилищният достъп до Интернет хълца, отразявам всичките си данни на външен сървър, подобен на облак. Тъй като съм в Европа, имаше смисъл да взема най-малкото специален гол метал (т.е. невиртуализиран) сървър от Online.net , който се предлага с VIA процесор от нисък клас, предлагащ 2 GB RAM и 500 GB SSHD . Както при мини-сървъра Raspberry Pi, нямам нужда от висока производителност на процесора или дори памет, така че това е перфектно съвпадение. (Като страна настрана си спомням първия си „голям“ сървър, който имаше два процесора Pentium 3 и 1 GB RAM и вероятно беше половината от скоростта на Raspberry Pi 2, и как направихме страхотни неща с него, което повлия на интерес към оптимизацията.)

Архивирам своя Raspberry Pi на отдалечен облачен сървър, като използвам rdiff-backup . Съдейки по относителните размери на системите, тези архиви ще ми осигурят практически неограничена история. Друго нещо, което имам на подобния на облак сървър, е инсталиране на ownCloud , което ми позволява да стартирам частна услуга, подобна на Dropbox. ownCloud като продукт преминава към групов софтуер и сътрудничество, така че става още по-полезен, ако повече хора го използват. Откакто започнах да го използвам, буквално нямам всякакви локални данни, които не са архивирани нито на Raspberry Pi, нито на подобен на облак сървър и повечето от тях се архивират два пъти. Всяко допълнително резервно резервиране, което можете да направите, винаги е добро нещо, ако оценявате данните си.

„Магията“ на SSHFS

По-голямата част от работата ми в наши дни включва разработване на неща, които не са пряко свързани с мрежата (шокиращо, знам!), Така че работният ми процес често следва класически цикъл на редактиране-компилация. В зависимост от конкретните обстоятелства на даден проект, може или да разполагам с файловете му локално на лаптопа си, да ги поставя в собствената синхронизирана с Cloud директория, или по-интересното е, че мога да ги поставя директно на Raspberry Pi и да ги използвам от там .

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

Имате отдалечена директория на проекта? Монтирайте го локално и отидете за него. Ако имате нужда от мощен сървър за разработка или тестване и - по някаква причина просто да отидете там и да използвате дойдох в конзолата не е опция - монтирайте този сървър локално и правете каквото искате. Това работи особено добре, когато съм на връзка с ниска честотна лента към Интернет: дори и да работя в конзолен текстов редактор, опитът е много по-добър, ако стартирам този редактор локално и след това просто прехвърля файловете чрез SSHFS, а отколкото работа над отдалечена SSH сесия.

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

Или може би трябва да обработите големи регистрационни файлове, но не искате да инсталирате инструмента за анализ на регистрационния файл на сървъра (защото има милиони зависимости) и поради каквато и да е причина копирането на регистрационните файлове е неудобно. Още веднъж, не е проблем. Просто монтирайте директорията за отдалечен дневник локално чрез SSHFS и стартирайте какъвто и да е инструмент, от който се нуждаете - дори ако е огромен, тежък и управляван от GUI. SSH поддържа компресия в движение и SSHFS го използва, така че работата с текстови файлове е доста удобна за честотната лента.

За моите цели използвам следните опции на sshfs командна линия:

g++ компилира C++

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 достъп, който може да се свърже с горния хост
• вашата локална система, localhost

Команда за препращане на порт 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 за хоста и в допълнение към това, слушайте на localhost порт 8080, към който можете да се свържете.

Един от най-впечатляващите трикове, които SSH е разработил през последните години, е способността му да създава истински VPN тунели. Те се проявяват като виртуални мрежови устройства от двете страни на връзката (ако приемат, че имат настроени подходящи IP адреси) и могат да ви позволят достъп до отдалечената мрежа, сякаш сте физически там (заобикаляйки защитни стени). Както от техническа гледна точка, така и от съображения за сигурност, това изисква корен достъп и на двете машини, които са свързани с тунела, така че е много по-малко удобно от простото пренасочване на портове или SSHFS или SCP. Това е за напредналите потребители, които лесно могат да намерят уроци за това как да го направя.

предизвикателства за сигурността в интернет на нещата

Отдалечен офис навсякъде

Можете да продължите да работите дори докато чакате колата си при механика. Tweet

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