On Tue, Jan 30, 2018 at 6:25 AM, Dilan Udara Ariyaratne <[email protected]> wrote:
> Hi Imesh, > > +1 to this suggestion. > > My personal experience is that even our users find it confusing to see > dockerfile definitions for a product or product profile in multiple > repositories. > Thus, it would be quite intuitive to have a single source of truth per > each product or product profile in the relevant docker-<product> repository > from this point onward. > And with the level of generalization that we have reached now in > dockerfile definitions, my gut feeling is that we can use the same > definition for any container platform without any specializations even in > future. > Thanks Dilan for your thoughts! On Tue, Jan 30, 2018 at 11:08 AM, Lakmal Warusawithana <[email protected]> wrote: > > > On Mon, Jan 29, 2018 at 7:36 AM, Imesh Gunaratne <[email protected]> wrote: > >> ... >> 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 Lakmal! Yes, let's do that! Will keep the platform specific Dockerfiles for the time being. As we progress with the POC scenarios we should be able to get a better picture. Thanks Imesh > > >> 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 <+94%2071%20428%209692> > Blogs : https://medium.com/@lakwarus/ > http://lakmalsview.blogspot.com/ > > > -- *Imesh Gunaratne* WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: https://medium.com/@imesh TW: @imesh lean. enterprise. middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
