‫Son videoda Zorunluluk ve Zorunsuzluğu ele almıştım.
‫Açıklayıcı. Kubernetes'te birinin ya da diğerinin özellikleri
‫hakkında konuştuk.
‫Gerçekten de Kubernetess dokümantasyonuna baktığınızda,
‫üç farklı stile uygun olduğunu görürsünüz.
‫Arada ince bir fark vardır, ancak bunlar gerçekten de bir tarafta
‫tamamen zorunlu, diğer tarafta tamamen bildirimsel bir
‫spektrum üzerindedir.
‫Ardından, kullanmak isterseniz ortadaki bu güzel,
‫küçük seçenek. Bu kursta şimdiye
‫kadar size katı ve zorunlu CLI komutlarını
‫öğrettim. Buna kaçmak, ifşa olmak da dahil.
‫Belki de ölçeğimiz vardır.
‫Düzenlemeyi ele almadık ama tam olarak düşündüğünüz
‫şeyi yapıyor. Bir kaynağı gerçek zamanlı olarak düzenler.
‫Ya da bir çalışma yapmanın yeni yolu olan dağıtım oluşturun.
‫Bunlar, işlerin nasıl yürüdüğünü öğrenmek
‫için gerçekten en iyisidir. Kaynak türlerini ve ne yaptıklarını öğrenmek,
‫kişisel projeler ve belki de sorumlu tek kişi olduğunuz gerçekten
‫küçük kurulumlar. Otomatikleştirmeye
‫çalışmıyorsunuz. Tam bir üretim iş akışı ve CICD oluşturmaya
‫çalışmıyorsunuz, değil mi?
‫Bunlar için harika.
‫Kubernetes'in create komutları ile size
‫sunduğu güzel bir orta yol var: create komutlarını kendi
‫başlarına kullanabileceğiniz gibi bunları bir YAML
‫dosyası ile de kullanabilirsiniz.
‫create -f kullanabilir ve daha önce gördüğümüz gibi
‫bu özelliklerden birini verebilirsiniz.
‫Ona bir özellik verebilirsiniz ve o da orada sahip olduğunuz nesnelerden herhangi
‫birini yaratacaktır. Bu dosyada birden fazla
‫nesneniz olabilir. Orada bir dağıtım ve bir
‫hizmetiniz olabilir.
‫Belki sahip olduğunuz bazı depolama ihtiyaçları, ağ kurulumları,
‫her neyse. Tüm bunları güzel bir dosyada toplayabilirsiniz.
‫Ardından, orada herhangi bir şeyi değiştirmeniz
‫gerekirse, dosyayı düzenleyebilir ve ardından henüz ele almadığımız
‫replace komutunu kullanabilirsiniz, ancak düşündüğünüz
‫şeyi yapar. Bir de kullandığımız delete
‫komutu var ki o da sizin düşündüğünüz şeyi yapıyor.
‫Burada güzel olan şey, bunun bir tür orta yol olması, değil mi?
‫Sizi YAML kullanmaya zorlar, böylece ne yaptığınızı belgelemiş olursunuz
‫ve git gibi bir şey kullanıyorsanız bu değişiklik kaydına
‫sahip olursunuz.
‫Umarım git kullanıyorsunuzdur.
‫Ancak buradaki fayda, biz insanlar için yaratma,
‫değiştirme veya silme işlemlerini kullanıyor
‫olmamızdır. Böylece, create komutunu kullanırken
‫yanlışlıkla bir şeyi silmediğimizi bilmemiz için bize kullanmamız
‫gereken bu açık fiili verir.
‫Ve replace komutunu kullandığımızda yanlışlıkla bir şeyi
‫silmediğimizi biliyoruz.
‫Yani bu yardımcı olur, değil mi?
‫Bu, tam, bildirimsel nesne modeline ulaştığınızda
‫kullanmanız gerekecek YAML spesifikasyonlarında
‫ayaklarınızı ıslatmak için iyi bir orta zemindir.
‫Ben de daha önce bundan bahsediyordum.
‫Bu, yalnızca YAML kullandığınız ve yalnızca apply komutunu
‫kullandığınız yerdir.
‫Uygulamanıza yardımcı olacak başka komutlar da vardır, örneğin diff,
‫yapmak üzere olduğunuz değişiklikleri size gösterecektir.
‫Ancak, uygulamak basitçe YAML'yi düzenlemek ve uygulamayı
‫çalıştırmaktır.
‫Biraz daha YAML düzenleyin, uygulamayı çalıştırın.
‫Bu, Swarm yığınlarına sahip olduğumuz Swarm'a benzer.
‫Hatırlarsanız, bir docker stack deploy komutu var
‫ve bunları güncellemek için aynı komutu tekrar tekrar
‫kullanıyorsunuz.
‫Burada da tamamen bildirimsel nesnelerle aynı
‫tarz söz konusudur. Dokümantasyonlarının olması
‫güzel ve bunu bu dersin kaynak bağlantılarında göreceksiniz,
‫bu üç farklı tür hakkında çok ayrıntılı bir sayfa.
‫Bunu kontrol etmenizi tavsiye ederim.
‫Bu konuyla ilgili kaynak sayfasını
‫okusanız bile, tüm bunlar için vereceğim gerçek
‫kural, üç yaklaşımı karıştırmamaktır.
‫Gerçek üretim bağımlılıklarınız olduğunda bu üçünü
‫karıştırmamanız daha önemlidir.
‫Üretimde, olgunluk modelinizde olabildiğince
‫erken, apply komutuyla YAML dosyalarını
‫kullanarak tam bildirimsel modele bağlı kalmaya
‫çalışmanızı gerçekten savunacağım.
‫Bu konuda ne kadar çabuk rahat olursanız, bunu YAML'de
‫belgelemeye ve her değiştirdiğinizde bir git-commit'e kaydetmeye
‫ne kadar çabuk alışırsanız, bu süreç daha sonra
‫size gerçekten fayda sağlayacaktır.
‫Herhangi biri yaptığınız değişiklikleri görmek istediğinde,
‫git-log'a bakabilir. Çoğumuz muhtemelen bugün git'te bir şeyler
‫yapıyoruz, bu yüzden sadece bu YAML'leri saklamak için başka bir git
‫reposu oluşturmak sizin için çok fazla çaba gerektirmeyecek,
‫değil mi? Makinenizde sadece yerel olarak
‫git yapıyor olsanız bile, git locally temel olarak bu YAML'lerde
‫yaptığınız değişikliklerin geçmişini görmenize yardımcı
‫olabilir, böylece üç ay önce neyi değiştirdiğinizi altı ay sonra
‫unuttuğunuzda, geri dönüp bakabilir ve orada ne yaptığınızı görebilirsiniz.
‫Bu size gerçekten çok zaman kazandıracak.
‫En önemli kural, yaklaşımları karıştırmamaktır.
‫Çalıştırarak bir şey yaratırsanız, daha sonra bu kaynağı
‫yönetmek için uygulamayı kullanmak daha zor olacaktır.
‫Nesneleri daha sonra bozmadan düzenlemek için
‫bu komutlardan bazılarıyla yapabileceğiniz küçük
‫hileler vardır.
‫Ama gerçekten, eğer üretim yapacaksanız, muhtemelen üretim
‫sunucunuzda bu çalıştırma komutlarıyla başlamamalısınız.
‫Muhtemelen
‫uzun vadeli düşünmeli ve YAML ile devam etmelisiniz. Buradaki dört tavsiyem, sizin yaptığınız
‫gibi komut satırını öğrenmek.
‫Bu zorunlu komut satırını öğrenin, böylece yerel olarak
‫çalıştırabilirsiniz. Ve bu komutlara bazen sorun giderme,
‫test etme ve sunucular için de ihtiyaç duyacaksınız.
‫Ardından, ilk üretim Kubernetes'inize hazırlanmak için yapabileceğiniz
‫en hızlı şey apply komutunu, diff komutunu ve kullanacağınız tüm
‫kaynak türleri için YAML spesifikasyonunu
‫öğrenmektir.
‫Sonra dediğim gibi git'te depolayın.
‫Ekibinizin kullanabileceği bir yerde yerel git veya git
‫depoları olsa bile.
‫YAML'yi düzenleme, değişikliği git'e
‫kaydetme, ardından kubectl apply ile uygulama, ardından
‫tekrar kaydetme ve değişiklikleri git'te saklama yöntemini
‫unutmayın.
‫Bu süreç sizi DevOps otomasyonu yoluna ve daha önce
‫bahsettiğim git-ops'a götürecektir, ki bence
‫bu araçlardan bazıları bu noktaya doğru gitmeye
‫başlıyor. Git merkezli olduğumuz yer.
‫Tıpkı yazılımcıların yaptığı gibi bir git reposunda değişiklikler
‫yapıyoruz...
‫Bu DevOps iş akışında da aynı şeyi yapıyoruz.
‫Kendi operasyonlarımız ve araçlarımız için onların değişim
‫çalışmalarını bir ekip halinde yapma şeklini benimsiyoruz.