Docker için Gece Yarısı Ekspresi yazmış adam :-) Hiç iyi bir şey görememiş, ilginç.
2017-10-17 15:09 GMT+03:00 Cerem Cem ASLAN <[email protected]>: > Yok, öyle araştırmadan inanmak olmaz :) > https://thehftguy.com/2016/11/01/docker-in-production-an- > history-of-failure/ > > 17 Ekim 2017 15:02 tarihinde Ferhat Savcı <[email protected]> yazdı: > > Konu çok daldan çok dala atlayınca takip etmekte zorlandım ama sırf > > merakımdan soruyorum: Docker'da veri tutulamadığını kim söyledi? Niye > > inandınız araştırmadan? :-) > > > > 2017-10-17 14:53 GMT+03:00 Cerem Cem ASLAN <[email protected]>: > >> > >> Hakkaten direndim ama yok, illa muhabbete saracağız :)) > >> > >> Şimdi, öncelikle, bu zahmete evet, laptop'um için giriyorum. Aslında > >> zaten laptop ile sunucu arasında da çok bir fark görmüyorum. > >> Sanallaştırma sistemlerini de kullanıyorum elbette, ama özel işler > >> için. Mesela VirtualBox olmazsa olmazlarım arasında. Onun dışında > >> Docker kullanayım dedim, fakat Docker'da veri tutulamadığı yönünde > >> yazıları okuyunca bundan vazgeçtim. Zaten Docker'ı mantık olarak > >> kopyalamakta bir problem göremiyorum. Hazır görememişken, şöyle bir > >> şey yapmıştım: https://github.com/aktos-io/lxc-to-the-future Şu anda > >> bu yöntem sunucularımızda kullanılıyor. > >> > >> Yani Docker yerine LXC'yi doğrudan kullanıyorum, Docker ile hazırlanan > >> altyapı yerine kullandığım işletim sisteminin o anki kopyasını > >> çıkarıyorum (`git clone` gibi). Bu kopyayı LXC ile açıyorum, ister > >> ilelebet bir server gibi kullanıyorum, ister deneme yanılma yapıyorum > >> (mesela basitçe `apt-get upgrade && apt-get dist-upgrade` burada > >> yapılabilir). Sonra, bu sanal makina artık host makinam olarak > >> çalışsın istersem bilgisayarı yeniden başlatıyorum, Grub ekranında > >> `...subvol=/var/lib/lxc/mytest/rootfs` deyip sistemi buradan > >> açabiliyorum. > >> > >> Bunlar hep güzel şeyler. > >> > >> Bu zamana kadar 2 kez diskim çöktü, 1 kez laptop'ım çalındı. İlkinde > >> diskim çökmüştü, bitirme projemi aklımda kaldığı kadarıyla sıfırdan, 1 > >> haftada yazmıştım. 2.'sinde bilgisayarım çalınmıştı, projelerimin ve > >> kişisel dosyalarımın bir kısmına anneme hediye ettiğim makinada kalan > >> dosyalarımdan ulaşmıştım (giden gitmişti, ayrıca bütün bilgiler çalan > >> kişinin eline geçmişti), 3.sünde (geçtiğimiz günlerde) diskim bir anda > >> çöktü, sıfır veri kaybıyla atlattım. Ama yedeklere dönme işi 3 günümü > >> aldı (Cryptroot'un UUID meselesine takıldım). > >> > >> Şimdi, istiyorum ki, nasıl bir projeyi `git init && git ... && git > >> push` yapıp sonra `git clone` deyip kopyalayabiliyorsak, tüm > >> bilgisayarı da aynı şekilde yedekleyip geri yedekten > >> yükleyebilmeliyiz. Nasıl ki `git` sadece değişiklikleri gönderiyorsa > >> biz de değişiklikleri göndermeliyiz (vs.) ve nasıl ki `git` ile işler > >> tek komutta bitiyorsa, bizimkinde de öyle kolay olmalı. > >> > >> "Buluttan çalışmak işi ile uzak masaüstü ile çalışma işi aynı şey" > >> noktasından hareketle (yanılıyorsam düzeltin lütfen) internet > >> bağlantısının sıkıntılı olduğu noktalarda bu şekilde çalışamayız. > >> Kaldı ki bizler bilgisayarlarımıza dönüştürücüler takıp sahadaki > >> makinalara bağlanıyoruz. İnternetin çok problemli olduğu veya hiç > >> olmadığı zamanlar olduğu noktalarda bilgisayarlarımızı kullanmamız > >> gerekiyor. > >> > >> UUID kopyalama işi zaten sorun değil, sonuçta yeni diskin UUID'sini de > >> istediğimiz gibi değiştirebiliriz. Fakat iki tane aynı UUID'li diski > >> bilgisayara aynı anda bağlamak mümkün olmayacağı için bilgisayara > >> bağlı diskler sadece rol değiştiremeyecek. Aynı anda yalnızca biri > >> bağlı olabilir. Kaldı ki problem sadece UUID'lerin farklılaşması > >> değil, disk yerleşimi de değişebilir. > >> > >> Sanırım kullanım noktamı söylersem daha anlaşılır olacak. > >> > >> Bendeniz işimin bir parçası olarak laptop'ım ile sahada makina > >> programlıyorum. "Saha" dediğimiz yer bir fabrika da olabilir, dağın > >> başında bir tesis de olabilir. > >> > >> Böyle bir yerde, siloların tepesinde bilgisayarınızı elinizden > >> düşürürseniz (evet, düşürmemeniz lazım, ama düşebilir) bunun size > >> maliyeti bilgisayardan çok çok çok daha fazla olur. Bilgisayar birkaç > >> bin TL'ye alınabilir, ancak orada işiniz durursa tüm ekip durur. > >> > >> Ben de şöyle bir çözüm buldum: Bilgisayara bir harici disk > >> bağlayacağım, sahada güvenli bir noktada bunu bilgisayarla > >> eşitleyeceğim (bu işlem en en en fazla bir çay içimi süresinde > >> bitmeli). Bu aldığım yedek o güvenli noktada duracak. Ben çalışırken > >> oraya bıraktığım yedek de çalınabilir (evet, garip bir ülkede > >> yaşıyoruz, adam beğendiği için alabiliyor), dolayısıyla hiçbir özel > >> verimin de başkaları tarafından okunmaması gerekir, bu yüzden kriptolu > >> disklerde tutulmalı. Bir sürü garip garip dosya sistemi barındıracak > >> bu diski bilgisayara bağladığımda da her biri için tek tek > >> uğraşmamalıyım, taktığım anda kriptosu da açılmalı, LVM de > >> aktifleştirilmeli, uygun disk uygun yere mount da edilmeli. Yani bir > >> flaş belleği basitçe usb'ye dürtmekten farkı olmamalı. Bilgisayarımın > >> başına bir şey gelirse herhangi bir bilgisayara "FBI adına" el koyup o > >> az önce aldığım yedek diski takıp işime devam edebilmeliyim. Bu arada, > >> yedek disk ile bilgisayarı açtığımda hemencecik herhangi bir diski az > >> önceki yedeğin rolüne koyabilmeliyim. Bunun için belki o anda uygun > >> ebatta disk bulamayacağım. O zaman birkaç disk bulmalıyım. Bunları da > >> LVM ile biraraya getirip sistemin yedeğini tekrar oluşturmalıyım. Tüm > >> bu "yeni yedek diski oluşturma işi" de yine 1 bardak çay içme süresini > >> geçmemeli. Smith-sync'i bu yüzden yazmaya başladım: > >> https://github.com/ceremcem/smith-sync > >> > >> Bu arada kişisel verilerin olduğu klasör anlık olarak webdav üzerinden > >> yedekleniyor, ama bahsettiğimiz senaryoda internet erişimi kısıtlı > >> olabilir demiştik. Bunu çözmek için de yanımızdaki kendi kablosuz > >> ağımıza bağlı başka bir makine (bu bir Raspberry de olabilir) anlık > >> olarak bu değişiklikleri yedekleyecek, uygun bağlantı bulduğunda kendi > >> sunucularımızla eşitleyecek. Bunu henüz yapmadık ama yapılacaklar > >> listesinde duruyor. > >> > >> rsync'nin de kendine göre sıkıntıları vardı, onu hallettiler mi > >> bilmiyorum ama büyük boyutlu bir dosyanın yerini değiştirdiğinizde > >> değişikliği "silme" ve "yeni dosya oluşturma" olarak görüyor. Aslında > >> o konu çözülse rsync de gayet güzel kullanılabilir. > >> > >> Onun dışında deneme imkanım olmadı ama `bup` güzel bir seçenek gibi > >> duruyor (https://bup.github.io/). > >> > >> Fakat yine, aynı noktaya geliyoruz, bunlar hep yedek alma > >> stratejileri. Yedeklerden sistemi açma konusu bunların dışında > >> kalıyor. > >> > >> Son birkaç haftada çeşitli sebeplerden dolayı tüm sistemimi (800 GB > >> kadar) bir diskten diğer diske taşıyıp durdum. Bunlar arasında katman > >> farkı olanlar da vardı (BTRFS//LVM//LUKS, BTRFS//LUKS) fiziksel > >> farklar olan da vardı (rootfs//DISK_1 -> rootfs//DISK_1 + > >> home//DISK_2). Tüm bu noktalarda işler gayet başarılı oldu ama > >> özellikle şu initramfs'ye parametre verme işinde fena halde takıldım. > >> Bir de yedek rootfs'nin değişmesi gereken /etc/fstab ve /etc/crypttab > >> meselesine bir çözüm getirmek gerekir. > >> > >> 17 Ekim 2017 13:46 tarihinde Abdullah Ülker (Yandex) > >> <[email protected]> yazdı: > >> > +1 > >> > > >> > > >> > 17 Ekim 2017 13:24:02 Koray Toksöz <[email protected]> yazdı: > >> > > >> >> Merhaba > >> >> > >> >> ben de sohbete bir köşesinden dahil olayım, > >> >> Öncelikle şunu belirteyim, uzmanlığım sistem yönetimi değil, yazılım > >> >> geliştirme. > >> >> > >> >> Bu kadar zahmete dizüstü bilgisayarınızı çalışır durumda tutmak için > >> >> girmediğinizi varsayıyorum, kişisel bilgisayarda sadece verilerinizin > >> >> yedeğini almak yeterlidir bence. Bu veriler resimler, libreoffice > >> >> dokümanları vb. olabilir. En zorlu senaryoda bir NAS cihazı alır > basit > >> >> bir > >> >> rsync scripti yazar cron a bağlarsınız. > >> >> > >> >> sunucu tarafına gelirsek, bence burada istediğiniz şey standard dışı > >> >> bir > >> >> durum olduğu için sorun yaşıyorsunuz. > >> >> > >> >> Normal şartlarda, “yedekleme", yedeklemeye çalıştığınız senaryoya > özel > >> >> olmalıdır, öncelik sistemi kurtarmadan önce, sistemi sürekli çalışır > >> >> halde > >> >> tutmak bence. > >> >> Bir örnek vermem gerekirse, > >> >> > >> >> bir uygulamanız var, bu uygulama arkada dört tomcat uygulama > sunucusu, > >> >> mongo sunucuları, redis, iki nginx web sunucusu ve bir fiziksel load > >> >> balancer cihazından oluşsun. > >> >> > >> >> Dikkat ettiyseniz bu uygulama katmanı, bu katmanda yedeklilik zaten > >> >> uygulama sunucular seviyesinde sağlanmış, örneğin 4 app serverden > >> >> herhangi > >> >> birinin başına birşey gelirse kimsenin haberi bile olmaz (hatta > sistem > >> >> yöneticisinin de haberi olmayabilir, o yüzden monitoring önemlidir:)) > >> >> > >> >> birden fazla sunucu, redundant güç kaynakları, hatta birden fazla > rack > >> >> kabinet üzerinde şase yedekliliği de sağladınız, veritabanı > >> >> yedeklerinizi > >> >> düzenli alıyor, yazılım geliştirme yaşam döngüsünü oturtmuş ve > >> >> uygulamalarınızı ona göre yaygınlaştırıp sistemlerinizi izliyorsunuz, > >> >> network switchlerinizde de yedeklilik var ama yetmiyor, hatta tier-3 > >> >> seviyesinde veri merkeziniz bile var ama felaket kurtarma > istiyorsunuz, > >> >> bu > >> >> durumda, coğrafi olarak yedeklilik düşünebilirsiniz, bir tane de > >> >> konyaya > >> >> benzer sistemi kurarsınız. > >> >> Tebrikler, ufak bir uygulamanız vardı, artık coğrafi yedekliliğiniz, > >> >> jeneratörleriniz, upsleriniz, network cihazlarınızın yedekliliği, > >> >> veritabanı ve sanallaştırma çözümleriniznn yedeklerini almak için LTO > >> >> yedekleme üniteleriniz, firewall, IDS ve IPS sistemleriniz, yedekli > >> >> hatta > >> >> belki aynı anda birden fazla operatörden aldığınız internet > >> >> hizmetleriniz, > >> >> fiziksel güvenliği sağlamak için özel güvenlikleriniz, 24 saat veri > >> >> merkezini izleyen elemanlarınız oldu :) > >> >> > >> >> Bütün bunların yerine, bulut çözümlerini de kullanabilirsiniz tabii > ki, > >> >> ihtiyacınız kadar alır, çok daha az ödersiniz. > >> >> > >> >> sunucularda sanallaştırmadan hoşlanmadığınızı söylemişsiniz, fakat > ben > >> >> sanallaştırmayı geçtim, yeni projelerimde mümkünse bulut içerisinde, > >> >> değilse kendi sistemlerimde container tabanlı bir yapı kurmaya > >> >> çalışıyorum > >> >> (docker olarak anahtar kelime verebilirim) > >> >> > >> >> Bir küçük anıyla noktalayayım, > >> >> > >> >> bir şekilde üzerinde veritabanı çalışan sunucudan (maalesef açık > kaynak > >> >> değil) bazı sistem dosyaları da dahil olmak üzere silmeyi başarmışlar > >> >> (rm > >> >> -rf / belki de:)) çalışan başka bir sistemden ve rpm depolarından > >> >> dosyaları > >> >> kopyalayarak birkaç restart ile o sunucuyu çalışır hale getirmeyi > >> >> başarmıştım yarım gün içerisinde. Demem odur ki, linux tabanlı > >> >> sistemlerde, > >> >> "mavi ekrana düşüyorum, güvenli kipte de açılmadı formatı basmam > lazım > >> >> başka çaresi yok (!)” demeden önce pek çok çözüm bulunabilir. > >> >> > >> >> iyi çalışmalar dilerim > >> >> > >> >> > >> >>> On 17 Oct 2017, at 12:06, Cerem Cem ASLAN <[email protected]> > >> >>> wrote: > >> >>> > >> >>> "Sistem" ve "koşan uygulamalar" derken tam olarak nasıl bir ayrımdan > >> >>> bahsettiğimizi anlayamadım. Bana sorsanız "sistem zaten koşan > >> >>> uygulamalardan oluşur" derdim, belki belki sanal makinaları bunun > >> >>> dışında bırakmak gerekirdi. > >> >>> > >> >>> Sistemi sanallaştırmak her zaman çözüm olamıyor maalesef. Şahsen > >> >>> sanallaştırma işini oldukça da gerilimli buluyorum. Mesela > virtualbox > >> >>> hatası verip durduğu için açılmayan sunucularınız oldu mu? Benim > oldu > >> >>> :) Dosya kurtarmaya kalkmak da oldukça sıkıntılı oluyor. Yani > >> >>> sanallaştırma bir seçenek, fakat bir Alex değil. > >> >> > >> >> > >> >> > >> >> > >> >> ---------- > >> >> _______________________________________________ > >> >> Linux-sohbet mailing list > >> >> [email protected] > >> >> https://liste.linux.org.tr/mailman/listinfo/linux-sohbet > >> >> Liste kurallari: http://liste.linux.org.tr/kurallar.php > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Linux-sohbet mailing list > >> > [email protected] > >> > https://liste.linux.org.tr/mailman/listinfo/linux-sohbet > >> > Liste kurallari: http://liste.linux.org.tr/kurallar.php > >> _______________________________________________ > >> Linux-sohbet mailing list > >> [email protected] > >> 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 > > [email protected] > > https://liste.linux.org.tr/mailman/listinfo/linux-sohbet > > Liste kurallari: http://liste.linux.org.tr/kurallar.php > > > _______________________________________________ > Linux-sohbet mailing list > [email protected] > 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 [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-sohbet Liste kurallari: http://liste.linux.org.tr/kurallar.php
