Hello Eugen and all,
I like the initiative and I am convinced this is a forward-looking approach. As you have read in the comment from Pierre the hurdle to overcome is the external dependency injection of e.g. database connectivity as configuration maps at runtime. In my company in Kubernetes stacks we are solving that by maintaining a config map of RDBMS connectivity per application stage and region and deploy that. The app then reads the config information at container startup. When taking the regular OFBiz approach, though, you would need to know at build time to which stage (Staging, production, Development) and which region you are going to deploy, which will be a bit of an overkill if you want to leverage the full flexibility of a cloud-based deployment which typically comes with variance on DB connection strings. Alternatively, you would need to unpackage certain release artifacts and rewrite them as part of the deployment process, which might be an antipattern on Helm. Could that be overcome and dynamic DB connection string be used somehow? Warm regards Carsten --- Dr. Carsten Schinzer *Inhaber* t +49 89 88569642 | f +49 89 99964059 | m +49 159 05269462 DCS Verkaufssysteme Gerner Str. 27 | 80638 München | Germany Am Do., 1. Juli 2021 um 10:57 Uhr schrieb Pierre Smits < pierre.sm...@gmail.com>: > Hi Ioan, > > My apologies for the late reaction. > > IMO we can forget about the Derby route for this. Derby is not production > grade, and often adopters/implementers already have their preferred RDBMS > for production in play or decided upon. Configuration of such is the > entityengine.xml file, and deployment of such for the various > environments/instances like UAT or PROD can easily managed and deployed via > VCS. > > Best regards, > Pierre Smits > > > On Sun, May 9, 2021 at 9:13 PM Eugen Stan <eugen.s...@netdava.com> wrote: > > > > > > > Hello, > > > > NOTE: I previously sent this email from an un-subscribed email address, > > please ignore that one. > > > > I'm working on a Helm chart for OFBiz > > https://github.com/ieugen/charts/tree/main/ofbiz . > > > > The goal is to have OFBiz running in Kubernetes. > > > > Right now it's a rough start: it starts OFBiz with Derby and that's > > about it. > > > > I'll keep pushing updates as soon as I have them. > > > > I'm interested in your feedback. > > If you plan on testing it and using it let me know. > > I do accept and encourage collaboration. > > > > If this is interesting I might push it upstream but it uses the binary > > build of OFBiz in Docker. > > > > > > I'm using docker images built from trunk on jdk-11. > > There are amd64 and arm64 (Raspberry PI4) images. > > > > Some issues that need solving are the many configuration files that > > OFBiz has. > > > > This details creates a lot of configuration when deploying in Docker / > > Kubernetes as they need to be mounted in a volume with many entries or > > multiple volumes. > > > > There are many potential solutions to this but it boils down to: > > * It would be nice to load max 1-2 or 3 configuration file with multiple > > sections instead of the currently many configs split over the code base. > > * It would be nice to support configuration (overwrite) via ENV vars for > > some things like DB connection. > > > > > > Regards. > > Eugen > > >
