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
