On Mon, Jan 29, 2018 at 7:36 AM, Imesh Gunaratne <[email protected]> wrote:
> On Mon, Jan 29, 2018 at 6:58 AM, Muhammed Shariq <[email protected]> wrote: > >> Hi Imesh / all, >> >> Personally, I think the best option going forward is to maintain a single >> set of docker image across all platforms. It's true that there is a concern >> of users having to do more work, but in reality, user's will have do quite >> a lot of config changes such as copying jdbc drivers, create key stores and >> update hostnames etc right? As long as we provide a clean option, which is >> using volume mounts or in k8s case config maps, we should be good. >> >> For the evaluation / demo case, users can use the docker-compose >> artifacts that's already preconfigured and ready to go. >> >> While it might seem attractive to maintain images per platform, I think >> it would be very costly and hard to maintain in the long run. In the >> future, we would have to do things like running some scans etc on the built >> images before making it available to pull. Having to identify issues across >> many different platforms and fixing them one by one would be cumbersome. >> >> I would suggest we go with a single set of images for all platforms and >> then create per platform images if the need arises. >> > > I completely agree with Shariq! > > The reason for starting this thread was that when we started creating > DC/OS Docker images we found that we can simply use the Docker images > created in the product Docker Git repositories (github.com/wso2/docker- > <product>) without making any changes except for adding user group id for > managing volume permissions (which would be common for any container > platform). > > This model will allow us to efficiently manage WSO2 Docker images by only > creating one image per product version (in EI and SP there will be one per > profile) and use those on all container platforms by following above best > practices. Most importantly, it will work well when releasing > updates/patches. > > Regarding the concern of having additional steps for copying files to > volumes, let's do a quick POC and see whether we can find a better way to > overcome that problem in each platform for evaluation scenarios. > > @Lakmal: Would you mind sharing your thoughts on this? > > Lets do a POC and then decide. IMO we should not kill optimization by doing generalization. Users point of view, they need optimized dokcer image for orchestration platform > Thanks > Imesh > >> >> >> >> On Mon, Jan 22, 2018 at 5:30 PM, Imesh Gunaratne <[email protected]> wrote: >> >>> On Mon, Jan 22, 2018 at 2:46 PM, Pubudu Gunatilaka <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>> >>> Thanks for the quick response Pubudu! Yes, that's a valid concern. With >>> the proposed approach user would need to execute an extra step to copy >>> required files to a set of volume mounts before executing the deployment. >>> In a production deployment I think that would be acceptable as there will >>> be more manual steps involved such as creating databases, setting up CI/CD, >>> deployment automation, etc. However, in an evaluation scenario when someone >>> is executing a demo it might become an overhead. >>> >>> I also noticed that kubectl cp command can be used to copy files from a >>> local machine to a container. Let's check whether we can use that approach >>> to overcome this issue: >>> https://kubernetes.io/docs/reference/generated/kubectl/kubec >>> tl-commands#cp >>> >>> On Mon, Jan 22, 2018 at 3:03 PM, Isuru Haththotuwa <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>> >>> Thanks Isuru for the quick response! What I meant by image per profile >>> is that, in products like EI and SP, we would need a Docker image per >>> profile due to their design. >>> >>>> >>>> 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. >>>> >>> >>> A good point! I think it would be better to have a one to one mapping >>> between the Docker images and the Dockerfiles to make it easier for users >>> to understand how Docker images are built. >>> >>>> >>>> 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. >>>> >>> >>> Yes, I think that's what we have at the moment and with that approach >>> every other container platform we need to support we need to create a new >>> set of Docker images. >>> >>> Thanks >>> Imesh >>> >>>> >>>> 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 <+94%2071%20635%208048>* <http://wso2.com/>* >>>> >>>> >>>> >>> >>> >>> -- >>> *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 >>> >>> >> >> >> -- >> Thanks, >> Shariq >> Associate Technical Lead >> > > > > -- > *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 > > -- Lakmal Warusawithana Senior Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
