Posts tagged with blog-helm-sample

• 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).

• Adding code coverage with nyc

  Dec 29, 2017

  In this post, I’ll add code coverage to the build pipeline and configure TeamCity to break the build if the code coverage drops.

• Adding mocha unit tests

  Dec 29, 2017

  In this post, I’ll add unit tests to the example application that I’ve been fiddling around with in the recent posts.

• Adding WebdriverIO tests

  Dec 29, 2017

  In this post, I’ll add some automated browser tests using PhantomJS and WebdriverIO.

• 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:

• Removing the image-tag.txt artifact

  Dec 29, 2017
  Small update on replacing the image-tag.txt artifact with the implicit build.number parameter.

• Host DNS in Docker Toolbox

  Dec 29, 2017
  How to configure Docker Toolbox so that it uses your laptop's hosts file.

• Smoke test for a Docker image

  Dec 28, 2017

  According to Wikipedia, a smoke test is a preliminary test that reveals simple failures severe enough to (for example) reject a prospective software release. The process of smoke testing aims to determine whether the application is so badly broken as to make further immediate testing unnecessary. If we consider our dockerized blog-helm web application, a possible smoke test can be: can we pull the image from the registry? If we run the image, does the container stay alive or does it crash immediately? In this post, I’ll implement this in an extra build configuration in TeamCity with a generic bash script doing the actual work.

• Build chains in TeamCity

  Dec 27, 2017

  In a previous post, I had configured a deployment build configuration in TeamCity. I had mentioned back then that it’s possible to set it up in a different way, which makes it is easier to visualize the deployment pipeline across all environments. In this post, I’ll modify that deployment pipeline to use snapshot dependencies and project templates.

• Build configurations as code with TeamCity

  Dec 25, 2017

  In this post, I’ll show how to setup TeamCity so that your project’s build configurations are stored in your git repository. This allows you to change your build configuration in the same way you change your code, via a pull request. It allows to make changes to the pipeline without affecting other branches. And all that is supported in a way that you don’t have to give up the user friendly way of defining your build via the UI.

• One script to version all

  Dec 20, 2017

  This is just a fun hacking post. I put together a script that is able to handle all versioning strategies that I mentioned about in the post about versioning.

• Semantic versioning with GitVersion

  Dec 19, 2017

  I recently stumbled upon a tool called GitVersion which takes a different approach on versioning. I already mentioned some options regarding versioning, but all of them require you to actively specify the version somewhere. GitVersion instead is able to calculate it based on the state of your git repository.

• Fixing root permissions on Docker volume

  Dec 16, 2017

  In a previous post, we saw how to dockerize the build plan of an application. Typically, you’ll want the build to run tasks like linting and unit tests, and then publish the results of these operations as XML reports that the build server can consume and present in a human friendly way.

• 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.