‫Bu bölüm, kalıcı veriler etrafındaki konferanslar ve ödevlerle dolacak.
‫Öncelikle, kalıcı verilerin sorunlarını ve bunun başta bir sorun
‫haline geldiğini tartışacağız.
‫Anlamanız gereken temel kavramlar değişmez altyapı fikridir.
‫Ve kapların etrafındaki fikir, doğal olarak tasarımda kısa ömürlüdür.
‫Bunları birinci derste ele alacağız. Ardından veri hacimlerine ve bu sorunların bazılarını
‫kalıcı verilerin etrafında nasıl çözdüklerine dalacağız. Sonra bind bağlamlarını ve bunun kalıcı veriyle
‫farklı sorunları nasıl çözdüğünü de keşfedeceğiz. olacağı konusunda bu bölümle birkaç atama yapacağız.
‫Ardından, veritabanlarının kapsayıcılarını değiştirirken, veritabanı verilerini korumanın nasıl Ayrıca, kodu düzenlerken ana
‫makinenin bir kabına gerçekte kod eklerken, bu
‫kodu kapsayıcıda canlı olarak çalıştırabilirsiniz. İlk dersin gereklilikleri sadece konteynırların nasıl çalıştırılacağını ve
‫şu ana kadar tartıştığımız konteyner ve görüntü konseptlerini anlamaya yöneliktir.
‫Şimdiye kadar, yalnızca bir kapsayıcı çalıştırdıktan sonra oluşturulabilecek benzersiz veriler değil, bir kapsayıcıyı çalıştırmak için neyin
‫gerekli olduğunu merak ettiniz.
‫Konteynerlerin değişmez ve kısa ömürlü olması amaçlanmıştır.
‫Bunlar değişmeyen ve geçici veya tek kullanımlık fantezi kelimeleridir.
‫Buradaki fikir, bir konteyneri atıp bir imajdan yeni bir tane yaratmak olabilir, değil
‫mi?
‫O halde, konteynırların gerçek bir sınırlamasından değil, daha çok bir tasarım hedefinden veya en
‫iyi uygulamalardan bahsediyoruz.
‫Bu, değişen altyapı fikridir, burada çalıştıklarında şeyleri değiştirmiyoruz.
‫Bir yapılandırma değişikliğinin olması gerekiyorsa veya konteyner sürümünün yükseltilmesi gerekiyorsa, tamamen yeni
‫bir kapsayıcı yeniden kuruyoruz.
‫Bu bize güvenilirlik ve tutarlılık açısından büyük avantajlar sağlıyor ve değişikliklerin tekrarlanabilir olmasını sağlıyor.
‫Fakat bir dezavantaj var.
‫Uygulamanızın üreteceği benzersiz veriler ne olacak? Bu veritabanları veya anahtar değer mağazaları veya uygulamanızın bir
‫dosyaya verdiği başka bir şey var mı?
‫İdeal olarak, konteynırlar, uygulama ikili dosyaları ile karıştırılmış benzersiz verilerinizi içermemelidir. Bu "endişelerin ayrılması" olarak bilinir
‫ve Docker aslında burada büyük bir fayda sağlar.
‫Uygulamanızın güncellenmiş bir sürümüyle birlikte yeni bir kapsayıcı oluşturarak uygulamanızı güncelleyebiliriz ve ideal olarak, benzersiz
‫verilerimiz, hala nerede olması gerektiği ve konteynırın geri dönüştürülmesi sırasında bizim için korunmuştur.
‫Şu ana kadar fark etmediyseniz, kullandığımız konteynerler varsayılan olarak kalıcıydı.
‫Bunların içindeki değişiklikler aslında yeniden başlatma boyunca tutuldu ve kap kaldırılıncaya kadar yeniden başlatıldı.
‫Kabı durdurduğumuzdan veya ana makineyi yeniden başlattığımızdan,
‫kabın dosya değişiklikleri gitmediği anlamına gelmez.
‫Yalnızca UFS katmanın kaybolduğu konteyneri kaldırdığımızda, ancak bunu istediğiniz gibi
‫yapabilmek istiyoruz.
‫Benzersiz verilerle ilgili bu sorun endüstride "kalıcı veriler" olarak bilinir ve konteynırlara kadar
‫gerçekten bunun için bir isim vermedik. Çünkü, eski uygulamalarınızı beş ila on yıl veya
‫daha uzun süre çalıştıran eski sunucuları biliyorsunuz gibi, yaptığınız çoğu şey kalıcıydı.
‫Her şey varsayılan olarak kalıcıydı.
‫Artık yeni konteynır ve uygulama otomasyon ölçeklemesinde, kalıcı veriler benzersiz bir
‫sorun oluşturuyor.
‫Donör, bu sorunun "veri hacimleri" ve
‫"bağlama" olarak bilinen iki çözümü vardır. "Liman hacimleri, benzersiz verileri depolamak için
‫söz konusu kapsayıcı birliği dosya sisteminin dışında özel bir
‫yeri oluşturan bir kapsayıcı için bir yapılandırma seçeneğidir.
‫Bu, konteynerlerin taşınması boyunca korur ve onu istediğimiz konteynerin herhangi birine bağlamamızı sağlar.
‫Ve konteyner sadece onu bir yerel dosya yolu gibi görür.
‫Sonra bind mountları var, bunlar sadece bir host dizinini veya dosyasını bir konteynerle paylaşıyor ya da monte ediyoruz.
‫Yine, kapsayıcıya yerel dosya yolu veya dizin yolu gibi görünecektir.
‫Gerçekten ev sahibinden geldiğini bilmiyor.