Bu, yeni sürüme geçişe hazırlanmanıza yardımcı olacak, yaklaşan Red Hat OpenShift platform 4.0 güncellemesindeki değişiklikler, iyileştirmeler ve eklemelerle ilgili bir dizi gönderinin ilkidir.
Acemi Kubernetes topluluğunun 2014 sonbaharında Google'ın Seattle ofisinde ilk kez toplandığı andan itibaren Kubernetes projesinin kaderi, günümüzde yazılımın geliştirilme ve dağıtılma biçiminde devrim yaratmasıydı. Aynı zamanda, genel bulut hizmet sağlayıcıları, BT ile çalışmayı ve yazılım oluşturmayı çok daha kolay ve erişilebilir hale getiren ve bunları, XNUMX'lerin başında çok az kişinin hayal edebileceği şekilde inanılmaz derecede uygun fiyatlı hale getiren altyapı ve hizmetlerin geliştirilmesine aktif olarak yatırım yapmaya devam etti. on yıl.
Elbette, her yeni bulut hizmetinin duyurusuna Twitter'daki uzmanlar arasında çok sayıda tartışma eşlik etti ve açık kaynak döneminin sonu, şirket içi BT'nin gerilemesi ve bulut hizmetlerinin kaçınılmazlığı gibi çeşitli konularda tartışmalar yürütüldü. bulutta yeni bir yazılım tekelinin kurulması ve yeni X paradigmasının nasıl diğer tüm paradigmaların yerini alacağı.
Söylemeye gerek yok, tüm bu anlaşmazlıklar çok aptalcaydı
Gerçek şu ki hiçbir şey ortadan kaybolmayacak ve bugün hayatımızda sürekli yeni yazılımların ortaya çıkması nedeniyle son ürünlerde ve bunların geliştirilme şekillerinde katlanarak bir büyüme görebiliyoruz. Ve etraftaki her şeyin değişeceği gerçeğine rağmen, özünde her şey değişmeden kalacak. Yazılım geliştiricileri hâlâ hata içeren kod yazmaya devam edecek, operasyon mühendisleri ve güvenilirlik uzmanları çağrı cihazlarıyla dolaşıp Slack'te otomatik uyarılar almaya devam edecek, yöneticiler yine OpEx ve CapEx açısından çalışmaya devam edecek ve her arıza meydana geldiğinde geliştirici, kıdemli olanı görevlendirecek. Üzgün bir şekilde şu sözlerle iç çekiyor: “Sana söylemiştim”...
Gerçekten mi tartışılmalı, daha iyi yazılım ürünleri oluşturmak için hangi araçlara sahip olabileceğimiz ve bunların güvenliği nasıl geliştirip geliştirmeyi daha kolay ve daha güvenilir hale getirebilecekleridir. Projeler karmaşıklaştıkça yeni riskler ortaya çıkıyor ve günümüzde insanların hayatları yazılıma o kadar bağımlı ki geliştiricilerin işlerini daha iyi yapmaya çalışmaları gerekiyor.
Kubernetes böyle bir araçtır. Yazılımın kullanıcılar için daha güvenilir, yönetimi kolay ve daha güvenli olmasını sağlayacak şekilde Red Hat OpenShift'in diğer araç ve hizmetlerle tek bir platformda birleştirilmesine yönelik çalışmalar sürüyor.
Bununla birlikte OpenShift ekibi basit bir soru soruyor:
Kubernetes'le çalışmayı nasıl daha kolay ve rahat hale getirebilirsiniz?
Cevap şaşırtıcı derecede açıktır:
- bulut üzerinde veya bulut dışında dağıtımın karmaşık yönlerini otomatikleştirin;
- karmaşıklığı gizlerken güvenilirliğe odaklanın;
- basit ve güvenli güncellemeleri yayınlamak için sürekli çalışmaya devam edin;
- kontrol edilebilirliği ve denetlenebilirliği sağlamak;
- Başlangıçta yüksek güvenlik sağlamaya çalışın, ancak kullanılabilirlikten ödün vermeyin.
OpenShift'in bir sonraki sürümü, hem yaratıcıların deneyimlerini hem de dünyanın en büyük şirketlerinde büyük ölçekte yazılım uygulayan diğer geliştiricilerin deneyimlerini dikkate almalıdır. Ayrıca, günümüzün modern dünyasının temelini oluşturan açık ekosistemlerin birikmiş tüm deneyimlerini de hesaba katmalıdır. Aynı zamanda, amatör geliştiricilerin eski zihniyetini terk etmek ve yeni bir otomatikleştirilmiş gelecek felsefesine geçmek gerekiyor. Yazılımı dağıtmanın eski ve yeni yolları arasındaki boşluğu doldurması ve ister en büyük bulut sağlayıcısı tarafından barındırılıyor olsun ister uçtaki küçük sistemlerde çalışıyor olsun, mevcut tüm altyapıdan tam olarak yararlanması gerekiyor.
Bu sonuca nasıl ulaşılır?
Red Hat'te yerleşik topluluğu korumak ve şirketin dahil olduğu projelerin kapanmasını önlemek için uzun süre sıkıcı ve nankör işler yapmak adettir. Açık kaynak topluluğu, eğlenceli, eğitici, yeni fırsatlar açan ve tek kelimeyle güzel olan en olağanüstü şeyleri yaratan çok sayıda yetenekli geliştiriciyi içerir, ancak elbette hiç kimse herkesin aynı yönde hareket etmesini veya ortak hedefler peşinde koşmasını beklemez. . Kullanıcılarımıza fayda sağlayacak alanlar geliştirmek için bu enerjiyi kullanmak ve doğru yöne yönlendirmek bazen gerekli olabilir ancak aynı zamanda topluluklarımızın gelişimini izlemeli ve onlardan öğrenmeliyiz.
Red Hat, 2018'in başında geleceğe dair benzer görüşlere sahip, daha güvenli ve güvenilir, açık kaynak ilkelerine göre oluşturulmuş CoreOS projesini satın aldı. Şirket, tüm yazılımların güvenli bir şekilde çalışmasını sağlamak için felsefemizi uygulamaya koyarak bu fikirleri daha da geliştirmek ve uygulamak için çalıştı. Tüm bu çalışmalar Kubernetes, Linux, genel bulutlar, özel bulutlar ve modern dijital ekosistemimizi destekleyen binlerce başka proje üzerine inşa edilmiştir.
OpenShift 4'ün yeni sürümü net, otomatik ve daha doğal olacak
OpenShift platformu, çıplak donanım desteği, kullanışlı sanallaştırma, otomatik altyapı programlama ve elbette konteynerler (aslında sadece Linux görüntüleridir) ile en iyi ve en güvenilir Linux işletim sistemleriyle çalışacaktır.
Platformun başlangıçtan itibaren güvenli olması gerekir, ancak yine de geliştiricilerin kolayca yineleme yapmasına olanak tanıyın; yani yeterince esnek ve güvenli olmalı, aynı zamanda yöneticilerin platformu kolayca denetlemesine ve yönetmesine olanak tanıyın.
Yazılımın "hizmet olarak" çalıştırılmasına izin vermeli ve operatörler için yönetilemez altyapı büyümesine yol açmamalıdır.
Geliştiricilerin kullanıcılar ve müşteriler için gerçek ürünler yaratmaya odaklanmasına olanak tanıyacak. Donanım ve yazılım ayarları ormanında ilerlemeniz gerekmeyecek ve tüm kazara ortaya çıkan sorunlar geçmişte kalacak.
OpenShift 4: Bakım gerektirmeyen NoOps platformu
В şirketin OpenShift 4 vizyonunu şekillendirmeye yardımcı olan görevleri açıkladı. Ekibin hedefi, yazılımın çalıştırılması ve bakımıyla ilgili günlük görevleri mümkün olduğunca basitleştirmek, bu süreçleri hem uygulamaya katılan uzmanlar hem de geliştiriciler için kolay ve rahat hale getirmektir. Peki bu hedefe nasıl yaklaşabilirsiniz? Minimum müdahale gerektiren yazılımları çalıştırmak için bir platform nasıl oluşturulur? Bu bağlamda NoOps ne anlama geliyor?
Özetlemeye çalışırsanız, geliştiriciler için "sunucusuz" veya "NoOps" kavramları, "operasyonel" bileşeni gizlemenize veya geliştirici için bu yükü en aza indirmenize olanak tanıyan araçlar ve hizmetler anlamına gelir.
- Sistemlerle değil, uygulama arayüzleriyle (API'ler) çalışın.
- Yazılımı uygulamaya zahmet etmeyin; bırakın sağlayıcı bunu sizin için yapsın.
- Hemen büyük bir çerçeve oluşturmaya girişmeyin; "yapı taşları" görevi görecek küçük parçalar yazarak başlayın, bu kodun diskler ve veritabanlarıyla değil, veriler ve olaylarla çalışmasını sağlamaya çalışın.
Amaç, daha önce olduğu gibi, yazılım geliştirmede yinelemeleri hızlandırmak, daha iyi ürünler yaratma fırsatı sağlamak ve böylece geliştiricinin, yazılımının üzerinde çalıştığı sistemler hakkında endişelenmesine gerek kalmamasıdır. Deneyimli bir geliştirici, kullanıcılara odaklanmanın durumu hızla değiştirebileceğinin bilincindedir; bu nedenle, gerekli olduğundan kesinlikle emin olmadığınız sürece yazılım yazmaya çok fazla çaba harcamamalısınız.
Bakım ve operasyon profesyonelleri için "NoOps" kelimesi biraz korkutucu gelebilir. Ancak saha mühendisleriyle iletişim kurulduğunda, güvenilirliği ve güvenilirliği sağlamayı amaçlayan kullandıkları kalıp ve tekniklerin (Site Güvenilirlik Mühendisliği, SRE) yukarıda açıklanan kalıplarla pek çok benzerliğe sahip olduğu ortaya çıkıyor:
- Sistemleri yönetmeyin, yönetim süreçlerini otomatikleştirin.
- Yazılımı uygulamayın; dağıtmak için bir işlem hattı oluşturun.
- Tüm hizmetlerinizi bir araya getirmekten ve bir hizmetin arızalanmasının tüm sistemin çökmesine neden olmasına izin vermekten kaçının; bunları otomasyon araçlarını kullanarak tüm altyapınıza dağıtın ve izlenebilecek ve izlenebilecek şekillerde bağlayın.
SRE'ler bir şeylerin ters gidebileceğini biliyor ve sorunun izini sürüp çözmeleri gerekeceğini biliyorlar; bu nedenle rutin işleri otomatikleştiriyorlar ve hata bütçelerini önceden belirliyorlar, böylece bir sorun ortaya çıktığında önceliklendirmeye ve karar vermeye hazır oluyorlar.
OpenShift'teki Kubernetes, iki ana sorunu çözmek için tasarlanmış bir platformdur: sizi sanal makineleri veya yük dengeleyici API'lerini anlamaya zorlamak yerine, daha yüksek düzeyde soyutlamalarla (dağıtım süreçleri ve hizmetleri) çalışır. Yazılım aracıları yüklemek yerine konteynerleri çalıştırabilir ve kendi izleme yığınınızı yazmak yerine platformda zaten mevcut olan araçları kullanabilirsiniz. Dolayısıyla, OpenShift 4'ün gizli sosu aslında bir sır değil; geliştiricilere ve operasyon mühendislerine yardımcı olmak için yalnızca SRE ilkelerini ve sunucusuz kavramları alıp bunları mantıksal sonuçlarına götürmek gerekiyor:
- Uygulamaların kullandığı altyapıyı otomatikleştirin ve standartlaştırın
- Geliştiricilerin kendilerini kısıtlamadan dağıtım ve geliştirme süreçlerini birbirine bağlayın
- XNUMX. hizmetin, özelliğin, uygulamanın veya tüm yığının başlatılmasının, denetlenmesinin ve güvenliğinin sağlanmasının ilkinden daha zor olmamasını sağlamak.
Ancak OpenShift 4 platformu ile öncülleri arasındaki ve bu tür sorunların çözümüne yönelik "standart" yaklaşımdan farkı nedir? Uygulama ve operasyon ekipleri için ölçeği yönlendiren şey nedir? Çünkü bu durumda kral kümedir. Bu yüzden,
- Kümelerin amacının net olduğundan emin oluyoruz (Sevgili bulut, bu kümeyi yapabildiğim için aldım)
- Kümeye hizmet edecek makineler ve işletim sistemleri mevcuttur (Majesteleri)
- Ana bilgisayarların durumunu kümeden yönetin, yeniden inşa edilmelerini (sürüklenme) en aza indirin.
- Sistemin her önemli unsuru için sorunları takip edecek ve ortadan kaldıracak bir dadıya (mekanizmaya) ihtiyaç vardır.
- Bir sistemin *her* unsurunun veya öğesinin başarısızlığı ve ilgili kurtarma mekanizmaları hayatın normal bir parçasıdır
- Tüm altyapının API aracılığıyla yapılandırılması gerekir.
- Kubernetes'i çalıştırmak için Kubernetes'i kullanın. (Evet, evet, bu bir yazım hatası değil)
- Güncellemelerin kurulumu kolay ve sorunsuz olmalıdır. Bir güncellemeyi yüklemek için birden fazla tıklama gerekiyorsa, o zaman açıkça bir şeyleri yanlış yapıyoruz demektir.
- Herhangi bir bileşenin izlenmesi ve hata ayıklaması sorun olmamalıdır ve bu nedenle tüm altyapı genelinde izleme ve raporlama da kolay ve rahat olmalıdır.
Platformun yeteneklerini çalışırken görmek ister misiniz?
OpenShift 4'ün önizleme sürümü geliştiricilerin kullanımına sunuldu. Kullanımı kolay bir yükleyiciyle AWS üzerinde Red Had CoreOS'un üzerinde bir küme çalıştırabilirsiniz. Önizlemeyi kullanmak için yalnızca altyapıyı hazırlamak üzere bir AWS hesabına ve önizleme görüntülerine erişmek için bir dizi hesaba ihtiyacınız vardır.
- Başlamak için şuraya gidin: ve “Başlayın”a tıklayın.
- Red Hat hesabınızda oturum açın (veya yeni bir tane oluşturun) ve ilk kümenizi kurmak için talimatları izleyin.
Başarılı kurulumun ardından eğitimlerimize göz atın OpenShift 4 platformunu Kubernetes'i çalıştırmanın bu kadar kolay ve rahat bir yolu haline getiren sistem ve kavramları daha derinlemesine anlamak için.
Yeni OpenShift sürümünü deneyin ve görüşünüzü paylaşın. Kumbernetes ile çalışmayı olabildiğince erişilebilir ve zahmetsiz hale getirmeye kararlıyız; NoOps'un geleceği bugün başlıyor.
Ve şimdi dikkat!
Konferansta 20 Nisan'da OpenShift geliştiricilerinden biri olan Vadim Rutkovsky bir ana sınıf düzenleyecek - on kümeyi kıracak ve onları düzeltmeye zorlayacak. Konferans ücretlidir ancak #RedHat promosyon koduyla %37 indirimden yararlanırsınız
Master dersi 17:15 - 18:15 arasıdır ve stand tüm gün açıktır. Tişörtler, şapkalar, çıkartmalar - her zamanki gibi!
Salon #2
"Burada tüm sistemin değişmesi gerekiyor: Kırık k8 kümelerini sertifikalı tamircilerle birlikte onarıyoruz."
Kaynak: habr.com