Application Container kavramı aslında çok çok uzun zamandan beri Linux üzerinde kullanılan bir özellikti fakat 2013’de Docker’ın çıkışı ile birlikte kullanımı ve yönetimi çok kolaylaşarak developer’a daha fazla yarar sağlamaya başladı. Hızlı bir şekilde CI , Test ve geliştirme süreçlerine dahil edildi, hem Developer tayfası hem de DevOps kabilesi kökten ve hızlı bir dönüşümün içine girdi…
Özellikle Docker piyasaya çıktıktan sonra Microsoft, Google, Amazon çabucak sahip çıktılar. Azure CoreOS + Docker desteği verdi. Google ise Docker ile koşturduğu Kubernetes servisini duyurdu. En son hepsi birleşip Open Container Project‘i başlattılar. Şimdide standartları belirlemeye çalışyorlar. Bknz: Open Container Specifications
Not: Bizim memlekette Application Container’a Kap (bildiğin kap) gibi güzel ve anlamlı bir isim verilmiş zamanında. Container yerine kullanılabilecek bir literatür olarak kabul görüyor.
Linux Geek’leri zaten bilir ki yıllardan beri LXC + chroot ve cgroups ile zaten koşturuyorlar. E peki neden Docker’dan sonra Container’a abanıldı böyle?
Not: LXC alternatifi olarak yeni standartlara göre libcontainer da kabul görmeye başladı. Docker uzun vadece LXC’den kurtulup kendi implementasyonunu kullanma niyetinde. Ek olarak farklı ihtiyaçlarla beraber yeni alternatifleri görmemiz de mümkün. Konu ile ilgili güzel bir yazı => https://www.flockport.com/lxc-vs-docker/
Her ne kadar iş cgroups ve biraz Kernel hokus pokus’u görünsede işin sırrı standartlaşmada tabi. Docker ilk defa Application Container tüm dağıtımlarda standart şekilde yönetilmeye başlandı. Cross-Platform herkesi heyecanlandırdı, belirli bir Community oluştu, Vendorlar destek vermeye başladı. Neden?
E her şey belli oldu da ondan.
Peki Vendor’lar neden bunu sevdi? Para! tabiki. (Vendor dediğim. Azure, AWS, Google gibi IaaS gezegenleri.)
Bu arkadaşların hepsi şu sıralar Virtual Machine satıyorlar.
Yani sen uygulamanı çalıştırmak istiyorsan öncelikle bir işletim sistemini UP etmen lazım, daha sonra Runtime üzerinde uygulamanı koşturman gerekiyor.
Yani ufak bir Node.js uygulaması host edeceksen işletim sistemi için en az 1GB Disk, 512MB Ram’i Guest OS’a ayırıyorsun ve 5MB Disk ve 64MB RAM kullanacak olan uygulama çalıştırıyorsun hem de Pragmatizme küfür eder gibi.
Application Container da ise Guest OS (VM veya Sanal Sunucu veya VDS) aradan çıkıyor. Guest OS’un kullandığı Ram, Disk, CPU ve diğer utilization unsurları elemine ediliyor. Uygulama direkt Host OS’da daha performanslı çalışıyor.
Şimdi, Azure veya Amazon gibi milyon VM çalıştıran sistemlerdeki tasarrufu düşünsenize! (Buraya Aha! efekti gelecek)
Velhasıl kelam, Developer için standart bir ortam sağlaması, Vendor için daha az kaynak ile daha çok uygulama host etmesinden mütevellit Application Container’lar kutsal sayılmaya başlandı bile.
Gerçek Hayat Senaryosu:
Docker veya Rkt ile production ortamında ciddi bir tecrübem olmadı ama ufak bir sistem tasarlama şansım oldu.
Developer tayfası bir sunucu istiyor, sunucu üzerinde Nginx + PHP ve MySQL olsun diyor.
Sistem Yöneticisi, İşletim Sistemini kuruyor. Nginx, PHP ve MySQL’i yapılandırıyor.
Arkasından Developer geliştirdiği uygulamayı sunucuya deploy ediyor ve hemen ağlamaya başlıyor
“Local’imde çalışıyor du, sunucuya gönderdim çalışmıyor ühühü” Neden?
Çünkü sunucu üzerindeki php.ini’de fsockopen güvenlik dolayısı ile disable edilmiş. Halbuki Developer uygulamasını Containerize (ne havalı laf) etseydi ve
“ben PHP’de fsockopen kullanıyorum” diye Container dosyasına belirteseydi Sistem Yöneticisi hiç suya sabuna dokunmayacaktı. Developer local’de geliştridiği uygulamasını sunucuya Commit edip zahmetsizce çalıştıracaktı.
Şimdi ise Sistem Yöneticisinin sorunu çözüp PHP’yi Developer’ın istediği gibi yapılandırması lazım ki uygulaması çalışsın.
Developer ile Sistem Yöneticisi arasındaki üstü kapalı soğuk savaş ve insanın hiç duymadığı lafların havada uçuşmasıda cabası.
Güvenlik Faydası;
Containerıze olmuş bir uygulamada bir şekilde güvenlik zayıflığından dolayı yetki yükseltmeleri ve başka yere zıplamalar doğal olarak elemine ediliyor. Uygulama sanal bir User Space‘de çalıştığı için Host OS’da oraya buraya zıplayamıyor. (Yinede ileride bir zero-day bulunur ve herkes hacklenir. Bu kaçınılmaz.)
Deployment Faydası;
Developer yeni bir version yayınlayacak örneğin. Imajı Commit etti ve canlıya alındı. Şak! sağlam bir bug farkedip hemen bir önceki imaja alabiliyor. Ek olarak aynı ugulamayı bir çok sunucuya kurmak gerektiğinde direkt imajı commit etmek çok kolay oluyor. Uygulamanın çalışması için ön hazırlık ortadan kalkıyor.
Container İle Application Hosting
Web Hosting sektöründe Containerlar Parallels’in Virtuozzo‘su ile Linux’de 2001’den Windows’da ise 2005’den beri kullanılıyordu zaten. Genelde Reseller Hosting’de ve VPS satışları Virtuozzo üzerinden yapılıyordu (Bizde az ekmek yemedik hani). Fakat uygulamanın çalıştığı ortam standart olmadığından dolayı Developer tayfası hep şikayetçiydi. Hosting firmasıda developer isteklerinden bir haber olduğundan pek cazip çözüm olarak görülmeyip Developer yine bir Virtual Machine kiralamaya yöneliyordu.
Docker, Rocket işte burada işleri değiştirerek Servis Sağlayıcılara yeni ve karlı bir hizmet sunma fırsatı verebilir.
Tabi Container as a Service hizmetine kalkıştığınız zaman sizin rakipleriniz Google, Amazon, Azure gibi rockstar’lar oluyor. Bunu da göz ününe almak lazım, yine de farklılaşılacak çok alan var ve custom servis arayan müşteriler her zaman çoktur.
Talep
Bir şey satabilmek için önce ithiyacı belirlemek gerekiyor. Container Hosting için ihtiyaç ise şu;
Müşterinin bir WordPress uygulaması vardır, güzel bir tema hazırlamış, hızlı çalışması için ise Redis üzerinde Caching özelliği aktif etmiştir. php.ini dosyasını kendine göre düzenlemiş ve mutlaka PHP 5.6’da çalışan bir WordPress PlugIn’i kullanmıştır.
Şimdi bu müşterinin uygulamasını Kontrol Panel’i MaestroPanel olmayan bir Web Hosting Firmasında host etmesi mümkün değil (Bu satırlar yazılırken en azından). Ufak çaplı bir VDS (Virtual Dedicated Server) kiralayarak hem sunucu yönetimini hem de uygulamanın deployment’ı için uğraşacak zaman ve bilgiside yok! Bu zate bir maliyet. E peki günümüzde en efektif çözüm nedir?
Arz
Bu ihtiyaca çözüm olarak tabiki özelleştirilmş bir ortam sağlayabilir ve hatta otomatize edebilirsiniz fakat her müşteriye custom bir Environment sağlayarak büyüyemezsiniz.
Bu aşamada Application Container’lar pragmatist bir çözüm sunmanız için varlar.
WordPress yayınlamak isteyen müşteriye Container Imajını Commit edebileceği bir servis sunarsanız ve Container üzerindeki ayaları basit web arayüzleri ile yönetilmesini sağlarsanız rekabetin fazla olduğu genel web hosting firmalarından marjinal bir şekilde farklılaşabilirsiniz. Bunun yanında Cluster, LoadBalance, Çoklu Lokasyon ve Otomatik Backup/Restore ile desteklendiğinde çok farklı müşteri kitlelerine ulaşılabilir. (Belkide Web Hosting’in mavi okyanusu buralarda yatıyordur.)
Container’lar sayesinde müşteri WordPress’ini istediği gibi çalıştırma imkanı bulur, bu mutlu müşteri olarak size döner, WOM etkisi olur, Az kaynak kullanmış olursunuz. İşiniz sadece Container yönetimi olur, Host OS, Guest OS’lara sırt vermekten kurtulur. Daha az kaynak ile daha çok müşteri host edersiniz. Toplamda karlılık artar. E zaman tüm amaç bu değil mi?
Tabi yeni gelişmekte olan bu modeller için işler yukarıdaki kadar kolay değil. Öğrenme süreci, ar-ge v.b. aşamalarla beraber sistemi kararlı halde tutacak adamda lazım. İş çok kolay değil ama potansiyeli motivasyon yaratabilir.
Çözülmesi Gereken Problemler
Öncelikle Developer kabilesinin Container’larla çalışmayı özümsemesi lazım ki bu çabuk olur.
Doğal olarak Sistem Yöneticilerin Container işletmeye başlamaları Developer’lardan sonra gerçekleşecektir. Geçi benim tahminim her şeyde olduğu gibi bizim memlekette de Applicaton Container kiteleye inene kadar insanlık Mars’da koloni kurmuş olacak fakat değişimin ne kadar çabuk olacağı belli olmaz.
Aslında kurumsal kesim maliyerlerinden ötürü işe para harcamaya hevesli bu da hareketlenme yaratacaktır. Özellikle Nano Server’dan sonra Bankalar olayı tetikleyeceklerdir. Fakat siz ne zaman eğitim firmaları “Docker Eğitimi Çıktı” diye bağırırlar işte o zaman artık Container devri başladığını anlayabilirsiniz.
Docker, Rocket gibi sistemler işin en acı veren kısımlarını çözse bile iş akışını oturtmak, müşterinin uçuk, kaçık isteklerine cevap vermek ve kararlılığı sağlamak zaman ve Ramston çeliği gibi bir Alar ister. (Burada Patrick Rothfuss’un Kral Katili Güncesine Atıfta bulunuyorum, Okuyun Süper!)
Aşağıda genel hatlarıyla dikkat edilmesi gereken husuları sıralamaya çalıştım.
Hub Registry
Container Hosting yapılacaksa işin başı kararlı bir Registry Hub’ı oluşturmak.
Registry’i Github gibi düşnebilirsiniz, nasıl kaynak kodunuzun versionlarını tutabiliyorsunuz. Registry’de aynı şekilde Container imajlarına öyle davranıyor. Örnek DockerHub
Registry için CoreOS biçilmiş kaftan, etcd ile dağıtık yapıda çalışabilmesi ve direkt bu iş için tasarlanmış araçları ile sistemi kurguayabilirsiniz => coreos.com (CoreOS ayrıca Rocket’i de geliştiriyor)
Kullanıcılar kendi yerel ortamında oluşturdukları Container imajlarını sisteme göndermek için bu Hub’ı kullanması gerekiyor. Daha sonra sistem Run komutunu aldıktan sonra Registry’den pull ederek process’leri Host OS üzerinden başaltıyor. Yani konfigürasyon burada tutuluyor.
Registry üzerinden kullanıcıya kendi imajını upload etme şansı vermek gerekiyor. Diğer yandan kullanıcıya geniş bir Container template desteği sağlayarak projesinin ilk adımını direk sistemimiz üzerinden cazip hale getirmek sadakat açısından iyi görünebilir.
Bu aşamada bir Web Administration Panel müşterilerinizin temel işlevlerini yaptırabilirsiniz fakat tabiki yeterli olmayacaktır çünkü olay Continuous Integration’da empoze ediyor o nedenle kullanıcıya bir Command Line aracı sunmak hemen hemen şart gibi hatta Web Uygulamasını tasarlarken bir CLI aracından da ulaşılacağını düşünerek geliştirmek çok doğru olacaktır. CLI Önemli.
Clustering (Availability)
Tabiki imkan varsa yatay ve dikey genişleyen bir Container yapısı oluşturlmanız avantaj olacaktır. Özellikle HA fetişi olan Enterprise kesim için.
Enterprise tarafta ne olursa olsun çalışayım, devam edeyim kafası sürekli gündemdedir. O nedenle kurumsal bir müşterinin soracağı ve sizinde “dibine kadar destekliyoruz” demeniz gereken High Availability’dir.
Docker’ın native cluster özelliği Swarm ile işi kotarabilirsiniz fakat bu satırlar yazılırken Beta’daydı. Docker Machine ile kombin edilince bu faz tamamlanacaktır.
Piyasada Docker’ı Cluster çalıştıran bir çok Orchestration var. CoreOS, Mesos, Flynn, Deis bu oturmuş araçlar ile güzel bir cluster kurabilirsiniz. Özellikle CoreOS, etcd‘den mütevellit favorim. Diğer yandan Multi-Container maymunluklarınıda bu başlık altında yalayıp, yutup otomatize etmek gerekir.
Hazır sistemlerde mevcut Jelastic çoktan Docker desteklemeye başladı. Akabinde Odin Virtuozzo’da göreve hazır. MaestroPanel ise bir gün destekleyecek.
Networking
Neyseki Containerler Muti-Host Networking desteklemeye başladı (Docker 1.7’den sonra) yani bir birleri ile kolay bir şekilde haberleşip configüre olabiliyorlar. Bu çok önemli lakin farklı network’lerde farklı lokasyonlardaki sistemleri birbirine bağlamak her zaman ihtiyaç. Container’lar bunu SDN (Software Defined Network) ile çözüyorlar. Kurgulayacağınız yapının Network kabiliyetlerinin çok esnek olması gerekir ki ön görülemeyen sorunlarda elinizde koz olsun.
Docker’ın daha palazlanmadan SocketPlane‘i satın aldı. Böylelikle SDN (Software Defined Network), Network Plugin ve Discovery özelliklerini bünyesine kattı. Libnetwork projesini de inceleyin.
Öncelikle Cotainer’ların bir birleri ile iletişim özelliği ayrıca ücretlendirilebilir.
Her bir Container’a bir IP adresi tanımlayabilirsiniz ve bunu ekstra ücretli satabilirsiniz ki çok mantıklı fakat Container’lar kendi içlerinde SDN’e dahi oldukları için Host OS’un Container’in içinde belirli bir portta çalışan uygulamaya yönlendirme yapması gerekiyor. Yani Container’da Nginx (80 port) çalışıyorsa buna dışarıdan ulaşmak için bir Portmap yapılması gerekir.
Weave, Container Networking üzerinde sağlam çalışmış, incelenip feyz alınası fikirler var => weave.works
Her halukarda bir HTTP router’a ihtiyacınız olacak hem Portmap’leri yönetmek, hem LoadBalance için hem de Custom Domain Name için gerekli. Bunuda en güzel Ngix ile yapabilirsiniz.
Storage
Container’ları direkt Host OS üzerindeki bir volume’e bağlayabilirsiniz veya bir Container açıp sadece disk amaçlı bile kullanabilirsiniz fakat bunlar Container Hosting için kullanılacak efektif yöntemler olmaz. Bu iş için güvenli, yatay genişleyebilen, Backup/Restore işlerinde zahmetsiz bir yapı gerekiyor. Ek olarak verileri Container’ın içinde tulmaması ile ilgilide bazı önemler almak lazım.
Burada NSF kullanarak Host OS’da LVM‘lerle ilerleyebilirsiniz ilk aşamada böylece her kontrolü ve genişleyebilen taş bir yapınız olur ama ihtiyaçlar çok çeşitli olacaktır.
Bizim ihtiyacımız olan kavramları sağlayan ClusterHQ adında güzel bir sistem mevcut. Bu Açık Kaynak proje Portable olmayan Container volume’larınızı Portable hale getiriyor ve farklı storage tiplerine ulaşmanızı sağlayarak büyük bir esneklik sağlıyor. ClusterHQ üzerinden bir yapı kurulabilir ve şık olur.
Diğer bir proje ise Portworx. Portworx bu işe biraz daha uygun çünkü her Container’a özel yapılandırma sağlıyor, limitlemeler, authentication mekanizmaları Container Hosting iş akışlarına daha bir oturuyor, sanki.
Ahvalin sonunda Container’ların native özellikleri ile Container Hosting verilmesi pek uygun değil, bu işe uygun araçlar ile volume’leri yönetilmesi ve iş akışının belirlenmesi daha doğru.
Ek olarak Container için Storage Driver seçerken AUFS en uygun çözüm, hem yüksek yük altında iyi çalışıyor hem de dağıtık yapıları destekleyen güzel özellikleri var. Fakat Linux mainframe’de direkt gelmemesi gibi bir dezavantajı var. Derin bir tecrübem olmadı ama bakımı zor görünüyor
Özellikler
Gelgelim esas para edecek konuya.
Container malının belirli özelliklerde, limitlerde satılması gerekir muhakkak. Aşağıda bir Container planı hazırlamaya çalıştım.
- 10 Image Storage
- 4 Container
- 4 vCPUs
- 8GB Ram
- 20GB HDD
- 50GB Traffic
- Custom Domain
- Real Time Statistics
- SSL
Bu plana göre Registry üzerinde 10 Container Image’ı tutabilirsiniz, bunları public, private yapabilirsiniz. Registry’de tuttuğunuz Containerlarıdan 4 tanesini aynı anda çalıştırabilirsiniz ve bu Container’lara Disk, vCPU ve RAM’i sınırları dahilinde paylaştırabilirsiniz (Pooling). (Donanımsal kaynakların sınırlanması standart bir durumdur. User bazlı limitleyebileceğiniz gibi imaj bazlıda kolaylıkla limitlenebilir.)
Pooling ile ilgili bir açıklama yapmak lazım: Örneğin müşteriye 8GB Ram verdiniz, müşteri bu 8 GB’ram i her bir Container’a tanımlayabilmeli, siz sadece Toplam Kullanım’ı Limitlemelisiniz. Dört Container toplamda 8 GB’ı geçmemeli.
Custom Domain’i DNS servisi ve bir tane CNAME ile çözülmesi gerekiyor. Siz her açılan container’a bir host ismi vermelisiniz. Kullanıcı bu host ismine CNAME tanımlayıp kendi ismi üzerinden ulaşabilmeli. Yine kendi ismine SSL tanımlanabilmesi gerekir.
Bunu çözmek için Loadbalancing yapan bir Nginx Cluster’ı kurabilirsiniz. Ucuz ve başlangıç için pratik olur. SSL yapılandırmalarınız ile ilgili yönetim zorlaştıracak bir vhosts mantığı var ama o kadarda kötü değli.
İkinci bir önerim ise Citrix Netscaler olur. Netscaler VM olarak kurulabiliyor, Loadbalancing ve SSL sertifikalarını üzerinde tutacak özellikleri var. Lisans ücretide para kazanmaya başladığınızda tahammül edilebilir.
Şimdi asıl soru. Bu Plan’ı kaça satacağız?
Bilmiyorum! :)
Aklıma gelen en iyi yöntem mümkün olduğunca çok kişiye “Böyle bir plana kaç para verirsin?” diye sormak.
Monitoring
Container Monitoring’in babası Open Source olan cAdvisor projesi. Genelde tüm işinizi görür. Fakat kendi firkirlerinizide implemente edecekseniz aslında işin sadece ps aux çıktısından ibaret olduğunu söyleyebiliriz.
Kısaca iş, sunucu üzerinde koşan docker proseslerini izleyip kullandığı CPU, RAM ve Disk miktarlarını kenrara yazmak olacak. Tabi Network için Up/Down streamleri de hesaba katmak lazım. Bu işin kolay taraflarından birisi
Docker’ın bu konu ile ilgili blog yazısını okuyabilirsiniz.
Katma değerli servis olarak, Docker üzerindeki güvenlik anomalilerini de ayrıca raporlayabilirsiniz. Örneğin web uygulamasına gelen SQL Injection, XSS atakları veya brute-force desenine uygun istekleri raporlamanız da istenen özelliklerden biri olacaktır.
Monitoring’in ne olursa olsun çok şekil ve göze hoş gelen bir tarzda verilmesi önemli. Kullanıcıların Containerların ne yaptığını çok net görebilmesi servisin kalitesini arttıracaktır.
Sonuç
Şimdiye kadar Container’ın standart VM hizmetini kökünden değiştirme postansiyelinin var olduğuna hem fikiriz sanırım.
Eğer VM hizmeti veren firmanız var ise olayın nasıl karşınıza çıkabileceğini de söylemeye çalışalım.
Örneğin aşağıdaki konfigürasyon.
- 2 Core CPU
- 4GB Ram
- 60GB HDD
Bunun ortalama fiyatı 150 TL/Ay. Ek olarak sunucu güncellemesi, bakım, güvenlik sıkılaştırmaları ve uygulama deployment’i kullanıcıya ait. Ek olarak Disk sanal ve taşınabilirliği çok zor.
Aynı konfigürasyonun Container’ı tabiki daha ucuza satılacak, bakımı daha zahmetsiz olacak.
Öncelikle Guest OS’un harcadığı RAM direkt ugulamanıza aktarılacak, Sanal Disk’ten ziyade Host OS’un Diskine direkt erişiminiz olacak ki Container’daki uygulama daha hızlı çalışacak.
Şimdi sizin 150 TL’ye sattığınız hizmeti, Container satan başka bir firma aynı donanım özellikleri ile ve Container rahatlığını 75 TL /Ay gibi bir fiyata satabileceğini söyleyebiliriz kabaca. İşte değişimi tetikleyecek olan şey de bu.
Çok güzel yazı Oğuzhan. Teşekkürler.
Çok güzel bir yazı olmuş. Artık bu tip bir yapı için de Maestropanel desteği bekliyoruz o zaman. :)
gerçekten muazzam yazı olmuş. teşekkürler
Hocam cok guzel bir yazi olmus Arz, Talep basliklarindan sonra para cokomel gelecek zannettim :))