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
- 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
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.
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.
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.
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 <[email protected]> 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 <[email protected]
>>> <mailto:[email protected]>> 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/><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/
>>>> <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
