OpenShift 101 — Web Console
Bir önceki yazıda OpenShift kurulumunu gerçekleştirmiştik. Bu yazıda OpenShift web konsolunu kullanarak HA (highly available) uygulamalar nasıl deploy ediliyor bakalım…
Yukarıda görebileceğiniz gibi bir OpenShift ortamında devreye alabileceğimiz birçok servis türü dil, veritabanı, middleware ve CI/CD başlıkları altında gruplandırılmış. OpenShift ortamında bir .Net Core uygulaması devreye almak istediğimizde, ilgili şablonu seçerek kaynak kodların bulunduğu adresi belirtmek yeterli.
Katalogdan Bir Uygulama Oluşturmak
Uygulama deploy etmek için önce bir Project oluşturmamız gerekiyor. Proje kavramı Kubernetes’teki kaynakları birbirlerinden izole etmeyi sağlayan namespace kavramına karşılık geliyor.
Create Project tuşu ile bir proje oluşturuyorum:
Projeyi oluşturduktan sonra proje içinde uygulamalar tanımlayabilir, CI/CD süreçlerini oluşturabilir, depolama alanı ekleyebilir ve uygulamanın nasıl çalıştığını izleyebilirim.
Adım adım ilerleyelim ve önce bir uygulama deploy edelim.
Browse Catalog tuşu ile kataloga geçelim ve listeden NodeJS’i seçelim.
Bu sayfada biraz oyalanmak istiyorum. Node.js uygulama tanımını okuduysanız, oluşturulacak uygulamanın CentOS 7 üzerinde Node.js 10 ile çalıştırılacağını görmüşsünüzdür. Açıklamanın hemen devamında bir Github repo adresini görüyorsunuz. Bu repoya giderseniz, uygulama şablonundan container oluşturulmasını sağlayan S2I adındaki yazılımın Node.js uyarlamasını göreceksiniz. S2I yine Redhat tarafından geliştirilmiş bir araç ve temel olarak yaptığı şey kaynak kodların, oluşturulacak container imajı içine enjekte edilmesini sağlayarak geliştiricinin işini kolaylaştırmak. Herhangi bir Dockerfile kullanmadan, sadece kaynak kodlarla container imajları oluşturabilmek, kodu CI/CD sürecine dahil edebilmek S2I’ın sağladığı ve geliştiriciye hız kazandıran özelliklerden bazıları.
Sayfada gördüğünüz ikinci url ise, uygulama tanımlarken kullanabileceğiniz örnek bir repo adresi içeriyor. Bu adrese de gidip bir bakmanızı tavsiye ediyorum. Çok basit bir Node.js uygulamasının kaynak kodlarının yanı sıra, uygulamanın OpenShift içinde nasıl deploy edileceğini gösteren Helm chart’ları ve OpenShift şablon tanımları da aynı repo içinde tutuluyor.
Bir sonraki sayfada uygulamaya bir isim verip, bu yazı için geliştirdiğim basit Node.js uygulamasının Github repo adresini giriyorum (https://github.com/onselakin/openshift-nodejs-mongo.git):
Create tuşu ile uygulamayı oluşturdum. Gördüğünüz gibi, uygulama oluşturmak ve bu uygulamayı CI/CD süreçlerine sokmak, bir repo adresi girmek kadar kolay.
Uygulama tanımını tamamladıktan sonra, sidebar’daki Overview tuşu ile projenin ana sayfasına geçiyorum:
Bu sayfadan, uygulama için oluşturulan container, uygulamanın ağ ayarları, build durumu hakkında genel bilgiler edinebiliyorum.
Uygulama şu anda çalışır durumda. Sağ üstte bulunan url ise, uygulamanın çalıştırıldığı adres. Tıklayıp görelim:
Uygulama çalışıyor ancak görebileceğiniz gibi MongoDB bağlantısında sorun var. Bu da beklenen bir durum çünkü şu anda sadece Node.js uygulamasını deploy ettik, MongoDB ile ilgili herhangi bir işlem gerçekleştirmedik.
PaaS İş Başında
Tek bir Github repo adresi girerek OpenShift üzerinde çalışan bir uygulama deploy edilmesini sağladık. Uygulamanın deployment sayfasına tekrar gidip neler var bir bakalım.
Containers başlığı altında, uygulamanın hangi container imajı ile çalıştığını, en son hangi build’in tamamlandığını, en son hangi commit’ten kodların alındığını ve uygulamanın hangi port’ları kullandığını görebiliyoruz. Aynı zamanda uygulamanın kaç pod ile çalıştığı bilgisi de ekranın sağında mevcut. HA (high availibility) konusuna geldiğimizde bu kısımda biraz daha çok vakit geçireceğiz.
Networking başlığı altında ise uygulamanın hem cluster içi hem de cluster dışından erişilebilir olmasını sağlayan adres ve port bilgilerini görebiliyoruz.
Build bölümünde ise tamamlanmış build bilgisini görmek mümkün. Şu esnada devam etmekte olan bir build olsaydı, build log’larını canlı olarak bu bölgede görmek mümkün olacaktı. Build bölgesinde build numarasına (#1 olarak görüntülenen sayı) tıklayarak build ile ilgili detaylı bilgilere ulaşmak mümkün:
Bu sayfada Build için gerekli Environment tanımlarını yapabileceğiniz gibi build ile ilgili logları da görmeniz mümkün. Derleme aşamasında ortaya çıkabilecek sorunlar için bol bol izleyeceğiniz bir sayfa da şu:
Sidebar menüsündeki Applications seçeneğinden Pods bölümüne geçtiğinizde, pod listesinde iki adet pod göreceksiniz:
Bunlardan biri çalışmaya devam ediyor, biri ise tamamlanmış durumda görünüyor. Tamamlanmış olan pod, adından da anlayabileceğiniz gibi sadece uygulamanın build sürecinde kullanılmış, uygulama build’i tamamlanınca da kapatılmış.
Applications -> Deployments altından uygulamamızın Deployment sayfasına gidelim.
OpenShift’in bizim için oluşturduğu Deployment’ı görüyoruz. Deployment’ın sağlamayı hedeflediği faydalarından biri de HA’nın otomatik olarak çalıştırılabilmesini sağlamak. Böylece uygulamamda bir sorun olduğunda, OpenShift önceden belirlemiş olduğum replica sayısına göre, her zaman çalışabilir bir instance’ın devrede olmasını sağlayabilecek.
Applications -> Services seçeneği ile, uygulama için oluşturulan servis bilgilerine de bir göz atalım.
Service, uygulamaya erişim için belli port’ları açıp, host / domain isimleri ile uygulamalara ulaşmak için imkan sağlayan bileşenlerdir. Bu sayfada, servisin kullandığı IP adreslerini, port eşleştirmelerini ve uygulamalar için tanımlanan route’ları görebiliyoruz.
Tüm sayfaları hızlıca bir dolaşmanızı, her sayfada bulunan Yardım bağlantısına tıklayarak OpenShift dokümantasyonuna geçerek bilgi almanızı tavsiye ederim :-)
oc Client Tools
OpenShift üzerindeki tüm yönetimsel işleri bir CLI tool’u olan oc ile de yapabiliyoruz.
oc araçlarını okd.io sitesinden indirebilirsiniz, gerekli yönergeler sitede mevcut. Mac OS kullanıyorsanız, aşağıdaki komut yeterli olacaktır:
$ brew install openshift-clioc kurulumunu tamamladıktan sonra, Web Console uygulamasında, developer menüsü altından Copy Login Command seçeneği ile terminalden sisteme giriş yapmak için gerekli olan komutu kopyalayabilirsiniz.
Terminalde komutu paste ederek sisteme bağlanıyorum (Böylece bir önceki yazıda verdiğim hiç terminal açmama sözümü yemiş oluyorum 🙂):
Aktif proje olarak nodejs-app seçilmiş durumda. oc ile vereceğim komutların tamamı bu projeyi etkileyecek.
Örneğin, projenin OpenShift üzerindeki bileşenlerine biraz daha detaylı bakalım:
Pod bilgisi:
Service bilgisi:
High Availability (HA) ve Fault Tolerance
Bu noktaya kadar gördüğünüz gibi, sadece bir Github repo adresi ile build, deployment ve service tanımları tamamen OpenShift tarafından gerçekleştirilen bir uygulamayı çalışır hale getirdik.
Uygulama için oluşturulan deployment, replication controller ve pod’ları listeliyorum:
Bu liste bana mevcut durumu gösteriyor. Yapmak istediğim şey, uygulamanın HA ayarlarını değiştirirken bir taraftan da bu listenin nasıl değiştiğini gözlemlemek. Böylece bir pod öldüğünde, OpenShift yeni pod’ları nasıl devreye sokuyor canlı olarak görebileceğim. Konfigürasyon değişikliği yaptıkça bu komutu tekrar vererek değişiklikleri izleme imkanınız mevcut ama ben daha farklı bir yol izleyip, watch aracı ile otomatik olarak değişiklikleri izlemek istiyorum:
$ brew install watchwatch kurulumu tamamlandıktan sonra, bir önceki komutu tekrar watch ile bir kez daha veriyorum. -n 1 parametresi komutun her saniye tekrar çalıştırılmasını ve ekranın güncellenmesini sağlayacak:
$ watch -n 1 oc get dc,rc,pods
Şimdi, uygulamanın scaling ayarlarıyla biraz oynayalım.
Daha önceden bildiğimiz bu sayfanın sağ tarafında, uygulamanın kaç pod ile çalıştığını görebiliyoruz. Çemberin hemen sağında bulunan yukarı ve aşağı ok tuşları ile scaling ayarlarını yapıyoruz:
Pod sayısını 5'e çıkartıyorum. Ben bu işlemi yaparken terminalde neler oluyor ona da bakalım:
Yeni eklenen pod’ları ekranda görebilirsiniz. Uygulamayı scale etmek bu kadar kolay. Tabi şu anda Minishift üzerinde tek node ile bir cluster çalıştırdığım için aslında gerçek bir HA durumundan söz etmek mümkün değil ama minimum 3 node’lu bir cluster ile HA durumuna erişmek bu derece kolay.
Kasıtlı olarak pod’lardan ikisini sildiğimde ne oluyor onu da göstermek istiyorum:
2 pod’u siliyorum ve sistem yine desired state’e, yani 5 pod’a ulaşacak şekilde hemen yeni pod’ları devreye alıyor. Şahane 😍
Yeni Versiyonlar ve Rollout Stratejisi
Diyelim ki uygulamamızda güncelleme yaptık, güncel versiyonu deploy etmemiz gerekiyor ve bunu sistemde bir kesinti olmadan gerçekleştirmek istiyoruz. HA gibi bu işlem de OpenShift’de gerçekten çok kolay.
Uygulamanın deployment konfigürasyonuna bir bakalım önce:
Gördüğünüz gibi güncelleme sonrası uygulamanın deploy edilmesinin nasıl yürütüleceğine dair üç farklı seçenek var. Bunlardan ilki olan Rolling, uygulamanın güncel versiyonunun deploy edildiği pod’lar oluşturulurken, mevcut pod’ları scale down ederek yeni versiyona geçiş yapılmasını sağlıyor. Recreate stratejisi, önce mevcut versiyondaki pod’ları tamamen durdurup, ardından güncel versiyonun bulunduğu pod’ları devreye alıyor. Uygulamanız aynı anda iki farklı versiyonu desteklemiyorsa bu seçeneği tercih edebilirsiniz. Custom ise deployment sürecini deployment hook’ları ve parametreler kullanarak tamamen özelleştirebileceğiniz stratejidir. Şu anda bizi ilgilendiren Rolling stratejisi.
Normal şartlar altında, kod üzerinde bir güncelleme yaptığımda Github hook’ları üzerinden OpenShift’teki uygulamanın güncel versiyonunu deploy etmek mümkün. Ancak Github’ın benim tek cluster’lık minik OpenShift kurulumuma ulaşması mümkün olmadığı için yeni bir deployment tetiklendiğinde rolling out nasıl çalışıyor elle göstereceğim.
Uygulamanın Deployment sayfasındaki Deploy tuşunu kullanarak yeni bir deployment başlatıyorum:
Bu kadar, eski versiyon scale down edilirken, güncel versiyon da scale up ediliyor ve yine desired state olan 5 pod sayısına ulaşıncaya kadar pod’ları oluşturuyor. Böylece servis kesintisi olmadan uygulama güncellenmiş oldu.
Service Discovery ve MongoDB Bağlantısı
Örnek Node.js uygulamasına baktıysanız, MongoDB bağlantısı için kullandığım connection string’in şu şekilde olduğunu görmüş olmalısınız:
mongodb://dbuser:dbpass@mongodb/sampledbUygulamanın ulaşabileceği mongodb adında bir veritabanı sunucusu olduğu sürece, uygulama sorunsuz çalışacak ancak şu anda böyle bir sunucumuz yok. OpenShift kataloğunu kullanarak bir MongoDB servisi tanımlayalım.
Katalogdan MongoDB’yi seçiyor ve ayarlarını aşağıdaki gibi yapıyorum. Servis adına dikkatinizi çekiyorum. Aslında bir OpenShift servisi tanımlıyorum ancak servis adı uygulamanın connection string’i içindeki host adı ile aynı. OpenShift’in service discovery özelliğini bu şekilde kullanmış oluyoruz.
Daha önce MongoDB bağlantısı kuramayan uygulamanın ana sayfasını tekrar açıyorum ve sonuç:
Pod’lardan birine bağlanıp mongodb servisinin ip adresini sorgulamamız da mümkün:
Böylece uygulamada konfigürasyon değişikliği yapmadan, IP adresleri ile uğraşmak zorunda kalmadan, mongodb adındaki servis üzerinde bir değişiklik yaptığımda sistemi bozmadan çalışmayı mümkün kılmış oluyoruz.
Bayağı uzun bir yazı oldu. Bir developer olarak OpenShift ile çalışırken karşılaşacağınız bir çok kavramı özetleyerek anlatmaya çalıştım. Daha önce de söylediğim gibi, OpenShift dokümantasyonu dostunuz, okuyun onu 🙂
Umarım işinize yarar.
