Spring Config Server Yönetimi
Bu konuyla birlikte aslında iki yazıdan oluşan bir seri düşündüm; ilkinde yani bu yazıda, config server nedir? neden ihtiyaç duyulur? ve beraberinde ise projeyi dockerize hale getirip, Spring ile implementasyonundan bahsedip bir sonraki yazıda Gitlab’de CI/CD Pipeline ile birlikte AWS’ye deploy kısmına değineceğim. Merak edenler için amazon kısmındaki stack şu şekilde olacak. Dockerize edilmiş image’ı ECR (Elastic Container Registry)’ye pushlayıp ECS(Elastic Container Service) ile yöneteceğiz.
Neden Config Server Kullanmalıyız?
Büyük ölçekli bir monolitik api uygulamanız olduğunu düşünün ve bütün gerekli config bilgileri (postgre - elasticsearch - redis vs.) uygulamanın içerisinde tanımlı.
- Herhangi bir config bilgisini değiştirmek için deploy çıkmak zorunda kalacaksınız ve deploy süreniz uzun ise bu sizin için eziyet olacak.
- Tanımlı config bilgileri ekipteki herkes tarafından görünür ve/veya değiştirebilir olacak.
Yukarıdaki durumları önlemek için, beraberinde mikroservis gibi yapılarda esneklik ve tek yerden yönetim sağlamak için config server kullanmak büyük kolaylık sağlayacaktır.
Config Server nedir?
Config server, http tabanlı bir api ile, ilgili config bilgilerinin (veritabanı kullanıcı adı, parolası gibi) herhangi bir git tabanlı sağlayıcı üzerinden paylaşıldığı bir uygulama olarak düşünebiliriz.
Yazının buradan sonrasını spring üzerinden ilerleteceğm.
Aşağıda gördüğünüz gibi EnableConfigServer notasyonunu eklediğimizde bu uygulamanın bir config server olduğunu spring’e bildirmiş oluyoruz.
Config server’ın application.yml dosyasını aşağıda görebilirsiniz.
test ve canlı ortamlarınızın config değerleri farklı repoda olacağı için, yml dosyasında belirtilen değerleri environment variable olarak atamak mantıklı olacaktır. Config değerlerinin git tabanlı bir sistemde tutulması gerektiğinden bahsetmiştim. Github, gitlab veya bitbucket olabilir. Diyelim ki gitlab üzerinde tutuyoruz. Burada belirtilen username ve password gitlab’de repoya erişen kullanıcının bilgileri olacaktır ve repo name ise ortama bağlı config değerlerinin bulunduğu reponun adı. Örneğin test ortamı için gerekli config değerlerini qa-configs reposunda tutuyorsunuz dolayısıyla build aşamasında CONFIG_GIT_REPO_NAME değerini qa-configs olarak setlemeniz gerekir. Aşağıda 3 ortam için ilgili config bilgilerinin bulunduğu repoları görebilirsiniz. prod-configs reposu canlı ortama ait değerlerin olduğu repo, bu repoya erişimi sınırlandırmak isteyebilirsiniz. local-configs reposunda işe development esnasında local ortamınıza ait değerleri koyabilirsiniz.
Bu yapıda birçok microservice kullandığınızı göz önünde bulundurursak, örneğin; qa-configs reposu içerisinde her bir microservice’in qa ortamına özel değerleri barınmalı. 3 adet microservice’inizin olduğunu düşünürsek, her bir servisin ismi (spring.application.name)-qa.yml olarak belirtebilirsiniz. Mesela score service’ini qa ortamında ayağa kaldırdığınızda score-service-qa.yml dosyasından değerleri okuyacaktır.
Yazının başında projeyi dockerize hale getireceğimizden bahsetmiştim, config server’ın application.yml dosyasıda verdiğimiz environment variable’ları docker’ı run ederken parametre geçeceğiz.
Docker build alarak docker imajını çalıştırmak için hazır hale getirebiliriz. Bu yazıyı çok uzatmamak adına, bir sonraki yazıda AWS’nin ECR (Elastic Container Registry) servisine build edilmiş docker imajını push’layacağız ve ECS (Elastic Container Service) ile pushladığımız docker imajını ortam bazı (qa/prod) ayağa kaldıracağız.
Dockerize projeyi ayağa kaldırmak için docker build ve run komutlarına buradan erişebilirsiniz.
Son olarak toparlamak gerekirse, mevcut api uygulamalarınızda ortam bazlı tuttuğunuz bilgileri tek yerden güvenli ve hızlı bir şekilde değiştirebilir yapmak istiyorsanız config server kullanmak tutarlı olacaktır.
Umarım açıklayıcı bir anlatım olmuştur, aklınıza takılan bir kısım olursa aşağıya 👇 yorum bırakabilirsiniz.
