Ana içeriğe atla

​
Ortam Kavramı

Ortam, Kubernetes bağlamında Namespace ifadesine karşılık gelir. Kubernetes kümeleri büyük miktarda bağlantısız iş yüklerini eş zamanlı olarak yönetebilir. Kubernetes, küme içindeki nesnelerin karmaşasını gidermek için Namespace adı verilen bir kavramdan faydalanır.
Namespace’ler nesnelerin birbirleriyle gruplanmasına ve bu grupların bir birim olarak filtrelenip kontrol edilmesine olanak sağlar. Böylece özelleştirilmiş erişim kontrol politikalarını uygulamak ya da bir test ortamı için tüm birimleri birbirlerinden ayırmak için gruplamalar yapmak gibi amaçlarla kullanılabilir.

​
Ortam Özellikleri

İzolasyon

Her ortam diğer ortamlardan tamamen izole edilmiştir. Bir ortamdaki API Proxy’ler diğer ortamlardaki API Proxy’lerle doğrudan iletişim kuramaz.

Kaynak Tahsisi

Her ortamın kendisine ayrılmış CPU ve RAM gibi kaynakları vardır. Bu kaynaklar diğer ortamlarla paylaşılmaz.

Erişim Adresi

Her ortamın kendisine ait bir erişim adresi (URL) vardır. Bu adres üzerinden ortamdaki API Proxy’lere erişilebilir.

Ayarlar

Her ortamın kendisine özgü ayarları vardır. Bu ayarlar diğer ortamlardan bağımsızdır.

​
Ortam Yapısı

Aşağıdaki diyagram, ortamın ne içerdiğini high-level olarak gösterir:

​
Neden Birden Fazla Ortam Kullanılır?

İki temel nedenle birden çok ortam kullanılması tavsiye edilmektedir:

​
1. Yaşam Döngüsü Yönetimi

Geliştirme (Development), Test, Sandbox ve Üretim (Production) gibi farklı amaca yönelik ortamlar oluşturarak API yaşam döngüsünü yönetmek.

Development

Geliştirme ortamı. Yeni özelliklerin geliştirildiği ve test edildiği ortam.

Test

Test ortamı. Geliştirilen özelliklerin kapsamlı testlerinin yapıldığı ortam. Donanımdaki kaynakların yeterliliğini ölçmek için de kullanılır.

Sandbox

Sandbox ortamı. Ürün bitmiş ve son kullanıcıya çıkmadan önce gerçek kullanıcıyı simüle etmek için kullanılır. Production sürecini etkilemeden ve üretim sürecine yakın olarak güvenli test yapabilme imkanı sağlar.

Production

Üretim ortamı. Canlı sistemin çalıştığı ortam. Son kullanıcıların kullanımı için tasarlanmıştır ve istemcilerin yükünü taşıyabilecek şekilde yapılandırılır.
Önemli Farklar:
  • Test environment ve sandbox environment arasındaki fark: Ürün (API Proxy ya da Uygulama), geliştirme sürecinde test etmek için test environment, ürün bitmiş ve son kullanıcıya çıkmadan önce gerçek kullanıcıyı simüle etmek için sandbox environment üzerinde etkin hale getirilir.
  • API Proxy’nin kullanım amacına göre ilgili roldeki ortama kurulum gerçekleştirilir. Aynı API Proxy farklı amaçlar için farklı ortamlar üzerinde etkinleştirilebilir.
  • Her bir ortam diğerlerinden bağımsız olarak çalışır.

​
2. Kaynak İzolasyonu

Çok kaynak tüketen API’leri gruplandırarak izole çalışmalarını sağlamak, böylece diğer API’lerin performansının kötü etkilenmesine engel olmak.
Örneğin, yüksek trafikli API’ler bir ortamda, düşük trafikli API’ler başka bir ortamda çalıştırılabilir. Bu sayede kaynak kullanımı optimize edilir.

​
Ortam Bileşenleri

Bir ortamda aşağıdaki bileşenler bulunur:
Apinizer Platformu’ndaki ortam kavramı, Kubernetes ortamındaki Namespace kavramına karşılık gelmektedir. Her ortam Kubernetes’te bir Namespace olarak oluşturulur.
API Proxy’lerin çalıştığı pod’lar. Apinizer Platformu’nun çekirdek (core) modülüdür, tüm API isteklerinin Backend API’ye yönlendirilmesinden sorumludur ve Policy Enforcement Point olarak çalışır.
Dağıtılmış önbellek pod’ları. Apinizer’da gerek duyulan cache değerlerinin tutulduğu ortamdır.
API Integrator görevlerinin çalıştığı pod’lar. Entegrasyon işlemlerini yönetir.
Environment Service (Ortam servisi), Environment Deployment’da yer alan Apinizer Worker pod’una erişebilmek için oluşturulur. Servis, tüm podlara gelen istekleri karşılayan katmandır. Konum olarak podların önünde yer alır. Varsayılan olarak NodePort kullanılmakta ve bunun haricindeki servis tipleri Apinizer tarafından desteklenmemektedir.
Oluşturulan ortamdaki tüm API Trafiğinin ve isteklerin loglanacağı log sunucularına (örneğin Elasticsearch kümesi) bağlantı sağlayan konnektörlerdir.
Access URL, Proxy’nin dış erişim adresidir. https://<your-IP-address> şeklinde belirtilir. Dışarıdan erişim adres bilgisi kullanılarak Proxy’lere mesaj gönderilebilir.

​
Ortam Türleri ve Protokoller

​
Ortam Türleri

Bir ortam oluştururken Test veya Üretim (Production) türlerinden biri seçilir. Bu tür, lisans yönetimi ve kaynak tahsisi açısından önemlidir.

​
İletişim Protokolü Türleri

Ortam oluştururken aşağıdaki iletişim protokollerinden biri seçilebilir:
  • HTTP: Standart HTTP protokolü
  • gRPC: Yüksek performanslı RPC protokolü
  • HTTP+WebSocket: HTTP ve WebSocket protokollerinin birlikte kullanımı

​
Ortam Erişim Adresi

Bir API Proxy’e, dağıtıldığı ortamın erişim adresi üzerinden erişilebilir.

​
Erişim Adresi Yapısı

Bir API Proxy’nin erişim adresi şu şekildedir: 
http://demo.apinizer.com/apigateway/myproxy
BileşenAçıklama
http://demo.apinizer.com/Ortam Erişim Adresi
apigateway/Root Context
myproxyAPI Proxy Relative Path

​
Erişim Adresi Yapılandırması

Ortam için tanımlanacak erişim adresi genelde, WAF veya Nginx gibi bir load balancer’da tanımlanan DNS adresidir. Apinizer’da tanımlanan ortamlar Kubernetes’te bir namespace’e karşılık gelmektedir. Namespace içinde çalışan Apinizer Worker’larına erişim için Apinizer tarafından otomatik bir NodePort tipinde Kubernetes servisi oluşturulmaktadır.

​
Ortam Yönetimi

​
Ortam Oluşturma

Yeni bir ortam oluştururken şu bilgiler tanımlanır:
  • **Tür **: Test veya Üretim (Production)
  • İletişim Protokolü Türü: HTTP, gRPC veya HTTP+WebSocket
  • **Ortam Adı **: Ortamı tanımlayan benzersiz isim (Kubernetes’teki namespace’e karşılık gelir)
  • Anahtar (Key): Ortama özgü kısaltılmış bir anahtar
  • Node Listesi: Ortamın hangi Kubernetes sunucularında çalışacağı
  • Proje (Project): Ortamın kullanılabileceği projeler (boş bırakılırsa tüm projelerde kullanılabilir)
  • Erişim URL Adresi (Access URL): Ortam içinde çalışan API Proxy’lerin dış erişim adresi
  • Gateway Sunucusu Erişim URL’si: Apinizer Yönetim konsolunda yapılan konfigürasyonların Gateway Pod’larına yüklenebilmesi için gerekli olan nodeport veya ingress tipindeki servis erişim adresi
  • Kaynak Limitleri: CPU ve RAM limitleri
  • Ayarlar: Ortama özgü konfigürasyonlar
  • Açıklama: Yönetim kolaylığı ve önemli notlar için kullanılabilir
Detaylı ortam oluşturma ve yönetimi için Gateway Runtime’ları sayfasına bakabilirsiniz.

​
API Proxy Yükleme

API Proxy’ler, bir veya birden fazla ortam üzerine yüklenebilir. Aynı API Proxy farklı ortamlarda farklı versiyonlarıyla çalışabilir.
Önemli Notlar:
  • İstemcinin API Proxy’e erişebilmesi için en az bir ortama dağıtılmış olması gerekir.
  • Kurulumu yapılan ortam ya da ortamların hepsi bir küme (cluster) içinde yer alır ve Apinizer Platformu’nun kurulu olduğu sunucular üzerinde çalışır.

​
Proje ve Ortam İlişkisi

Projeler ve ortamlar farklı kavramlardır:
  • Proje: Mantıksal organizasyon birimi (hangi API’ler birlikte çalışır?)
  • Ortam: Fiziksel/kaynak birimi (API’ler nerede çalışır?)
Bir projedeki API Proxy’ler farklı ortamlara yüklenebilir: 
Proje: E-Ticaret API'leri
├─ Development Ortamı
│  ├─ Product API v1.0
│  └─ Order API v1.0
├─ Test Ortamı
│  ├─ Product API v1.1
│  └─ Order API v1.1
├─ Sandbox Ortamı
│  ├─ Product API v1.2
│  └─ Order API v1.2
└─ Production Ortamı
   ├─ Product API v1.2
   └─ Order API v1.2
Ortam oluştururken, ortamın hangi projelerde kullanılabileceği belirlenebilir. Eğer proje seçimi boş bırakılırsa, ortam tüm projelerde kullanılabilir.

​
Ortam ve Kubernetes Namespace İlişkisi

Apinizer Platformu ile oluşturulan tüm ortamlar Kubernetes altyapısında çalışmaktadır. Her ortam, Kubernetes’te bir Namespace’e karşılık gelir: 
Apinizer Ortamı → Kubernetes Namespace
├─ Development → apinizer-dev
├─ Test → apinizer-test
├─ Sandbox → apinizer-sandbox
└─ Production → apinizer-prod
Bu yapı sayesinde:
  • Ortamlar arası izolasyon sağlanır
  • Kaynak kullanımı kontrol edilir
  • Erişim kontrolü yapılabilir
  • Ölçeklendirme yönetilebilir

​
Sonraki Adımlar

Proje Nedir?

Proje kavramını öğrenin

API Proxy Nedir?

API Proxy kavramını öğrenin

Gateway Runtime'ları

Gateway Runtime oluşturma ve yönetimi

Deployment Modelleri

Deployment modellerini inceleyin