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
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/>
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> 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/>>
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
