___OpenShift Roadmap___

Selamlar , ben Uğur. Work for dream series üçüncü sayısında sizlerle Cloud olarak kullandığımız Openshift Container Platform’u hakkında teknik bir konuyu başlık olarak alıyorum. Sade ve öz bir anlatım ile bildiklerimi kaleme aldım.
Konu başlıkları olarak..
Openshift nedir ?
Container Platform avantajları nelerdir?
Openshift ortamının yapısı nasıl olmalı ?
Openshift’e dair kullanılan pencereler ve bunlara baglı olarak nasıl bir application oluşturabiliriz ?

Artık bir yemek yapmamız lazım . Çok lezzetli olması şart değil önce karın doyursa yeterli olur. Yemek yapmak için elinizde hangi malzemelerin olduğu ve olmadığını bilmek bir başlangıçtır.

Openshift Nedir ?

OpenShift, Red Hat tarafından geliştirilen bir containerization yazılım ürünüdür. Başlıca ürünleri, Kubernetes tarafından düzenlenen ve yönetilen bir Hizmet Olarak Platform (PaaS) olan OpenShift Konteyner Platformu’dur. Go ve AngularJS ile yazılmış ve bir Apache Lisansına sahiptir.

k8s and ocp

OpenShift Origin, Red Hat’ın open-source ve cloud-based bir platformudur ve geliştiricilerin cloud uygulamaları oluşturmalarını, test and deploy etmelerini sağlar. Sistem daha hızlı uygulama development, easy deployment and scaling(Ölçekleme) için bir Kubernet core üstüne araçlar ekler.

Openshift ( Platform as a Service )

Platform, Go, Node.js, Ruby, Python, PHP, Perl ve Java’yı desteklemenin yanı sıra, kullanıcıların diğer diller için destek ekleyebilmelerine olanak sağlayacak şekilde genişletilebilir. Ölçeklenebilirlik ile ilgili olarak, platform kapsayıcı uygulamaların otomatik veya manuel olarak scaling edilmesini sağlar.

OpenShift’in sunduğu özelliklerden bazıları:

• Constant security — Uygulama uzun süre konteyner alyapısı altında güvenlik kontrolleri yapılmıştır.
• Built-in monitoring — Platformda bulunan Prometheus, bir database ve application monitoring yazılımınıdır.Prometheus:Prometheus %100 açık kaynaklı servis izleme sistemidir.Grafana dashboard ile servis gerçek zamanlı izlenebilmektedir.
• Centralized policy management — Tek bir console ile uygulamak için merkezi bir yer sağlar.
• Compatibility — OpenShift sertifikalı Kubernetes programının bir parçasıdır. Bu nedenle Kubernetes container yapısı ile uyumlu bir çalışma saglamaktadır.

OpenShift ile çalışmanın faydaları:

• Fast application development — Platform, konteyner yönetim sürecini yürütür ve otomatikleştirir, bunun için DevOps sürecini geliştirir. Uygulama geliştirmedeki bu hızlanma, daha hızlı bir şekilde pazara gidebileceğiniz ve rekabetçi olabileceğiniz anlamına gelir.
• No vendor lock-in — Satıcıya yönelik açık kaynaklı bir platform sunar; bu, kullanıcıların konteyner işlemlerini yinelemelerine gerek kalmadan gerektiğinde konteyner işlemlerini gerektiğinde yeni işletim sistemlerine geçirebilecekleri anlamına gelir.
• Self-service provisioning — OpenShift, kullanıcıların en çok kullandıkları araçları entegre etmelerini sağlar; örneğin, bir video oyunu geliştiricisi, birkaç işletim sistemiyle uyumlu oyunlar geliştirirken bu özelliği kullanabilir.

Kuberneste ( K8s ) altyapısıyla gelen Openshift CLI olarak ta k8s alt yapısını kullanmaktadır. Burada CLI ekranını kullanan ve k8s tecrübesi olan arkadaslarımız sadece “kubectl” ile bşlayan komut yerine “oc” kullanarak CLI ekranını kolayca manage edebilir.

Birinde ‘oc’ komut satırı kullanılırken,diğerinde ‘kubectl’ komut seti kullanılmaktadır.Alttaki iki komut seti aynı sonuçları vermektedir.

kubectl get nodes(Kubernetes)

oc get nodes(Openshift)

Openshift infrastructure

Yukarıdaki resimde bir openshift mimarisinin kuş bakışı görünümü yer almaktadır. Burada end to end olarak bir uygulamanın hangi cycle içerisinde bulunuduğunu tek tek konu olarak incelemeye hazırsanız başlayalım.

1-Project Management

oc get projects #komutu projeleri listeler

Project management, AWS ile karşılaştırdığımızda proje yönetim ekranıyla aynı diyebiliriz. Openshift üzerinde bulunan aynı infra üzerinde bulunan projeleri namespace bazında listeler .

Project management, bizlere console anlamında çok kolaylık sağlamaktadır.
Burada birden fazla test , pre-prod ve prod ortamları arasında geçiş ve yönetimi gui olarak bizlere bu kolaylığı sağlamaktadır.

Projects

2-Deployment Config

oc get dc #komutu namespace üzerindeki deployment listeler.

Deployment Config , K8s ile karşılatırdığımızda deployment olarak yapı , Openshift ile birlikte Deployment Config yapısı ile gelmektedir.

Burada her microservis kendi içerisindeki dinamiklerine göre bir yapı kurulabilir. Sağlıklı bir şekilde çalışan uygulamamızın openshift gui üzerinden kolayca scale edebilir ve durumunu memory , cpu ve network durumunu monitör etmemizi sağlamaktadır.

Deployment Config

Microservise bağlı pod ( replica ) olarak ayağa kalmış uygulamanın yönetimini bu ekran üzerinden yapabilirsiniz.

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: example
  namespace: PROJECT_NAMESPACE
spec:
  selector:
    app: hello-openshift-micsroservice
  replicas: 3
  template:
    metadata:
      labels:
        app: microservice
    spec:
      containers:
        - name: hello-openshift
          image: openshift/hello-openshift
          ports:
            - containerPort: 8080

3-Stateful Set

oc get statefulset #komutu namespace üzerindeki stateful set deployment listeler

State kelimesi IT camiasında farklı bir anlamı vardır. Örnek vermek gerekirse bir sisteme giriş yapmış kullanıcının o anki durumu bir Session objesinde tutulur ve bu bizim için bir state teşkil etmektedir .

Örnek bir neden gerekirse bir uygulama gidip oturum verisini kendi kaynaklarında uygulama içerisinde bir noktada veya RAM’de, application server restart olunca RAM’de tutulan tüm stateler kaybolacaktır.

State’lerimizi daima uygulama sunucusundan ayrılması söylenir , örnek veriyorum sepet verisini alıp başka bir external Redis, Memcache gibi bir servise yönlendirmemiz gerekebilir .Uygulamamız eğerki sadece bir computing işlemi yapıyor state tutma gibi bir vazifesi yoksa veya arındırılmışssa zaten bu uygulamaya stateless uygulama deniyor.

Stateless yapıların ölçekleme, yük dengeleme gibi konularda da mimari açısından da farklı bir perspektife sahip .

Not : Bu konuyla ilgili ilerleyen zamanlarda Openshift üzerinde Stateful Set olarak Redis kurulumunu ele alıyor olcağım.. :)

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: example
  namespace: YOUR_NAMESPACE
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: nginx
          image: 'gcr.io/google_containers/nginx-slim:0.8'
          ports:
            - containerPort: 80
              name: web
          volumeMounts:
            - name: www
              mountPath: /usr/share/nginx/html

4-Config Maps

oc get cm #configmap listelenir

Configmap , proje üzerinde bulunan Deployment Config’lerin microservis (backend or frontend) uygulamanızın ayağa kalkmadan öncedi okuması gereken dosya olarak adlandırabiliriz.

Config Maps

Örneğin microservisler arasında bir data alışverişi ya da haberleşmesi için configmap’ler aracılığı ile yapılabilir.

apiVersion: v1
kind: ConfigMap
metadata:
  name: example
  namespace: YOUR_NAMESPACE
data:
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3

5-Horizontal Pod Autoscaller ( HPA )

oc get hpa #komutu namespace üzerindeki hpa listelenir.

Uygulamalarımızın en iyi çalışma özelliklerinden biri de otomatik kendini dinleyen uygularımızdır aslında. Çünkü uygulamayı kendi içindeki dinamiklerine göre bir yapı kurduğunuzda uygulama kendi üzerine gelen yüke göre design edebilmeli. Burada devreye HPA giriyor.

HPA

HPA bizim microservislerimizin üzerine gelen yüke göre belirlediğimiz pod sayısında otomatik scale edebilme esnekliği sağlıyor.

Uygulama üzerinde gelen client sayısı ya da yüklerin cpu ve memory limitlerinin belli bir seviyeyi zorladıgında failover olmaması için scale edip yoluna sorunsuz devam etmesini sağlamaktadır.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: example
  namespace: YOUR_NAMESPACE
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: DeploymentConfig
    name: example
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          averageUtilization: 80
          type: Utilization
    - type: Resource
      resource:
        name: memory
        target:
          averageUtilization: 80
          type: Utilization

6-Networking

Networking , bir microservis mimarisinde uygulamaların içerde ve dışarda haberleşmesi için bulunan L4 ve L7 katmanlarının ayrıldığı kısımdır.

Openshift bize bu katmanları içerde uygulamaların konusması için “Services” , uygulamanın secure bir şekilde dışarıyla haberleşmesi için “Router” lar üzerinden çalışmasını sağlamaktadır.

6.1-Router

oc get route #komutu namespace üzerindeki dns router listenir.

Router’lar , bir uygulamanın secure bir şekilde openshift üzeriande sertifikalı bir dns kaydını otomatik bir yapı oluşturmaktadır.

Örneğin , buradaki yapıda apigw üzerinde bir tanımlama yapılırken router’lar üzerinden haberleştiriyoruz. Çünkü, bir microservisin dışarı cıkması secure ve ssl olarak uygun yapıda conf edilmesi lazım.

Router

Ek olarak, birbirinden izole 2 ortamımız var ve burada bu iki ortamı high avaible olarak haberleşmesini istiyoruz. LB seviyesinde router’larla bu kolaylığı openshift routerlar sayesinde kolay yönetebilir hale getiriyor. Eğer high avaiable olan 2 ortamınız mevcut ise LB seviyesinde %50 %50 LB yönlendirecek şekilde design edilmesi uygulamanın disasster durumunu kurtarıcaktır.

Load balancing for application

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: example
  namespace: YOUR_NAMESPACE
spec:
  path: /
  to:
    kind: Service
    name: example
  port:
    targetPort: 80

6.2-Services

oc get service #komutu namespace üzerindeki servisler listenir.

Servisler , microservis mimarisinde uygulamaların openshift cluster içinde haberleşmeleri için configmap’lerde uygulamarın birbiri ile bağlı bağımlılıkları var ise servisler aracılığı ile konuşturmak için kullanabiliriz.

Services

Burada her microservisin isim , label ve port olarak her bir ms’i biribirinden izole bir şekilde manage ediyoruz. Her servisin kendi içerisinde bir yapı kurmus oluyoruz.

apiVersion: v1
kind: Service
metadata:
  name: example
  namespace: YOUR_NAMESPACE
spec:
  selector:
    app: example
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

7-Persistance Volume Claım ( PVC )

oc get pvc #komutu proje üzerindeki ms’lere baglı pvc listeler

Bir microservis mimarisinde en çok istenen özelliklerden biri de geri dönük bir data havuzu tutabilmek. Log , dosya , yedekleme , backup gibi yada dosya üzerinden read-write yapmak istediğimiz bir durumda pvc ‘leri kullanıyoruz.

Persistent Volume Claim ( PVC )

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example
  namespace: YOUR_NAMESPACE
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

8-User Management ( Role Binding )

oc get rolebindings #komutu proje üzerindeki role’ları listeler.

Openshift’in en sevdiğim özelliklerinden biri de User management. Çünkü bir yapıyı kurduğunuzda bunun test ve prod ortamında yönetimini squad’lar içinde bir çok kişinin çalıştığı ortam haline geliyor. Developer ve Devops arasında bu çalışma alanını sınırlamak için “Role Binding” ile bu durumu Openshift çok iyi cover etmiş durumda.

Role Bindings

Openshift kendi içerisindeki hazır Policy’leri ile burada group bazlı ya da admin, view , only read yetkileri gibi birçok yetkileri kolay bir şekilde manage etmemizi ve secure ilerlemezi sağlamaktadır.

9-Operatör HUB

OperatorHub, OpenShift Container Platform web konsolu aracılığıyla kullanılabilir ve küme yöneticilerinin Operatörleri keşfetmek ve yüklemek için kullandığı ara katmanımız. Tek bir tıklamayla, bir Operatör küme dışı kaynağından alınabilir, kümeye kurulabilir ve abone olabilir ve mühendislik ekiplerinin Operator Lifecycle Manager (OLM) kullanarak ürünü dağıtım ortamlarında self servis yönetmesi için hazır hale getirilebilir.

Operator HUB

Örneğin , monitoring için Grafana, İstio , Appdyanmics…cache’le için kullandığımız Redis…yönlendirme için kullanıcağımız nginx’i tek tıklamay ile openshift bu güzelliği hazır bir tool olarak bize sağlamaktadır.

Openshift Ortamının Yapısı Nasıl Olmalı ?

Aslında burda High-Available bir ortam kurmamız daha doğru oluyor.Bunun için çoklu master, infra, router yapısı gerekmektedir.

• 3 Master Sunucusu
• 1 Load Balancer (İsteğe bağlı 2 adet’e çıkarabilirsiniz)
• 3 Etcd Sunucusu
• 2 Node Worker Sunucusu (İhtiyaca bağlı olarak arttırıp azaltabilirsiniz)

— — — — — — — — — — — — — — — — — — — — — — — — — —

WorkForDreamSeries ‘in üçüncü yazısında Devops Engineer olarak özetle Openshift Container Platform’unda sade ve basit anlamda neler yaptığımızdan kullanılan teknolojilerden bilgim dahilinde bahsetmek istedim.

Artık sizlerde basit bir adımla openshift üzerinde uygulamalarınızı step by step design edebilir ve yönetimini kolayca yapabilirsiniz.

Yazımı beğendiyseniz claps atmayı ve follow butonuna basmayı unutmayın :)

Uğur Duran
Bestcloudfor.me Cloud Native Engineer
#workfordreamseries