In API Manager K8s artifacts, what we have followed is not having an image-per-profile method. With the introduction of Config Maps, it has become only two base images - for APIM and Analytics. Its extremely helpful from the maintenance PoV that we have a single set of Dockerfiles, but has a tradeoff with automation level AFAIU, since the user might have manual steps to perform.
Its would be still possible to to write a wrapper script for a single set of Dockerfiles so that we can copy the artifacts, etc. using a single Docker image, but still that script would need to be maintained. What if we go for a hybrid mode - not using Dockerfile per product profile or a single set of Dockerfiles for all, but use a specific set of Dockerfiles for a platform (Kubernetes, DC/OS, etc.)? Also we need to be open for any other platform that would need to support in future. 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 <077%20374%202057> > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > -- 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
