Deploy an Application

Preconditions

• The application is registered already

When deploying an application we have the option to override certain fields, we call that a Patch, see below.

Via sipctl

Have you installed sipctl?

If you run the subcommands without the flags, you get informative help about them. Have a look at them for fine-tuning. Below are the recommended ones.

sipctl deploy <app-namespace>/<name> <deployment-namespace>/<deployment-name> -u Stable
sipctl update -n <deployment-namespace> <name>

name: The name of the application you want to instantiate, e.g. flowable

app-namespace: The namespace storing applications in your organisation, e.g. vseth-apps

deployment-name: The name of the new deployment being created

deployment-namespace: The target namespace where the deployment will be running

Implementation

Now you have created a new deployment.sip in the deployment-namespace. sip-manager will take care of creating resources (DBs, etc) and then create a deployment.apps from it which will spawn the pod finally running your container.

Patch Logic

In general a Patch overrides fields of a sip.yml.  If a field is single value such as the replicas or image field. This means that the complete field will be replaced. If the field is a list, it will try to merge the original list and the patch.

Patching Atomic Values

Patching atomic values is the simplest option. We will look at it using the example of replicas. It will simply set the field to the value specified in the patch. 

Example:

sip.yml:
---
ingress:
  - name: "http-default"
    subdomain: eule
    http:
      - path: /
        port: 80
replicas: 2

Patch:
---
replicas: 5

Result:
---
ingress:
  - name: "http-default"
    subdomain: eule
    http:
      - path: /
        port: 80
replicas: 5

Patching List

When patching lists it will append the new list elements in the patch. If the original sip.yml already has a list item with the same name, it will replace this item. It will not try to merge two list items with the same name. This applies to all Databases, the env field, the volumes, and s3.  Below is an example for the env field. 

Example:

sip.yml
---
env:
- name: TEST
  value: "hohooooo"
- name: TEST2
  value: "foo"
- name: TEST4
  value: "bar"

patch
---
env:
- name: TEST3
  value: "blub"
- name: TEST2
  value: "fooBar"

result
---
env:
- name: TEST
  value: "hohooooo"
- name: TEST2
  value: "fooBar"
- name: TEST4
  value: "bar"
- name: TEST3
  value: "blub"

Patching Ingress

In general Ingresses are merged the same way as other lists, but if there are two list items with the same name, we try to merge them. When a patch specifies an existing ingress, every field in the ingress struct will be replaced, except when it is not set.

Example:

sip.yml
---
ingress:
  - name: "http-default"
    subdomain: eule
    http:
      - path: /
        port: 80

patch
---
ingress:
  - name: "http-default"
    subdomain: eule2

result
---
ingress:
  - name: "http-default"
    subdomain: eule2
    http:
      - path: /
        port: 80

Patching Resources

We try to merge specified resources.  Only non nil patch fields are applied.