Hi Joao, We have already done this for API Manager v3.0.0 pattern-1 and you can find those artifacts in [1]. We are planning to release this officially for APIM v3.1.0 in the coming weeks.
[1] - https://github.com/wso2-incubator/wso2am-k8s-operator Thank you! On Sat, Feb 15, 2020 at 9:47 PM Joao Emilio <[email protected]> wrote: > Have we moved forward with this initiative? > > Regards, > > *João Emilio* > Solutions Architect | WSO2 > > E-mail: [email protected] <[email protected]> > Phone: + 55 11 3847 8967 > Web: http://www.wso2.com > > <http://wso2.com/signature> > > > On Sun, Oct 20, 2019 at 4:45 AM Pubudu Gunatilaka <[email protected]> > wrote: > >> Hi, >> >> Adding @architecture <[email protected]> public mailing list. >> >> The objective of this project is to remove complexities that users face >> while deploying WSO2 products in Kubernetes. The approach is to introduce >> custom resources for each product for deploying that product in K8s. For >> example, once you have deployed the relevant K8s operator in K8s you can >> use the following commands to bring up the simplest product pattern in K8s. >> >> Option 1: >> >> kubectl create -f apim.yaml >> >> >> apiVersion: wso2.com/v1alpha1 >> >> kind: APIManager >> >> metadata: >> >> name: "cluster-1" >> >> spec: >> >> pattern: Pattern-1 >> Option 2: >> >> kubectl add apimanager cluster-1 >> >> >> >> With these commands, you can bring up an API Manager Pattern-1 deployment >> in K8s. >> >> Already released K8s operators for micro integrator and Siddhi are >> basically focused on product functionality. From these CRDs what we expect >> is to focus on deploying WSO2 products in K8s. >> >> >> Thank you! >> >> >> >> On Fri, Oct 18, 2019 at 3:32 PM Keshiha Jeyatharan <[email protected]> >> wrote: >> >>> Our project is Creating WSO2 Products CRD for Kubernetes to effectively >>> deploy WSO2 Products (APIM, IS, EI, SP) in Kubernetes, starting with the >>> very first product WSO2 API Manager. Here is the overall diagrammatic >>> depiction of the project. >>> >>> >>> >>> >>> >>> The following are the controller artifacts where we deploy those at the >>> installation step. For each pattern (1,2,3,4) of API Manager, we will be >>> having preconfigured configurations and persistent volume claims with >>> relevant components defined for each pattern: >>> >>> - >>> >>> API Manager (Publisher, Store, Traffic Manager) >>> - >>> >>> Key Manager >>> - >>> >>> Gateway >>> - >>> >>> API Analytics >>> - >>> >>> MySQL >>> >>> >>> >>> In the controller artifacts, we will be having deployment-specific >>> common artifacts and product-specific artifacts. >>> >>> >>> 1. >>> >>> Deployment-specific-configmap >>> >>> Defines the common specifications such as replicas count, livenessProbe >>> and readinessProbe, etc. >>> >>> 1. >>> >>> Apim-deployment-specific-configmap >>> >>> Defines the APIM related only configurations such as memory, CPU, image, >>> etc. >>> >>> >>> The final outcome will be, the user being able to execute either 1 of >>> the below commands to run WSO2 API Manager. The 2 commands are: >>> >>> 1. kubectl create -f apim.yaml >>> >>> >>> apiVersion: wso2.com/v1alpha1 >>> >>> kind: APIManager >>> >>> metadata: >>> >>> name: "cluster-1" >>> >>> spec: >>> >>> pattern: Pattern-1 >>> >>> 2. kubectl add apimanager cluster-1 >>> >>> >>> >>> Also if they want to deploy other patterns, it can be done by the >>> following commands >>> >>> kubectl add apimanager cluster-2 --pattern=pattern-2 >>> >>> kubectl add apimanager cluster-3 --pattern=pattern-3 >>> >>> kubectl add apimanager cluster-4 --pattern=pattern-4 >>> >>> >>> >>> Once we deploy the custom resource, it will create deployment, service, >>> and ingress for the deployment. Also, controller acts as a template, >>> where all the required values are fetched from the relevant Config maps. >>> >>> >>> - >>> >>> When the users need to update the specifications in config map and >>> persistent volume, they can Override the defined configmaps and >>> persistent >>> volume claims. >>> - >>> >>> If they want to create totally new config maps and persistent volume >>> claims, it is possible via adding new configmaps and persistent volume >>> claims >>> - >>> >>> Also if the users want to update the deployment-specific >>> configurations such as replicas, livenessProbe etc. it can be done by >>> overriding the relevant deployment-specific configurations for a single >>> deployment or for all deployments. >>> - >>> >>> Finally, it is also possible for a user to deploy a completely new >>> deployment pattern with a new yaml file. >>> >>> >>> Also, the documentation about this project can be found in this link >>> <https://docs.google.com/document/d/1XBpdvjGUwqD8ojUBr1EYLMWTUEWkw_vgWDq4DSa3MsY/edit?usp=sharing> >>> . >>> >>> Thank you! >>> >>> >>> -- >>> Keshiha Jeyatharan | Intern Engineering | WSO2 Inc. >>> (m) +94 76 926 9011 | (e) [email protected] >>> >> >> >> -- >> *Pubudu Gunatilaka* | Associate Technical Lead | WSO2 Inc. >> (m) +94774078049 | (w) +94112145345 | (e) [email protected] >> <http://wso2.com/signature> >> >> -- *Pubudu Gunatilaka* | Technical Lead | WSO2 Inc. (m) +94774078049 | (w) +94112145345 | (e) [email protected] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
