Deploying WSO2 products in Google Container Cloud

This blog explains the steps of deploying WSO2 products in Google Container Cloud.


More info can be found in following WSO2 Official documentation.

Kubernetes Artifacts

Dockerfiles Documentation

Puppet Modules

1) Download and Install

Google Cloud SDK 

kubectl 

2) Subscribe

Subscribe to 'Google Cloud Trial'

3) Setup / Configure

i) A container cluster

WHAT : This is the cluster of container hosts.

HOW :

• Go to Google Container Engine 

• Create a container cluster. (Change the machine type and node count if you need)

ii) kubectl 

WHY : kubectl should be configured with Google Container Cloud, so that the kubectl commands can be invoked against the cloud.

HOW : Instructions can be found by clicking on 'connect' on container cluster entry we just created in the previous step.

4) Git Clone

IMPORTANT : Please make sure you checkout a release tag of these repos since the master branch would contain not production ready RnD stuff.

i) https://github.com/wso2/kubernetes-artifacts

WHAT : The repo of services and replication controllers for WSO2 products

ii) https://github.com/wso2/dockerfiles

WHAT : Docker files to build WSO2 product images.

iii) https://github.com/wso2/puppet-modules

WHAT : Puppet scripts to deploy WSO2 products in a host.

WHY : These puppet scripts are used by the docker files to build an image with WSO2 product deployments.

5) Build Images

TWEAK :

WSO2 Kubernetes clustering scheme talks to the Kubernetes API to get node data. Because of the JVM version difference in WSO2 Docker Images (Java 7) and Google VMs (Java 8), we need to add the following line to PUPPET_MODULES_GIT_REPO/modules/<product>/templates/<version>/bin/wso2server.sh.erb  

-Ddeployment.security.SSLv2Hello=false \
-Ddeployment.security.SSLv3=false \
-Ddeployment.security.TLSv1=false \
-Ddeployment.security.TLSv1.1=true \
-Ddeployment.security.TLSv1.2=true \
-Dhttps.protocols=TLSv1.2 \

HOW : Refer to the 'Build Docker Images' section here.

6) Push the Images

HOW : Refer this 

7) Deploy Services and Replication Controllers

 

HOW :

• Go to KUBERNETES_ARTIFACTS_GIT_REPO/<product>

• ./deploy sh

TWEAK :

The image names in the deployed replication controllers are not valid in the Google Container Cloud env. So we have to amend the replication controller definitions to refer to the image names in the Google container registry.

We can do it from the Google Kubernetes Dashboard

Select 'View/edit YAML' of the desired replication controller.

Edit the spec/containers/image element with the correct image name.

e.g. gcr.io/dazzling-bruin-148110/wso2am-kubernetes:1.10.0

In order to make the change effective you can scale the nodes to 0 and then scale up.

8) Open Firewall Ports

WHY : By default the ports of Google cloud nodes are closed for traffic from outside.

HOW : Go to Networking -> Firewall rules section and add a rule to expose the desired ports.

WSO2 App Manager 1.2.0 - How to use custom app properties in ReST APIs

WSO2 App Manager supports defining and using custom properties for app types. In order to add new custom property, the relevant RXT file (registry extension) and couple of other files should be amended. But these custom properties are not marked as 'custom' properties  in any place. Once defined they are treated just like any other another field.  

With the introduction of the new ReST API implementation in App Manager 1.2.0, it was bit of challenging to expose these custom fields through APIs. The new ReST APIs are documented using Swagger. So when the relevant API response models are defined, the custom fields can't be added as named properties since they are dynamic. So the solution is to have a field, which is a Map, to represent the custom properties. And the need of marking custom fields as 'custom' should be addressed too. 

In App Manager, this has been addressed by having another configuration to store the custom properties.

Where is the definitions file

In the registry there are JSON resources which are custom property definitions. There is a definition file per app type.

e.g. Definition file for web apps -  
         /_system/governance/appmgt/applicationdata/custom-property-definitions/webapp.json

What does a definition file look like

As of now the custom property definitions file only has the names of the custom properties.

e.g.
{"customPropertyDefinitions":[{"name":"overview_custom1"}]}

How do I persist these custom properties for an app using the ReST API

The request payload should contain the custom properties as below.

{
  "name": "app1",
  "version": "1.0",
  "isDefaultVersion":true,
  .
  .
  .
  "customProperties":[
    {
       "name":"overview_custom1",
       "value":"custom_property_1"
    }
  ]
}