Hi Paul and everyone:

Two quick notes on your feedback:

1- You can improve your docker file by symlinking the log to stdout, this
way you can view logs with the simple command "docker logs containeridhere"

2- I tried docker as a development platform, and it doesn't really fit that
environment very well. There are too many problems like setting up the IDE,
user permissions, gradle cache issues and so on not to mention that if you
rely on postgres then you must have a docker-compose.yml file. The feedback
loop is also longer and a bit awkward. So perhaps I would not go as far as
saying we should remove derby and only use docker with postgres. For me I
tried that and it wasn't a very smooth experience.

On Fri, May 18, 2018, 3:27 AM Paul Mandeltort <p...@marcospec.com> wrote:

> Probably out of scope for me and the mailing list to sell you on the
> benefits of containerization, but (in my crappy opinion) there’s a reason
> that docker is valued at over a billion dollars and all major cloud hosting
> providers support containers natively now. I think it’s built into some
> linux distros now.
>
> I encourage you to try it out and see for yourself:
>
> 1) install docker: https://docs.docker.com/install/ <
> https://docs.docker.com/install/>
> 2) docker run -d -p 8080:8080 -p 8443:8443 marcopinball/ofbiz-demo:latest
> 3) if you want to monitor logs:
>         docker ps, find container ID
>           docker exec -ti <container id> tail -f
> /ofbiz/runtime/logs/ofbiz.log
> Ta-da, running ofbiz with demo data on https://localhost:8443.
>
> When done just docker rm -f <container id> the container and it’s gone! no
> cleanup and your system remains unaffected.
>
> This is just OOTB w/ Derby. Want to quickly test ofbiz against a different
> version of java? Just edit the dockerfile (below) and point it at the java
> image you want, and run.
>
> This works on Mac, Linux, Windows.
>
> Here’s the docker file and image I slapped together (referenced above) as
> a proof of concept. IT SHOULD NOT BE CONSIDERED BEST PRACTICES OR
> PRODUCTION READY. Again, I am not an expert here.
>
> It may or may not be best practices but it’s a good starting point for
> anyone else messing with it:
> https://hub.docker.com/r/marcopinball/ofbiz-demo/ <
> https://hub.docker.com/r/marcopinball/ofbiz-demo/>
>
> —Paul
>
> > On May 17, 2018, at 13:44, Mathieu Lirzin <mathieu.lir...@nereide.fr>
> wrote:
> >
> > Hello Paul,
> >
> > Paul Mandeltort <p...@marcospec.com <mailto:p...@marcospec.com>> writes:
> >
> >> STRONG +1 here as an end user.
> >>
> >> Having a solid tested reference implementation would save man years of
> >> time in development, testing, and deployment especially for small
> >> teams that are weak in the devops department.
> >>
> >> I started playing with this but it’s a back burner project right now.
> >>
> >> A proper set of docker images and a reference docker compose
> >> architecture based around Postgres would be ideal going forward. Then
> >> SOLR could also be managed as a docker image. One of the biggest new
> >> user pain points for ofbiz is figuring out how to switch the database
> >> to a real dbms.  We could then just drop support for derby as the only
> >> reason it’s there is that it supposedly saves time for testing ofbiz.
> >> Docker Postgres solves that problem and is the clear standard for open
> >> source databases now.
> >>
> >> Making docker ofbiz the standard starting point also eliminates all
> >> the cross platform java headaches which I see at lest a post or two a
> >> week about.
> >>
> >> It would also accelerate adoption, development, and save everyone
> >> money long term as it makes it super easy to fire up and iterate
> >> ofbiz.
> >
> > I don't think this kind of incantative tone serves your cause.
> >
> > Being enthousiastic about a technology is one thing but pretending it
> > will make everything easy, agile, allow everyone to save money, and
> > avoid headaches sounds more like bullshit...
> >
> > IMHO some code, facts, measurements and an enonciation of the necessary
> > tradeoffs would be more convincing.
> >
> > --
> > Mathieu Lirzin
> > GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>
>

Reply via email to