On Thu, Mar 24, 2016 at 9:36 AM, Chamila De Alwis <[email protected]> wrote:
>
> The suggested design change covers the first approach, however if we are
> dropping the Puppet support (I'm seeing Puppet based configuration of the
> image only in the profile specific images), we are not going to cover the
> second approach. Therefore, IMO we should additionally support a standard
> automated configuration approach as well, like the design we had initially.
>
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. 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
- 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
[1]
https://github.com/imesh/docker-for-java/blob/master/tomcat-webapp/Dockerfile
Thanks
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Wed, Mar 23, 2016 at 1:49 PM, Imesh Gunaratne <[email protected]> wrote:
>
>> Hi All,
>>
>> Recently after a discussion we had with Lakmal and the PaaS team, we
>> reduced the size of the WSO2 Docker images by combining multiple RUN
>> instructions, removing the puppet modules COPY command and by removing the
>> wso2/base docker image. Afterwards we thought of redesigning the way we
>> create Docker images to optimize it's build process and the usage.
>>
>> What we thought was to create two sets of Docker images for WSO2 products:
>>
>>
>> 1. WSO2 Product Base Docker Images
>> - This is to package the vanilla distributions of WSO2 products in
>> Docker images.
>> - These would not contain any configurations or artifacts but the
>> JDK, product distribution and a bash script to start the server.
>> 2. WSO2 Product Docker Images with Configurations and Artifacts
>> - These would be created based on the WSO2 product base docker
>> images by adding configurations and deployable artifacts on top.
>> - Configurations can be added manually or using a configuration
>> management system such as Puppet, Chef, Ansible, etc.
>> - Depending on the deployment pattern, different product profiles
>> would be generated.
>>
>> The following diagram shows two sample sets of Docker images and how they
>> are tagged:
>>
>>
>>
>> Following are the main reasons for taking this approach:
>>
>> - Reduce the image size to the maximum possible level
>> - Reduce the time it takes to build a custom WSO2 product docker
>> image (with configurations and artifacts)
>> - Adhere to the standards used by the Docker community
>>
>> Please share your thoughts on this. We are planning to update the WSO2
>> Dockerfiles repository according to this model.
>>
>> Thanks
>>
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.io
>> Lean . Enterprise . Middleware
>>
>>
>
--
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.io
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
