• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Config injection and service discovery

 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings,

Currently, in the code (multiple very dependent on each other microservices running on AWS), we have a separate per environment configuration file.  All environment data needs to be entered into this file before building the code.

We need to get to immutable deployable artifacts. In order to do that we need a better mechanism for configuration management.

We need to decide the mechanisms to use for configuration management.

High level requirements:

be able to make changes without redeploying containers

be able to provide per environment or per service defaults

Any help will be appreciated!
 
Saloon Keeper
Posts: 22784
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's not really enough information.

I have built environment-insensitive applications since long before containers and cloud computing. JEE web applications, for example, get their configuration information (per the standard) from 2 deployment descriptors. There's a server-independent deployment descriptor, which is the webapp's [tt]/WEB-INF/web.xml[/i] data. And the server-dependent deployment descriptor that, as its name indicates, is specific to the particular instance and type of deployment. Tomcat, for example, uses a Context XML element. By leverating this, I can use the exact same WAR on my desktop, on Beta test machines, and in Production. Which means that if Production fails, I don't have to worry about there being something different in the compiled classes that would prevent trying to re-0ccreate the fault in a test/diagnostic environment.

Configuration for non-java apps under Linux typically goes in an '/etc/" file or directory. When containerizing such a setup, one generally aliases it to an external mountpoint. That's what my Bacula containers do, for example. Since the containers are not integral to the OS, the actual target here is /opt/bacula/conf", mappring to the container's internal /etc/bacula/ directory.

It's really pretty easy to do this kind of stuff and inject it as part of container deployment, regardless of which sort of container orchestration system you're using, be it Kubernetes, Docker Compose, or in my case, Ansible.
 
John Landon
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:That's not really enough information.

I have built environment-insensitive applications since long before containers and cloud computing. JEE web applications, for example, get their configuration information (per the standard) from 2 deployment descriptors. There's a server-independent deployment descriptor, which is the webapp's [tt]/WEB-INF/web.xml[/i] data. And the server-dependent deployment descriptor that, as its name indicates, is specific to the particular instance and type of deployment. Tomcat, for example, uses a Context XML element. By leverating this, I can use the exact same WAR on my desktop, on Beta test machines, and in Production. Which means that if Production fails, I don't have to worry about there being something different in the compiled classes that would prevent trying to re-0ccreate the fault in a test/diagnostic environment.

Configuration for non-java apps under Linux typically goes in an '/etc/" file or directory. When containerizing such a setup, one generally aliases it to an external mountpoint. That's what my Bacula containers do, for example. Since the containers are not integral to the OS, the actual target here is /opt/bacula/conf", mappring to the container's internal /etc/bacula/ directory.

It's really pretty easy to do this kind of stuff and inject it as part of container deployment, regardless of which sort of container orchestration system you're using, be it Kubernetes, Docker Compose, or in my case, Ansible.



Thanks but I really dont see a question to fill in the information in your answer. What you need to know in order to help? These are java apps running in AWS.... with spring boot
 
Tim Holloway
Saloon Keeper
Posts: 22784
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Spring Boot contains an embedded Tomcat or jetty webapp server. Normally, that would mean a Context definition, but I think that in the case of Spring Boot, you'd have to inject the property values you need as command-line parameters.

For authoritative general information on supplying external configuration to Spring Boot, this is the link:
https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config

For an example of configuring a database connection pool - which is one of the more common things you'd do in a Context, see this link:
https://www.baeldung.com/spring-boot-hikari

To inject environmental information into a docker container, you can use the Docker run "-e" flags. If you don't want to inject each element individually, you can inject the location of an external config file or directory (such as my /opt/bacula/config) and setup the container's internal command line/run script to use the information in that file/directory.
 
Yeah, but does being a ninja come with a dental plan? And what about this tiny ad?
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic