+1 to this idea in general. Before this change, the Dockerfiles had the puppet apply command hardcoded. A user did not need a puppet installation in the local machine since the Dockerfile commands are run in a temp container. But still the puppet related complexities (puppet related directory structure is required, etc.) were there. With the proposed approach, any configuration method is possible via the extension points mentioned in the above mail, which makes it easy to try out WSO2 Docker images locally.
On Thu, Mar 31, 2016 at 3:22 PM, Chamila De Alwis <[email protected]> wrote: > Hi, > > As described in the Isuru's email [1], wso2/dockerfiles[2] structure was > simplified to enable a single Docker image per WSO2 product. At the same > time, the approach that was used to build the Docker images was changed > from Puppet to an extensible approach. > > Earlier only a "puppet apply" method was used to build the Docker images. > The Puppet modules from wso2/puppet-modules[3] were copied at the build > time into the build container and a puppet apply was executed to configure > the product. This approach created a dependency on Puppet, that was not > necessary. Dockerfiles should not be dependent on a single build approach. > > Therefore, this step was changed in a way that allowed user defined > provisioning methods to be used when configuring the WSO2 product in the > Docker image. wso2/dockerfiles will ship "default" and "puppet" > provisioning methods. > > [image: Inline image 1] > > The default provisioning method simply copies the JDK and the product pack > in to the Docker image. The Puppet provisioning method offers the previous > Puppet related configuration option. > > Users can introduce their own provisioning methods. For example if a user > already has a set of Chef recipes to configure a WSO2 product, they can > include the relevant validations (image-prep.sh) and config commands > (image-config.sh) in <DOCKERFILES_HOME>/common/provision/chef folder and > pass "-r chef" to the build.sh helper script. > > The Dockerfiles only enforces a single RUN layer approach to keep the > resulting image size to a minimum. When multiple RUN layers are used, > especially on the same files, the existing layers will get duplicated each > time to apply the changes, increasing the image size uncontrollably. > Furthermore, file copying, modification, and cleaning has to be done in a > single layer to minimize unnecessary persistence [4]. Therefore, any > provisioning method has to prepare and validate a folder to serve the > necessary files from, be it a folder with the JDK and the product pack, or > the PUPPET_HOME folder. The needed files can then be downloaded in the > config script when building the image and cleaned afterwards in the same > build container. > > [1] - [Docker] Creating a Single Docker Image for a Product - @architecture > [2] - https://github.com/wso2/dockerfiles > [3] - https://github.com/wso2/puppet-modules > [4] - [DEV][Dockerfiles] Reducing the image size - @dev > > Regards, > Chamila de Alwis > Committer and PMC Member - Apache Stratos > Software Engineer | WSO2 | +94772207163 > Blog: code.chamiladealwis.com > > > -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
