Hi Imesh, It is very convenient if we can reuse the docker image. AFAIU if we follow the above approach we can use a single docker image in all the container platforms.
One of the drawbacks I see with this approach is that the user has to update the volume mounts with the necessary jar files, JKS files, etc. If any user tries this approach in Kubernetes, he has to add those jar files and binary files to the NFS server (To the volume which holds NFS server data). This affects the installation experience. IMHO, we should minimize the effort in trying out the WSO2 products in Kubernetes or any container platform. Based on the user need, he can switch to their own deployment approach. Thank you! On Mon, Jan 22, 2018 at 1:36 PM, Imesh Gunaratne <[email protected]> wrote: > Hi All, > > Currently, we build Docker images for each platform (Docker, Kubernetes, > DC/OS, etc) for each WSO2 product profile (EI: Integrator, MB, BPS; API-M: > Gateway, Key Manager, Pub/Store, etc). AFAIU, the main reason to do this > was bundling platform specific JAR files (membership scheme JAR file for > clustering) and platform specific filesystem security permission management > (mainly for OpenShift). > > With the recent refinements we did in Dockerfiles, Docker Compose > templates we found that the same set of Docker images can be used in all > container platforms if we follow below approach: > > - Create the product profile Docker images by including the product > distribution, and the JDK. > - Provide configurations using volume mounts (on Kubernetes use > ConfigMaps) > - Provide JAR files and other binary files using volume mounts > - Use a standard permission model for accessing volume mounts in > runtime: > - Use a none root user to start the container: wos2carbon (uid: 200) > - Use a none root user group: wso2 (gid: 200) and add wso2carbon > user to wso2 group > - Grant required filesystem access to wso2 user group to the > product home directory > - Use wso2 user group (using gid: 200) to provide access to the > volume mounts in runtime: > - On Kubernetes we can use Pod Security Policies to manage these > permissions > - On OpenShift this can be managed using Security Context > Constraints > - On DC/OS volumes can be directly granted to user group gid:200. > > Really appreciate your thoughts on this proposal. > > Thanks > Imesh > > -- > *Imesh Gunaratne* > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Senior Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
