In one of my previous posts I described how FlexDeploy can automate building and deploying microservices with Docker containers. One of the most popular deployment platforms in containers world is Kubernetes. The deployment of a microservice to a K8s cluster might become challenging as it is related to creating a number of various K8s resources such as pods, replica sets, services, config maps, secrets, etc. Helm helps with that. Helm is an open source tool that simplifies application deployment to a K8s cluster. The idea is that we create a template of a K8s manifest for each K8s resource that we need for our application. The template may refer to parameters (e.g. image name, deployment name, port number, etc.). Those parameters are substituted with provided values during the deployment. A collection of such templates is called a Helm Chart. So the deployment is basically telling Helm what chart to deploy and with what values. The good news is that now FlexDeploy provides great support of this utility.

Let’s say there is a project configured to build a Docker image as a deployment artifact:

There is a simple chart containing a couple of templates for a K8s deployment and K8s service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{.Values.deployment.name}}
  labels:
    app: superapp
    workload: {{.Values.deployment.name}} 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: superapp
      workload: {{.Values.deployment.name}}       
  template:
    metadata:
       labels: 
         app: superapp
         workload: {{.Values.deployment.name}} 
    spec:
      containers: 
        - name: superapp
          image: "{{ .Values.image.name }}"
          ports: 
            - containerPort: 8080
apiVersion: v1
kind: Service
metadata:
  name: superapp
  labels:
    app: superapp
spec:
  selector:
    app: superapp
  ports:
    - port: {{.Values.service.port}}
      targetPort: 8080

The chart is packaged into an archive and is available on an http server.

The project in FlexDeploy is configured as the following:

So the project “knows” what Helm chart is associated with it and it knows what values should be provided for the chart parameters during the deployment. Those values are evaluated on-the-fly from the Groovy script expressions referring to the project and environment-instance properties.

The deployment workflow contains a single step:

 

invoking the Helm plugin operation deploy:

The operation takes Chart Name, Release Name and values from the project configuration (unless they are overridden here) and installs/upgrades a chart to a K8s cluster. The endpoint where this workflow step is being executed should have Helm utility installed and configured to communicate with the target K8s environments.

That’s it!

Eugene Fedorenko

I have over 16 years of progressive experience in information technology with software design and development, testing and deployment of enterprise banking software. Graduated from Kharkiv Aviation Institute (Ukraine) in 1999 with a master's degree in computer science. I previously worked for CS Integra in Ukraine and for eProseed in the Netherlands, focusing on building enterprise solutions with Oracle ADF. Recently, I joined Flexagon and hold a position of Senior Architect. I have been recognized as an Oracle Certified Professional (OCP) and I am considered to be an expert in Oracle Fusion Middleware. I have been a speaker at various local and international IT conferences such as Oracle Day, Oracle OpenWorld, ODTUG Kscope, RMOUG Training Days, UKOUG and DOAG. I am an author at the ADF practice blog and a member of ADF Enterprise Methodology Group.

More posts by Eugene Fedorenko
  

Leave a Reply

Your email address will not be published. Required fields are marked *