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
