Mobile App- Backend Mimarisi GCP Architecture (Part-2)

Bu proje kapsaminda cok fazla detay oldugu icin bazi kisimlarin cok detayina girmeyecegim.

Bu noktada Google Cloud uzerinde bir adet cluster olusturmaniz gerekiyor. Cluster yapinizi , node sayinizi vs kendiniz belirlemeniz gerekiyor. (Ben baslangic olarak 3 node lu e2 standart node tipi secerek ilerledim.) Bu noktada dikkat etmeniz gereken sey, eger kubernetes vs de calismaya yeni basladiysaniz ve minimum konfigurasyon ile ilerlerseniz ilerleyen surec de servislerinizi deploy ederken kaynak yetersizligi ile karsilabilirsiniz ve deployment noktasinda aldiginiz hatayi cozmek biraz zamaninizi alabilir. Ki belki boyle ogrenmek en guzeli de olabilir.

Kubernetes Clusterimiz olusturulurken, firebase tarafina gecip uygulamalarimizi olusturalim.

https://console.firebase.google.com/u/0/

Uygulamanizi olusturduktan sonra Firebase in karsilama ekrani ile karsilasacaksiniz.

Burada ilk isimiz bir uygulama olusturmak olacak. Bunun icin de ekranin ortasindaki simgelerden birini sececegiz. Ben iOS ile ilerleyecegim.

Bu makaleyi yazarken gercek bir uygulama gelistirme sureclerini aktardigim icin iOS bu noktada bir sorun olusturmuyor. Fakat iOS tercih etmeniz durumunda Apple Developer tarafinda uygulamayi register etme , provision profile yukleme , Apple key olusturma gibi surecleri halletmeniz gerekecek.

Apple icin uygulama olusturuyorsaniz “GoogleService-Info.plist” Android icin uygulama olusturuyorsaniz “google-services.json ” isimli dosya indirmeniz gerekecek. Bu dosyalari iOS ve Android uygulamalariniza dahil etmeniz gerekecek.

Uygun bir vakitte projenin mobil tarafindaki islemler icin de ayri bir makale hazirlamaya gayret edecegim.

Firebase de sol tarafda yer alan bir cok ozelligi de mobil uygulamalarimiza dahil edecegiz.

Biz mu islemleri yaparken kubernetes clusterimiz da olusmus islem yapmamiza hazir hale gelmis olmali. Biz tekrar backend kismina giris yapalim.

Domain Setup

Uygulamalarimiz bizim servislerimiz ile bir API uzerinden haberlesecegi icin oncelikle domainimizi hazirlamamiz gerekiyor. Bu nokta da da ilk isimiz bir SSL sertifikasi olacaktir.

Bunun icin Google Cloud uzerinde Security Center da Certificate Manager kismina gidip domaininiz icin bir adet sertifika olusturmaniz gerekmekte.

Create new Certificate Seceneginden bu islemi yapabilirsiniz. Kendinize ait bir sertifika var ise onu kullanabilir ya da isin o kismini da Google a yukleyebilirsiniz. (Ben mumkun olan tum is yuklerini Google a yuklemeyi tercih ediyorum)

Burada Create Google-managed certificate sectikten sonra asagidaki resimdeki gibi Google sizin domaini dogrulamanizi istiyor. bunun icinde DNS dogrulamayi tercih ediyorum.

Bunun icinde domaini ekledikten sonra Google sizden bunu dogrulamak icin eklemeniz gereken DNS bilgilerini olusturuyor.

Sizinde bu bilgileri domain nameservera eklemeniz gerekmekte. Burada Create butonuna basmadan once bu bilgileri eklemeniz daha faydali olacaktir.
Sertifikayi olustururken verdigim isim “api-example-com-cert” bunu asagida kullanacagiz.

Oncelikle domainin bulundugu ns servera bu bilgileri ekledikten sonra bir cay icip Create butonuna basabilirsiniz.

Burada sertifikanin provizyon edilmesi icin biraz beklemeniz gerekmekte. Sertifika dogrulanip olusturulduktan sonra aktif hale gelecektir.

Daha sonra bu sertifikayi GKE de kullanabilmek icin certificate map olusturmaniz gerekiyor.

Bunun icin oncelikle google tarafinda bir map-entry olusturmalisiniz.

gcloud certificate-manager maps create api-example-com-map

Bu komutla bir certificate map olusturuyorsunuz. Ardindan olusturmus oldugunuz certifika ile bu mapi birlestirmeniz gerekiyor.

gcloud certificate-manager maps entries create \
api-example-com-map-entry \
 - map=api-example-com-map \
 - hostname=api.example.com \
 - certificates=api-example-com-cert

Bu komut ile de sertifikanizin map entrysini olusturup kullanmaya hazir hale gelebilirsiniz.

APIGateway Kurulumu

Neden Ingress Yerine Gateway ?

Projeye başlarken, trafik yonetimi için Ingress dogal bir secimdi ancak projeye derinlemesine baktıkca, Ingress’in sunduklarından daha fazlasına ihtiyac duyacagimizi fark ettim. Iste o zaman Gateway API olmasina karar verdm.

Bu proje basit olmayacaktı. Esneklik ve karmasik trafik kurallarını yönetebilme kabiliyetine ihtiyac duyuyordum. Gateway, bu ihtiyacları fazlasıyla karşılıyordu. Trafigi yonlendirmekten daha fazlasını sunuyor; bunu hassasiyetle yaparken sistemi gelecekteki zorluklara hazırlıyordu.

Neden Gateway Mantıklı?

Gateway, trafik yönetimini iç yönlendirmeden ayırarak bana ihtiyaç duyduğum kontrolü ve olceklenebilirliği sagladı. Ayrıca Kubernetes’in olasi guncellemeleri ile de uyumluydu, bu da onu ileriye yonelik bir tercih haline getirdi. Bu kararın yalnızca bugünün sorunlarını çözmekle kalmayıp, yarının gereksinimlerine de uygun olmasi gerekiyordu.

Elbette, Gateway kendi karmaşıklıklarıyla geldi. Daha fazla kurulum gerektiriyor ve Kubernetes’i daha derinlemesine anlamayı zorunlu kılıyordu. Ancak sunduğu avantajlar — daha iyi güvenlik, ayrıntılı kontrol ve service mesh’lerle sorunsuz entegrasyon — bu ekstra efora degdi.

Sonuc olarak, Ingress yerine Gateway’i secmek, projenin gelisip evrildikce buyuyeceği ve uyum saglayabilecegi bir mimari insa etmekle ilgilydi. Bu is icin dogru aracti.

Daha onceden de KONG kullandigim icin Gateway olarak ben yine KONG kullanmayi tercih ediyorum. Siz bu noktada native Gateway classini kullanabilirsiniz.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: api-gateway
spec:
  controllerName: konghq.com/kic-gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: api-mobile-gateway
  annotations:
    networking.gke.io/certmap: api-example-com-map
    kubernetes.io/ingress.global-static-ip-name: api-ip-adress
spec:
  gatewayClassName: kong
  listeners:
  - name: proxy
    port: 80
    protocol: HTTP
  - name: https
    protocol: HTTPS
    port: 443

Bu “ networking.gke.io/certmap: api-example-com-map” tanimlama bizim olusturmus oldugumuz certificate map i icerir.

Artik APIGateway kurulumuzu hazirladik. Bunun icin basic bir deneme yapabiliriz. public bir repo kullanabiliriz bunun icin bir nginx servisi olusturacagim.

nginx-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-test
  labels:
    app: web-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-test
  template:
    metadata:
      labels:
        app: web-test
    spec:
      containers:
        - name: webapphost
          image: nginx:1.19-alpine
          imagePullPolicy: Always
          ports:
            - containerPort: 80

nginx.yaml

apiVersion: v1
kind: Service
metadata:
  name: web-test
  labels:
    app: web-test
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: web-test

kubectl apply -f nginx-deploy.yaml
kubectl apply -f nginx-deploy.yaml

Bu basit nginx servisini deploy ettikten sonra bunu kullanacagimiz Gateway e tanimlamaya haziriz.

Bu noktada bu route da API dokumantasyonunu yayinlamayi tercih ediyorum. Fakat bu ornekde basit bir nginx ile ilerliyorum.

Burada da HTTP Route devreye giriyor.

home-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-home-route
  annotations:
    konghq.com/strip-path: 'true'
spec:
  hostnames:
  - api.example.com
  parentRefs:
  - name: api-mobile-gateway
  rules:
  - matches:
    - path:
        type: Exact
        value: /
    backendRefs:
    - name: web-test
      kind: Service
      port: 80

kubectl apply -f homeroute.yaml

Route tanimlamasi da yaptiktan sonra domaini ziyaret edebilirsiniz.

Tataaa:

Bir sonraki partta gorusmek uzere. Iyi okumalar