OFBiz 16.11.01 docker demo-data image

[marcopaul]

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

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

[Todd Thorner]

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

[marcopaul]

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 <[hidden email]> 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

[Todd Thorner]

That's some fantastic information, Mr. Mandeltort.  Thanks very much



- Todd


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 <[hidden email]> 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
>

[Sharan Foga]

Hi Paul

Thanks for sharing this. It sounds like something that could be very useful.  Would you be interested in creating a page on the wiki and adding these details as an option for potential users?

Thanks
Sharan

On 2017-01-17 19:23 (+0100), Paul Mandeltort <[hidden email]> 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.1 1.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/>
>
> 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

[Todd Thorner]

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 <[hidden email]> 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
>

[marcopaul]

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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

[taher]

Hi Paul, Thank you for your thoughts, inline ...

On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>
>

[marcopaul]

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 <[hidden email]> wrote:
>
> Hi Paul, Thank you for your thoughts, inline ...
>
> On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort <[hidden email]> 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

[Shi Jinghai-3]

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:[hidden email]]
发送时间: 2017年1月25日 7:05
收件人: [hidden email]
主题: 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 <[hidden email]> wrote:
>
> Hi Paul, Thank you for your thoughts, inline ...
>
> On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort <[hidden email]> 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

[Jacques Le Roux]

Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :
>   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.
And what about developers working on Windows like me? I'm not talking about Windows servers of course.

Jacques

[marcopaul]

Docker for Windows is out now, quick install, comes with everything you need to get going.

https://docs.docker.com/docker-for-windows/ <https://docs.docker.com/docker-for-windows/>

Requires Win10 Pro/64bit.

Try it, it’s amazing. Once you have that installed,

docker run -d -p 8080:8080 -p 8443:8443 marcopinball/ofbiz-demo:latest

and you will have a functional ofbiz demo up and running once it downloads. This is the quick Dockerfile/image I put together, I plan on getting it separated more soon for more manipulation.  

Or,
docker run -p 5432:5432 -e POSTGRES_PASSWORD=mypassword -d postgres

Boom, instant postgres server. Keep in mind containers don’t save state (images do) so if you restart a container you’ll lose data, so getting used to using volumes takes a bit but makes a ton of sense once you understand the archtitecture.

The Windows distro ships with Kitematic now, which is a great GUI for messing around and doing things like running and managing containers.  Give it a shot.

Docker caches images and containers intelligently, so subsequent image downloads are a LOT faster and your don’t run out of hard drive space like you do with lots of VM versions.  It’s game-changing technology for developers working on complex systems like OFBiz and has completely replaced VMs in my (albeit limited) development workflow.

—P

> On Jan 25, 2017, at 1:57 AM, Jacques Le Roux <[hidden email]> wrote:
>
> Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :
>>  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.
> And what about developers working on Windows like me? I'm not talking about Windows servers of course.
>
> Jacques
>

[Jacques Le Roux]

Le 25/01/2017 à 08:57, Jacques Le Roux a écrit :
> Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :
>>   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.
> And what about developers working on Windows like me? I'm not talking about Windows servers of course.
>
> Jacques
>
>
OK, I answer to myself, Docker needs Windows 10 and I don't want to give my data to Microsoft
https://docs.docker.com/docker-for-windows/

The subject is close for me, period. Actually for the moment since I read Microsoft is considering to revise its policy, let's see...

Jacques

[marcopaul]

Windows 10 Pro adds Hyper-V support which means the docker images run natively in Windows without extra VM overhead.

For Windows 7 & 8 you can install Docker Toolbox which contains an embedded install of VirtualBox VM environment.  Everything will run just fine, just not quite as snappy, but the configuration headaches and portability of the docker images far outweigh the performance drawback, which I doubt is horrible.

https://www.docker.com/products/docker-toolbox <https://www.docker.com/products/docker-toolbox>

This guide is pretty handy:
http://www.htpcbeginner.com/install-docker-on-windows-7-8-10/ <http://www.htpcbeginner.com/install-docker-on-windows-7-8-10/>

—P
 

> On Jan 25, 2017, at 2:03 PM, Jacques Le Roux <[hidden email]> wrote:
>
> Le 25/01/2017 à 08:57, Jacques Le Roux a écrit :
>> Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :
>>>  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.
>> And what about developers working on Windows like me? I'm not talking about Windows servers of course.
>>
>> Jacques
>>
>>
> OK, I answer to myself, Docker needs Windows 10 and I don't want to give my data to Microsoft
> https://docs.docker.com/docker-for-windows/
>
> The subject is close for me, period. Actually for the moment since I read Microsoft is considering to revise its policy, let's see...
>
> Jacques
>

[Jacques Le Roux]

Thanks Paul!

Jacques


Le 25/01/2017 à 21:42, Paul Mandeltort a écrit :

> Windows 10 Pro adds Hyper-V support which means the docker images run natively in Windows without extra VM overhead.
>
> For Windows 7 & 8 you can install Docker Toolbox which contains an embedded install of VirtualBox VM environment.  Everything will run just fine, just not quite as snappy, but the configuration headaches and portability of the docker images far outweigh the performance drawback, which I doubt is horrible.
>
> https://www.docker.com/products/docker-toolbox <https://www.docker.com/products/docker-toolbox>
>
> This guide is pretty handy:
> http://www.htpcbeginner.com/install-docker-on-windows-7-8-10/ <http://www.htpcbeginner.com/install-docker-on-windows-7-8-10/>
>
> —P
>  
>> On Jan 25, 2017, at 2:03 PM, Jacques Le Roux <[hidden email]> wrote:
>>
>> Le 25/01/2017 à 08:57, Jacques Le Roux a écrit :
>>> Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :
>>>>   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.
>>> And what about developers working on Windows like me? I'm not talking about Windows servers of course.
>>>
>>> Jacques
>>>
>>>
>> OK, I answer to myself, Docker needs Windows 10 and I don't want to give my data to Microsoft
>> https://docs.docker.com/docker-for-windows/
>>
>> The subject is close for me, period. Actually for the moment since I read Microsoft is considering to revise its policy, let's see...
>>
>> Jacques
>>
>
>