Her Yerde Yazılım Geliştirme: Dağıtılmış Uzak İş Yerim

Uzak bir serbest çalışan olarak çalışmanın birçok faydası vardır, ancak etkili bir dağıtılmış çalışma ortamı oluşturmak gerçek bir zorluk olabilir. Elbette, alınabilecek birçok yaklaşım vardır ve tek bir “en iyi” yol herkese uygun olmayacaktır. Uzaktan dijital işyeri organizasyonu gerçekten çok kişisel bir şeydir ve bir geliştirici için iyi olan şey, bir başkası için hiç iyi çalışmayabilir.

Bunu akılda tutarak, burada sunduğum kurulum, özellikle hem geliştirme hem de sistem yönetimi içeren uzak projelerde kişisel olarak benim için en iyi olan şeydir. Bu yaklaşımın bir takım avantajları olduğuna inanıyorum, ancak her okuyucu, operasyonel ihtiyaçları ve kişisel tercihlerinin bir kombinasyonuna dayanarak bunu kendileri için en iyi şekilde nasıl uyarlayacağını düşünmelidir.

Yaklaşımım büyük ölçüde SSH tarafından sunulan özelliklere ve Linux'taki ilgili araçlara dayanmaktadır. MacOS ve diğer Unix benzeri sistemlerin kullanıcılarının, sistemlerinin açıklanan araçları desteklediği ölçüde açıklanan prosedürlerden de yararlanabileceğini unutmayın.

Kendi Kişisel Mini Sunucum

Kurulumumdaki önemli bir ilk adım, kendi evimde, kaynak kod depolarımdan demo sitelerine kadar her şeyi barındırmak için kullanılan Raspberry Pi 2 ile çalışan bir sunucudur.

Seyahat etmeme rağmen, dairem iyi İnternet bağlantısı (100 Mbit/sn) ve neredeyse hiç ek gecikme süresi olmayan uzak “sabit operasyon üssü” olarak hizmet ediyor. Bu, dairemden temelde yalnızca hedef ağın hızıyla kısıtlandığım anlamına geliyor. Tanımladığım kurulum, bir gereklilik olmasa da, bu tür bir bağlantıyla en iyi sonucu verir. Aslında, nispeten düşük bant genişliğine sahip bir ADSL bağlantım varken bu yaklaşımı da kullandım ve çoğu şey gayet iyi çalışıyor. Tecrübelerime göre tek gerçek gereksinim, bant genişliğinin ölçülmemiş veya çok ucuz olmasıdır.

Bir konut kullanıcısı olarak, ISS'min satın alabileceği en ucuz ev ağı yönlendiricisine sahibim, bu da yapmam gereken şey için yeterli değil. Bu nedenle, ISP'den yönlendiriciyi, yalnızca bir bağlantı sonlandırıcı olarak hizmet ettiği ve tam olarak tek bir bağlı sisteme bir PPPoE uç noktası sunan "köprü moduna" geçirmesini talep ettim. Bu, cihazın bir WiFi erişim noktası olarak veya hatta ortak bir ev yönlendiricisi olarak çalışmayı durdurduğu anlamına gelir. Tüm bu görevler, profesyonel bir küçük Mikrotik yönlendirici RB951G-2HnD tarafından gerçekleştirilir. Yerel ağım için (10.10.10.0/24 olarak numaralandırdığım) NAT hizmetini gerçekleştirir ve kendisine bağlı kablolu ve kablosuz cihazlara DHCP sunar. Mikrotik ve Raspberry Pi, iyi bilinen bir adresin gerekli olduğu bağlamlarda kullanıldıkları için statik adreslere sahiptir. Benim durumumda bunlar sırasıyla 10.10.10.1 ve 10.10.10.10'dur.

Ev bağlantımın statik bir IP adresi yok. Amaç, 7/24 bir site değil, kişisel veya SOHO çalışma ortamı yaratmak olduğundan, bu, uzaktan çalışmak yalnızca hafif bir rahatsızlıktır. (Sunucuları için statik bir IP adresine ihtiyaç duyanlar için, statik IP adreslerinin maliyetinin düşmeye devam ettiğini ve oldukça ucuz statik VPN IP seçeneklerinin mevcut olduğunu belirtmekte fayda var.) Kullandığım DNS komisyoncusu, Joker.com , diğer tüm hizmetlerinin yanı sıra ücretsiz bir dinamik DNS hizmeti sunar, bu nedenle kişisel alanımın bir alt alanı dinamik ad olarak bulunur. Bu ismi dışarıdan kendi ağıma bağlanmak için kullanıyorum ve Mikrotik, NAT üzerinden Raspberry Pi'ye SSH ve HTTP iletecek şekilde yapılandırıldı. Kişisel ev sunucumda oturum açmak için ssh mydomain.example.com eşdeğerini yazmam gerekiyor.

Veri Her Yerde

Raspberry Pi'nin sunmadığı önemli bir şey fazlalıktır. 32 GB'lık bir kartla donattım ve bir şey olması durumunda kaybedecek çok veri var. Bunu aşmak ve evdeki İnternet erişimi kesintiye uğrarsa verilerime erişimi sağlamak için tüm verilerimi harici, bulut benzeri bir sunucuya yansıtıyorum. Avrupa'da olduğum için, 2 GB RAM ve 500 GB SSHD sunan düşük kaliteli bir VIA CPU ile gelen Online.net'ten en küçük adanmış çıplak metal (yani sanallaştırılmamış) sunucuyu almak bana mantıklı geldi. Raspberry Pi mini sunucuda olduğu gibi, yüksek CPU performansına ve hatta belleğe ihtiyacım yok, bu yüzden bu mükemmel bir eşleşme. (Bir kenara, iki Pentium 3 CPU ve 1 GB RAM'e sahip olan ve muhtemelen Raspberry Pi 2'nin yarısı kadar hızlı olan ilk "büyük" sunucumu ve onunla nasıl harika şeyler yaptığımızı hatırlıyorum, bu da beni etkiledi. optimizasyona ilgi.)

Raspberry Pi'mi rdiff-backup kullanarak uzak bulut benzeri sunucuya yedekliyorum. Sistemlerin göreceli boyutlarına bakılırsa, bu yedeklemeler bana neredeyse sınırsız bir geçmiş kazandıracak. Bulut benzeri sunucuda sahip olduğum diğer bir şey de, özel Dropbox benzeri bir hizmet çalıştırmamı sağlayan ownCloud'un kurulumu. Bir ürün olarak ownCloud, grup yazılımına ve işbirliğine doğru ilerliyor, bu nedenle daha fazla insan kullanıyorsa daha da kullanışlı hale geliyor. Kullanmaya başladığımdan beri, ne Raspberry Pi'ye ne de bulut benzeri sunucuya yedeklenmemiş herhangi bir yerel veriye sahip değilim ve çoğu iki kez yedeklendi. Verilerinize değer veriyorsanız, yapabileceğiniz herhangi bir ek yedekleme her zaman iyi bir şeydir.

SSHFS'nin “Büyüsü”

Bugünlerde işlerimin çoğu doğrudan web ile ilgili olmayan şeyler geliştirmeyi içeriyor (şok edici, biliyorum!), bu yüzden iş akışım genellikle klasik bir düzenleme-derleme-çalıştırma döngüsü izliyor. Bir projenin özel koşullarına bağlı olarak, dosyalarını ya dizüstü bilgisayarımda yerel olarak bulundurabilirim, onları ownCloud ile senkronize edilmiş dizine koyabilirim ya da daha ilginci, onları doğrudan Raspberry Pi'ye yerleştirip oradan kullanabilirim. .

İkinci seçenek, Raspberry Pi'den yerel olarak uzak bir dizini bağlamamı sağlayan SSHFS sayesinde mümkün oldu. Bu neredeyse küçük bir sihir gibidir: SSH erişiminiz olan (kullanıcınızın sunucuda sahip olduğu izinler altında çalışan) herhangi bir sunucuda yerel bir dizin olarak monte edilmiş bir uzak dizine sahip olabilirsiniz.

Uzak bir proje dizininiz var mı? Yerel olarak monte edin ve bunun için gidin. Geliştirme veya test için güçlü bir sunucuya ihtiyacınız varsa ve - herhangi bir nedenle oraya gitmek ve konsolda vim kullanmak bir seçenek değilse - o sunucuyu yerel olarak monte edin ve istediğinizi yapın. Bu, özellikle İnternet'e düşük bant genişliğine sahip bir bağlantıdayken işe yarar: bir konsol metin düzenleyicide çalışsam bile, bu düzenleyiciyi yerel olarak çalıştırıp ardından dosyaları SSHFS aracılığıyla aktarırsam deneyim çok daha iyi olur. uzak bir SSH oturumu üzerinde çalışmaktan daha iyidir.

Farklı uzak sunuculardaki birkaç /etc dizini karşılaştırmanız mı gerekiyor? Sorun yok. Her birini yerel olarak monte etmek için SSHFS'yi kullanın ve ardından bunları karşılaştırmak için diff (veya başka herhangi bir araç) kullanın.

Veya belki de büyük günlük dosyalarını işlemeniz gerekiyor, ancak günlük ayrıştırma aracını sunucuya yüklemek istemiyorsunuz (çünkü milyonlarca bağımlılığı var) ve her ne sebeple olursa olsun günlükleri kopyalamak elverişsiz. Bir kez daha, sorun değil. Uzak günlük dizinini SSHFS aracılığıyla yerel olarak bağlamanız ve büyük, ağır ve GUI tabanlı olsa bile ihtiyacınız olan aracı çalıştırmanız yeterlidir. SSH anında sıkıştırmayı destekler ve SSHFS bunu kullanır, bu nedenle metin dosyalarıyla çalışmak oldukça bant genişliği dostudur.

Amaçlarım için sshfs komut satırında aşağıdaki seçenekleri kullanıyorum:

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

Bu komut satırı seçenekleri şunları yapar:

• -o reconnect - Sshfs'e, bozulursa SSH uç noktasına yeniden bağlanmasını söyler. Bu çok önemlidir, çünkü varsayılan olarak, bağlantı koptuğunda, bağlama noktası ya aniden başarısız olur ya da basitçe askıda kalır (ki bunu daha yaygın buldum). Gerçekten bana öyle geliyor ki, bu varsayılan seçenek olmalı.
• -o idmap=user - sshfs'ye uzak kullanıcıyı (yani bağlandığımız kullanıcıyı) yerel kullanıcıyla aynı olacak şekilde eşlemesini söyler. İsteğe bağlı bir kullanıcı adıyla SSH üzerinden bağlanabildiğiniz için, bu, yerel sistemin kullanıcının aynı olduğunu düşünmesi için bazı şeyleri "düzeltir". Uzak sistemdeki erişim hakları ve izinleri, uzak kullanıcı için her zamanki gibi geçerlidir.
• -o follow_symlinks - İsteğe bağlı sayıda bağlı uzak dosya sistemine sahip olsanız da, yalnızca bir uzak dizini, ana dizinimi bağlamayı daha uygun buluyorum ve bunun içinde (uzak SSH oturumunda) önemli dizinlere sembolik bağlantılar oluşturabilirim /srv veya /etc veya /var/log gibi uzak sistemde başka bir yerde. Bu seçenek, sshfs'nin uzak sembolik bağlantıları dosya ve dizinlere çözümlemesini sağlayarak bağlantılı dizinleri takip etmenize olanak tanır.
• -C - SSH sıkıştırmasını açar. Bu, özellikle dosya meta verileri ve metin dosyaları için etkilidir, bu nedenle varsayılan bir seçenek olması gerektiği gibi görünen başka bir şeydir.
• server.example.com:. - Bu uzak uç nokta. İlk kısım (bu örnekte server.example.com ) ana bilgisayar adıdır ve ikinci kısım (iki nokta üst üste işaretinden sonra) bağlanacak uzak dizindir. Bu durumda, “.” ekledim. kullanıcımın ana dizinim olan SSH oturum açma işleminden sonra sona erdiği varsayılan dizini belirtmek için.
• server - Uzak dosya sisteminin bağlanacağı yerel dizin.

Özellikle düşük bant genişliğine sahip veya kararsız bir İnternet bağlantınız varsa, SSHFS'yi SSH genel/özel anahtar kimlik doğrulaması ve yerel bir SSH aracısı ile kullanmanız gerekir. Bu şekilde, SSHFS'yi kullanırken sizden parola (sistem parolaları veya SSH anahtarı parolaları) istenmez ve yeniden bağlanma özelliği ilan edildiği gibi çalışır. SSH aracısını, oturumunuz içinde gerektiğinde kilidi açılmış anahtarı sağlayacak şekilde ayarlamadıysanız, yeniden bağlanma özelliğinin genellikle başarısız olacağını unutmayın. Web, SSH temel eğitimleriyle dolu ve denediğim GTK tabanlı masaüstü ortamlarının çoğu, otomatik olarak kendi aracılarını (veya “cüzdanı” veya her ne diyorlarsa onu) başlatıyor.

Bazı Gelişmiş SSH Hileleri

İnternet üzerinde dünyanın her yerinden uzaktan erişilebilen ve yüksek bant genişliği bağlantısına sahip sabit bir noktaya sahip olmak - benim için bu benim Raspberry Pi sistemim ve gerçekten herhangi bir genel VPS olabilir - stresi azaltır ve yapmanızı sağlar veri alışverişi ve tünelleme ile her türlü şey.

Hızlı bir nmap'e mi ihtiyacınız var ve bir cep telefonu ağı üzerinden mi bağlandınız? Sadece o sunucudan yap. Bazı verileri hızlıca kopyalamanız gerekiyor ve SSHFS aşırıya kaçıyor mu? Sadece düz SCP kullanın.

Bir sunucuya SSH erişiminizin olduğu ancak bağlantı noktası 80'in (veya başka herhangi bir bağlantı noktasının) bağlandığınız dış ağa güvenlik duvarı ile kapatıldığı durumlarda bizimle karşılaşabileceğiniz başka bir durum. Bunu aşmak için, bu bağlantı noktasını yerel makinenize iletmek için SSH'yi kullanabilir ve ardından buna localhost aracılığıyla erişebilirsiniz. Daha da ilginç bir yaklaşım, SSH üzerinden bağlandığınız ana bilgisayarı başka bir makinedeki, muhtemelen aynı güvenlik duvarının arkasındaki bir bağlantı noktasını iletmek için kullanmaktır. Örneğin, aşağıdaki ana makinelere sahipseniz:

• 192.168.77.15 - Uzak yerel ağda, güvenlik duvarının arkasında bulunan ve 80 numaralı bağlantı noktasına bağlanmanız gereken bir ana bilgisayar
• foo.example.com - SSH erişiminiz olan ve yukarıdaki ana bilgisayara bağlanabilen bir ana bilgisayar
• yerel sisteminiz, localhost

192.168.77.15 üzerindeki 80 numaralı bağlantı noktasını foo.example.com SSH sunucusu aracılığıyla localhost:8080'e iletmek için bir komut şöyle olacaktır:

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

-L argümanı yerel bağlantı noktasını ve hedef adresi ve bağlantı noktasını belirtir. -C argümanı sıkıştırmayı etkinleştirir, böylece tekrar bant genişliği tasarrufu elde edebilirsiniz ve son olarak sonunda SSH ana bilgisayar adını yazmanız yeterlidir. Bu komut, ana bilgisayara düz bir SSH kabuk oturumu açar ve buna ek olarak, bağlanabileceğiniz 8080 numaralı yerel ana bilgisayar bağlantı noktasını dinler.

SSH'nin son yıllarda geliştirdiği en etkileyici numaralardan biri, gerçek VPN tünelleri oluşturma yeteneğidir. Bunlar kendilerini bağlantının her iki tarafında da sanal ağ cihazları olarak gösterirler (uygun IP adreslerine sahip oldukları varsayılarak) ve fiziksel olarak oradaymışsınız gibi uzak ağa erişmenize izin verebilir (güvenlik duvarlarını atlayarak). Hem teknik hem de güvenlik nedenleriyle bu, tünele bağlı olan her iki makinede de kök erişimi gerektirir, bu nedenle yalnızca bağlantı noktası iletme veya SSHFS veya SCP kullanmaktan çok daha az kullanışlıdır. Bu, nasıl yapılacağına dair öğreticileri kolayca bulabilen ileri düzey kullanıcılar içindir.

Her Yerde Uzak Ofis

Tek bir yerden çalışma ihtiyacından kurtularak, özetlediğim teknolojileri ve teknikleri kullanarak (arabanızı tamircide beklerken de dahil olmak üzere) yarı yeterli İnternet bağlantısına sahip herhangi bir yerden kelimenin tam anlamıyla çalışabilirsiniz. Özel sunucunuza veya bulut tabanlı verilerinize uzaktan erişmek, güneş banyosu yapan bir plaja bakarken veya sisli bir şehirde yenilikçi sınıf çevre dostu kahve içerken SSH, ileri bağlantı noktaları, sondaj tünelleri üzerinden yabancı sistemler kurun. Sadece yap!