spring boot app configuration management

[Mihai Kulcsar]

Hi Lugers,

Here's my problem. I have a few hundred spring boot apps/services that
talk to each other and together they form this massive system. The
communication between the apps is either http based or kafka or they
talk to various databases. The communication is configured any way
Spring allows, property files, yaml files, etc.

What I need is a way to take all these apps and deploy them to an
entirely new setup and change the configurations to match the new
setup. In other words if I have app1 that talks to app2 when I deploy
the two apps in the new environment I was app1new to talk to app2new
instead of the app2 how it's configured in app1s' yaml. I know I can
override configs at deployment but my issue is identifying these
configs in an automated fashion for hundreds of apps and determining
what the new ones should be.

Did anyone run into a situation like this one? Any suggestions of
products available out there? My searches have failed me so far.

Thanks all for actually reading and reaching this point in the email.

[George Law]

Is this something you see happening once or do you see having to do it again and again?

Just once maybe you just hammer it all out manually but if it's something you see yourself doing more than once, the first thing that comes to my mind is using Kubernetes and containers/pods

You could use an internal network to handle all of the inter-container communication and then just expose the public ports to the whole network.  You should be able to build this all out in a cluster of containerized services once then just redeploy the whole thing X items.  The internal network ips shouldn't need to change so nothing there to reconfig.

I've been out of development for 10 years but I think that's the main concept but I'm kind of sketchy in the exact process involved but I think Ben 's done a few k8s presentations in the past that there may be videos of.

~George

--
You received this message because you are subscribed to the Google Groups "Upstate Carolina Linux Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uclug+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/CADJrChNzqCNqpvKz%2BqYsBkpDvvKj1yqb-Py0pwhOh4PVn1Jw_g%40mail.gmail.com.

~George Law

[Mihai Kulcsar]

Hi George,

Thanks for the reply. This is something that will be done again and
again and hopefully without my intervention. So me just doing them
once will not really help.

The requirement is that every service be independent and accessible
through http and by use of URI so I'm not sure how K8s would solves
this anyway since every new deployment gets a new URI even if there
are multiple pods hidden behind it. So a new deployment of app1 would
need o know of the URI of the new deployment of app2 and all that is
in configs.

Thanks again,
Mihai

> To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/CAKzfAU6THt0R3k%2BYCaHBb4sx%3DuqW7ERDBHDMcCtxdX%3DMUHetsQ%40mail.gmail.com.

[Derek Wright]

Check out Consul from Hashicorp. It can help with service discovery, service health, rendering templates with consul-templates and restarting services.

Sent from my iPhone

> On Jul 4, 2022, at 11:19 AM, Mihai Kulcsar <mih...@gmail.com> wrote:
>
> Hi George,

> To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/CADJrChPQocC%2BUOPLtDHMALFV%2BPNEjiDd5uQiw4fSabP8e-4oAw%40mail.gmail.com.

[Mihai Kulcsar]

Thanks, this looks promising. I'll have to look more into it.

To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/A088A226-0F43-4B01-89A5-D2EDBCA032EB%40gmail.com.

[Brian Kennedy]

I yell at developers for hardcoding BS at least once a week,  BUT,  using service discovery and your use case it's actually a good time to do it.  app1 connects to app2, it may as well connect to http://app2:8080/ and let k8s service discovery find it for you, or consul or, etc.. 

For containerizing springboot specifically, addressing non mesh endpoints:

1.  delete every dev.properties, qa.properties, etc..   Environment configuration does NOT belong in code.  if java even knows what environment it's in, it's wrong.

2. in the application.properties .. or application.yaml .  There is where you define the datasources you need as profiles.  user-db, service-api, etc..   just the name.

3. deployment settings for the container:   env:  SPRING_CONFIG_ADDITIONAL_LOCATION = "file:/where/you/mount/the/volume"    ex "file:/configmap"

4. in the deployed environment is where you configure those datasources.  a configmap in k8s, a secret for ECS, etc..   and mount that config as a volume in the containers deployed. 

configmap data:

  - key: application-user-db.profile

    value: |

      user-db.user=whatever

      user-db.pass=whatelseever

  - key: application-service-api.yaml

    value: |

      service-api.url=https://out.there.com/for-us

etc..

or using the default springboot datasource object?  whatever that's called:

   value: |

     spring.datasource.password=123!

To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/CADJrChMvs14ah5gGhPjOU_LZFGRex9YjS4f-y4o8y3BHyGojtQ%40mail.gmail.com.

[Mihai Kulcsar]

Thanks, that is where I was leaning into making everyone standardize configs so they are easier to predict.

You gave me some good ideas, thank you.

Mihai

To view this discussion on the web visit https://groups.google.com/d/msgid/uclug/CACYs%3D5_JgRP2UnWyB%2BrAEz5dq3hp7KYPtDGyUBiUM3pC_m0jDw%40mail.gmail.com.