![]() I’m sure many of you reading this have, at some point, had multiple configuration entries in your application for your datasource in each environment, I know I have. A Datasource StoryĪ good example (I find) of externalized configuration is for a datasource. That way, the image you build doesn’t change throughout each environment, only the configuration that gets injected into it.īy using a ConfigMap, you ensure you keep your application image the same in every environment, you abstract your application configuration away from the application itself and you have a specific, separated resource to manage that configuration. One key enabler of this is to externalize your configuration. One of the best things about building containerised applications, is it gives you the ability to ensure your application operates consistently in each environment. Within each environment, resources are likely to be different, even from the most basic aspects such as datasource endpoints. If we’re building applications in the right way, most production grade services will have gone through various environments before finally being deployed into production. ![]() However, it can become difficult when you have a lot of configuration that you want to abstract, on the one hand, you want to abstract that configuration to separate the concerns between the application and the resource management, on the other, you don’t want the resource definition (manifest file in Kubernetes) becoming overly verbose and unreadable.ĬonfigMaps in Kubernetes are a great way of abstracting your configuration values away from your application, and also decoupling your configuration from your image, which ensures your application is more portable.Ī great usage of ConfigMaps is to externalize your Spring Boot configuration away from your application. Defining environment variables within a manifest file is really useful, as it allows you to abstract configuration values away from the application you’re building. Similarly to Docker Swarm, you can define environment variables for your Kubernetes Pods and Deployments within those manifest files. In Kubernetes, everything is a resource, and you manage those resources through manifest files. ![]() You can define environment variables in the stacks files which are then passed to the running containers. In Docker Swarm, you deploy services via a stack file, this is very similar to docker-compose for those familiar with that approach. One of those challenges was how to externalize the Spring Boot configuration within the Kubernetes cluster, I’d thought it would be similar to Docker Swarm, but there were several differences I found along the way. My previous experience has primarily been with Docker Swarm up until this project, so it’s been an interesting switch with different challenges. I’ve recently been working on a project where we’re writing Spring Boot microservices, which are being deployed into a Kubernetes cluster. Kubernetes is an open source container management and orchestration system, which makes it quick and easy to deploy and manage those production grade applications. Spring Boot is a widely used JVM-based framework which allows you to build out stand-alone, production grade applications. Spring Boot and Kubernetes go hand in hand when building modern microservices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |