CI with Wercker, Google Container Registry and Kubernetes: Part 1
Wercker is a platform for building and deploying your app using containers. It gives you a cli you can use to not only test your build locally, but also run a development container that watches your files and restarts automatically.
There are three key terms to understand in wercker:
- Step: a single unit of work, a command that must be executed. For example echo node -v or npm install. You can use predefined steps available from wercker’s registry, you can also create your own steps, and you can specify any arbitrary bash commands in a `script` step.
- Pipeline: defines a series of steps that must be executed in sequence. e.g. `build`. You write these in your wercker.yml in the root of your project.
- Workflow: a visual representation of how your pipelines are connected. i.e. build -> push to container registry -> deploy to kubernetes. These can be configured to execute on specific branches so that you get different pipelines executing on pushes to those branches. Set these up in wercker’s online UI.
Once you understand this, the next step is setting up your wercker.yml.
First you need to specify a box, which is simply a docker image to start your container from.
If you find that the dependencies you need are not included in any existing docker image, you can build your own docker image with the dependencies included and use that as your box. It will make your builds faster to start from an image that already has your dependencies bundled in.
Next you need a build pipeline, where you can test your app and then build it to produce the binary or assets required to run your app or service.
name: lint all the code
npm run lint
You can additionally specify after-steps that run on successful or failed builds, for example to send notifications to a slack integration channel when a build fails.
# note the indentation, this is still part of the build pipeline
after-steps: # these steps are just
At this point you should have a build happening on every `git push`, and you should be getting notifications to slack when your builds succeed or fail.
The next step will be to specify a `push` pipeline that you will use to push your container to a registry on every build (or on selected branch builds, e.g. development and master) to Google Container Registry (or any registry you choose), which will be the subject of part 2 of this series.