The Dockerfiles for the vanilla/base Docker images are shipped mainly because of the restriction on redistribution of the JDK. Other than that, the main function of the wso2/dockerfiles repository would be to provide tooling to ease customization and extension of the Dockerfiles.
When it comes to possible workflows, there can be two main approaches. 1) Image extension, where the user pulls/builds the vanilla image, and try new customization by overriding configuration (ex: mounting patched files), then persists the resulting container to an image (writing a new Dockerfile using the vanilla image as the base or docker commit). The build time would be minimal, however the image size is controlled by how the user chooses to extend the image. 2) Automated configuration approach, where for example the user has a deployment pipeline where new configuration is persisted in a configuration automation tool, which triggers a new Docker image build, and subsequent rolling updates in the runtime. Build time can be longer than expected, however the size can be optimized. 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. 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. 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
