Page Comparison

...

Info
For a full walkthrough of setting up a FlexDeploy Container Project deploying to Kubernetes via Helm, check out this Getting Started guide.

When a project is being deployed to a K8s Cluster, FlexDeploy offers the ability to configure a Helm Chart and/ or deployment strategies Kubernetes Manifests for the deployment. Both configurations are done on the follow following tab:Image Removed

...

Field Summary

Name	Description	Notes

Deployment NameThis is the K8s deployment name. The field is

App Context

Optional Parameter for the application context uri if your deployment consists of a web application.

See K8s Monitoring for more information.

Deployment Name

This is the K8s deployment name. The field is a groovy script by default

so be sure to enclose literal strings in quotes.

Result after a deployment:

kubectl get deployments

NAME
springboot1.0.5

Manifests to deploy

Actual K8s manifest files for your deployment. Files will run from top to bottom.

Usually consists of a deployment.yaml and service.yaml. File paths can be absolute or relative to the

temp

artifacts directory.

To make use of the Deployment Name field above, your deployment.yaml should use FD_KN_DEPLOYMENT_NAME flexdeploy property and can

also use the FD_PROJECT_DOCKER_IMAGE_NAME property configured on the docker tab.

codetitle

languagetextthemeMidnightfirstline1

deployment.yaml

linenumbers

Code Block

true

language

collapse

text

true

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: ${{FD_KN_DEPLOYMENT_NAME}}
spec:
  replicas: 1
  template:
    metadata:
       labels:
         app: superapp
         fd_deployment_name: ${{FD_KN_DEPLOYMENT_NAME}}
         fd_app_name: SpringBoot
    spec:
      containers:
        - name: superapp
          image: ${{FD_PROJECT_DOCKER_IMAGE_NAME}}
          ports:
            - containerPort: 8080

service.yaml

Code Block

language	text

themeMidnightfirstline1titleservice.yamllinenumberstruecollapsetrueapiVersion: v1 kind

apiVersion: v1
kind: Service
metadata:
  name: superapp
spec:
  selector:
    app: superapp   
  ports:
    - port: 8080
      targetPort: 8080

Blue/Green Istio Manifest

Istio manifest file to apply when running BlueGreen deployment strategies. If using a different strategy you can leave this blank.

The BlueGreen strategy is effectively an 'On/Off Switch' for your pods. When using this strategy all of your pods will deploy with a BLUE label, meanwhile

traffic is always routed to GREEN labels. Testers and QA will test BLUE pods through back doors and other means. When ready you can 'flip' the switch to

label all BLUE pods as GREEN resulting in them opening up for regular traffic.

As you can see in the below manifest file, the GREEN route will always receive 100 percent of the traffic through the Istio Mesh.

codetitle

languagetextthemeMidnightfirstline1

istio-bg.yaml

linenumbers

Code Block

true

language

collapsetrue

text

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: superapp
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: superapp
spec:
  host: superapp
  subsets:
  - name: green
    labels:
      fd_version: green
  - name: blue
    labels:
      fd_version: blue
---      
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: superapp
spec:
  gateways:
    - superapp 
  hosts:
    - superapp    
  http:
  - match:
    - uri:
        prefix: /version
    route:
    - destination:
        port:
          number: 8080
        host: superapp
        subset: green
      weight: 100 
    - destination:
        port:
          number: 8080
        host: superapp     
        subset: blue   
      weight: 0

Canary Istio Manifest

Istio Manifest file to apply when running the Canary deployment strategy. If using a

apiVersion: networking.

different deployment strategy you can leave this blank.

Canary is similar to the BlueGreen strategy but instead of being an 'On/Off Switch' think of it as a 'Dimmer Switch'. Instead of cutting all traffic over in one moment

you can adjust the weights as you go. For example, you can start at routing 90 percent of traffic to GREEN and 10 percent to BLUE, then 70/30, then 50/50, then full cut-over at 0/100.

You will notice the the manifest file looking similar to the BlueGreen manifest with the exception that we can see FlexDeploy variables used in the weight fields

(Check out the pipeline documentation to see where these weights are set):

istio-canary.yaml

Code Block

language	text

themeMidnightfirstline1titleistio-canary.yamllinenumberstruecollapsetrue

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: superapp
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: superapp
spec:
  host: superapp
  subsets:
  - name: green
    labels:
      fd_version: green
  - name: blue
    labels:
      fd_version: blue
---      
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: superapp
spec:
  gateways:
    - superapp 
  hosts:
    - superapp    
  http:
  - match:
    - uri:
        prefix: /version
    route:
    - destination:
        port:
          number: 8080
        host: superapp
        subset: green
      weight: ${{FD_KN_OLD_WEIGHT}} 
    - destination:
        port:
          number: 8080
        host: superapp     
        subset: blue   
      weight: ${{FD_KN_NEW_WEIGHT}}

AB Istio Manifest

Istio Manifest file to apply when running the AB deployment strategy. If using a

different deployment strategy you can leave this blank.

The AB deployment strategy still involves BLUE and GREEN pods like BlueGreen and Canary. The difference here is that BLUE traffic is only ever open based on a

'Routing Rule' which could be an http header of your choosing. For example, below we can anyone with the 'end-user' header set to a FlexDeploy property configured on the

pipeline will get sent to a BLUE pod, and everyone else is routed to GREEN. After the end-user has validated the BLUE pods, we flip them all to GREEN similar to the

BlueGreen strategy.

codetitle

languagetextthemeMidnightfirstline1

istio-ab.yaml

linenumbers

Code Block

true

language

collapsetrue

text

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: superapp
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: superapp
spec:
  host: superapp
  subsets:
  - name: green
    labels:
      fd_version: green
  - name: blue
    labels:
      fd_version: blue
---      
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: superapp
spec:
  gateways:
    - superapp 
  hosts:
    - superapp    
  http:
  - match:
    - headers:
         end-user:
           exact: ${{FD_KN_ROUTE_RULE}}
    route:
    - destination:
        port:
          number: 8080
        host: superapp
        subset: blue
  - route:
    - destination:
        port:
          number: 8080
        host: superapp
        subset: green

Helm Chart

The Helm chart to apply during deployment.

Can be a chart in the repository configured on the deploying endpoint, a folder with a chart, a chart package or URL.

Helm Release Name

Release Name in Helm to easily track all deployments on the endpoint.

Has nothing to do with FlexDeploy Release*

If it is unspecified, Helm will generate a random name.

Parameters Map

Parameters to pass to the Helm Chart

Expand

title	Example

In this example we will walk you through deploying your Kubernetes project through FlexDeploy. In this example we are assuming you have Kubernetes/Docker installed on a specific endpoint.

SCM Setup

For our first step we will add our Kubernetes manifest files to some sort of SCM. For this example we will be adding a deployment manifest to a git repository. Below you can see our .yaml file we added.

Expand

title	deployment.yaml

Image Removed

Workflows

We will now create a workflow to build and deploy our manifest files. For our build we will use an existing workflow so we will not need to create a new one. For our deploy workflow we will add the Kubernetes deploy operation. For the inputs on this operation you will just need to add the context which in our case is minikube.

Image Removed

Once we have added this we will then activate the workflow.

Topology

We will now create our topology. First we can create our endpoint if not already created. After creating an environment and instance and associating our workflow and endpoint with our new environment instance we can set all of the properties.

We will also need to create our SCM instance in topology. This integration instance will point to our repository containing our manifest files.

Project

We will now set up our project by configuring our workflows, instance and SCM instance.

Image Removed

We will then go to our kubernetes config tab and set some information. First we will need the deployment name. This will be the name the deployment is given. This will be returned by kubectl get deployments once the deployment is finished. We will also set our manifest files. This will be the path to the manifest files relative to our artifacts directory. In this example we will only need to give them the name of the file.

Image Removed

Build and deploy

We will now build and deploy the project. The build will pull our manifest files from git and put them in our artifacts directory. Our deploy will use those manifest files in the kubectl deploy command. If everything worked you should be able to see your new deployment on kubectl get deployments and see your new deployment

Code Block

kind: Deployment
apiVersion: apps/v1
metadata:
    name: nginx-deployment
    labels:
        deploy: example
spec:
    # A deployment's specification really only has a few useful options
    # 1. How many copies of each pod do we want?
    replicas: 3
    
    # 2. Which pods are managed by this deployment?
    selector:
        # This must match the labels we set on the pod
        matchLabels:
            deploy: example
    
    # This template field is a regular pod configuration nested inside the deployment spec
    template:
        metadata:
            # Set labels on the pod
            # This is used in the deployment selector
            labels:
                deploy: example
        spec:
            containers:
                - name: ngix
                  image: nginx:1.7.9

Workflows

We will now create a workflow to build and deploy our manifest files. For our build we will use an existing workflow so we will not need to create a new one. For our deploy workflow we will add the Kubernetes deploy operation. For the inputs on this operation you will just need to add the context which in our case is minikube.

Image Added

Once we have added this we will then activate the workflow.

Topology

We will now create our topology. First we can create our endpoint if not already created. After creating an environment and instance and associating our workflow and endpoint with our new environment instance we can set all of the properties.

We will also need to create our SCM instance in topology. This integration instance will point to our repository containing our manifest files.

Project

We will now set up our project by configuring our workflows, instance and SCM instance.

Image Added

We will then go to our kubernetes config tab and set some information. First we will need the deployment name. This will be the name the deployment is given. This will be returned by kubectl get deployments once the deployment is finished. We will also set our manifest files. This will be the path to the manifest files relative to our artifacts directory. In this example we will only need to give them the name of the file.

Image Added

Build and deploy

We will now build and deploy the project. The build will pull our manifest files from git and put them in our artifacts directory. Our deploy will use those manifest files in the kubectl deploy command. If everything worked you should be able to see your new deployment on kubectl get deployments and see your new deployment.

K8s Monitoring

When using the FlexagonHelmPlugin deploy operation or the FlexagonKubernetesPlugin deploy operation, FlexDeploy will capture details about your deployment, such as the deployment name and service url. For configured Container Projects a link will be saved on the Current State of Project Deployments

...

Deployment

If your deployed application includes a service, FlexDeploy will attempt to capture the application link for your deployment and display it here. If your application resides under some URI context, such as https://hostname/myapp, you can specify the uri under the AppContext on the Project K8s configuration tab.

Info
Often times after deployment, an external IP may not be immediately available. In this case the service link will not work. However, if a kubectl client is configured on the FlexDeploy server, FlexDeploy will periodically check back to see if the external IP has been resolved and update the link shown here.

Status

Represents the current status of your deployment. In order for FlexDeploy to accurately determine the deployment status, a kubectl client configured with the correct contexts available is required on the FlexDeploy server. If no kubectl client is found you will simply see a placeholder icon instead.

Deployment Strategies

After defining the K8s information and Deployment Strategy Manifest files in the project configuration as laid out above, the majority of the leg work is done by FlexDeploy Pipelines, though you can accomplish the same approach through traditional Projects and Workflows.

...

The below pipeline is using the Canary Strategy updating the weights as it progresses through the stages, starting at 10-90 and ultimately finishing with a full cutover at 100 - 0. Image Removed

...

Workflows

To use deployment strategies within FlexDeploy you need to use the Kubernetes Deploy Plugin operation within your workflow. If you have your Deployment Strategy information configured in the Pipeline as outlined above, you can defer the setting of those inputs in the workflow.

...

Helm Configuration

In order to deploy a Helm chart to a K8s cluster, FlexDeploy uses the deploy operation of Helm plugin, which invokes helm upgrade --install command under the hood. So, the deployment workflow should contain a step as in this example:

...

Versions Compared

Old Version 20

New Version Current

Key

Field Summary

deployment.yaml

service.yaml

istio-bg.yaml

istio-canary.yaml

istio-ab.yaml

SCM Setup

Workflows

Topology

Project

Build and deploy

Workflows

Topology

Project

Build and deploy

K8s Monitoring

Deployment

Status

Deployment Strategies

Workflows

Helm Configuration