Hi All,
With respect to "container-based" deployment patterns related to EI,
following were identified as the first set to be supported and are
currently under development.
Pattern 1: Standalone Integrator Profile with external DB,
Scalable, But Minimum High Availability Cluster for
Integrator Profile with external DB
Pattern 2: Standalone MB Profile with external DB,
Scalable, But Minimum High Availability Cluster for MB
Profile with external DB
Pattern 3: Standalone BPS Profile with external DB,
Scalable, But Minimum High Availability Cluster for BPS
Profile with external DB
Pattern 4: Standalone [ Integrator Profile + EI Analytics Profile ] with
external DB,
Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for EI Analytics Profile ]
with external DB
Pattern 5: Standalone [ Integrator Profile + MB Profile ] with external
DB,
Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for MB Profile ] with
external DB
Pattern 6: Standalone [ Integrator Profile + EI Analytics Profile + MB
Profile ] with external DB,
Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for MB Profile + High
Availability Cluster for MB Profile ] with external DB
Please add and correct, if I have missed any.
Thanks,
Dilan.
*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
On Mon, Jul 24, 2017 at 8:46 AM, Dilan Udara Ariyaratne <[email protected]>
wrote:
>
> Hi Isuru and Imesh,
>
> On Thu, Jul 20, 2017 at 7:20 PM, Imesh Gunaratne <[email protected]> wrote:
>
>>
>>
>> On Thu, Jul 20, 2017 at 6:06 AM, Isuru Haththotuwa <[email protected]>
>> wrote:
>>
>>> [ += 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.
>>>>
>>>>
>> ​+1 Isuru! We also had an offline discussion on this with Lakmal. Better
>> to make usage of Puppet optional for K8S based deployments.
>>
>
> I am also +1 to the idea that we should totally decouple Puppet from
> Docker as well as K8s and treat each of these separately as they cater
> different layers of the deployment spectrum.
>
> When it comes to a "deployment pattern", each product pack participating
> in that deployment pattern, has some specific configuration to use.
>
> Configuration can also differ depending on the fact that deployment is
> hosted in a container-based environment or not.
>
> We can support automating both these environments either by using
> [1] a simple copy based approach, [2] puppet or any other configuration /
> artifact update mechanism that we may bring in future.
>
> IMO, we can keep this layer totally decoupled from either the Docker or
> Kubernetes layers and what we can expect as the output, would be a fully
> configured product pack to cater a specific deployment pattern.
>
> Once the pack is there, we can use it directly at the docker layer to
> build an image as the output and that image will then be an input to the
> K8s layer to host the specific deployment pattern for which it was built.
>
> WDYT?
>
> Thanks,
> Dilan.
>
>
>> Thanks
>> Imesh​
>>
>>>
>>>> -
>>>> - 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 <+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
>>
>>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
