Full disclosure, I am relatively new to docker and containerization technology, and only have deployments on my staging servers at the moment, so my main goal here is to just facilitate discussion and get the group thinking about it from an end/user small-shop ops perspective! :-)
> On Jan 24, 2017, at 3:04 PM, Taher Alkhateeb <[email protected]> > wrote: > > Hi Paul, Thank you for your thoughts, inline ... > > On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort <[email protected]> wrote: > >> Just skimmed it. It’s an excellent overview for folks familiar with IT ops >> and virtual environments and covers some of the key architectural bits. >> >> As it applies to OFbiz, I foresee containerized ofbiz deployments to look >> like: >> >> - Application Container >> - Base OOTB OFBiz container >> - User-specified plugins/extra layers >> - Company-specific logic and code layer >> - Search Engine Container >> - SOLR and related configurations >> > > Hmmm, why a container here? Why not just a regular plugin pulled to the > code base? Assuming you’re talking about SOLR here? SOLR itself is a standalone service that can often grow and be partitioned on its own, it makes sense in the containerization ideology to keep that image separate and in its own application server. This also makes it easier to scale and optimize in deployment scenarios. I can recall several instances, at least in the Lucene days of OFbiz, where we had indexing configured incorrectly and accidentally triggered re-indexing operations that ended up consuming the entire application container and crashing/locking up the system (due partially to our lousy design). Pulling out this container and having it run separately makes the application more resilient, and lets administrators easily tweak performance priorities. > - Database Engine Container >> - A standard Postgres instance optimized for OFbiz >> - User-configured database configuration container >> - Demo-Data volume container >> - Standard data volume pre-loaded with OFBiz demo data >> > > Volume containers are sort of deprecated now. They were a work around in > the early days of Docker before managed volumes were introduced. In fact > managed volumes would make your life easier as you can quickly reset your > environment with: ./docker rm -fv $(docker ps -q) and that would remove > everything including the managed volumes. Agreed, my terminology was wrong. :-) I was referring to managed volumes. Either way having the database container separate means we can just switch the configuration (via configuration volumes which can also be managed) to point to Amazon RDS or existing company database infrastructure. Configuration management in OFbiz has always been a pain with the various .properties files running around everywhere. Locking all of that into a known good configuration image would greatly help deployments and versioning of systems. > >> As I understand it, the only reason OFBiz doesn’t ship OOTB in this >> configuration is that it’s a pain in the ass to configure and test quickly. >> I know I’ve wasted hours in the past setting up an instance of Postgres >> because I forget how to get Postgres ports configured correctly, or run >> into firewall issues on the linux host I’m using, or user accounts, or >> permissions, or whatever. Containers eliminate all of those problems. >> >> It’s theoretically possible to do a docker run apache/ofbiz:latest (I’m >> dreaming here, no official builds for ofbiz on docker hub, yet!) and have >> an entire IT-ready demo-data-pre-loaded system of ofbiz launch on any >> developer machine or production environment. >> > > Yeah that's very doable, the Dockerfile would be trivial too. We can start > from an image like "airdock/oracle-jdk", load gradle, pull dependencies > into cache, load data, and then set the CMD to ./gradlew ofbizBackground. > Probably /runtime should be exposed as a managed volume. This is basically what the demo-test Dockerfile I hacked together looks like. Still fiddling with which volumes to expose but the version I posted on docker hub exposes /ofbiz/runtime/data and /ofbiz/framework/entity/config. >> Architecturally, I’d like to put the idea out there that OFBiz should to >> switch to containerization from ground up. Having worked with OFBiz for >> some years now, all of the major pain points I’ve had with OFBiz have been >> related to configuration, deployment, and iteration speed. All of these >> issues are soundly addressed by containerization. If the OFBiz team jumps >> on this revolution, it could quickly spring to the forefront of ERP >> technologies since containerization is that powerful. >> > > I think the main value of containerization is standardization of deployment > and independence of machines and virtual machines, but not much more than > that. The pain is still here because we still need to "think" about > structuring our data and different deployment variations. I found it > painful to write some of the Dockerfiles for example, and also figuring out > all the docker commands needed to set things up correctly. Docker Compose > helps a little bit, but you're still left with lots of configurations to > sort out. Another enormous value is enable developers test entire system configurations on their local systems. For example, a developer could test a new version of Postgres, a new version of JDK, or switching out underlying OS components and have confidence that pushing that image to deployment will work much more smoothly. Doing these things on development machines is very time consuming! It also streamlines the developer->testing->staging->production workflow substantially and lets the entire deployment chain be managed in source code control via dockerfiles and docker-compose files. For deployment configuration management, there is a whole set of tools being developed. I’m most excited about Rancher right now, which can manage containers like services and can move containers between locally hosted VM hosts and cloud providers like Amazon from the same managed UI. Very exciting stuff. > >> In a containerized OFBiz world, we could lose Derby completely as it’s >> useless in production and only used because it’s easy to configure and >> deploy. Postgres has emerged as de facto standard Open Source database, and >> is scalable to enterprise applications but also packable OOTB now with >> Docker. >> > > Good idea, I thought about the same thing, replace derby with a production > scale DB in a container. Mind you, however, that people still need to learn > how to install Docker (not yet very trivial on Linux) and they also still > need to get comfortable with docker commands and concepts. It took me quite > some time to finally get the light-bulb on the real difference between > containers and VMs (VERY different). Docker installation is just about as trivial as any development tools installation on linux: https://docs.docker.com/engine/installation/linux/ubuntu/ <https://docs.docker.com/engine/installation/linux/ubuntu/> Just have to add a repo before the apt-get. It installs seamlessly on Windows and Mac OS machines, which at least in the US are still the most dominant end-user platforms from an ease-of-use perspective. Installing Docker on a Mac pretty much eliminates any advantages linux had over Mac, as now any linux tool is easily available from Docker now, and Docker for Mac installation is as easy as installing any other app - drag ’n drop. Can’t advocate it enough! Agreed that it’s a completely different world, but it opens up so much in terms of making it so much easier to manage the entire IT system. By the very definition of business, an OFbiz application never lives in a vacuum in production. I am advocating that all developers and administrators give it and the related technologies a look - there is a phenomenal amount of Silicon Valley investment going into this area of IT now and it is already as revolutionary as virtualization was. OFbiz, being open source and linux-based is phenomenally compatible with this new paradigm. > So in short, I think docker is an excellent tool, I would recommend though > taking an evolutionary approach instead of a revolutionary one. We can > start by defining some images on docker hub, maybe adding a Dockerfile into > the code base with updates to README.md for quick docker deployments, and > then we take it from there. Absolutely. The benefits and development speed-up are phenomenal though, hence why it’s worth looking into. —P
