Hi Eugen, My personal use cases for using Docker and Ofbiz are: - Development workflow. - Production and test builds incorporating custom plugins. - Use as part of immutable infrastructure.
== Development workflow I often use docker containers when testing PRs, but building a complete docker image with demo data loaded is time consuming process. To reduce build time I checkout trunk and then build a base docker image using my workspace with all demo data loaded into the integrated Derby database. I then checkout the PR and build a second docker image which extends from the first image, incorporating the differences introduced by the PR. Because the changes from the PR are normally small and don't require a change to demo data, building this second docker image is a very quick process. I can then quickly spin up a container based on the second image and test. Once testing is complete I can kill the container, knowing that I have an unmodified set of demo data still resident in the base image. Using docker for development builds and testing works well for me since I can isolate any tools needed for an ofbiz build in the container, rather than needing to install them on my development host. The approach of keeping development tools in containers has been working well across a variety of projects for me targeting java, javascript/typescript, node.js, sass, php, etc. Docker has been incredibly useful for creating environments for developing WordPress sites. Here [1] is a docker-compose project used for building a wordpress theme for a local brewery [2], tested against a MySQL database, Apache running with TLS certificates, and a gulp process running to detect changes to and compile SCSS to CSS. The good thing about the above is that as soon as I stop working on one project I can tear down any associated resources (such as DB and HTTP servers) and move on to the next project. == Production and test builds I want to be able to create custom ofbiz docker images incorporating client-specific plugins. For a recent project I was able to spin up a Virtual Private Server and deploy to it customised ofbiz images which included my client's plugin and data. Deployments would be triggered by check ins to either the ofbiz-framework repository or to the custom plugin's repository. Automatic deployments to the server meant the client could get regular updates on the project's process and support their decision making on were to focus development next. The test environment was supported by the Traefik reverse-proxy (also running in a container) which handled certificate updates with LetsEncrypt and could restrict access to Ofbiz by IP address. Having a way to more easily create these docker images with Ofbiz would be very helpful to me. I can then publish images to a private client-specific registry, allowing the client to pull the image into their on-premises production infrastructure. == Immutable infrastructure I often need to support clients while having limited access to their production environment. Normally because they are located some distance from me and remote-access to their on-premises infrastructure is often difficult to arrange. Therefore having builds of client-specific software which can be treated as part of their immutable infrastructure is very helpful. As mentioned above, I can create client-specific docker images and deploy them to test environments. Once a test build is approved by a client they should be able to pull that image and have it useable within their production environment with the minimum of fuss. This means any local configuration needs to be externalised from the docker image, using environment variables or configuration files bind-mounted into the running ofbiz container. When new versions of ofbiz are available, the client should be able to pull the latest docker image and have it operational with existing configuration, assuming there are no incompatibilities with the latest version. This might make deploying security updates to previous ofbiz releases easier for users. We could package up variants of ofbiz as docker images which contain everything needed to run, including database drivers that have been tested by the community and are considered 'supported'. Users of the docker image can then be confident that they have all components needed to run ofbiz without further downloads needed. This could be useful for air-gapped deployments where manual steps are required to bring data onto a network. Once the relevant docker image is imported, ofbiz can be used on air-gapped systems. Docker images containing demo data in a Derby database can be produced and deployed to demo hosts. This would allow users to run demonstration versions of ofbiz themselves without building, but might make administration of our demo environments easier. Couple this with a reverse-proxy like Traefik and we'll be able to run multiple demo versions on a single host. [1] https://github.com/danwatford/wb-wp-docker-compose [2] https://wantsumbrewery.co.uk/ On Tue, 1 Dec 2020 at 18:28, Eugen Stan <eugen.s...@netdava.com> wrote: > Hi, > > There has been some discussion regarding Docker and OFBiz, however no > consensus yet. > I'm starting this thread after discussions on Slack with Jacques Le > Roux, Daniel Watford and Michael Brohl. > > The the aim to establish some goals / objectives regarding Docker and > OFBiz. > > Please add your feedback, comments and suggestions. > > Prior work regarding this is found > > https://issues.apache.org/jira/browse/OFBIZ-10407 > > https://lists.apache.org/thread.html/r40fd679818a37e113b469add51755b1097a2b02d3961e71a2cfe928d%40%3Cdev.ofbiz.apache.org%3E > > and in the links stemming from the links above. > > ---- > > == How can we integrate Docker in OFBiz ? > > Docker can be used in two distinct ways: > > a. Use Docker as a way to build OFBiz components - this will make builds > more portable - as long as people have Docker (or containerd or podman) > installed locally, they will be able to build OFBiz "for sure" (tm). > > This aims to solve the issue of people not having the proper JDK and > required tools installed (gradle, git ?! etc). > > b. Use Docker to deploy OFBiz for production purposes (and demos) > IMO this means building a slim Docker image with only JRE and OFBiz + a > custom selection of plugins. IMO this is best achieved with pre-built, > published binaries for ofbiz. > > c. Use Docker to develop / debug OFBiz > I'm not sure if this is really a thing since IMO falls into b). > > > Using docker multi stage image builds is something that could help. > > The goals are sometimes at odds with one another in the sense that doing > something to fix a goal will hinder the other. > > Do you see other use-cases for Docker and OFBiz? > > > == My personal take > > Personally I would like to focus on b). I did not have good experience > with building sources with Docker - I could not get used to the workflow. > > Also when I deploy to production, I don't really care how it's built as > long as I have the binary and I can run just that. > > So we might end up with two or more Dockerfiles, each focusing on > specific objectives. > > > > Regards, > -- > Eugen Stan > +40720 898 747 / netdava.com > -- Daniel Watford
