OpenShift - Hızlı Kılavuz

OpenShift, Red Hat tarafından barındırılan bir Hizmet Olarak Bulut Geliştirme Platformudur (PaaS). Uygulamaları oluşturmak, test etmek ve çalıştırmak ve nihayet bunları bulutta dağıtmak için kullanılan açık kaynaklı, bulut tabanlı, kullanıcı dostu bir platformdur.

OpenShift, Node.js, Ruby, Python, Perl ve Java gibi farklı dillerde yazılmış uygulamaları yönetebilir. OpenShift'in en önemli özelliklerinden biri genişletilebilir olmasıdır, bu da kullanıcıların diğer dillerde yazılmış uygulamayı desteklemesine yardımcı olur.

OpenShift, soyutlama katmanı olarak çeşitli sanallaştırma kavramlarıyla birlikte gelir. OpenShift'in altında yatan konsept sanallaştırmaya dayanmaktadır.

Sanallaştırma

Genel olarak sanallaştırma, sistemden, depolamadan veya bir işletim sisteminden başlayan herhangi bir şeyin fiziksel veya gerçek versiyonundan ziyade sanal bir sistemin oluşturulması olarak tanımlanabilir. Sanallaştırmanın temel amacı, BT altyapısını daha ölçeklenebilir ve güvenilir hale getirmektir. Sanallaştırma kavramı on yıllardır varlığını sürdürmektedir ve günümüzde BT endüstrisinin evrimi ile, Sistem seviyesinden Donanım seviyesinden Sunucu seviyesinde sanallaştırmaya kadar çok çeşitli katmanlara uygulanabilir.

Nasıl çalışır

Herhangi bir uygulamanın veya işletim sisteminin gerçek fiziksel katmanından soyutlandığı bir teknoloji olarak tanımlanabilir. Sanallaştırma teknolojisinin temel kullanımlarından biri, katmanı temel donanımdan soyutlamak için hiper yönetici adı verilen bir yazılım kullanan sunucu sanallaştırmadır. Sanallaştırma üzerinde çalışan bir işletim sisteminin performansı, fiziksel donanım üzerinde çalıştığı zamanki kadar iyidir. Ancak, çalışan sistem ve uygulamaların çoğu temeldeki donanımın kullanılmasını gerektirmediğinden sanallaştırma kavramı popülerdir.

Fiziksel ve Sanal Mimari

Sanallaştırma Türleri

  • Application Virtualization- Bu yöntemde, uygulama temeldeki işletim sisteminden soyutlanır. Bu yöntem, uygulamanın, altındaki işletim sistemine bağlı olmaksızın tek başına çalıştırılabildiği çok kullanışlıdır.

  • Desktop Virtualization- Bu yöntem, masaüstünde ince bir istemci kullanarak masaüstüne uzaktan erişilebilen iş istasyonu yükünü azaltmak için kullanılır. Bu yöntemde, masaüstü bilgisayarlar çoğunlukla bir veri merkezinde çalıştırılır. Klasik bir örnek, kuruluşların çoğunda kullanılan bir Sanal Masaüstü Görüntüsü (VDI) olabilir.

  • Data Virtualization - Geleneksel veri ve veri yönetimi yöntemlerinden soyutlama ve uzaklaşma yöntemidir.

  • Server Virtualization- Bu yöntemde, fiziksel sunucu, süreç ve işletim sistemini içeren sunucu ile ilgili kaynaklar sanallaştırılır. Bu soyutlamayı sağlayan yazılım genellikle hiper yönetici olarak adlandırılır.

  • Storage Virtualization - Birden fazla depolama cihazında tek bir merkezi konsoldan yönetilen tek bir depolama cihazında havuzlama işlemidir.

  • Network Virtualization - Mevcut tüm ağ kaynaklarının, her biri birbirinden bağımsız olan mevcut bant genişliği ve kanalları bölerek birleştirildiği yöntemdir.

OpenShift

OpenShift, bulut özellikli bir Hizmet Olarak Uygulama Platformudur (PaaS). Kuruluşların geleneksel uygulama altyapılarını ve platformlarını fiziksel, sanal ortamlardan buluta taşımalarına yardımcı olan açık kaynaklı bir teknolojidir.

OpenShift, OpenShift bulut platformunda kolayca geliştirilip dağıtılabilen çok çeşitli uygulamaları destekler. OpenShift temel olarak geliştiriciler ve kullanıcılar için üç tür platformu destekler.

Hizmet Olarak Altyapı (IaaS)

Bu formatta, hizmet sağlayıcı, bazı önceden tanımlanmış sanal donanım yapılandırmalarına sahip donanım düzeyinde sanal makineler sağlar. Bu alanda AWS Google bulutu, Rackspace ve çok daha fazlasından başlayarak birden fazla rakip var.

Uzun bir kurulum ve yatırım prosedüründen sonra IaaS'ye sahip olmanın temel dezavantajı, işletim sistemi ve sunucu paketlerini kurmak ve sürdürmek, altyapı ağını yönetmek ve temel sistem yönetimiyle ilgilenmekten sorumlu olmasıdır.

Hizmet Olarak Yazılım (SaaS)

SaaS ile altta yatan altyapı hakkında en az endişe duyulur. Tak ve çalıştır kadar basittir, burada kullanıcının sadece hizmetlere kaydolması ve kullanmaya başlaması gerekir. Bu kurulumun ana dezavantajı, servis sağlayıcı tarafından izin verilen minimum miktarda özelleştirme yapılabilmesidir. SaaS'ın en yaygın örneklerinden biri, kullanıcının yalnızca oturum açması ve kullanmaya başlaması gereken Gmail'dir. Kullanıcı ayrıca hesabında bazı küçük değişiklikler yapabilir. Ancak, geliştiricinin bakış açısından pek kullanışlı değil.

Hizmet Olarak Platform (PaaS)

SaaS ve IaaS arasında bir orta katman olarak düşünülebilir. PaaS değerlendirmesinin birincil hedefi, geliştirme ortamının birkaç komutla döndürülebildiği geliştiriciler içindir. Bu ortamlar, doğrudan bir veritabanı içeren bir web uygulama sunucusuna sahip olmaktan tüm geliştirme ihtiyaçlarını karşılayacak şekilde tasarlanmıştır. Bunu yapmak için, tek bir komuta ihtiyacınız var ve servis sağlayıcı işleri sizin yerinize yapıyor.

Neden OpenShift Kullanmalı?

OpenShift, kurumsal birimlerin, temel işletim sistemi hakkında endişelenmeden uygulamalarını bulutta barındırmaları için ortak bir platform sağlar. Bu, uygulamaları bulut üzerinde kullanmayı, geliştirmeyi ve dağıtmayı çok kolaylaştırır. Temel özelliklerinden biri, her türlü geliştirme ve test için yönetilen donanım ve ağ kaynakları sağlamasıdır. OpenShift ile PaaS geliştiricisi, gerekli ortamlarını spesifikasyonlarla tasarlama özgürlüğüne sahiptir.

OpenShift, hizmet planları söz konusu olduğunda farklı türden hizmet düzeyi anlaşmaları sağlar.

Free - Bu plan, her biri için 1 GB alan olmak üzere üç yılla sınırlıdır.

Bronze - Bu plan 3 yılı içerir ve yılda 1 GB alanla 16 yıla kadar genişler.

Sliver - Bu 16 yıllık bronz planıdır, ancak ek maliyet olmadan 6GB depolama kapasitesine sahiptir.

Yukarıdaki özelliklerin dışında OpenShift, OpenShift Enterprise olarak bilinen şirket içi sürümü de sunar. OpenShift'te geliştiriciler, ölçeklenebilir ve ölçeklenemez uygulamalar tasarlama avantajına sahiptir ve bu tasarımlar HAproxy sunucuları kullanılarak gerçekleştirilir.

Özellikleri

OpenShift tarafından desteklenen birden fazla özellik vardır. Çok azı -

  • Çoklu Dil Desteği
  • Çoklu Veritabanı Desteği
  • Genişletilebilir Kartuş Sistemi
  • Kaynak Kodu Sürüm Yönetimi
  • Tek Tıkla Dağıtım
  • Çoklu Ortam Desteği
  • Standartlaştırılmış Geliştiricilerin iş akışı
  • Bağımlılık ve Yapı Yönetimi
  • Otomatik Uygulama Ölçeklendirme
  • Duyarlı Web Konsolu
  • Zengin Komut Satırı Araç Seti
  • Uygulamalara Uzaktan SSH Girişi
  • Rest API Desteği
  • Self-servis On Demand Uygulama Yığını
  • Yerleşik Veritabanı Hizmetleri
  • Sürekli Entegrasyon ve Sürüm Yönetimi
  • IDE Entegrasyonu
  • Uygulamalarda Uzaktan Hata Ayıklama

OpenShift, temelde yıl ve kartuşlar konseptine dayanan OpenShift V2 adlı tabanından ortaya çıktı; burada her bir bileşen, makine oluşturmadan uygulama dağıtımına, doğrudan uygulamanın kurulumuna kadar spesifikasyonlarına sahip.

Cartridges - Ortamın onları çalıştırmak için ihtiyaç duyduğu uygulama türünden ve bu bölümde karşılanan tüm bağımlılıklardan başlayarak yeni bir uygulama oluşturmanın odak noktasıydılar.

year- Kaynaklar, bellek ve CPU ile ilgili belirli özelliklere sahip ayı metal makinesi veya sunucu olarak tanımlanabilir. Bir uygulamayı çalıştırmak için temel bir birim olarak kabul edildi.

Application - Bunlar, OpenShift ortamında konuşlandırılacak ve çalıştırılacak uygulamaya veya herhangi bir entegrasyon uygulamasına atıfta bulunur.

Bu bölümde daha derine inerken, OpenShift'in farklı biçimleri ve teklifleri üzerinde tartışacağız. Önceki günlerde OpenShift'in üç ana sürümü vardı.

OpenShift Origin- Bu, OpenShift'in topluluk eki veya açık kaynak sürümüydü. Diğer iki versiyon için yukarı akış projesi olarak da biliniyordu.

OpenShift Online - AWS'de barındırılan bir hizmet olarak genel bir PaaS'dir.

OpenShift Enterprise - OpenShift'in ISV ve satıcı lisansları ile sağlamlaştırılmış sürümüdür.

OpenShift Çevrimiçi

OpenShift çevrimiçi, genel bulut üzerinde kapsayıcıya alınmış uygulamaları hızla oluşturabilen, dağıtabilen ve ölçeklendirebilen bir OpenShift topluluğu teklifidir. Red Hat'in genel bulut uygulama geliştirme ve barındırma platformudur ve geliştiricinin uygulama mantığı yazmaya odaklanmasına yardımcı olan, uygulamanın otomatik olarak sağlanması, yönetilmesi ve ölçeklendirilmesini sağlar.

Red Hat OpenShift Online'da Hesap Oluşturma

Step 1 - Tarayıcıya gidin ve siteyi ziyaret edin https://manage.openshift.com/

Step 2 - Red Hat hesabınız varsa, aşağıdaki URL'yi kullanarak Red Hat giriş kimliği ve şifresini kullanarak OpenShift hesabına giriş yapın. https://developers.redhat.com

Step 3 - Red Hat hesabı giriş bilgileriniz yoksa, aşağıdaki bağlantıyı kullanarak OpenShift çevrimiçi hizmetine kaydolun.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

Giriş yaptıktan sonra aşağıdaki sayfayı göreceksiniz.

Her şeyi yerine getirdikten sonra, Red Hat aşağıdaki ekran görüntüsünde gösterildiği gibi bazı temel hesap ayrıntılarını gösterecektir.

Son olarak, giriş yaptığınızda aşağıdaki sayfayı göreceksiniz.

OpenShift Konteyner Platformu

OpenShift konteyner platformu, geliştirme ve BT operasyonları ekibi gibi birden çok ekibin container mimarisine alınmış altyapı oluşturup dağıtmasına yardımcı olan kurumsal bir platformdur. OpenShift'te yerleşik olarak bulunan tüm kapsayıcılar, genel olarak barındırılan bulut platformlarının herhangi bir veri merkezinde dağıtılabilen çok güvenilir bir Docker kapsayıcı teknolojisi kullanır.

OpenShift konteyner platformu resmi olarak OpenShift Enterprises olarak biliniyordu. Bu, düzenleme ve yönetimin Kubernetes tarafından yönetildiği Docker tarafından desteklenen temel uygulama kapsayıcıları konseptine dayanan hizmet olarak Red Hat şirket içi özel bir platformdur.

Başka bir deyişle, OpenShift, Docker ve Kubernetes'i kurumsal düzeyde bir araya getirir. Kurumsal birimlerin başvuru sahiplerini kendi seçtikleri bir altyapıda dağıtmaları ve yönetmeleri için bir konteyner platformu yazılımıdır. Örneğin, AWS bulut sunucularında OpenShift örneklerini barındırmak.

OpenShift konteyner platformu şurada mevcuttur: two package levels.

OpenShift Container Local- Bu, uygulamaları yerel makinede dağıtmak ve test etmek isteyen geliştiriciler içindir. Bu paket esas olarak geliştirme ekipleri tarafından uygulamaları geliştirmek ve test etmek için kullanılır.

OpenShift Container Lab - Bu, geliştirmeden dağıtıma ve üretim öncesi ortama kadar genişletilmiş uygulama değerlendirmesi için tasarlanmıştır.

OpenShift Dedicated

Bu, OpenShift portföyüne eklenen başka bir tekliftir; burada, müşterinin kendi seçtikleri herhangi bir genel bulut üzerinde kapsayıcıya alınmış bir platform barındırma seçeneği vardır. Bu, son kullanıcıya, ihtiyaçlarını karşılayan herhangi bir bulut üzerinde OpenShift'i kullanabilecekleri gerçek bir çoklu bulut teklifi duygusu verir.

Bu, son kullanıcının test dağıtımı oluşturmak ve uygulamasını bulutta barındırılan OpenShift üzerinde çalıştırmak için OpenShift'i kullanabileceği en yeni Red Hat tekliflerinden biridir.

OpenShift Dedicated'in Özellikleri

OpenShift özel, genel bulut üzerinde özelleştirilmiş çözüm uygulama platformu sunar ve OpenShift 3 teknolojisinden miras alınır.

  • Extensible and Open - Bu, Docker'ın açık konsepti üzerine inşa edilmiştir ve gerektiğinde kendini harcayabildiği için bulut üzerinde konuşlandırılmıştır.

  • Portability - Docker kullanılarak oluşturulduğu için Docker üzerinde çalışan uygulamalar, Docker'ın desteklendiği bir yerden diğerine kolayca gönderilebilir.

  • Orchestration - OpenShift 3 ile, konteyner düzenleme ve küme yönetiminin temel özelliklerinden biri, OpenShift sürüm 3 ile birlikte sunulan Kubernetes kullanılarak desteklenir.

  • Automation - OpenShift'in bu sürümü, bir Hizmet sağlayıcı olarak Platform olarak pazarda çok popüler olmasını sağlayan kaynak kodu yönetimi, yapı otomasyonu ve dağıtım otomasyonu özelliğiyle etkinleştirilmiştir.

OpenShift'in rakipleri

Google App Engine- Bu, Google'ın web uygulamaları geliştirmek ve barındırmak için ücretsiz platformudur. Google'ın uygulama motoru, hızlı geliştirme ve dağıtım platformu sunar.

Microsoft Azure - Azure bulutu, Microsoft tarafından veri merkezlerinde barındırılır.

Amazon Elastic Cloud Compute - Amazon tarafından sağlanan ve bulut üzerinde ölçeklenebilir web uygulamalarının geliştirilmesine ve barındırılmasına yardımcı olan yerleşik hizmetlerdir.

Cloud Foundry - Java, Ruby, Python ve Node.js uygulamaları için açık kaynaklı bir PaaS platformudur.

CloudStack - Apache'nin CloudStack'i, Citrix tarafından geliştirilen bir projedir ve OpenShift ve OpenStack'in doğrudan rakibi olmak için tasarlanmıştır.

OpenStack - Bulut bilişim için Red Hat tarafından sağlanan başka bir bulut teknolojisi.

Kubernetes - Docker konteynerini yönetmek için oluşturulmuş doğrudan bir düzenleme ve küme yönetimi teknolojisidir.

OpenShift, her katmanın Kubernetes ve Docker kümesi kullanılarak diğer katmanla sıkı bir şekilde bağlandığı katmanlı bir sistemdir. OpenShift'in mimarisi, Kubernetes kullanılarak tüm katmanların üzerinde barındırılan Docker konteynerlerini destekleyebilecek ve yönetebilecek şekilde tasarlanmıştır. OpenShift V2'nin önceki sürümünden farklı olarak, OpenShift V3'ün yeni sürümü kapsayıcıya alınmış altyapıyı destekler. Bu modelde Docker, hafif Linux tabanlı kapsayıcıların oluşturulmasına yardımcı olur ve Kubernetes, birden çok ana bilgisayarda kapsayıcıları düzenleme ve yönetme görevini destekler.

OpenShift Bileşenleri

OpenShift mimarisinin temel bileşenlerinden biri, Kubernetes'te konteynerli altyapıyı yönetmektir. Kubernetes, altyapının Dağıtımı ve Yönetiminden sorumludur. Herhangi bir Kubernetes kümesinde, birden fazla ana ve birden fazla düğüme sahip olabiliriz, bu da kurulumda hiçbir hata noktası olmamasını sağlar.

Kubernetes Master Makine Bileşenleri

Etcd- Kümedeki düğümlerin her biri tarafından kullanılabilen yapılandırma bilgilerini depolar. Birden çok düğüm arasında dağıtılabilen yüksek kullanılabilirlikli bir anahtar değeri deposudur. Hassas bilgilere sahip olabileceği için yalnızca Kubernetes API sunucusu tarafından erişilebilir olmalıdır. Herkes tarafından erişilebilen, dağıtılmış bir anahtar değer Mağazasıdır.

API Server- Kubernetes, API'yi kullanarak küme üzerindeki tüm işlemleri sağlayan bir API sunucusudur. API sunucusu, farklı araçların ve kitaplıkların onunla kolayca iletişim kurabileceği anlamına gelen bir arabirim uygular. Kubeconfig, iletişim için kullanılabilen sunucu tarafı araçlarının yanı sıra bir pakettir. Kubernetes API'yi ortaya çıkarır ”.

Controller Manager- Bu bileşen, kümenin durumunu düzenleyen ve bir görevi yerine getiren koleksiyoncuların çoğundan sorumludur. Sonlandırılmayan bir döngüde çalışan ve API sunucusuna bilgi toplamak ve göndermekle sorumlu olan bir arka plan programı olarak düşünülebilir. Kümenin paylaşılan durumunu elde etmeye ve ardından sunucunun mevcut durumunu istenen duruma getirmek için değişiklikler yapmaya çalışır. Anahtar denetleyiciler, çoğaltma denetleyicisi, uç nokta denetleyicisi, ad alanı denetleyicisi ve hizmet hesabı denetleyicisidir. Denetleyici yöneticisi, düğümleri, uç noktaları vb. İşlemek için farklı türde denetleyiciler çalıştırır.

Scheduler- Kubernetes ana bileşeninin önemli bir bileşenidir. İş yükünü dağıtmaktan sorumlu olan bir ana hizmettir. Küme düğümlerinde çalışma yükünün kullanımını izlemekten ve ardından kaynakların mevcut olduğu iş yükünü yerleştirmekten ve iş yükünü kabul etmekten sorumludur. Başka bir deyişle, bu, kapsülleri mevcut düğümlere tahsis etmekten sorumlu mekanizmadır. Programlayıcı, iş yükü kullanımından ve yeni bir düğüme bir bölme tahsis etmekten sorumludur.

Kubernetes Düğüm Bileşenleri

Aşağıda, Kubernetes yöneticisi ile iletişim kurmak için gerekli olan Düğüm sunucusunun temel bileşenleri verilmiştir.

Docker - Her düğümün ilk gereksinimi, kapsüllenmiş uygulama konteynerlerinin nispeten izole edilmiş ancak hafif bir işletim ortamında çalıştırılmasına yardımcı olan Docker'dır.

Kubelet Service- Bu, her düğümdeki küçük bir hizmettir ve kontrol düzlemi hizmetine ve bu hizmetten bilgi aktarımından sorumludur. Yapılandırma ayrıntılarını ve Wright değerlerini okumak için etcd deposuyla etkileşime girer. Bu, komutları almak ve çalışmak için ana bileşenle iletişim kurar. Kubelet işlemi daha sonra çalışma durumunu ve düğüm sunucusunu koruma sorumluluğunu üstlenir. Ağ kurallarını, bağlantı noktası iletimini vb. Yönetir.

Kubernetes Proxy Service- Bu, her düğümde çalışan bir proxy hizmetidir ve hizmetlerin harici ana bilgisayarda kullanılabilir olmasına yardımcı olur. İsteğin doğru kapsayıcılara iletilmesine yardımcı olur. Kubernetes Proxy Hizmeti, ilkel yük dengeleme gerçekleştirebilir. Ağ ortamının öngörülebilir ve erişilebilir olmasını sağlar, ancak aynı zamanda izole edilir. Düğümdeki bölmeleri, birimleri, sırları yönetir, yeni kapsayıcı sağlık kontrolü oluşturur vb.

Entegre OpenShift Container Registry

OpenShift konteyner kaydı, Docker görüntülerini depolamak için kullanılan dahili bir Red Hat depolama birimidir. OpenShift'in en son entegre sürümüyle, OpenShift dahili depolamasındaki görüntüleri görüntülemek için bir kullanıcı arabirimi oluşturdu. Bu kayıtlar, daha sonra onlardan konteynerler oluşturmak için kullanılacak olan belirli etiketlerle görüntüleri tutabilir.

Sık Kullanılan Terimler

Image- Kubernetes (Docker) görüntüleri, Containerized Infrastructure'ın temel yapı taşlarıdır. Şu an itibariyle, Kubernetes yalnızca Docker görüntülerini desteklemektedir. Bir bölmedeki her konteynerin içinde çalışan Docker görüntüsü vardır. Bir bölmeyi yapılandırırken, yapılandırma dosyasındaki image özelliği Docker komutuyla aynı sözdizimine sahiptir.

Project - OpenShift V2'nin önceki sürümünde bulunan etki alanının yeniden adlandırılmış sürümü olarak tanımlanabilirler.

Container - Görüntü bir Kubernetes küme düğümünde konuşlandırıldıktan sonra oluşturulanlardır.

Node- Bir düğüm, usta için minion olarak da bilinen Kubernetes kümesinde çalışan bir makinedir. Fiziksel, sanal makine veya bulut örneği olabilen çalışma birimleridir.

Pod- Kapsül, bir kapsayıcılar koleksiyonudur ve bir Kubernetes kümesinin bir düğümü içindeki depolanmasıdır. İçerisinde birden fazla kap bulunan bir bölme oluşturmak mümkündür. Örneğin, veritabanı kapsayıcısını ve web sunucusu kabını bölmenin içinde tutmak.

Bu bölümde, OpenShift'in ortam kurulumu hakkında bilgi edineceğiz.

Sistem gereksinimleri

Kurumsal OpenShift'i kurmak için, kişinin aktif bir Red Hat hesabına sahip olması gerekir. OpenShift, Kubernetes ana ve düğüm mimarisi üzerinde çalıştığından, her ikisini de ayrı makinelerde kurmamız gerekir; burada bir makine ana makine görevi görür ve diğer makine düğümde çalışır. Her ikisini de kurmak için minimum sistem gereksinimleri vardır.

Ana Makine Yapılandırması

Aşağıda, ana makine yapılandırması için minimum sistem gereksinimleri verilmiştir.

  • Fiziksel, sanal veya herhangi bir bulut ortamında barındırılan bir temel makine.

  • Bu örnekte gerekli paketlere sahip en az Linux 7.

  • 2 CPU çekirdeği.

  • En az 8 GB RAM.

  • 30 GB dahili sabit disk belleği.

Düğüm Makinesi Yapılandırması

  • Ana makine için verilen fiziksel veya sanal temel görüntü.
  • Makinede en az Linux 7.
  • Docker, 1.6 sürümünden daha düşük olmayan bir sürümle yüklendi.
  • 1 CPU çekirdeği.
  • 8 GB RAM.
  • Görüntüleri barındırmak için 15 GB sabit disk ve görüntüleri depolamak için 15 GB sabit disk.

OpenShift Kurulumu için Adım Adım Kılavuz

Aşağıdaki açıklamada, daha sonra daha büyük bir kümeye genişletilebilecek OpenShift laboratuar ortamını kuracağız. OpenShift ana ve düğüm kurulumu gerektirdiğinden, bulut, fiziksel veya sanal makinelerde barındırılan en az iki makineye ihtiyacımız olacaktı.

Step 1- Önce Linux 7'nin en az sürüm olması gereken her iki makineye de kurun. Bu, aktif bir Red Hat aboneliğine sahipse aşağıdaki komutlar kullanılarak yapılabilir.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

Her iki makineye de yukarıdaki temel paketleri yükledikten sonra, sonraki adım ilgili makinelerde Docker'ı kurmak olacaktır.

Step 2- Docker'ı yalnızca yerel ağda güvenli olmayan iletişime izin verecek şekilde yapılandırın. Bunun için Docker dosyasını / etc / sysconfig içinde düzenleyin. Dosya mevcut değilse, manuel olarak oluşturmanız gerekir.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Docker'ı ana makinede yapılandırdıktan sonra, her iki makine arasında şifresiz bir iletişim kurmamız gerekiyor. Bunun için genel ve özel anahtar kimlik doğrulamasını kullanacağız.

Step 3 - Ana makinede anahtarlar oluşturun ve ardından id_rsa.pub anahtarını düğüm makinesinin yetkili anahtar dosyasına kopyalayın; bu, aşağıdaki komut kullanılarak yapılabilir.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Yukarıdaki tüm kurulumları yerine getirdikten sonra, bir sonraki adım, ana makinede OpenShift sürüm 3'ü kurmaktır.

Step 4 - Ana makineden aşağıdaki curl komutunu çalıştırın.

# sh <(curl -s https://install.openshift.com/ose)

Yukarıdaki komut, kurulumu OSV3 için yerine koyacaktır. Sonraki adım, makinede OpenShift V3'ü yapılandırmak olacaktır.

Doğrudan İnternetten indiremiyorsanız, şu adresten indirilebilir: https://install.openshift.com/portable/oo-install-ose.tgz yükleyicinin yerel ana makinede çalışabileceği bir katran paketi olarak.

Kurulumu hazırladıktan sonra, makinelerde OSV3'ün gerçek yapılandırmasıyla başlamamız gerekir. Bu kurulum ortamı gerçek üretim için test etmek için çok özeldir, bizde LDAP ve diğer şeyler var.

Step 5 - Ana makinede, /etc/openshift/master/master-config.yaml altında bulunan aşağıdaki kodu yapılandırın

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Ardından, varsayılan yönetim için standart bir kullanıcı oluşturun.

# htpasswd -c /root/users.htpasswd admin

Step 6- OpenShift, görüntüleri yapılandırmak için Docker kaydını kullandığından, Docker kayıt defterini yapılandırmamız gerekir. Bu, derlemeden sonra Docker görüntülerini oluşturmak ve depolamak için kullanılır.

Aşağıdaki komutu kullanarak OpenShift düğüm makinesinde bir dizin oluşturun.

# mkdir /images

Ardından, kayıt defteri kurulurken oluşturulan varsayılan yönetici kimlik bilgilerini kullanarak ana makinede oturum açın.

# oc login
Username: system:admin

Varsayılan oluşturulmuş projeye geçin.

# oc project default

Step 7 - Bir Docker Kayıt Defteri oluşturun.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Kullanıcı ayrıcalıklarını düzenleyin.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Görüntü kaydını oluşturun ve düzenleyin.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - Varsayılan bir yönlendirme oluşturun.

Varsayılan olarak OpenShift, yazılım ağı olarak OpenVswitch'i kullanır. Varsayılan bir yönlendirme oluşturmak için aşağıdaki komutu kullanın. Bu, yük dengeleme ve proxy yönlendirmesi için kullanılır. Yönlendirici, Docker kayıt defterine benzer ve ayrıca bir kayıt defterinde çalışır.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Ardından, kullanıcının ayrıcalıklarını düzenleyin.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - DNS'yi yapılandırın.

URL talebini işlemek için OpenShift'in çalışan bir DNS ortamına ihtiyacı vardır. Bu DNS yapılandırması, bir yönlendiriciye işaret eden DNS joker kartı oluşturmak için gerekli olan bir joker karakter oluşturmak için gereklidir.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- Son adım, isteğe bağlı olan OpenShift V3 ana makinesinde github sunucusunu kurmak olacaktır. Bu, aşağıdaki komut dizisi kullanılarak kolayca yapılabilir.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

Yukarıdaki kurulum tamamlandıktan sonra, sonraki bölümlerde hakkında daha fazla bilgi alacağımız uygulamaları test ederek ve dağıtarak doğrulayabilirsiniz.

Uygulamaların fiili kurulumuna ve dağıtımına başlamadan önce, OpenShift V3'te kullanılan bazı temel terimleri ve kavramları anlamamız gerekiyor.

Kaplar ve Görseller

Görüntüler

Bunlar, Docker görüntülerinden oluşan OpenShift'in temel yapı taşlarıdır. OpenShift'teki her bölmede, kümenin içinde çalışan kendi görüntüleri vardır. Bir bölmeyi yapılandırdığımızda, kayıt defterinden havuza alınacak bir alanımız olur. Bu yapılandırma dosyası görüntüyü çekecek ve küme düğümünde konuşlandıracaktır.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Bundan bir görüntü çekmek ve oluşturmak için aşağıdaki komutu çalıştırın. OC, oturum açtıktan sonra OpenShift ortamı ile iletişim kuran istemcidir.

$ oc create –f Tesing_for_Image_pull

Konteyner

Bu, Docker görüntüsü OpenShift kümesinde konuşlandırıldığında oluşturulur. Herhangi bir konfigürasyonu tanımlarken konfigürasyon dosyasında konteyner bölümünü tanımlıyoruz. Bir konteynerin içinde çalışan birden çok görüntü olabilir ve küme düğümünde çalışan tüm kapsayıcılar OpenShift Kubernetes tarafından yönetilir.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

Aşağıda, içinde çalışan birden çok görüntüye sahip bir kabın tanımlanması için belirtimler yer almaktadır.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

Yukarıdaki konfigürasyonda, içinde Tomcat ve MongoDB'nin iki görüntüsünün bulunduğu çoklu kapsayıcılı bir pod tanımladık.

Kapsüller ve Hizmetler

Kapsüller

Kapsül, bir konteyner koleksiyonu ve OpenShift (Kubernetes) kümesinin bir düğümü içindeki depolaması olarak tanımlanabilir. Genel olarak, tek bir kapsayıcıdan başlayıp çoklu kapsayıcıya kadar iki çeşit bölmeye sahibiz.

Single Container Pod - Bunlar, OC komutuyla veya temel bir yapılandırma yml dosyasıyla kolayca oluşturulabilir.

$ oc run <name of pod> --image = <name of the image from registry>

Aşağıdaki gibi basit bir yaml dosyasıyla oluşturun.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

Yukarıdaki dosya oluşturulduktan sonra, aşağıdaki komutla bir bölme oluşturacaktır.

$ oc create –f apache.yml

Multi-Container Pod- Çoklu konteyner kapsülleri, içinde çalışan birden fazla konteynerimiz olanlardır. Aşağıdaki gibi yaml dosyaları kullanılarak oluşturulurlar.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

Bu dosyaları oluşturduktan sonra, bir konteyner oluşturmak için yukarıdaki ile aynı yöntemi kullanabiliriz.

Service- Bir kapsülün içinde çalışan bir dizi kapsayıcımız olduğu için, aynı şekilde mantıksal bir kapsül kümesi olarak tanımlanabilecek bir hizmetimiz var. Bölmenin üzerinde, bölmelere erişilebilen tek bir IP ve DNS adı sağlayan soyut bir katmandır. Hizmet, yük dengeleme yapılandırmasını yönetmeye ve bölmeyi çok kolay bir şekilde ölçeklendirmeye yardımcı olur. OpenShift'te bir hizmet, yeni bir örnek oluşturmak için OpenShift master'da apiService'e tanımlanabilen bir REST nesnesidir.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Derlemeler ve Akışlar

Yapılar

OpenShift'te derleme, görüntüleri kaplara dönüştürme işlemidir. Kaynak kodunu bir görüntüye dönüştüren işlemdir. Bu derleme süreci, kaynak koddan görüntüye önceden tanımlanmış strateji üzerinde çalışır.

Derleme birden çok stratejiyi ve kaynağı işler.

Stratejiler Oluşturun

  • Source to Image- Bu temelde, yeniden üretilebilir görüntüler oluşturmaya yardımcı olan bir araçtır. Bu görüntüler her zaman Docker run komutunu kullanarak çalışmaya hazır bir aşamadadır.

  • Docker Build - Bu, basit Docker build komutu çalıştırılarak görüntülerin Docker dosyası kullanılarak oluşturulduğu süreçtir.

  • Custom Build - Bunlar, temel Docker görüntüleri oluşturmak için kullanılan yapılardır.

Kaynak Oluşturun

Git- Bu kaynak, git deposu görüntü oluşturmak için kullanıldığında kullanılır. Dockerfile isteğe bağlıdır. Kaynak koddaki konfigürasyonlar aşağıdaki gibi görünür.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - Dockerfile, yapılandırma dosyasında bir girdi olarak kullanılır.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

Image Streams- Görüntüler çekildikten sonra görüntü akışları oluşturulur. Bir görüntü akışının avantajı, bir görüntünün yeni sürümüyle ilgili güncellemeleri aramasıdır. Bu, etiketler tarafından tanımlanan herhangi bir sayıda Docker biçimli kapsayıcı görüntüsünü karşılaştırmak için kullanılır.

Görüntü akışları, yeni bir görüntü oluşturulduğunda otomatik olarak bir eylem gerçekleştirebilir. Tüm yapılar ve konuşlandırmalar, görüntü eylemini izleyebilir ve buna göre bir eylem gerçekleştirebilir. Aşağıda bir akış oluşturmayı nasıl tanımladığımız açıklanmaktadır.

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Rotalar ve Şablonlar

Rotalar

OpenShift'te yönlendirme, dışarıdan erişilebilir ana bilgisayar adı oluşturup yapılandırarak hizmeti dış dünyaya gösterme yöntemidir. Rotalar ve uç noktalar, hizmeti, kullanıcının tanımlı uygulamaya erişmek için ad bağlantısını (DNS) kullanabileceği dış dünyaya göstermek için kullanılır.

OpenShift'te yollar, OpenShift yöneticisi tarafından kümede dağıtılan yönlendiriciler kullanılarak oluşturulur. Yönlendiriciler, HTTP (80) ve https (443) bağlantı noktalarını harici uygulamalara bağlamak için kullanılır.

Rotalar tarafından desteklenen farklı protokol türleri aşağıdadır -

  • HTTP
  • HTTPS
  • TSL ve web soketi

Hizmeti yapılandırırken, hizmeti yapılandırmak ve bu hizmeti kullanarak uç noktayı bulmak için seçiciler kullanılır. Aşağıda, bir hizmeti nasıl oluşturduğumuza ve uygun bir protokol kullanarak bu hizmet için yönlendirmeye bir örnek verilmiştir.

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

Ardından, aşağıdaki komutu çalıştırın ve hizmet oluşturulur.

$ oc create -f ~/training/content/Openshift-Rservice.json

Hizmet, oluşturulduktan sonra böyle görünüyor.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Aşağıdaki kodu kullanarak servis için bir yönlendirme oluşturun.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Bir rota oluşturmak için OC komutu kullanıldığında, yeni bir rota kaynağı örneği oluşturulur.

Şablonlar

Şablonlar, OpenShift'te birden çok kez kullanılabilen standart bir nesne olarak tanımlanır. Birden çok nesne oluşturmak için kullanılan yer tutucular listesiyle parametreleştirilmiştir. Bu, bir bölmeden başlayarak, kullanıcıların oluşturma yetkisine sahip olduğu ağ oluşturmaya kadar her şeyi oluşturmak için kullanılabilir. Görüntüdeki CLI veya GUI arayüzünden şablon proje dizinine yüklenirse, nesnelerin bir listesi oluşturulabilir.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Kimlik doğrulama ve yetkilendirme

Doğrulama

OpenShift'te, ana ve istemci yapısını yapılandırırken, ana birim OAuth sunucusunun yerleşik bir özelliği ile gelir. OAuth sunucusu, API kimlik doğrulaması için kullanılan jeton oluşturmak için kullanılır. OAuth, ana makine için varsayılan bir kurulum olarak geldiğinden, varsayılan olarak kullanılan Tümüne İzin Ver kimlik sağlayıcısına sahibiz. Yapılandırılabilen farklı kimlik sağlayıcıları mevcuttur/etc/openshift/master/master-config.yaml.

OAuth'ta bulunan farklı türde kimlik sağlayıcıları vardır.

  • Hepsine izin ver
  • Hepsini inkar etmek
  • HTPasswd
  • LDAP
  • Temel Kimlik Doğrulama

Hepsine izin ver

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Hepsini inkar etmek

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd'yi kullanmak için, önce ana makinede Httpd-araçlarını kurmamız ve ardından bunu diğerleri için yaptığımız gibi yapılandırmamız gerekir.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

yetki

Yetkilendirme, bir kullanıcıyı doğrulamak için kullanılan bir OpenShift ana özelliğidir. Bu, kullanıcının belirli bir projede bu eylemi gerçekleştirmeye yetkili olup olmadığını görmek için bir eylemi gerçekleştirmeye çalışan kullanıcıyı kontrol ettiği anlamına gelir. Bu, yöneticinin projelere erişimi kontrol etmesine yardımcı olur.

Yetkilendirme politikaları şu şekilde kontrol edilir -

  • Rules
  • Roles
  • Bindings

Yetkilendirmenin değerlendirilmesi şu şekilde yapılır -

  • Identity
  • Action
  • Bindings

Politikaları Kullanma -

  • Küme politikası
  • Yerel politika

OpenShift, GUI veya CLI ile uygulama oluşturmak ve dağıtmak için iki tür medyadan oluşur. Bu bölümde, yeni bir uygulama oluşturmak için CLI kullanacağız. OpenShift ortamı ile iletişim kurmak için OC istemcisini kullanıyor olacaktık.

Yeni Bir Uygulama Oluşturmak

OpenShift'te, yeni bir uygulama oluşturmanın üç yöntemi vardır.

  • Bir kaynak koddan
  • Bir görüntüden
  • Bir şablondan

Kaynak Koddan

Kaynak koddan bir uygulama oluşturmaya çalıştığımızda, OpenShift, uygulama derleme akışını tanımlayan depo içinde bulunması gereken bir Docker dosyası arar. Bir uygulama oluşturmak için oc new-app kullanacağız.

Depo kullanırken akılda tutulması gereken ilk şey, depodaki OpenShift'in kodu çekip oluşturacağı bir kökene işaret etmesidir.

Depo, OC istemcisinin kurulu olduğu Docker makinesinde klonlanmışsa ve kullanıcı aynı dizindeyse, aşağıdaki komut kullanılarak oluşturulabilir.

$ oc new-app . <Hear. Denotes current working directory>

Aşağıda, belirli bir şube için uzak depodan derlemeye çalışma örneği verilmiştir.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Burada test1, OpenShift'te yeni bir uygulama oluşturmaya çalıştığımız daldır.

Depoda bir Docker dosyası belirtirken, aşağıda gösterildiği gibi build stratejisini tanımlamamız gerekir.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

Bir Görüntüden

Görüntüleri kullanarak bir uygulama oluştururken, görüntüler yerel Docker sunucusunda, şirket içinde barındırılan Docker deposunda veya Docker hub'ında bulunur. Bir kullanıcının emin olması gereken tek şey, herhangi bir sorun olmadan görüntüleri hub'dan çekebilme erişimine sahip olmasıdır.

OpenShift, ister Docker görüntüsü ister kaynak akışı olsun, kullanılan kaynağı belirleme yeteneğine sahiptir. Bununla birlikte, kullanıcı isterse, bunun bir görüntü akışı mı yoksa bir Docker görüntüsü mü olduğunu açıkça tanımlayabilir.

$ oc new-app - - docker-image tomcat

Bir görüntü akışı kullanmak -

$ oc new-app tomcat:v1

Bir Şablondan

Şablonlar, yeni bir uygulama oluşturmak için kullanılabilir. Zaten mevcut bir şablon olabilir veya yeni bir şablon oluşturabilir.

Aşağıdaki yaml dosyası, temelde dağıtım için kullanılabilecek bir şablondur.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Bir Web Uygulaması Geliştirin ve Dağıtın

OpenShift'te Yeni Bir Uygulama Geliştirme

OpenShift'te yeni bir uygulama oluşturmak için, yeni bir uygulama kodu yazmalı ve OpenShift OC build komutlarını kullanarak onu oluşturmalıyız. Daha önce de tartışıldığı gibi, yeni bir imaj yaratmanın birçok yolu var. Burada, uygulamayı oluşturmak için bir şablon kullanacağız. Bu şablon, oc new-app komutuyla çalıştırıldığında yeni bir uygulama oluşturacaktır.

Aşağıdaki şablon oluşturacaktır - İki ön uç uygulaması ve bir veritabanı. Bununla birlikte, iki yeni hizmet oluşturacak ve bu uygulamalar OpenShift kümesine konuşlandırılacaktır. Bir uygulama oluştururken ve dağıtırken, başlangıçta OpenShift'te bir ad alanı oluşturmamız ve uygulamayı bu ad alanı altında konuşlandırmamız gerekir.

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Şablon

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Nesne Tanımları

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

Yukarıdaki şablon dosyasının bir defada derlenmesi gerekir. Önce tüm içeriği tek bir dosyaya kopyalayıp, bittiğinde bunu bir yaml dosyası olarak adlandırmamız gerekiyor.

Uygulamayı oluşturmak için aşağıdaki komutu çalıştırmamız gerekiyor.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Yapıyı izlemek istersek, bunu kullanarak yapılabilir -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

OpenShift'te konuşlandırılmış uygulamaları kontrol edebiliriz -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Uygulama hizmetlerinin hizmet tanımına göre oluşturulup oluşturulmadığını kontrol edebiliriz.

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

OpenShift'te, derleme ardışık düzenini otomatikleştirmek için birden fazla yöntemimiz var. Bunu yapmak için, derleme akışını açıklamak üzere bir BuildConfig kaynağı oluşturmamız gerekir. BuildConfig'teki akış, Jenkins iş tanımındaki iş tanımıyla karşılaştırılabilir. Derleme akışını oluştururken, derleme stratejisini seçmeliyiz.

BuildConfig Dosyası

OpenShift'te BuildConfig, API'ye bağlanmak ve ardından yeni bir örnek oluşturmak için kullanılan bir dinlenme nesnesidir.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

OpenShift'te dört tür derleme stratejisi vardır.

  • Kaynaktan görüntüye stratejisi
  • Docker stratejisi
  • Özel strateji
  • Boru hattı stratejisi

Kaynaktan Resme Stratejisi

Kaynak koddan başlayarak kapsayıcı görüntüleri oluşturmaya izin verir. Bu akışta, asıl kod önce kapta indirilir ve sonra onun içinde derlenir. Derlenen kod aynı konteyner içinde dağıtılır ve görüntü bu koddan oluşturulur.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Birden fazla strateji politikası var.

  • Forcepull
  • Artımlı Derlemeler
  • Dış Yapılar

Docker Stratejisi

Bu akışta OpenShift, görüntüyü oluşturmak için Dockerfile kullanır ve ardından oluşturulan görüntüleri Docker kayıt defterine yükler.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Docker dosyası seçeneği, dosya yolundan başlayarak, önbellek olmadan ve zorla çekmeden başlayarak birden çok konumda kullanılabilir.

  • Resimden
  • Dockerfile yolu
  • Önbellek yok
  • Çekmeye zorla

Özel Strateji

Bu, farklı inşa stratejisi türlerinden biridir, burada yapının çıktısının bir görüntü olacağı gibi bir zorlama yoktur. Jenkins'in serbest stil işi ile karşılaştırılabilir. Bununla Jar, rpm ve diğer paketleri oluşturabiliriz.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Birden fazla inşa stratejisinden oluşur.

  • Docker soketini açığa çıkarın
  • Secrets
  • Çekmeye zorla

Boru Hattı Stratejisi

Ardışık düzen stratejisi, özel derleme ardışık düzenleri oluşturmak için kullanılır. Bu, temelde iş akışını boru hattında uygulamak için kullanılır. Bu derleme akışı, Groovy DSL dilini kullanarak özel derleme işlem hattı akışını kullanır. OpenShift, Jenkins'te bir ardışık düzen işi oluşturacak ve yürütecektir. Bu işlem hattı akışı, Jenkins'te de kullanılabilir. Bu stratejide Jenkinsfile kullanıyoruz ve bunu buildconfig tanımına ekliyoruz.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift CLI, OpenShift uygulamalarını komut satırından yönetmek için kullanılır. OpenShift CLI, uçtan uca uygulama yaşam döngüsünü yönetme yeteneğine sahiptir. Genel olarak, OpenShift ile iletişim kurmak için bir OpenShift istemcisi olan OC'yi kullanırdık.

OpenShift CLI Kurulumu

OC istemcisini farklı bir işletim sistemi üzerinde kurmak için, farklı adımlar dizisinden geçmemiz gerekir.

Windows için OC Client

Step 1 - Aşağıdaki bağlantıdan oc klibi indirin https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Makinede bir hedef yolda paketi açın.

Step 3 - Sistemin yol ortam değişkenini düzenleyin.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - Windows'ta OC kurulumunu doğrulayın.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Mac OS X için OC Client

Windows ile aynı konum için Mac OS kurulum ikili dosyalarını indirebilir ve daha sonra bunu bir konumda açıp PATH ortam değişkeni altında bir yürütülebilir dosya yolu belirleyebiliriz.

Alternatively

Home brew'ı kullanabilir ve aşağıdaki komutu kullanarak kurabiliriz.

$ brew install openshift-cli

Linux için OC İstemcisi

Aynı sayfanın altında kurulum için kullanılabilecek Linux kurulumu için tar dosyası var. Daha sonra, söz konusu çalıştırılabilir konuma işaret eden bir yol değişkeni ayarlanabilir.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Aşağıdaki komutu kullanarak tar dosyasını paketinden çıkarın.

$ tar –xf < path to the OC setup tar file >

Kimlik doğrulamayı kontrol etmek için aşağıdaki komutu çalıştırın.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

CLI Yapılandırma Dosyaları

OC CLI yapılandırma dosyası, birden çok OpenShift sunucu bağlantısını ve kimlik doğrulama mekanizmasını yönetmek için kullanılır. Bu yapılandırma dosyası aynı zamanda birden çok profili depolamak ve yönetmek ve bunlar arasında geçiş yapmak için de kullanılır. Normal bir yapılandırma dosyası aşağıdaki gibi görünür.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

CLI İstemcisini Ayarlama

Kullanıcı kimlik bilgilerini ayarlamak için

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Küme ayarlamak için

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Misal

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Bağlamı ayarlamak için

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

CLI Profilleri

Tek bir CLI yapılandırma dosyasında, her bir profilin farklı bir OpenShift sunucu yapılandırmasına sahip olduğu ve daha sonra farklı CLI profilleri arasında geçiş yapmak için kullanılabilecek birden fazla profilimiz olabilir.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Yukarıdaki yapılandırmada, OpenShift ana makinelerinin iki örneğini tanımlayan kümeden başlayarak dört ana bölüme ayrıldığını görebiliriz. İkinci bağlam bölümü, vipin ve alim adlı iki bağlamı tanımlar. Geçerli bağlam, şu anda hangi bağlamın kullanımda olduğunu tanımlar. Buradaki tanımı değiştirirsek, başka bir bağlam veya profile değiştirilebilir. Son olarak, bizim durumumuzda vipin olan kullanıcı tanımı ve kimlik doğrulama belirteci tanımlanır.

Kullanımdaki mevcut profili kontrol etmek istersek, bunu kullanarak yapılabilir -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Diğer CLI'ye geçmek istersek, aşağıdaki komut kullanılarak komut satırından yapılabilir.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Yukarıdaki komutu kullanarak profiller arasında geçiş yapabiliriz. Herhangi bir zamanda, yapılandırmayı görmek istersek, $ oc yapılandırma görünümü komutunu kullanabiliriz.

OpenShift CLI, uygulamaların tüm temel ve gelişmiş yapılandırmasını, yönetimini, eklemesini ve dağıtımını gerçekleştirebilir.

OC komutlarını kullanarak farklı işlemler gerçekleştirebiliriz. Bu istemci, uygulamalarınızı herhangi bir OpenShift veya Kubernetes uyumlu platformda geliştirmenize, oluşturmanıza, dağıtmanıza ve çalıştırmanıza yardımcı olur. Ayrıca, 'adm' alt komutu altında bir kümeyi yönetmek için yönetim komutlarını içerir.

Temel Komutlar

Aşağıdaki tablo temel OC komutlarını listeler.

Sr.No. Komutlar ve Açıklama
1

Types

Kavramlara ve türlere giriş
2

Login

Bir sunucuya giriş yapın
3

new-project

Yeni bir proje talep edin
4

new-app

Yeni Bir Uygulama Oluşturun
5

Status

Mevcut projeye genel bir bakış göster
6

Project

Başka bir projeye geç
7

Projects

Mevcut projeleri görüntüleyin
8

Explain

Kaynakların dokümantasyonu
9

Cluster

OpenShift kümesini başlatın ve durdurun

Oturum aç

Sunucunuzda oturum açın ve sonraki kullanım için girişi kaydedin. İstemciyi ilk kez kullananların, bir sunucuya bağlanmak, kimliği doğrulanmış bir oturum oluşturmak ve yapılandırma dosyasına bir bağlantı kaydetmek için bu komutu çalıştırması gerekir. Varsayılan konfigürasyon ".kube / config" altında ana dizininize kaydedilecektir.

Kullanıcı adı ve şifre, bir oturum belirteci veya sunucu ayrıntıları gibi oturum açmak için gerekli bilgiler bayraklar aracılığıyla sağlanabilir. Sağlanmazsa, komut gerektiğinde kullanıcı girişi isteyecektir.

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Seçenekler -

-p, --password = " - Şifre, sağlanmadıysa sorulacaktır

-u, --username = " - Kullanıcı adı, sağlanmadıysa sorulacak

--certificate-authority = "- Sertifika yolu. sertifika yetkilisi için dosya

--insecure-skip-tls-verify = false- Doğruysa, sunucunun sertifikasının geçerliliği kontrol edilmeyecektir. Bu, HTTPS bağlantılarınızı güvensiz hale getirecektir

--token = " - API sunucusuna kimlik doğrulama için taşıyıcı jeton

Herhangi bir komutla ilgili tüm ayrıntıları elde etmek için, oc <Command Name> --help komut.

Komutları Oluşturun ve Dağıtın

Aşağıdaki tablo, oluşturma ve dağıtma komutlarını listeler.

Sr.No. Komutlar ve Açıklama
1

Rollout

Bir Kubernetes dağıtımını veya OpenShift dağıtımını yönetin
2

Deploy

Bir dağıtımı görüntüleyin, başlatın, iptal edin veya yeniden deneyin
3

Rollback

Bir uygulamanın bir bölümünü önceki durumuna geri döndür
4

new-build

Yeni bir yapı yapılandırması oluşturun
5

start-build

Yeni bir yapıya başlayın
6

cancel-build

Çalışmayı, beklemeyi veya yeni yapıları iptal edin
7

import-image

Docker kayıt defterinden görüntüleri içe aktarır
8

Tag

Mevcut görüntüleri görüntü akışlarında etiketleyin

Uygulama Yönetimi Komutları

Aşağıdaki tablo, uygulama yönetimi komutlarını listeler.

Sr.No. Komutlar ve Açıklama
1

Get

Bir veya daha fazla kaynağı görüntüleyin
2

Describe

Belirli bir kaynağın veya bir kaynak grubunun ayrıntılarını gösterin
3

Edit

Sunucudaki bir kaynağı düzenleyin
4

Set

Nesnelerde belirli özellikleri ayarlamaya yardımcı olan komutlar
5

Label

Bir kaynaktaki etiketleri güncelleme
6

Annotate

Bir kaynaktaki ek açıklamaları güncelleme
7

Expose

Çoğaltılmış bir uygulamayı bir hizmet veya rota olarak gösterin
8

Delete

Bir veya daha fazla kaynağı silin
9

Scale

Bir dağıtımdaki kapsül sayısını değiştirme
10

Autoscale

Bir dağıtım yapılandırmasını, dağıtımını, çoğaltmasını, Denetleyicisini veya çoğaltma kümesini otomatik ölçeklendirin
11

Secrets

Sırları yönet
12

Serviceaccounts

Projenizdeki hizmet hesaplarını yönetin

Sorun Giderme ve Hata Ayıklama Komutları

Aşağıdaki tablo, sorun giderme ve hata ayıklama komutlarını listeler.

Sr.No. Komutlar ve Açıklama
1

logs

Bir kaynağın günlüklerini yazdırın
2

Rsh

Bir bölmede bir kabuk oturumu başlatın
3

Rsync

Dosyaları yerel dosya sistemi ve bir bölme arasında kopyalayın
4

port-forward

Bir veya daha fazla yerel bağlantı noktasını bir bölmeye iletin
5

Debug

Hata ayıklama için yeni bir kapsül örneği başlatın
6

Exec

Bir kapta bir komut yürütme
7

Procy

Kubernetes API sunucusuna bir proxy çalıştırın
9

Attach

Çalışan bir konteynere ekleyin
10

Run

Küme üzerinde belirli bir görüntüyü çalıştırın
11

Cp

Kapsayıcılara / kapsayıcılardan dosya ve dizin kopyalama

Gelişmiş Komutlar

Aşağıdaki tablo gelişmiş komutları listeler.

Sr.No. Komutlar ve Açıklama
1

adm

Bir kümeyi yönetmek için araçlar
2

create

Dosya adı veya stdin ile bir kaynak oluşturun
3

replace

Bir kaynağı dosya adı veya stdin ile değiştirin
4

apply

Bir kaynağa dosya adı veya stdin ile bir yapılandırma uygulayın
5

patch

Stratejik birleştirme yaması kullanarak bir kaynağın alanlarını güncelleyin
6

process

Kaynak listesine bir şablon işleyin
7

export

Kaynakları başka yerde kullanabilmeleri için dışa aktarın
8

extract

Sırları veya yapılandırma haritalarını diske çıkarın
9

idle

Boşta kalan ölçeklenebilir kaynaklar
10

observe

Kaynaklardaki değişiklikleri gözlemleyin ve bunlara tepki verin (deneysel)
11

policy

Yetkilendirme politikasını yönetin
12

auth

Yetkilendirmeyi inceleyin
13

convert

Yapılandırma dosyalarını farklı API sürümleri arasında dönüştürün
14

import

Uygulamaları içe aktaran komutlar

Komutları Ayarlama

Aşağıdaki tablo ayar komutlarını listeler.

Sr.No. Komutlar ve Açıklama
1

Logout

Mevcut sunucu oturumunu sonlandırın
2

Config

İstemci için yapılandırma dosyalarını değiştirin
3

Whoami

Mevcut oturum hakkındaki bilgileri döndür
4

Completion

Belirtilen kabuk (bash veya zsh) için çıktı kabuğu tamamlama kodu

OpenShift, OpenShift kümesini kurmak için iki yükleme yöntemi kullanır.

  • Hızlı kurulum yöntemi
  • Gelişmiş yapılandırma yöntemi

Küme Ayarlama

Hızlı Kurulum Yöntemi

Bu yöntem, hızlı, elde edilmeyen bir küme kurulum yapılandırmasını çalıştırmak için kullanılır. Bu yöntemi kullanmak için önce yükleyiciyi kurmamız gerekiyor. Bu, aşağıdaki komutu çalıştırarak yapılabilir.

Interactive method

$ atomic-openshift-installer install

Bu, etkileşimli bir kurulum çalıştırmak istendiğinde kullanışlıdır.

Unattended installation method

Bu yöntem, katılımsız bir kurulum yöntemi kurmak istendiğinde kullanılır, burada kullanıcı bir yapılandırma yaml dosyası tanımlayabilir ve bunu altına yerleştirebilir. ~/.config/openshift/installer.cfg.yml adıyla. Ardından, aşağıdaki komut çalıştırılabilir.–u tag.

$ atomic-openshift-installer –u install

Varsayılan olarak, altında bulunan yapılandırma dosyasını kullanır ~/.config/openshift/. Ansible ise kurulumun yedeği olarak kullanılır.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Burada, belirli bir değişken oluşturmak istendiğinde tanımlanabilen role özgü değişkenimiz var.

Tamamlandığında, aşağıdaki komutu kullanarak kurulumu doğrulayabiliriz.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Gelişmiş Kurulum

Gelişmiş kurulum tamamen Ansible konfigürasyonuna dayanmaktadır, burada ana ve düğüm konfigürasyonuna ilişkin eksiksiz ana bilgisayar yapılandırması ve değişken tanımları mevcuttur. Bu, yapılandırmayla ilgili tüm ayrıntıları içerir.

Kurulumu yaptıktan ve başucu kitabı hazır olduktan sonra, kümeyi kurmak için aşağıdaki komutu çalıştırabiliriz.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Bir Kümeye Ana Bilgisayar Ekleme

Kullanarak kümeye bir ana bilgisayar ekleyebiliriz -

  • Hızlı kurulum aracı
  • Gelişmiş yapılandırma yöntemi

Quick installation toolhem etkileşimli hem de etkileşimli olmayan modda çalışır. Aşağıdaki komutu kullanın.

$ atomic-openshift-installer -u -c </path/to/file> scaleup

Uygulama yapılandırma dosyası görünümlerini ölçeklendirme biçimi, hem ana hem de düğüm eklemek için kullanılabilir.

Gelişmiş Yapılandırma Yöntemi

Bu yöntemde, Ansible'ın ana bilgisayar dosyasını güncelliyoruz ve ardından bu dosyaya yeni bir düğüm veya sunucu ayrıntıları ekliyoruz. Yapılandırma dosyası aşağıdaki gibi görünür.

[OSEv3:children]
masters
nodes
new_nodes
new_master

Aynı Ansible hosts dosyasına, aşağıda gösterildiği gibi yeni düğümle ilgili değişken ayrıntıları ekleyin.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Son olarak, güncellenmiş ana bilgisayar dosyasını kullanarak, yeni yapılandırmayı çalıştırın ve aşağıdaki komutu kullanarak kurulumu yapmak için yapılandırma dosyasını çağırın.

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Küme Günlüklerini Yönetme

OpenShift küme günlüğü, kümenin ana ve düğüm makinelerinden üretilen günlüklerden başka bir şey değildir. Bunlar, sunucu günlüğü, ana günlüğü, kapsayıcı günlüğü, bölme günlüğü vb. İle başlayarak her tür günlüğü yönetebilir. Kapsayıcı günlüğü yönetimi için birden çok teknoloji ve uygulama mevcuttur.

Araçların birkaçı listelendiği gibidir ve log yönetimi için uygulanabilir.

  • Fluentd
  • ELK
  • Kabna
  • Nagios
  • Splunk

ELK stack- Bu yığın, tüm düğümlerden günlükleri toplamaya ve bunları sistematik bir biçimde sunmaya çalışırken kullanışlıdır. ELK yığını esas olarak üç ana kategoriye ayrılmıştır.

ElasticSearch - Esas olarak tüm konteynerlerden bilgi toplamak ve merkezi bir yere koymaktan sorumludur.

Fluentd - Toplanan tomrukları elasticsearch konteyner motoruna beslemek için kullanılır.

Kibana - Toplanan verileri grafik arayüzde yararlı bilgiler olarak sunmak için kullanılan bir grafik arayüz.

Unutulmaması gereken önemli bir nokta, bu sistemin kümeye yerleştirildiğinde tüm düğümlerden günlükleri toplamaya başlamasıdır.

Günlük Tanılama

OpenShift'in dahili bir oc adm dignosticsBirden fazla hata durumunu analiz etmek için kullanılabilen OC ile komut. Bu araç, ana bilgisayardan küme yöneticisi olarak kullanılabilir. Bu yardımcı program, bilinen sorunları gidermek ve gidermek için çok yararlıdır. Bu, ana istemcide ve düğümlerde çalışır.

Herhangi bir agrument veya bayrak olmadan çalıştırılırsa, istemci, sunucu ve düğüm makinelerinin konfigürasyon dosyalarını arayacak ve bunları tanılama için kullanacaktır. Aşağıdaki bağımsız değişkenleri ileterek tanılamayı ayrı ayrı çalıştırabilirsiniz -

  • AggregatedLogging
  • AnalyzeLogs
  • ClusterRegistry
  • ClusterRoleBindings
  • ClusterRoles
  • ClusterRouter
  • ConfigContexts
  • DiagnosticPod
  • MasterConfigCheck
  • MasterNode
  • MetricsApiProxy
  • NetworkCheck
  • NodeConfigCheck
  • NodeDefinitions
  • ServiceExternalIPs
  • UnitStatus

Bunları aşağıdaki komutla çalıştırabilirsiniz.

$ oc adm diagnostics <DiagnosticName>

Bir Kümeyi Yükseltme

Kümenin yükseltilmesi, küme içindeki birden çok şeyin yükseltilmesini ve kümenin yeni bileşenler ve yükseltmelerle güncellenmesini içerir. Bu şunları içerir -

  • Ana bileşenlerin yükseltilmesi
  • Düğüm bileşenlerinin yükseltilmesi
  • Politikaların yükseltilmesi
  • Rotaların yükseltilmesi
  • Görüntü akışının yükseltilmesi

Tüm bu yükseltmeleri gerçekleştirmek için, önce hızlı yükleyicileri veya araçları yerine koymamız gerekiyor. Bunun için aşağıdaki yardımcı programları güncellememiz gerekiyor -

  • atomic-openshift-utils
  • atomic-openshift-excluder
  • atomic-openshift-docker-excluder
  • etcd paketi

Yükseltmeye başlamadan önce, aşağıdaki komutlar kullanılarak yapılabilen ana makinede etcd yedeklememiz gerekir.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Ana Bileşenlerin Yükseltilmesi

OpenShift master'da etcd dosyasını güncelleyerek ve ardından Docker'a geçerek yükseltmeyi başlatıyoruz. Son olarak, kümeyi gerekli konuma getirmek için otomatik yürütücüyü çalıştırıyoruz. Bununla birlikte, yükseltmeye başlamadan önce, her bir master üzerindeki atomik openshift paketlerini etkinleştirmemiz gerekir. Bu, aşağıdaki komutlar kullanılarak yapılabilir.

Step 1 - Atomic-openshift paketlerini kaldırın

$ atomic-openshift-excluder unexclude

Step 2 - Tüm ustalarda etcd'yi yükseltin.

$ yum update etcd

Step 3 - etcd hizmetini yeniden başlatın ve başarıyla başlayıp başlamadığını kontrol edin.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Docker paketini yükseltin.

$ yum update docker

Step 5 - Docker hizmetini yeniden başlatın ve doğru şekilde çalışıp çalışmadığını kontrol edin.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - Tamamlandığında, aşağıdaki komutlarla sistemi yeniden başlatın.

$ systemctl reboot $ journalctl -r -u docker

Step 7 - Son olarak, paketleri yum hariç tutulanlar listesine geri getirmek için atomik yürütücüyü çalıştırın.

$ atomic-openshift-excluder exclude

Politikayı yükseltmek için böyle bir zorunluluk yoktur, yalnızca tavsiye edilirse yükseltilmesi gerekir ve aşağıdaki komutla kontrol edilebilir.

$ oadm policy reconcile-cluster-roles

Çoğu durumda, politika tanımını güncellememiz gerekmez.

Düğüm Bileşenlerinin Yükseltilmesi

Ana güncelleme tamamlandığında, düğümleri yükseltmeye başlayabiliriz. Unutulmaması gereken bir nokta, kümede herhangi bir sorunu önlemek için yükseltme süresinin kısa olması gerektiğidir.

Step 1 - Yükseltmeyi gerçekleştirmek istediğiniz tüm düğümlerden tüm atomik OpenShift paketlerini kaldırın.

$ atomic-openshift-excluder unexclude

Step 2 - Ardından, yükseltmeden önce düğüm planlamasını devre dışı bırakın.

$ oadm manage-node <node name> --schedulable = false

Step 3 - Geçerli ana bilgisayardan diğer ana bilgisayara tüm düğümü çoğaltın.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - Ana bilgisayarda Docker kurulumunu yükseltin.

$ yum update docker

Step 5 - Docker hizmetini yeniden başlatın ve ardından Docker hizmet düğümünü başlatın.

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - Her ikisinin de doğru şekilde başlayıp başlamadığını kontrol edin.

$ journalctl -r -u atomic-openshift-node

Step 7 - Yükseltme tamamlandıktan sonra düğüm makinesini yeniden başlatın.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Düğümlerde planlamayı yeniden etkinleştirin.

$ oadm manage-node <node> --schedulable.

Step 9 - OpenShift paketini düğümde geri almak için atomic-openshift yürütücüsünü çalıştırın.

$ atomic-openshift-excluder exclude

Step 10 - Son olarak, tüm düğümlerin kullanılabilir olup olmadığını kontrol edin.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

Otomatik ölçeklendirme, OpenShift'te dağıtılan uygulamaların belirli özelliklere göre istendiğinde ölçeklenebildiği ve çökebildiği bir özelliktir. OpenShift uygulamasında, otomatik ölçeklendirme, kapsül otomatik ölçeklendirme olarak da bilinir. İki tanetypes of application scaling aşağıdaki gibi.

Dikey Ölçekleme

Dikey ölçeklendirme, tek bir makineye daha fazla güç eklemekle ilgilidir, bu da daha fazla CPU ve sabit disk eklemek anlamına gelir. Bu, artık OpenShift sürümleri tarafından desteklenmeyen eski bir OpenShift yöntemidir.

Yatay Ölçeklendirme

Bu tür ölçeklendirme, makinelerin sayısını artırarak daha fazla isteği işleme ihtiyacı olduğunda kullanışlıdır.

OpenShift'te var two methods to enable the scaling feature.

  • Dağıtım yapılandırma dosyasını kullanma
  • Görüntüyü çalıştırırken

Dağıtım Yapılandırma Dosyasını Kullanma

Bu yöntemde, ölçeklendirme özelliği, bir konuşlandırma konfigürasyonu yaml dosyası aracılığıyla etkinleştirilir. Bunun için, OC otomatik ölçeklendirme komutu, kümede herhangi bir zamanda çalışması gereken minimum ve maksimum sayıda çoğaltma ile kullanılır. Otomatik ölçekleyicinin oluşturulması için bir nesne tanımına ihtiyacımız var. Aşağıda, pod otomatik ölçekleyici tanımlama dosyası örneği verilmiştir.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Dosyayı yerleştirdikten sonra, yaml formatında kaydetmemiz ve dağıtım için aşağıdaki komutu çalıştırmamız gerekir.

$ oc create –f <file name>.yaml

Görüntüyü Çalıştırırken

Aşağıdakileri kullanarak yaml dosyası olmadan da otomatik ölçeklenebilir. oc autoscale oc komut satırında komut.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

Bu komut ayrıca daha sonra referans için kullanılabilecek benzer türde bir dosya oluşturacaktır.

OpenShift'te Dağıtım Stratejileri

OpenShift'teki dağıtım stratejisi, farklı mevcut yöntemlerle bir dağıtım akışını tanımlar. OpenShift'te aşağıdakiler bulunmaktadır:important types of deployment strategies.

  • Rolling stratejisi
  • Stratejiyi yeniden oluşturun
  • Özel strateji

Aşağıda, esas olarak OpenShift düğümlerinde dağıtım için kullanılan bir dağıtım yapılandırma dosyası örneği verilmiştir.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

Yukarıdaki Deploymentconfig dosyasında Rolling olarak stratejimiz var.

Dağıtım için aşağıdaki OC komutunu kullanabiliriz.

$ oc deploy <deployment_config> --latest

Yuvarlanma Stratejisi

Döndürme stratejisi, güncellemeler veya dağıtım için kullanılır. Bu süreç ayrıca herhangi bir dağıtım sürecine kod enjekte etmek için kullanılan yaşam döngüsü kancalarını da destekler.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Stratejiyi Yeniden Oluşturun

Bu dağıtım stratejisi, yuvarlanan dağıtım stratejisinin bazı temel özelliklerine sahiptir ve ayrıca yaşam döngüsü kancasını da destekler.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Özel Strateji

Bu, kendi dağıtım sürecini veya akışını sağlamak istediğinde çok faydalıdır. Tüm özelleştirmeler ihtiyaca göre yapılabilir.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

Bu bölümde, bir düğümün nasıl yönetileceği, bir hizmet hesabının nasıl yapılandırılacağı gibi konuları ele alacağız.

Ana ve Düğüm Yapılandırması

OpenShift'te, yeni bir sunucuyu başlatmak için OC ile birlikte start komutunu kullanmamız gerekir. Yeni bir ana bilgisayarı başlatırken, ana kumandayı başlatma komutuyla birlikte kullanmamız gerekirken, yeni düğümü başlatırken düğümü başlatma komutuyla birlikte kullanmamız gerekir. Bunu yapabilmek için, ana düğümler için olduğu kadar düğümler için de yapılandırma dosyaları oluşturmamız gerekiyor. Aşağıdaki komutu kullanarak ana ve düğüm için temel bir yapılandırma dosyası oluşturabiliriz.

Ana yapılandırma dosyası için

$ openshift start master --write-config = /openshift.local.config/master

Düğüm yapılandırma dosyası için

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Aşağıdaki komutları çalıştırdıktan sonra, yapılandırma için başlangıç ​​noktası olarak kullanılabilecek temel yapılandırma dosyalarını alacağız. Daha sonra, yeni sunucuları başlatmak için aynı dosyaya sahip olabiliriz.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Düğüm yapılandırma dosyaları

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Düğüm yapılandırma dosyaları bu şekilde görünür. Bu yapılandırma dosyalarını yerleştirdikten sonra, ana ve düğüm sunucusu oluşturmak için aşağıdaki komutu çalıştırabiliriz.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Düğümleri Yönetme

OpenShift'te, çoğunlukla OpenShift'teki tüm işlemleri gerçekleştirmek için kullanılan OC komut satırı yardımcı programımız var. Düğümleri yönetmek için aşağıdaki komutları kullanabiliriz.

Bir düğümü listelemek için

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Bir düğümle ilgili ayrıntıları açıklama

$ oc describe node <node name>

Bir düğümü silme

$ oc delete node <node name>

Bir düğümdeki kapsülleri listeleme

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Bir düğümdeki kapsülleri değerlendirme

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Yapılandırma Kimlik Doğrulaması

OpenShift master'da, kimlik doğrulamasını yönetmek için kullanılabilecek yerleşik bir OAuth sunucusu vardır. Tüm OpenShift kullanıcıları jetonu bu sunucudan alır ve bu da OpenShift API ile iletişim kurmalarına yardımcı olur.

OpenShift'te ana yapılandırma dosyasıyla birlikte yapılandırılabilen farklı kimlik doğrulama düzeyi türleri vardır.

  • Hepsine izin ver
  • Hepsini inkar etmek
  • HTPasswd
  • LDAP
  • Temel kimlik doğrulama
  • Başlık isteyin

Ana konfigürasyonu tanımlarken, kullanmak istediğimiz politika tipini tanımlayabileceğimiz tanımlama politikasını tanımlayabiliriz.

Hepsine izin ver

Hepsine izin ver

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Hepsini inkar etmek

Bu, tüm kullanıcı adlarına ve şifrelere erişimi engelleyecektir.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd, kullanıcı adı ve parolayı şifrelenmiş bir dosya parolasına karşı doğrulamak için kullanılır.

Şifrelenmiş bir dosya oluşturmak için aşağıdaki komut verilmiştir.

$ htpasswd </path/to/users.htpasswd> <user_name>

Şifrelenmiş dosyayı kullanma.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

LDAP Kimlik Sağlayıcı

Bu, LDAP sunucusunun kimlik doğrulamada önemli bir rol oynadığı LDAP kimlik doğrulaması için kullanılır.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Temel Kimlik Doğrulama

Bu, kullanıcı adı ve parolanın doğrulanması sunucudan sunucuya kimlik doğrulamasına karşı yapıldığında kullanılır. Kimlik doğrulama, temel URL'de korunur ve JSON biçiminde sunulur.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Bir Hizmet Hesabını Yapılandırma

Hizmet hesapları, kimlik doğrulama için kullanıcı adı ve parolayı açığa çıkaran OpenShift API'ye erişmenin esnek bir yolunu sağlar.

Bir Hizmet Hesabını Etkinleştirme

Hizmet hesabı, kimlik doğrulama için genel ve özel anahtarlardan oluşan bir anahtar çifti kullanır. API için kimlik doğrulama, özel bir anahtar kullanılarak ve bir genel anahtara göre doğrulanarak yapılır.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Hizmet Hesabı Oluşturma

Bir hizmet hesabı oluşturmak için aşağıdaki komutu kullanın

$ Openshift cli create service account <name of server account>

HTTP Proxy ile Çalışma

Üretim ortamının çoğunda, İnternete doğrudan erişim kısıtlanmıştır. Ya internete maruz kalmazlar ya da bir HTTP ya da HTTPS proxy aracılığıyla açığa çıkarılırlar. OpenShift ortamında, bu proxy makine tanımı bir ortam değişkeni olarak ayarlanır.

Bu, altında bulunan ana ve düğüm dosyalarına bir proxy tanımı eklenerek yapılabilir. /etc/sysconfig. Bu, diğer uygulamalar için yaptığımız gibi.

Usta Makine

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Düğüm Makinesi

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Bittiğinde, ana ve düğüm makinelerini yeniden başlatmamız gerekiyor.

Docker Pull için

/ etc / sysconfig / docker

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Proxy ortamında bir bölmeyi çalıştırmak için, şu şekilde yapılabilir -

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

OC ortam komutu, mevcut env'i güncellemek için kullanılabilir.

NFS ile OpenShift Depolama

OpenShift'te, kalıcı birim ve kalıcı birim talepleri kavramı kalıcı depolama oluşturur. Bu, ilk kalıcı birimin oluşturulduğu ve daha sonra aynı hacmin talep edildiği temel kavramlardan biridir. Bunun için, temel donanım üzerinde yeterli kapasiteye ve disk alanına sahip olmamız gerekir.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Ardından, OC create komutunu kullanarak Persistent Volume oluşturun.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Oluşturulan birimi talep etmek.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

İddiayı oluşturun.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Kullanıcı ve Rol Yönetimi

Kullanıcı ve rol yönetimi, kullanıcıları, erişimlerini ve farklı projelerdeki kontrollerini yönetmek için kullanılır.

Bir Kullanıcı Oluşturma

OpenShift'te yeni kullanıcılar oluşturmak için önceden tanımlanmış şablonlar kullanılabilir.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

Kullanıcı oluşturmak için oc create –f <dosya adı> komutunu kullanın.

$ oc create –f vipin.yaml

OpenShift'te bir kullanıcıyı silmek için aşağıdaki komutu kullanın.

$ oc delete user <user name>

Kullanıcı Erişimini Sınırlandırma

ResourceQuotas ve LimitRanges, kullanıcı erişim düzeylerini sınırlamak için kullanılır. Küme üzerindeki bölmeleri ve kapsayıcıları sınırlamak için kullanılırlar.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Yukarıdaki yapılandırmayı kullanarak fiyat teklifi oluşturma

$ oc create -f resource-quota.yaml –n –Openshift-sample

Kaynak teklifini açıklama

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Kapsayıcı sınırlarının tanımlanması, konuşlandırılan kapsayıcılar tarafından kullanılacak kaynakları sınırlamak için kullanılabilir. Belirli nesnelerin maksimum ve minimum sınırlamalarını tanımlamak için kullanılırlar.

Kullanıcı projesi sınırlamaları

Bu, temel olarak bir kullanıcının herhangi bir zamanda sahip olabileceği proje sayısı için kullanılır. Temelde kullanıcı seviyelerini bronz, gümüş ve altın kategorilerinde tanımlayarak yapılırlar.

İlk olarak bir bronz, gümüş ve altın kategorisinin kaç tane projeye sahip olabileceğinin değerini taşıyan bir nesne tanımlamamız gerekiyor. Bunların master-confif.yaml dosyasında yapılması gerekir.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Ana sunucuyu yeniden başlatın.

Bir kullanıcıyı belirli bir seviyeye atamak.

$ oc label user vipin level = gold

Gerekirse kullanıcıyı etiketin dışına taşımak.

$ oc label user <user_name> level-

Bir kullanıcıya rol ekleme.

$ oadm policy add-role-to-user 
      
        <user_name>

Rolü bir kullanıcıdan kaldırma.

$ oadm policy remove-role-from-user 
      
        <user_name>

Bir kullanıcıya küme rolü ekleme.

$ oadm policy add-cluster-role-to-user 
      
        <user_name>

Bir kullanıcıdan bir küme rolünü kaldırma.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Bir gruba bir rol eklemek.

$ oadm policy add-role-to-user 
      
        <user_name>

Gruptan bir rolü kaldırma.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Bir gruba küme rolü ekleme.

$ oadm policy add-cluster-role-to-group 
      
        <groupname>

Bir gruptan küme rolünü kaldırma.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Küme yönetimi için kullanıcı

Bu, kullanıcının bir kümenin oluşturulmasından başlayarak bir kümenin silinmesine kadar eksiksiz bir kümeyi yönetme yeteneğine sahip olduğu en güçlü rollerden biridir.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Nihai güce sahip kullanıcı

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift, Docker ve Kubernetes üzerine inşa edilmiştir. Tüm kapsayıcılar, Kubernetes düzenlemeleri özelliğini kullanarak temelde Linux makinelerinin üzerinde Kubernetes hizmeti olan Docker kümesinin üzerine inşa edilmiştir.

Bu süreçte, tüm düğümleri kontrol eden ve kapsayıcıları tüm düğümlere dağıtan Kubernetes master'ı oluşturuyoruz. Kubernetes'in ana işlevi, farklı türde bir yapılandırma dosyası kullanarak OpenShift kümesini ve dağıtım akışını kontrol etmektir. Kubernetes'te olduğu gibi, kubctl'yi, küme düğümlerinde kapsayıcılar oluşturmak ve dağıtmak için OC komut satırı yardımcı programını kullandığımız gibi kullanırız.

Aşağıda, kümede farklı türdeki nesnelerin oluşturulması için kullanılan farklı yapılandırma dosyası türleri verilmiştir.

  • Images
  • POD
  • Service
  • Çoğaltma Denetleyicisi
  • Kopya seti
  • Deployment

Görüntüler

Kubernetes (Docker) görüntüleri, Containerized Infrastructure'ın temel yapı taşlarıdır. Şu an itibariyle Kubernetes yalnızcaDockerGörüntüler. Bir bölmedeki her konteynerin içinde çalışan Docker görüntüsü vardır.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

POD

Bir bölme, bir Kubernetes kümesinin bir düğümü içindeki kapsayıcılar ve depolanmasıdır. İçerisinde birden fazla kap bulunan bir bölme oluşturmak mümkündür. Aşağıda, bir veritabanı kapsayıcısı ve web arabirimi kabını aynı bölmede tutmanın bir örneği verilmiştir.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

Hizmet

Bir hizmet, mantıksal bölmeler kümesi olarak tanımlanabilir. Bölmelere erişilebilen tek bir IP adresi ve DNS adı sağlayan bölmenin üstünde bir soyutlama olarak tanımlanabilir. Service ile yük dengeleme yapılandırmasını yönetmek çok kolaydır. POD'ların çok kolay ölçeklenmesine yardımcı olur.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Çoğaltma Denetleyicisi

Replication Controller, kapsül yaşam döngüsünü yönetmekten sorumlu Kubernetes'in temel özelliklerinden biridir. Herhangi bir zamanda belirtilen sayıda bölme çoğaltmasının çalıştığından emin olmaktan sorumludur.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Kopya Seti

Çoğaltma kümesi, kapsülün kaç çoğaltmasının çalışacağını garanti eder. Çoğaltma denetleyicisinin yedeği olarak düşünülebilir.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Dağıtım

Dağıtımlar yükseltilir ve çoğaltma denetleyicisinin daha yüksek sürümleri. Aynı zamanda çoğaltma denetleyicisinin yükseltilmiş bir sürümü olan çoğaltma kümelerinin dağıtımını yönetirler. Replika setini güncelleme ve önceki sürüme geri dönme kabiliyetine sahiptirler.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Tüm yapılandırma dosyaları, ilgili Kubernetes nesnelerini oluşturmak için kullanılabilir.

$ Kubectl create –f <file name>.yaml

Kubernetes nesnelerinin ayrıntılarını ve açıklamalarını bilmek için aşağıdaki komutlar kullanılabilir.

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Docker ve Kubernetes ile nasıl çalışılacağı hakkında daha fazla ayrıntı için lütfen aşağıdaki bağlantı kubernetes'i kullanarak Kubernetes eğiticimizi ziyaret edin .

OpenShift güvenliği, esas olarak güvenlik kısıtlamalarını yöneten iki bileşenin birleşimidir.

  • Güvenlik Bağlamı Kısıtlamaları (SCC)
  • Hizmet Hesabı

Güvenlik Bağlamı Kısıtlamaları (SCC)

Temel olarak kapsül kısıtlaması için kullanılır, yani bir kapsülün sınırlamalarını, hangi eylemleri gerçekleştirebileceği ve kümede erişebileceği her şeyde olduğu gibi tanımladığı anlamına gelir.

OpenShift, yönetici tarafından kullanılabilen, değiştirilebilen ve genişletilebilen bir dizi önceden tanımlanmış SCC sağlar.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Önceden tanımlanmış herhangi bir scc kullanmak istenirse, bu sadece kullanıcı veya grubu scc grubuna ekleyerek yapılabilir.

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

Hizmet Hesabı

Hizmet hesapları, temel olarak, ana makinelerin veya düğüm makinelerinin herhangi birinden bir komut veya istek çalıştırıldığında çağrılan OpenShift ana API'sine erişimi kontrol etmek için kullanılır.

Bir uygulama veya işlem, kısıtlı SCC tarafından verilmeyen bir yeteneği gerektirdiğinde, belirli bir hizmet hesabı oluşturmanız ve hesabı ilgili SCC'ye eklemeniz gerekecektir. Bununla birlikte, bir SCC gereksiniminize uymuyorsa, en uygun olanı kullanmak yerine gereksinimlerinize özel yeni bir SCC oluşturmak daha iyidir. Sonunda, dağıtım yapılandırması için ayarlayın.

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

Konteyner Güvenliği

OpenShift'te, konteynerlerin güvenliği, konteyner platformunun ne kadar güvenli olduğu ve konteynerlerin nerede çalıştığı kavramına dayanır. Konteyner güvenliği ve nelere dikkat edilmesi gerektiği hakkında konuştuğumuzda ortaya çıkan birçok şey var.

Image Provenance - Üretim ortamında çalışan konteynerlerin nereden geldiğini tam olarak ve tartışılmaz bir şekilde tanımlayan güvenli bir etiketleme sistemi mevcuttur.

Security Scanning - Bir görüntü tarayıcı, tüm görüntüleri bilinen güvenlik açıklarına karşı otomatik olarak kontrol eder.

Auditing - Tüm kapların güncel kaplara dayandığından ve hem ana bilgisayarların hem de kapsayıcıların güvenli bir şekilde yapılandırıldığından emin olmak için üretim ortamı düzenli olarak denetlenir.

Isolation and Least Privilege- Kapsayıcılar, etkili bir şekilde çalışması için gereken minimum kaynaklar ve ayrıcalıklarla çalışır. Ev sahibine veya diğer kaplara gereksiz yere müdahale edemezler.

Runtime Threat Detection - Çalışma zamanında kapsayıcıya alınmış uygulamaya karşı etkin tehditleri algılayan ve buna otomatik olarak yanıt veren bir yetenek.

Access Controls - Erişim kontrollerini uygulamak için AppArmor veya SELinux gibi Linux güvenlik modülleri kullanılır.

Konteyner güvenliğinin arşivlendiği birkaç anahtar yöntem vardır.

  • OAuth aracılığıyla erişimi kontrol etme
  • Self servis web konsolu aracılığıyla
  • Platform Sertifikalarına göre

OAuth aracılığıyla Erişimi Kontrol Etme

Bu yöntemde, API kontrol erişimine yönelik kimlik doğrulama, OpenShift ana makinesinde yerleşik olarak gelen OAuth sunucuları aracılığıyla kimlik doğrulaması için güvenli bir belirteç alınarak arşivlenir. Yönetici olarak, OAuth sunucu yapılandırmasının yapılandırmasını değiştirme olanağına sahipsiniz.

OAuth sunucu yapılandırmasıyla ilgili daha fazla ayrıntı için bu eğiticinin 5. Bölümüne bakın.

Self Servis Web Konsolu aracılığıyla

Bu web konsolu güvenlik özelliği, OpenShift web konsolunda yerleşiktir. Bu konsol, birlikte çalışan tüm ekiplerin kimlik doğrulama olmadan diğer ortamlara erişmemesini sağlar. OpenShift'teki çoklu telnet ana aygıtı aşağıdaki güvenlik özelliklerine sahiptir:

  • TCL katmanı etkinleştirildi
  • Kimlik doğrulama için x.509 sertifikası kullanır
  • Ana makinede etcd yapılandırmasını güvenli hale getirir

Platform Sertifikalarına Göre

Bu yöntemde, her ana bilgisayar için sertifikalar, Ansible aracılığıyla kurulum sırasında yapılandırılır. Rest API üzerinden HTTPS iletişim protokolünü kullandığından, farklı bileşenlere ve nesnelere TCL güvenli bağlantıya ihtiyacımız var. Bunlar önceden tanımlanmış sertifikalardır, ancak erişim için ana kümeye özel bir sertifika bile yüklenebilir. Ana cihazın ilk kurulumu sırasında, özel sertifikalar, mevcut sertifikalar kullanılarak geçersiz kılınarak yapılandırılabilir.openshift_master_overwrite_named_certificates parametre.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Özel sertifikaların nasıl oluşturulacağı hakkında daha fazla ayrıntı için aşağıdaki bağlantıyı ziyaret edin -

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Ağ güvenliği

OpenShift'te, iletişim için Yazılım Tanımlı Ağ (SDN) kullanılır. Ağ ad alanı, kümedeki her bölme için kullanılır; burada her bölme, üzerinde ağ trafiğini almak için kendi IP'sini ve bir dizi bağlantı noktasını alır. Bu yöntemle, diğer projedeki podlarla iletişim kuramadığı için podlar izole edilebilir.

Bir Projeyi İzole Etmek

Bu, aşağıdakiler kullanılarak küme yöneticisi tarafından yapılabilir oadm command CLI'den.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Bu, yukarıda tanımlanan projelerin kümedeki diğer projelerle iletişim kuramayacağı anlamına gelir.

Birim Güvenliği

Hacim güvenliği, OpenShift kümesindeki projelerin PV ve PVC'sini güvence altına almak anlamına gelir. OpenShift'te birimlere erişimi kontrol etmek için başlıca dört bölüm vardır.

  • Ek Gruplar
  • fsGroup
  • runAsUser
  • seLinuxOptions

Ek Gruplar - Ek gruplar, normal Linux gruplarıdır. Sistemde bir işlem çalıştığında, bir kullanıcı kimliği ve grup kimliği ile çalışır. Bu gruplar, paylaşılan depolamaya erişimi kontrol etmek için kullanılır.

Aşağıdaki komutu kullanarak NFS montajını kontrol edin.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Aşağıdaki komutu kullanarak bağlama sunucusundaki NFS ayrıntılarını kontrol edin.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/ Opt / nfs / ihracat UID ile ulaşılabilir454265 ve grup 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup, kapsayıcı ek grupları eklemek için kullanılan dosya sistemi grubunu ifade eder. Ek grup kimliği, paylaşılan depolama için kullanılır ve fsGroup, blok depolama için kullanılır.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser, iletişim için kullanıcı kimliğini kullanır. Bu, kapsayıcı görüntüsünün kapsül tanımında tanımlanmasında kullanılır. Gerekirse tüm kapsayıcılarda tek bir ID kullanıcı kullanılabilir.

Kapsayıcı çalıştırılırken, tanımlanmış kimlik, dışa aktarmadaki sahip kimliği ile eşleştirilir. Belirtilen kimlik dışarıda tanımlanırsa, bölmedeki tüm kaplar için genel olur. Belirli bir kapsülle tanımlanmışsa, o zaman tek bir kaba özgü hale gelir.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265
ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved