Doğru container yapısı

Veri analizi insanları ile yazılım geliştirme insanları uzun yıllar boyu türk filmlerinin o ünlü repliğindeki ifade ile "ayrı dünyaların insanları" oldular. Bu nedenle yıllarını veri analizi ile geçiren bir kişi ile yıllarını yazılım geliştirme ile geçiren iki profesyonelin alet kutularında kullandıkları alet edavatların kesişim kümesini aldığınızda boş küme çıkma olasılığı yüksekti.

Bu nedenle, 28 Kasım da Istanbul Spark Meetup etkinlikleri kapsamında yapılan ve IBM Spark Tech Center dan Principle Data Solutions Engineer Chris Fregly nin Spark 1.6 daki yenilikler ve sonrası ile ilgili yaptığı sunum, ayrı dünyaların geri dönülemez bir biçimde birleştiğini bir kere daha gösterdi.
Gelen kişi tam bir "developer" du. Sunumun içinde yer alan demo ortamı katılımcılarla Docker container olarak paylaşıldı. İçerik; Kafka, Spark, Cassandra, Redis, Parquet, ElasticSearch, Zeppelin gibi birçok bileşenden oluşuyordu.

 

Pratik

Docker container da oluşturulan demo ortamı kolayca çalıştırılabilsin diye oluşturulmasına rağmen, umulan olmadı ve benim görebildiğim kadarı ile kendi lokalinde demoyu çalıştırabilen olmadı yada azdı. Bu konuyu meetup sonrası düşündüğümde, daha önceki "veri analizinde yeni alışkanlıklar" başlıklı yazımda konu ettiğim docker container kullanarak bir veri notebook u yardımı ile polyglot diller kullanarak veri analizlerin nasıl kolayca yapılabildiğini anlatmam ile bu durumun uyuşmadığını gördüm. Bunun üzerine olası sebepler için biraz araştırma yaptığımda sıkıntının kaynağını anladım. Bunu burada sizlerle paylaşıyorum.

LXC

Öncelikle LXC (Linux Containers) dünyasının Docker container lardan oluşmadığını, farklı container ların da olduğunu hatırlamak gerekiyor. Farklı container ların olması sadece bir marka, pazar payı farklılığı değil, problem çözme için aynı noktadan çıkıp farklı yolları takip etmelerinden kaynaklanıyor. Esases hepsi Linux tabanlı namespace ve chroot olarak adlandırılan iki tekniğin kullanılması ile ortaya çıkıyor. Fakat bu ortak çıkış noktası sonrası, çözümdeki bazı temel farklar kendini gösteriyor.

Container dünyası CPU, disk, bellek ve ağ kaynaklarının kullanımını sınırlandırma imkanı veren namespaces ile işletim sisteminin dosyalama yapısı üzerinde ayrı bir dosyalama yapısı ve yetkilendirme imkanı veren chroot özelliğinin kullanımına dayanıyor. Sanal makina kurmak için kullanılan bu özellikler container oluşturmak için de kullanılıyor.

Tek process

Docker ın ölçeklenebilir mimarilerde hızla yaygınlaşmasını sağlayan minimalist yaklaşım "bir container, bir process ilkesi" nedeni ile Docker container larda init mekanizması yok ve birden fazla process in aynı anda çalışmasını sağlayacak bir deamon (yani process) yönetimi yapısı da taşımıyor. Bu ölçeklenebilir mimari açısından arzu edilebilir bir özellik olmakla birlikte, basit senaryoların oluşturulmasında karmaşık bir yapı ile kullanıcıyı başbaşa bırakıyor. Bu karmaşıklığa güzel bir örnek için bakınız.

Çok process

Bu durumda bir Docker container da birçok programın birlikte çalışması nasıl sağlanıyor? Bunun için yapıyı daha da karmaşıklaştıran bir şey yapılıyor ve docker sitesindeki örnekte verildiği üzere supervisor isimli process kontrol sistemi kullanılıyor. Kısaca, supervisord docker ın yapısına uygun şekilde tek çalışan process oluyor ve kendisi diğer processleri yönetiyor.

Basitlikten çıkış

Bu durum yapının daha da karmaşık olmasına yol açıyor. Bu nedenle detayları bu linkte verilen; mysql db, nginx web server, php-fpm ve wordpress uygulamasından oluşan basit bir blog uygulamasını ayrı ayrı containerlarda çalıştırmak yerine, hepsini tek bir Docker container da çalıştırmak yoluna gidiliyor. Tabii bu Docker ın temel dizayn ilkesine aykırı bir durum oluşturuyor ve zorluklar o yüzden ortaya çıkıyor.
Yazının başında belirttiğim Spark demo Docker container ının, çok daha karmaşık bir yapının tek bir container a konması anlamına geldiğini artık anlamış bulunuyoruz.Peki, bu durumda doğru olan nedir?

Başka kart çekmek

Bu durumda desteden başka kart çekmek gerekiyor. Tek container içinde çok process i destekleyen bir yapıya sahip olan bir çözüm işimizi görür. Buna örnek olarak flockport verilebilir. Burada yukarıda verdiğimiz wordpress örneğindeki gibi bir çözümü tek bir container da daha basit olarak oluşturmak mümkün. Tabii demo amaçlı olarak tek Docker container ı kullanmak hala bir seçenek ama artı ve eksilerinin farkında olarak kullanmak gerekiyor.

Sonuç

Container teknolojilerini bilmek ve doğru tercihlerde bulunmak bu yeni dünyanın nimetlerinden yararlanırken dikkat etmemiz gereken önemli konulardan birisidir. Olası problem noktalarını önlemede,  çıkan problemlerin doğru tespit edilmesinde bunun faydalarını göreceksiniz. Özellikle Spark gibi data streaming ile veri işleme yapmada kullanılan tool ların kullanımında developer lık nerede başlıyor, veri bilimcilik nerede bitiyor sınırları çizmek gerçekten zor. O yüzden genel resmin bileşenlerinin farkında olmakta ciddi faydalar var.