Posts tagged with helm

• Terraform secrets part 2 - Randomize it

  Nov 4, 2018

  In a previous post, I used Terraform and Helm to pass the connection string of an Azure CosmosDB database to the service that needs it without storing it anywhere in between. In this post, I’ll do something similar for a PostgreSQL database and beef up the security a bit.

• Terraform secrets

  Oct 6, 2018

  Since the beginning of this year, I’ve been using Terraform to manage infrastructure. I use it with both AWS and Azure and so far I haven’t encountered any problems. The documentation is quite good and you get that happy feeling when things just work as expected.

• Deploying with Helm v2.0

  Sep 1, 2018

  In the series with Helm and Continuous Deployment nine months ago, I used helm to deploy the application to the kubernetes cluster. To be able to do that from the CI server, I had to make a workaround. I had punched a hole in the cluster with a NodePort service for Tiller. This allows pretty much anyone to reach Tiller (the server side component of Helm) and interact with it. Great for a demo blog post, but not so great for security.

• Using AWS ECR as a Docker registry

  Dec 30, 2017

  In this post, I’ll modify the pipeline from the previous posts to use a Docker registry powered by AWS ECR (Amazon Elastic Container Registry).

• Waiting for the correct version after deployment

  Dec 29, 2017

  In this post, I’ll implement a post deployment check that waits until the application is running with the expected version. The first step is to make the application aware of its version. The easiest way to do that in our setup is with an environment variable. We’ll modify the deployment template of the Helm chart:

• CD with Helm part 8: DTAP

  Dec 9, 2017

  In the series so far, we have build a CI pipeline that produces a Docker image and a Helm chart. They are linked together with a unique version, allowing us to use Helm to deploy any feature branch we want. Now we’ll see how to implement a traditional DTAP and use Helm to deploy whatever, wherever.

• CD with Helm part 7: Docker registry

  Dec 9, 2017

  In a previous post, we had taken a shortcut: we had TeamCity running inside Kubernetes, sharing its Docker daemon. That trick allowed Kubernetes to access the Docker images produced by our builds. In this post, we’ll setup our own Docker registry and publish Docker images there.

• CD with Helm part 6: networking interlude

  Dec 3, 2017

  Before we continue with setting up the multiple environments that comprise our DTAP, I’d like to take a break and discuss a bit about networks. This way we can understand better what is going on inside and outside of Kubernetes.

• CD with Helm part 5: versioned artifacts

  Dec 2, 2017

  In the previous post we created the Helm chart for our hello world blog-helm application. The Helm chart contains all the information we need to deploy our application to a Kubernetes cluster. But so far, we always deploy the latest version. In a CD setup, we’d like to be able to deploy any version, from any feature branch, at any given point in time, to any environment (DTAP). Let’s start by looking at versioning.

• CD with Helm part 4: Helm Intro

  Nov 27, 2017

  In the previous post we had a first look at Kubernetes and deployed our hello world app on a local cluster using the CLI. The simple commands we used are good enough for a first taste. However, the full power of Kubernetes comes with using configuration files. Helm builds on top of that, taking these configuration files to the next level.

• CD with Helm part 3: Kubernetes Intro

  Nov 25, 2017

  In the previous posts we took the first steps to dockerize our hello world application. This allows us to run the application on any host, as long as it runs Docker. We also dockerized the build plan, which allows us to use any build server, as long as it runs Docker. Now we’re ready to run the application on production. Where should we run it?

• CD with Helm part 2: Dockerize the build plan

  Nov 18, 2017

  With Docker, we can package our application in a Docker image and we have the assurance that it will run on any machine that has Docker. We can do the same with our build plan. Dockerizing the build environment means that the only dependency we have on the build server is that it supports Docker. This reduces the amount of work needed to manage the build server and enables teams to be more independent.

• CD with Helm part 1: Dockerize it

  Nov 15, 2017

  In the previous post, we created the hello world application that we’ll be using. Now it’s time to dockerize the app. Dockerizing means to create a Docker image that can be used to run the app.

• CD with Helm part 0: hello world app

  Nov 13, 2017

  I’d like to start a tutorial series on how to apply CI/CD principles with tools like Kubernetes and Helm. I’m extremely new in these technologies, so this is a learning exercise for me.