Oldukça ayrıntılı olmuş, teşekkürler. Ferhat Savcı <ferhat.sa...@cs.com.tr>, 26 Ağu 2018 Paz, 04:09 tarihinde şunu yazdı: > > "The HFT Guy" nam şahsın ne dediğini bildiğine çok emin olamadım, 2016'dan bu > tarafa hem kendi uygulamalarımızı, hem müşteri uygulamalarını Docker ve > Kubernetes üzerinde çalıştırıyoruz. Bazı söylediklerini yaşamadık (bunların > çoğu -örneğin registry'den imaj silinememesi iddiası- bana ekibin ayarları, > araçları ve ekosistemi anlamadığını/tanımadığını çağrıştırıyor), bazılarını > biz de yaşadık, bazıları da külliyen yalan (örneğin, registry'de garbage > collection var ve cillop gibi çalışıyor). Ne bileyim, dosya-sistemi sürümü > bazında geriye doğru uyumluluk isteyen adamın "immutable container" mantığını > kavradığına ikna olamadım, container içinde veri tutmaya çabalamışlar gibi > anladım.
Container içinde veri tutmaya çalışmışlar, evet. Birazdan bahsedeceğim üzere, bana da "başta" çok mantıklı gelen, belki de ilk akla gelen yöntem olması hasebiyle tercih etmişlerdir. > > Herhangi bir altyapı yazılımı için clean-up script'i yazmanın neden kötü bir > şey olduğunu anlamadım. Kabaca bakıyorum birkaç sistemdeki cron işlerimize, > docker çalışan yerlerde docker temizliği tek script, buna karşılık logların > sıkıştırılıp arşive taşınması, postgresql vacuum vs. onlarca script > çalıştırıyoruz periyodik olarak. Periyodik olmayıp deployment sırasında > çalışan temizlik scriptlerini de sayarsak yüzlerce var. Herhangi bir kurumsal > uygulama altyapısında "malı kurdum daha da bakım yapmam" diye bir strateji > duymadım, görmedim. Bunun çoğunu da otomatiğe bağlamak için script yazıyoruz, > hem işimizi kolaylaştırmak için (tekrarlı işleri manuel yapmak sıkıcı), hem > hataları azaltmak için (insana bırakınca unutulabilir ya da ihmal edilebilir > kritik işler). > Anladığım kadarıyla "her şey bir clean-up script'i yazmakla başladı" diyor. Sonra olaylar gelişmiş sanırım. Yoksa "işler için script yazmak kötüdür" demiyordur herhalde... > "Worldwide docker outage" dediği Docker reposunda başımıza gelmedi ama > PPA'larda gelmişliği var. En basit çözümü de apt ayarlarında repoyu > kapatıyorsun, odur. Ben olsam gece 3'e kadar Amerika'yı beklemez, repoyu > kapatıp sistemleri güncelleyip eve gidip hanımla TV seyrederdim. Sistem > Docker'ın [vardıysa] son versiyonunu bir gün geç alacak diye çatlayacak > değil, yüzlerce sunucuda repoyu ayarlardan elle kapatacaksa da dertlerine > yansınlar, o kadar sunucusu olan ekip repo kapatmayı ssh üzerinden script'le > yapamıyorsa bir zahmet Ubuntu'ya Red Hat'e üç-beş kuruş verip Landscape ya da > Satellite ile yönetsin sistemlerini. > Evet, bu bahsettiği meseleyi ben de anlamamıştım aslında, yani ulaşamayınca ne oluyor, çözememiştim. Yeni bir Docker container'ı kuramama problemi yaşamış olabilirler, bunu bilemiyorum, ama illa ki offline bir kopyadan yeni bir Docker imajı kurulabiliyordur. Eğer öyleyse burası biraz fazla abartılmış gibi duruyor. > Bu ortamlara geçmeyi düşünenlere tek uyarım şudur: üzerlerinde çalışacakları > sunucu ezelden ebede çalışacak diye varsayılarak salakça tasarlanmış mevcut > uygulamaları oldukları gibi bu ortamlara atmak salaklık düzeyini geometrik > artırır. Uygulama geliştirilirken oyun planı sistemin olmadık zamanlarda > çökebileceği üzerine kurulmalı. Sistem yük altındayken herhangi bir klasik > ilişkisel veritabanının sunucusunun elektrik fişini rasgele bir zamanda > çekin, bakalım kaç saatte açılacak? Aynı veritabanı yazılımını Docker > ortamında çalıştırınca container öldüğünde aynı şey olacak. Sorun aynı. > Sadece altyapı yazılımları için değil, iş uygulamaları için de aynı. > Bir sunucunun çalışması her an, her şekilde kesilebilir. Elektrik kesilebilir, internet bağlantısı kopabilir, disk bozulabilir, arkadaşın biri yanlış bir script yazıp ortalığı karıştırabilir (ben yapmadım, bizim bi arkadaş yaptı, ordan biliyorum). Oluyor yani böyle şeyler (valla ben yapmadım). O bakımdan her an hazırlıklı olmak zaten gerekli olduğundan Docker imajının başına bir şey gelmesi pek de korkulacak bir şey olmamalı tabi. > Yazılımı tasarlayan ve geliştiren ekibe CAP teoremini (Consistency, > Availability, Partition tolerance -tutarlılık, erişilebilirlik, ağ hatalarına > dayanıklılık- üçünden herhangi ikisini seç) belletip her tasarım kararının > sistemin pozisyonuna uygun alınmasını sağlamak lazım, geliştirme ekibine her > pozisyona uygun ayrı altyapının sağlanması lazım. Kalıcı veri? CA - ilişkisel > veritabanı - sistem dışında tut, üretici çözsün. Kullanıcı oturumu? AP - > Redis - sistem içinde çoklu kopya oluştur, verinin tutarlılığını kaybettiğini > yakalayacak kontroller koy. Kredi kartı ödemesi? CP - altyapı yazılımı > bulursanız bana da haber verin :-) > > LXC tarafına gelirsek, sanal makinaların (kasıt container sanırım) neden > yedeklendiğini anlamadım: veri mi tutuyorsunuz? Volume mantığı (ana makinanın > bir kılavuzunu container içine mount edebilmek) LXC'de de var, kalıcı veriyi > container dosya sisteminde tutmaktan daha verimli: tüm container'ın içeriğini > yedekleyeceğinize sadece kalıcı veriyi yedekleyebilirsiniz. Evet, bütün veriler containerlarda bulunuyor. LXC'nin mount seçeneğinin farkındayım ama şimdiye kadar hiç ihtiyaç hissetmedim. BTRFS'in nimetlerinden faydalandığımız için, snapshot'lar kullanarak yeni bir container oluşturmanın disk maliyeti kabaca 0MB, zaman maliyeti saniyeler, bunun içine kurduğumuz yazılımlar ilk yedekleme esnasında kendisi kadar bir yer daha kaplıyor, sonraki tüm yedekler sadece container'a kaydedilen veri kadar yer kaplıyor. Yani tüm makinayı yedeklemenin ekstra bir maliyeti yok sayılır. Veriyi container içinde tutmanın ve tamamını yedeklemenin bir gereği de şu: Sadece verinin anlam ifade etmediği, server'a kurduğunuz/yazdığınız yazılımın da veri ile uyumlu olması gerektiği durumlarda tüm sistemin yedeğini alıyorsanız herhangi bir yedeğinize problemsiz şekilde dönebiliyorsunuz. O tarihte sizin yazdığınız yazılımın sürümünü ayrıca takip etmeniz gerekmiyor. Ayrıca sistemin belli noktalarında fantastik değişiklikler yapmaktan çekinmiyorsunuz: Sanal makinanın komple yedeğini alıyorsunuz, ona yeni bir kimlik veriyorsunuz ve başlatıyorsunuz; elinizde bir anda denemeler için veri tabanının son haline sahip yeni bir makina oluyor ve bu işlem (mevcut makinanın tümüyle yedeğini alıp ona yeni bir kimlik verip boot etmek) 5-6 saniye sürüyor. Geliştirmelerde çok işe yarayan bir imkan. > > Yük altında sorun çıkartan genelde uzak depolama erişimi için kullanılan FUSE > user-space sürücüleri (NFS, GlusterFS gibi), container volume'larını bunların > üzerine koymamakta yarar var, ama registry gibi, etcd gibi, nadiren yazılan > ama sıklıkla okunan ya da Redis gibi bellekte çalışan ama arasıra checkpoint > vs. yazan ve sunucular arasında taşımak isteyebileceğin veri tutan altyapı > uygulamalarında sorun olmuyor. Sorun çıktığında Docker ya da Kubernetes > üzerinde genel bir etki olmuyor, mount edilmiş volume'u kullanan container > kapatılamaz duruma geliyor, o yüzden mount seçeneklerinde > soft/timeo=T/retrans=N (hata durumunda T aralıkta N deneme sonrasında IO > hatası üretir -- default "hard", hata durumunda sonsuza kadar yeniden dener), > _netdevice (network başlamadan mount etme), noatime (dosya erişim zamanlarını > güncelleme -- yazmaları oldukça azaltıyor) gibi optimizasyonlar önemli. O zaman bu noktalarda problem çıkmasını da beklememeliyim, zira böyle bir durumumuz yok, olsa bile - anladığım kadarıyla - sanal değil gerçek makina da olsa aynı problem çıkacaktır (yani sanal makinaya özgü bir problem değil) > > Son olarak GUI içeren bir uygulamanın container içinde yaşamasına çok anlam > veremedim: bir, X erişimi için kulağı tersten göstermek gerekir diye tahmin > ediyorum, iki, tek kullanıcının kullanacağı bir uygulama için farklı > sürümleri yönetebilmek amacıyla uzun zamandır yerleşmiş alternatives gibi > başarılı altyapılar zaten mevcut, chroot ile kullanıldığında da aynı etkiyi > çok daha ucuza (kaynak anlamında) ve kolay (kullanıcı deneyimi açısından > normal masaüstü uygulamalarla aynı davranışta) bir şekilde sağlar. > chroot konusunu hiç düşünmemiştim, şimdi baktım, bazı işler için çok daha basit bir alternatif olabilir, en yakın zamanda birkaç deneme yapmalıyım. Fakat mevcut düzenimde (BTRFS) kullandığım ana makinayı (mesela laptop) tamamen kopyalayıp (içindeki tüm işletim sistemi + kişisel dosyalarla birlikte) bir LXC container'ında çalıştırmak, buna yeni bir program kurmak, upgrade etmek ve sonuçtan memnun kaldıysam bunu tekrar ana makinam olarak kullanmaya başlamak da zor olmadığından başka bir çözüme yönelmeyi düşünmüyorum. GUI içeren bir uygulamayı LXC container'ında tutmanın başlıca birkaç avantajı var: Bu uygulamayı ağ üzerindeki farklı makinalardan da kullanabiliriz (tek kullanıcı olmak zorunda değil yani, mesela ekipten birkaç kişinin aynı anda aynı yüksek kaynak tüketen yazılımı kullanmaya çalıştığını düşünün). Ağ erişimi avantajını bir kenara bırakırsak LXC ile chroot zaten neredeyse birbirinin aynısı, yani LXC daha gelişmiş olmasına rağmen performans olarak bir dezavantajı yok sanırım. Çok fazla ayar gerektirdiği için zaman alıyor, ama onu da script'lerde toplayarak basitleştirme yoluna gidiyorum (snapshot-lxc gibi). X yönlendirme işi aslında müthiş başarılı değil, aynı makinadaysanız farkı neredeyse hissetmiyorsunuz ama ağ üzerinde bir makinaysa oldukça sınırda bir deneyim sunuyor, zira X bunun için tasarlanmış bir protokol değil. Belki bu kısmı için uzak masaüstü tarzı bir yaklaşım düşünülebilir. > > On Sat, Aug 25, 2018 at 11:45 PM Cerem Cem ASLAN <cerem...@ceremcem.net> > wrote: >> >> Selamlar, >> >> Docker'ı üretimde (production) kullanan var mı? Bildiğim kadarıyla >> Docker'la ilgili kötü bir ün var >> (https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/) >> fakat benzer şeyler LXC için söylenmiyor. Docker da LXC üzerine kurulu >> olduğuna göre bu problemlerin kaynağı Docker'ın büyülü soyutlandırma >> katmanları olsa gerek... >> >> Bazen belli projelerin kesinlikle doğru şekilde arşivlenmesini >> sağlamak için projenin dosyalarını yedeklemek yetmiyor, projede >> kullanılan yazılımları ve onların bağımlılıklarını da yedeklemek >> gerekiyor. Aksi halde ileri bir tarihte proje dosyasını >> açamayabiliyorsunuz. Örneğin bir önceki major versiyonla yapılmış bir >> devre şeması bir sonraki versiyonla açılmayabiliyor. Bu gibi >> problemlerin önüne geçmek için en garanti çözüm olarak proje başına >> bir sanal makine kurma fikri doğdu. Kurulum süresi, disk alanı >> kullanımı ve çalışma esnasındaki kaynak tüketimi konusu olduğunda en >> mantıklı çözüm LXC gibi görünüyordu. >> >> BTRFS'nin nimetleriyle de birleşince ortaya çok keyifli bir çözüm >> çıktı: https://github.com/aktos-io/lxc-to-the-future >> >> Her proje için her an o bilgisayardan ya da ağ üzerinden kullanılmaya >> hazır şekilde sanal makineler oluşturmak ve depolamak çok hızlı ve >> verimli hale geldi (sanal makine başına 10 saniye + 2-3 MB gibi). >> >> Açıkçası LXC'yi çok uzun süredir problemsiz şekilde üretimde >> kullanıyoruz. Neredeyse hiç problemle karşılaşmadım. Onlarca sanal >> makinenin yedeklerini ayrı ayrı almak, onları depolamak, aktarmak en >> ufak bir problem teşkil etmiyor. Yani neden problemle karşılaşmadığımı >> çözemedim. Acaba yeterince yüklenmiyor muyuz? O bakımdan, Docker >> kullananların deneyimlerini merak ettim. >> _______________________________________________ >> Linux-sohbet mailing list >> Linux-sohbet@liste.linux.org.tr >> https://liste.linux.org.tr/mailman/listinfo/linux-sohbet >> Liste kurallari: http://liste.linux.org.tr/kurallar.php > > > > -- > -- Ferhat Y. Savcı > +90 (530) 548 1716 > _______________________________________________ > Linux-sohbet mailing list > Linux-sohbet@liste.linux.org.tr > https://liste.linux.org.tr/mailman/listinfo/linux-sohbet > Liste kurallari: http://liste.linux.org.tr/kurallar.php _______________________________________________ Linux-sohbet mailing list Linux-sohbet@liste.linux.org.tr https://liste.linux.org.tr/mailman/listinfo/linux-sohbet Liste kurallari: http://liste.linux.org.tr/kurallar.php
