On Mon, Jan 29, 2018 at 6:58 AM, Muhammed Shariq <sha...@wso2.com> 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? Thanks Imesh > > > > On Mon, Jan 22, 2018 at 5:30 PM, Imesh Gunaratne <im...@wso2.com> wrote: > >> On Mon, Jan 22, 2018 at 2:46 PM, Pubudu Gunatilaka <pubu...@wso2.com> >> 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 <isu...@wso2.com> >> 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 <im...@wso2.com> 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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
