[ += Architecture ] On Thu, Jul 20, 2017 at 2:57 PM, Isuru Haththotuwa <[email protected]> wrote:
> Hi Dilan, > > Apologies for the delayed response. > > A couple of changes that I can think of: > > - Rather than using Puppet to build the Docker images, use a simple > copy based approach. > - IMHO using puppet to build docker images is an overkill. We can > have one product base images, and build the images relevant to product > specific deployment patterns extending from the base image. > - Without using an intermediate set of scripts do build docker > images (currently we have our own docker build, run scripts), let the user > directly use Docker API for building images, running them, etc. > - For a Docker user its more natural to use the Docker API. > Additionally, there would be no need to maintain our own build scripts. > > Please share your thoughts. > I have started this effort for APIM the new deployment patterns discussed > in thread [1] in APIM group, and the WIP artifacts can be found at [2] and > [3]. Note that these artifacts are not finalized. > > [1]. API-M perf results to share with a customer > [2]. https://github.com/isurulucky/docker-apim/tree/new-deploymen > t-patterns > [3]. https://github.com/isurulucky/kubernetes-apim/tree/new-deplo > yment-patterns > > On Thu, Jul 13, 2017 at 7:56 PM, Dilan Udara Ariyaratne <[email protected]> > wrote: > >> >> ---------- Forwarded message ---------- >> From: Dilan Udara Ariyaratne <[email protected]> >> Date: Thu, Jul 13, 2017 at 7:48 PM >> Subject: [Architecture] [Kubernetes] Improving Kubernetes Deployment >> Support for WSO2 Products >> To: architecture <[email protected]> >> >> >> Hi All, >> >> I am currently working on $subject. Initial idea is to deliver a fully >> automated, stable Kubernetes deployment experience for the end users of >> both WSO2 EI and APIM products >> such that during the process, we can understand how we can improve >> Kubernetes-common, the base Kubernetes deployment enabling layer as its >> platform. >> >> Earlier with our old product strategy, we did maintain a repository >> called, kubernetes-artifacts >> <https://github.com/wso2/kubernetes-artifacts> where all the product >> specific artifacts were also kept. >> >> Now, we have split this out in to two levels, namely >> [1] kubernetes-common <https://github.com/wso2/kubernetes-common> - base >> Kubernetes deployment enabling layer >> [2] kubernetes-<product-label>, i.e. for example, kubernetes-ei - >> Product specific kubernetes artifacts that integrates with kubernetes-common >> >> However, with our new product strategy and architectural changes, most of >> the product-specific kubernetes artifacts are not yet done and WSO2 EI, >> WSO2 APIM are two such products. >> >> While there is an on-going effort by Isuru (Isuruh) on finalizing >> kubernetes-apim related deployment artifacts, I will be working on >> kubernetes-ei related artifacts >> as an effort to improve Kubernetes Deployment Support for WSO2 Products. >> >> As mentioned above, during this process, we will be also accessing ways >> of improving Kubernetes-common layer for a much-developer friendly >> framework in building >> more customer centric production ready kubernetes deployment artifacts >> with very minimum effort. >> >> Thanks, >> Dilan. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> > > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048 <071%20635%208048>* <http://wso2.com/>* > > > -- 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
