Hi Imesh, Please find my comments inline.
On Thu, Mar 24, 2016 at 10:11 AM, Imesh Gunaratne <[email protected]> wrote: > May be you did not get the reason for doing this change properly. We are > not dropping support for Puppet or any other orchestration management > system for automating the configuration. > +1, we should keep the Puppet workflow, as a workflow enabling method. > One high level this is the idea of this change: > > - Say we want to create a Docker image to run a Java web app on > Tomcat. Following is the standard used by the Docker community: > - Pull the Tomcat base Docker image from Docker Hub. This Tomcat > Docker image does not have any configurations. It's equal to Tomcat > vanilla > distribution. > - Write a Dockerfile to package the Java web app based on the above > Tomcat image [1]. This image can contain any configurations or artifacts > needed. > - Build the new Docker image and run > > Yes, this is what I meant in the first workflow. With the proposed change this scenario is covered well. > > - We are trying to build a similar model for WSO2 products. The only > difference is that we cannot publish our base product Docker images to > Docker Hub at the moment due to Oracle JDK licensing issue. > > > - The reason why we don't use Puppet for building the base product > Docker images is that, we do not need to have any configurations in those > images. > > > - If any organization need to use Docker for running WSO2 products > what they need to do is following: > - Clone WSO2 Dockerfiles repositiory > - Build base product Docker images by adding the JDK and the > vanilla product distributions. > - Import them into a central Docker registry. > - Build their own WSO2 Docker images with the required > configurations and artifacts using the profile Dockerfiles provided (in > the > same repository). > - Afterwards use those Docker images on standard Docker, Mesos, > Kubernetes or any other container cluster management system that > supports > Docker. > > Furthermore, I think the term "base image" for the vanilla image we are >> going to ship is not correct. It can be used out of the box, although with >> limited space to work with all the functionality. >> > > I tend to disagree, base images cannot be used OOB for a real use case. > This is due to many reasons: > > - There will be zero configurations in base product images. > - As a result any registry databases, user management databases will > not be configured configured. > - A server cluster cannot be setup without setting proxy ports > > The "base" images can be started and run in the standalone mode, although not production readily. Usually base images are used to collect common configurations, not runnable products. However it's naming issue, so I guess we can go with the existing terminology. Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Software Engineer | WSO2 | +94772207163 Blog: code.chamiladealwis.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
