Concourse

This chart bootstraps a Concourse deployment on a Kubernetes cluster using the Helm package manager. Concourse is 100% open source CI/CD system with approximately 100 integrations to the outside world. Concourse's principles reduce the risk of switching to and from Concourse, by encouraging practices that decouple your project from your CI's little details, and keeping all configuration in declarative files that can be checked into version control.

Prerequisites Details

  • Kubernetes 1.6 (for pod affinity support)
  • PV support on underlying infrastructure (if persistence is required)

Configuration As Code

You can think of a pipeline as a distributed, higher-level, continuously-running Makefile.

Each entry under resources is a dependency, and each entry under jobs describes a plan to run when the job is triggered (either manually or by a get step).

Jobs can depend on resources that have passed through prior jobs. The resulting sequence of jobs and resources is a dependency graph that continuously pushes your project forward, from source code to production.

Fancy Visualization

Your pipeline configuration is then visualized in the web UI, taking only one click to get from a red (failed) box to seeing why it failed. The visualization also provides a "gut check" feedback loop - if it looks wrong, it probably is wrong.

CI Under Source Control

All administration is done using the fly CLI. The fly set-pipeline command pushes the config up to Concourse. Once it looks good, you can then check the file into source control. This makes it easy to recover if your Concourse server burns down.

Reproducible, Debuggable Builds

Everything runs in containers, ensuring a clean environment on every run. Each task specifies its own image, giving it full control over its dependencies, rather than managing them on your workers. The fly intercept command will pop you right into one of your build's containers, which can be useful for debugging.

Rapid Local Iteration

The fly execute command executes a task as a one-off build, with your local changes. This will run your code in exactly the same way it would run in your pipeline, without you having to repeatedly push broken commits until it works. Achieve the fabled green build #1!

When a job fails, you can also use fly execute with -j flag to run with the same inputs as the failed job. You can then replace an input with your local changes with -i to test if your fix is valid.

Bring Your Own Integrations

Concourse does not have a complex plugin system. Instead, it has a single strong abstraction.

The resources section of a pipeline lists Resources, which are abstract external locations where your pipeline will monitor for changes, fetch bits from, and push bits to.

For example, a resource with type git refers to a git repository, which will be cloned in a get step and pushed to in a put step. Behind the scenes, Concourse will continuously run git fetch to look for new commits that jobs may want to trigger on.

At its core, though, Concourse knows nothing about Git. It comes with a git resource type out of the box, but you could just as easily bring your own into your pipeline. Resource types are implemented as container images containing scripts - using the docker-image resource type, they can be fetched from a Docker registry.

Tell us about a new Kubernetes application

Newsletter

Never miss a thing! Sign up for our newsletter to stay updated.

About

Discover and share new Kubernetes applications

Navigation