Hi Paul, Thank you for your thoughts, inline ... On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort <p...@marcospec.com> 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? - 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. > 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. > 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. > 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). 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. > > We also lose Java version and OS dependency problems - if OFbiz > deployments were standardized in a containerized world, then the OFBiz > tested image will always have the correct versions of everything in it, so > next time a Heartbleed like vulnerability is discovered that affects > OS-level components like OpenSSL, upgrading becomes trivial. > > Odoo (formerly OpenERP), arguably the main OFBiz competitor, is already on > Dockerhub and has their automated builds publishing their images > automatically have a look at how they are doing it: > https://hub.docker.com/r/_/odoo/ <https://hub.docker.com/r/_/odoo/> > > —P > > > On Jan 24, 2017, at 10:35 AM, Todd Thorner <tthor...@infotinuum.com> > wrote: > > > > For those OFBiz end users who might be interested, there exists a free > (with registration) e-book that covers containerizing traditional > applications. I haven't read it yet, so this can't be a direct endorsement. > > > > > > http://info.nirmata.com/containerizing-traditional- > apps-ebook?hsCtaTracking=09d8e4bd-2cfa-401f-8534- > 90f19e6ba312|3ddcaf2a-01e7-4ea7-9adb-2ba1c7033753&__hstc=52585783. > 0993e39ff53fa9e412248fb800e32a02.1485203112635. > 1485203112635.1485203112635.1&__hssc=52585783.1.1485203112635&__hsfp=null > <http://info.nirmata.com/containerizing-traditional- > apps-ebook?hsCtaTracking=09d8e4bd-2cfa-401f-8534- > 90f19e6ba312|3ddcaf2a-01e7-4ea7-9adb-2ba1c7033753&__hstc=52585783. > 0993e39ff53fa9e412248fb800e32a02.1485203112635. > 1485203112635.1485203112635.1&__hssc=52585783.1.1485203112635&__hsfp=null> > > > > > > > > On 17-01-17 12:34 PM, Paul Mandeltort wrote: > >> CoreOS goes hand-in-hand with Docker - it’s designed for deploying > Docker on production bare metal servers. > >> > >> I’ve been experimenting with CoreOS for our internal servers and > overall it’s an awesome OS simply because updates and security are > architected in. Keep in mind it’s designed for cloud deployments so getting > it going the first time is a bit tricky. > >> > >> CoreOS is just a lightweight cloud-scalable replacement for your bare > metal OS layer. It’s just as compatible with OFbiz as any other Linux OS. > If it runs the JVM well, it’ll run OFBiz well (generally speaking, this is > an optimistic simplification). I haven’t completed any significant > validation testing on CoreOS yet but so far I don’t see any major > showstoppers. > >> > >> So a modern in-house stack might look like: > >> Bare Metal Server > >> Virtualization OS (Xen, VMware, VirtualBox, etc) > >> CoreOS for Docker Host OS (or Ubuntu or CentOS or RancherOS) > >> Docker > >> Application Docker Image > >> Debian/Ubuntu/Alpine essential OS components > >> JVM - OpenJDK > >> Tomcat > >> OFBiz Application Layer > >> Database Docker Image > >> Debian/Ubuntu/Alpine essential OS components > >> PostgreSQL > >> Data over NFS to NAS appliance or cloud hosting disk > >> Web Proxy Image (apache/nginx) > >> Debian/Ubuntu/Alpine essential OS components > >> Bare Metal NAS appliance (no point in virtualizing data stores, just > adds overhead). > >> Sounds complex, but the major paradigm shift here is packaging up the > OS specific components with your release and version-controlling the system > as a whole rather than just the application layer component. In this new > model, you deploy specific versions of OFBiz with a specific version of the > JVM, a specific version of the application OS, and even a specific version > of the database. Moving a Docker image to a cloud host is very easy now, > so you can easily have your developers working on the complete versioned > stack on their machines, check the whole stack in to github/dockerhub, > deploy it to your test servers, then just slap those docker images live on > your cloud hosts once everything is verified with no surprises. > >> > >> If I was working on a new deployment, going cloud-hosted for everything > is a no-brainer these days. > >> > >> The paradigm that the entire industry is rushing towards is treating IT > resources (servers, OSs, deployments, etc) as cattle, not pets: > >> http://cloudscaling.com/blog/cloud-computing/the-history- > of-pets-vs-cattle/ <http://cloudscaling.com/blog/ > cloud-computing/the-history-of-pets-vs-cattle/><http:// > cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ < > http://cloudscaling.com/blog/cloud-computing/the-history- > of-pets-vs-cattle/>> > >> > >> If OFbiz were to get behind this paradigm (and this is a whole > different discussion probably for the developers but I’m just advocating > from an end user’s point of view), we could easily decouple the heavier > components and have them versioned as docker images separately. For > example, an OFBiz release would be a collection of docker images - one for > SOLR, one for Postgres, one for Tomcat, and one for the OFBiz application > layers. > >> > >> —P > >> > >>> On Jan 17, 2017, at 1:41 PM, Todd Thorner <tthor...@infotinuum.com > <mailto:tthor...@infotinuum.com>> wrote: > >>> > >>> Great stuff, thanks. > >>> > >>> Have you any opinion on leaping straight toward something like > CoreOS? Is the difference mostly a matter of codebase maturity, or is it > something more fundamental to the design/architecture which might leave > docker as being more compatible with OFBiz? > >>> > >>> > >>> - Todd > >>> > >>> > >>> > >>> On 17-01-17 10:23 AM, Paul Mandeltort wrote: > >>>> Hey guys, thought you’d be interested in a side project I’ve been > working on to smooth out our devops. One of the biggest pain points for me > in OFbiz development and deployment (as an end user) is managing the > complex dependencies and differences between JDK’s, OS’s, hardware > platforms, etc. Docker solves all of these problems. > >>>> > >>>> Even spinning up a demo of OFBiz is needlessly complicated in a world > where I can hop on the app store and have an application as complex as > Apple Xcode installed on my local with one click. > >>>> > >>>> Docker is as big of a revolution as virtualization for development > and deployment, and is taking over the IT dev-ops and development world. > >>>> > >>>> I noticed several other OFBiz docker projects on dockerhub but none > of them have been updated for the 16.11.01 release. > >>>> > >>>> Have a look here - I preloaded a copy of the ofbiz 16.11.01 release > with the demo data for immediate download and execution. You can start up > ofbiz in under 5 minutes now (Depending on your internet bandwidth). This > is ideal for any folks evaluating ofbiz or want a quick copy to hack at. > >>>> > >>>> https://hub.docker.com/r/marcopinball/ofbiz-demo/ < > https://hub.docker.com/r/marcopinball/ofbiz-demo/><http > s://hub.docker.com/r/marcopinball/ofbiz-demo/ <https://hub.docker.com/r/ > marcopinball/ofbiz-demo/>><https://hub.docker.com/r/ > marcopinball/ofbiz-demo/ <https://hub.docker.com/r/ > marcopinball/ofbiz-demo/><https://hub.docker.com/r/ > marcopinball/ofbiz-demo/ <https://hub.docker.com/r/ > marcopinball/ofbiz-demo/>>> > >>>> > >>>> If you already have docker installed, > >>>> > >>>> docker run -d -p 8080:8080 -p 8443:8443 marcopinball/ofbiz-demo:latest > >>>> > >>>> This downloads and runs a image preloaded with OpenJDK8, Debian > Linux, and the out-of-the-box demo and derby database components > pre-compiled and loaded, with the JVM pre-tweaked to 2GB Xmx. > >>>> > >>>> Grab a cup of coffee while it loads, then > >>>> > >>>> https://localhost:8443/ should be ready to roll! > >>>> > >>>> Would love to see an official OFBiz repo w/ automated builds on > Dockerhub. I’m still experimenting and learning with which volumes to > expose for data retention/configuration. Right now the entityengine.xml > config path is expose so theoretically you can feed your own > entityengine.xml in there and attach this instance to a different database. > >>>> —P > >
