On the Solr, I guess Paul wants to separate read/write in some cases. Besides this, we also use Solr to offer exchange data to/from other systems (middle database), as an EDI interface as well.
-----邮件原件----- 发件人: Paul Mandeltort [mailto:[email protected]] 发送时间: 2017年1月25日 7:05 收件人: [email protected] 主题: Re: OFBiz 16.11.01 docker demo-data image 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
