Netty Agents v1.0.0 yayınlandı

Bir açık kaynak projesi olarak başlattığımız Netty Agents, 1.0.0 sürümü ve Apache v2.0 lisansı ile yayınlandı.

Mesaj tabanlı ve senkron haberleşmeye imkan veren bir iletişim kütüphanesi olarak tanımlayabileceğimiz Netty Agents, yine bir açık kaynak haberleşme kütüphanesi olan Netty (https://netty.io/) ürününü kullanmaktadır.

Ürünün Özellikleri

• Kalıcı iletişim kanalları üzerinden çift yönlü iletişim imkanı,
• Performans, özelleştirebilme ve esneklik (Netty kütüphanesinin sunduğu soket seviyesi iletişim ve pipe-and-filter mimarisi gibi güzel özelliklerini kullanarak) 
• Veri tipinin ve protokolün net bir şekilde tanımlandığı ve haberleşen taraflar tarafından bilindiği bir haberleşme mekanizması tasarlama ve kullanım imkanı,
• Asenkron haberleşme imkanına ek olarak, senkron, istek-cevap ikililerini destekleyen bir modelin kullanılabilmesi imkanı,
• İletişim ve iletişim güvenliği gereksinimlerinin, basitleştirilmiş bir kütüphane arayüzü üzerinden sunularak daha az kodlama yaparak karşılanabilmesi imkanı,
• TLS ve çift taraflı sertifika doğrulaması kullanarak üst seviyede iletişim güvenliği imkanı

Motivasyon

Yazılım sistemleri geliştirilirken bağımsız çalışan birden çok alt-sistem yazılım bileşenini birbiriyle etkileşime sokma ihtiyacı duyabilirsiniz. Bu bileşenler aynı işletim sistemi olabileceği gibi farklı işletim sistemleri üzerinde de kurulu olabilirler. Mikro-servis mimarisi, bu yapılara verilebilecek güzel bir örnektir.

Alt-sistemler arası etkileşim için çok çeşitli ağ iletişim yöntemleri, protokolleri ya da modelleri kullanılabilmektedir. Dikeyde ele alabileceğimiz bir örnek aşağıda verilmiştir.

• En alt katmanda TCP/UDP protokolleri doğrudan kullanılabilir,
• TCP üzerinde çalışan HTTP protokolü kullanılabilir,
• HTTP üzerinde çalışan REST iletişim modeli kullanılabilir

Çoğu alt-sistem (özellikle mikro-servis mimarisinde), iletişim modeli olarak REST kullanılmaktadır. Kalıcı bir iletişim kanalı ihtiyacımız yoksa bu, mantıklı bir seçenek olabilir. Fakat çift yönlü iletişim ihtiyacı nedeniyle kalıcı bir iletişim kanalı ihtiyacı olan (özellikle hat üzerinde firewall gibi güvenlik cihazlarının olduğu) durumlarda, REST servis mimarisi yetersiz kalmaktadır. Bu durumda da Web soket (ki bu da her iki tarafta da HTTP işleme yeteneği gerektirmektedir) gibi çözümler ortaya çıkmaktadır.

Netty Agents projesini geliştirirken bu ve benzeri sorunları çözme isteğinin yanı sıra aşağıdaki hedefleri gözettik:

• Kalıcı ve çift yönlü bir iletişim kanalı sağlamak (REST'ten farklı olarak),
• HTTP vb. gerektirmeden daha alt katmanda bir iletişim mekanizması sunabilemek (Web soket mimarisinden farklı olarak) 
• Veri tipi belirli (POJO nesneleri) and net tanımlanmış bir protocol mimarisi sunmak (ham TCP/UDP soket tabanlı programlamadan farklı olarak),
• Asenkron mimariden ödün vermeksizin, bloke olmayı gerektiren istek-cevap tabanlı iletişim ihtiyaçlarına cevap verebilme
• Projelerin ihtiyaç duyduğu iletişim ve iletişim güvenliği ihtiyaçlarının, olabildiğince az kod yazarak ve yığınla kod tekrarı olmadan karşılanabilmesinin sağlanması

Kalıcı ve çift yönlü bir iletişim kanalı kurmak aşağıdaki yetenekleri sağlamada kolaylık sağlamaktadır:

• iki tarafın da doğrulanması ve böylece daha güvenli bir yapı
• doğrulama sürecinin kanalın ömrü boyunca bir kez yapılması nedeniyle performans artışı,
• tarafların sağlık durumlarının anlık izlenmesi, ve
• çilf yönlü iletişim (mesaj gönderiminin iki taraf tarafından da tetiklenebiliyor olması)

Düşük seviyede (soket seviyesi) bir iletişim modeli kullanmak şu avantajları sağlamaktadır:

• üst seviye protokollere (HTTP vb.) bağımlılık olmaması nedeniyle performans artışı
• esneklik (üst seviye protokollerin sınırları dahilinde hareket etmek gerekmiyor)
• flexibility by breaking limitations of higher layer protocol, and
• özelleştirebilme (Netty kütüphanesinin sağladığı pipe-and-filter mimarisi vb. sayesinde)

İletişim veri tipleri belirli ve iyi tanımlanmış protokol modeli sayesinde

• geliştiricilerin iş mantığına daha fazla odaklanmasının sağlanması, ve
• hatasız tasarım ve gerçekleştirim imkanı sağlanmaktadır.

Senkron, istek-cevap tabanlı iletişim modeli ise

• gerekmeyen noktalarda "event driven" tasarımın sebep olacağı karmaşıklıktan, ve
• geliştirme esnasında "event handling" metodları arasında kaybolmaktan bizi kurtarır.

Linkler ve Dokümantasyon

Proje sitesi:
https://gitlab.com/opentoolset/netty-agents

Wiki dokümantasyonu:
https://gitlab.com/opentoolset/netty-agents/-/wikis/home

WebDAV ile dosya paylaşımı

Versiyonlanması gerekmeyen büyük boyutlu dosyaları versiyon kontrol sunucularında (SVN vb.) tutmak yerine farklı bir dosya paylaşım ortamı kullanmak mantıklı bir tercih olabilir. Apache sunucusu HTTP protokolüne ek özellikler kazandıran WebDAV (Web-based Distributed Authoring and Versioning) protokol standardını desteklemektedir. Bu özellik, Web sunucuları üzerinde interaktif şekidle dosya paylaşım ve düzenleme imkanını bize vermektedir. Sunucuların sunduğu bu desteği kullanabilmek için istemci tarafının da desteği gerekmektedir. Günümüzdeki çoğu işletm sistemi, dosya yöneticilerine bu desteği koymuş durumdadır.

Bu yazıda Debian üzerinde kurulu Apache 2.x Web sunucusu ve Windows 7 istemcisi kullanarak dosya paylaşımı örneklenmiştir.

Güvenlik açısından dikkat edilmesi gerekenler -- DİKKAT --

• Web üzerinden erişimin sadece HTTPS üzerinden yapılmasına dikkat edilmelidir.
• Kullanıcılar kısıtlı bir küme olmasına ve belirli bir dizinle sınırlanmış olmasına rağmen dışarıdan sunucu üzerine müdahale izni verilmiş olmaktadır. Bu nedenle paylaşım dizinine zararlı kod yüklenmesi olasıdır. Web sunucu ve genel olarak işletim sistemi üzerinde paylaşım dizinindeki dosyaların çalıştırılamamasını sağlayıcı önlemler ayrıca alınmalıdır.

Apache 2.x üzerinde WebDAV desteğinin etkinleştirilmesi

• DAV modüllerinin etkinleştirilmesi

cd /etc/apache2/mods-enabled
ln -s ../mods-available/dav.load
ln -s ../mods-available/dav_fs.conf
ln -s ../mods-available/dav_fs.load

• Web sunucu kullanıcısının paylaşım dizine yazabilmesinin sağlanması

chown -R www-data:www-data /home/www-data/paylasim
chmod -R u+rw /home/www-data/paylasim

• Apache ayar dosyasında örnek ayarlama:

Alias /paylasim /home/www-data/paylasim
<Location /paylasim>
  Dav On
  AuthType Basic
  AuthName "Paylasim"
  AuthUserFile /secrets/.htpasswd
  Require valid-user
  Options Indexes FollowSymLinks
</Location> 

• Ayarların aktifleştirilmesi:

service apache2 reload

Windows 7 istemci ayarları

• Basic authentication etkinleştirilmesi için registry içerisinde HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\UseBasicAuth şeklinde DWORD türünde bir değer tanımlanıp içeriğine 0 dışında bir rakam atanmalıdır.
• Sunucu SSL sertifikası Internet Exporer tarafından güvenilir görünmüyorsa install seçeneği üzerinden güvenilir sertifika havuzuna eklenmelidir.
• Internet Explorer menü çubuğu üzerinden Tools > Map network drive seçilerek ilgili Web URL'si ağ sürücüsü olarak tanımlanır. Tanımlama esnasında "Reconnect at logon" seçilmemiş, "Connect using different credentials" seçilmiş olmalıdır. Örneğimizde tanımlanacak URL şöyle olabilir:

https://sunucumuz/paylasim/

• Doğrulama bilgileri (kullanıcı adı/şifre) girilerek tanımlama işlemi tamamlanır.

Linkler

• http://httpd.apache.org/docs/2.4/mod/mod_dav.html
• http://www.webdav.org/

Windows ağ paylaşımı iç ağ IP bloğunun değiştirilmesi

Windows işletim sistemleri ağ paylaşım özelliği ile NAT tabanlı bir gateway haline getirilebiliyor. Bu özellik etkinleştirildiğinde Windows iç ağ bloğunu 192.168.137.0/24 şeklinde belirler ve iç tarafta kalan ağı bu adres bloğunu kullanmak zorunda bırakır. Bu durum, örneğin katmanlı NAT (iç ağda başka bir Windows makine üzerinden NAT) uygulaması yapmanız gerektiği durumlarda sağlıklı bir konfigürasyon oluşturulmasını engelleyecektir. Bu sorunu aşmak ve iç tarafta kendi belirleyeceğimiz bir ağ bloğunu kullanabilmek için Windows registry editöründe HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SharedAccess\Parameters anahtarı altında ScopeAddress değerinin 192.168.137.1 olan ön tanımlı halinden istediğimiz değere getirilmesi ve bilgisayarın yeniden başlatılması yeterlidir.

SVN yansılarının ana ambar haline getirilmesi

Daha önceki yazılarda SVN yansılama işleminden ve bu yöntemin SVN yedeği almakta nasıl kullanılabileceğinden bahsetmiştik. Ana ambardan hizmet alınamaması durumunda yansı alınan hedef ambarın ana ambar haline getirilmesi mümkündür. Burada büyük boyutlu ağ trafiğinden kaçınıyorsak, yeni çalışma dizini oluşturmak yerine hali hazırdaki çalışma dizini kullanmaya devam edebiliriz. Sadece mevcut çalışma dizininin yeni ambara konumlanması gerekiyor. Yapılması gereken işlemler aşağıda sıralanmıştır:

• Sağlıklı geciş için
• Öncelikle ana ambar sabitlenmelidir. Yani yazmaya kapatılarak herhangi birinin çalışma dizininde yapacağı değişikliğin ambara uygulanması önlenmelidir.
• Daha sonra yansı hedefi olan ambarın ana ambarın en güncel yansısı olduğundan emin olunmalıdır. Gerekiyorsa sync işlemi manuel olarak tekrar uygulanır.
• Çalışma dizininde SVN ambarına yönelik bilgilerin alınması:

  developer1@calisma-makinesi:~/projects/project1$ svn info
  Path: .
  URL: https://ana-ambar/project1
  Repository Root: https://ana-ambar/project1
  Repository UUID: a11a111a-111a-111a-aa11-a1aa11a11aa1
  Revision: 1234
  ...
  

• Yansı hedef ambarının UUID değerinin ana ambarın UUID değerine eşitlenmesi:

svnuser@yeni-ambar:~$ cd /svn-ambarlari/project1
svnuser@yeni-ambar:/svn-ambarlari/project1$ svnadmin setuuid . a11a111a-111a-111a-aa11-a1aa11a11aa1

• Hali hazırdaki çalışma dizinde yeni ambara konumlanma:

developer1@calisma-makinesi:~/projects/project1$ svn switch --relocate https://ana-ambar/project1 https://yeni-ambar/project1

Böylece çalışma dizinimiz yeni ambarı kullanacak şekilde ayarlanmış olacaktır.