"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.
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). "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. 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ı. 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. 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. 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. 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
