Devops Trends Report
Find out what technologies from the DevOps space you should keep an eye on this year. Be the innovator in your team and learn more about Kubernetes, Service Mesh and Chaos Engineering. Read the report.
Google has released Skaffold, an open source command line tool that facilitates continuous development for Kubernetes applications. Skaffold is entering an increasingly crowded space of Kubernetes development automation tooling, including Azure's Draft, Datawire's Forge and Weavework's Flux.
Skaffold automates the workflow for building, pushing and deploying applications into a Kubernetes cluster. With Skaffold, developers can iterate on application source code locally while having it continually updated and ready for validation or testing in their local or remote Kubernetes clusters. Developers can run Skaffold as a background process while they are developing their code, and it can also be used in a one-off or automated context such as a CI/CD pipeline. This allows developers to leverage the same workflow and tooling when moving applications from local development to production environments.
The Google Cloud Platform Blog states that Kubernetes provides operators/sysadmins with APIs and methodologies that increase their agility and facilitates reliable deployment of software applications. Kubernetes takes bespoke deployment methodologies and "provides programmatic ways to achieve similar if not more robust procedures". Operators can therefore focus on the parts of infrastructure management that are most critical to their organisations -- maintaining the speed (of release) and stability of services.
In some cases, developers can be the last people in an organisation to be introduced to Kubernetes. Developers may have already taken steps to create reproducible deployment artifacts for their applications using package management technologies like RPMs or DEBs, or more recently Linux containers like Docker. Docker allows developers to produce repeatable runtime environments where they can define the dependencies and configuration of their applications in a simple and repeatable way. This can allow developers to stay in sync with their development runtimes across the team, however, it doesn't introduce a common deployment and validation methodology. Accordingly, developers often want to use the Kubernetes APIs and methodologies that are used in production environments to create a similar local, integration and QA environment.
A typical developer workflow for an application that is to be deployed to Kubernetes is as follows:
- Find or provision a Kubernetes cluster.
- A cluster can be initialised using hosted platforms such as GKE, AKS or (in the future) AWS Fargate, or for running on-premise tools like kops can be used
- Build and upload a Docker image for each service to a registry that is available within their cluster.
- This is typically achieved via the Docker Community Edition image build tooling (which now includes a local installation of Kubernetes in the Edge version)
- Use the reference documentation and examples to create their Kubernetes manifest definitions.
- Use the kubectl CLI or the Kubernetes Dashboard to deploy their application definitions.
- Repeat steps 2-4 until their feature, bug fix or changeset is complete.
- Check in their changes and run them through a CI process that includes:
- Unit testing
- Integration testing
- Deployment to a test or staging environment
- Liveness and observability checks
The Google blog argues that Steps 2 through 5 require developers to use many tools via multiple interfaces to update their applications:
Most of these steps are undifferentiated for developers and can be automated, or at the very least guided by a set of tools that are tailored to a developer's experience.
Skaffold can be run in one of two modes, 'skaffold dev' or 'skaffold run'. In 'dev' mode Skaffold performs the following operations: watches source code and the dependencies of Docker images for changes, and runs a build and deploy when changes are detected; streams logs from deployed containers; and runs in a continuous build-deploy loop, only warning on errors. In 'run' mode Skaffold runs a pipeline once and exits on any errors in the pipeline. This is useful for continuous integration or continuous deployment pipelines and "sanity checking after iterating on your application".
Skaffold has been released in "alpha", and currently includes the following design considerations and capabilities:
- No server-side components, meaning no overhead on a cluster
- Image tag management
- Support for multiple application components (build and deploy only the pieces of the application stack that have changed).
Skaffold has a pluggable architecture that allows developers to "choose the tools in the developer workflow that work best for you".
As recently noted by thought leaders within this space, like Gareth Rushgrove and Joe Beda, there is currently a lot of tooling emerging within this space of Kubernetes development workflow automation -- including Draft, Forge, Flux, Gitkube, Heighliner and ksync -- each of which offers subtly different functionality.
The Microsoft Azure team has released Draft, which targets the "inner loop" of a developer's workflow: run 'draft create' to containerise an application based on Draft packs; run 'draft up' to deploy an application to a Kubernetes development sandbox; and use a local editor to modify the application, with changes rapidly deployed to Kubernetes. Once the developer is happy with changes made via Draft, they commit and push to version control, after which a continuous integration (CI) system takes over. Draft builds upon Kubernetes Helm and the Kubernetes Chart format, making it easy to construct CI pipelines from Draft-enabled applications.
Datawire provides Forge as part of their developer automation workflow tooling, which also includes the Telepresence remote debugging tool and the Ambassador API Gateway (built upon Envoy Proxy). With Forge, developers define how each service is built with a Dockerfile, define how each services is run via a Kubernetes manifest, and define the services and dependencies that make up an application with a 'service.yaml' file. Running 'forge deploy' automates all of the standard container build and deploy steps for Kubernetes, including detection changed dependencies and allowing for incremental builds. Forge also supports canary releasing (specified via a version control branch), and CI/CD integration.
Weavework's Flux tool is a realisation of the organisation's "GitOps" philosophy, and automatically ensures that the state of a Kubernetes cluster matches what is specified in version control (the "single source of truth"). The overall goal of Flux is to automate the deployment of services. A typical use case would be: a developer makes changes to a service and creates a GitHub-style pull request; an operational cluster is now out of date and needs to be updated; Flux observes those changes and deploys them to the cluster; and Flux maintains the current state of the cluster (e.g. in the event of failure). Flux also provides a CLI and a UI (in Weave Cloud) to perform these operations manually, and integrates with CI/CD tooling.
Gitkube is a tool for building and deploying Docker images on Kubernetes using "git push", much like the Cloud Foundry "cf push" model. The project web states that Gitkube is "ideal for development where developers can push a WIP branch to the cluster to test", and that the project is aiming to be a reference implementation for writing git-based automation. An example suggests that engineers fork the Gitkube repository and create a Kubernetes Custom Resource Definition (CRD), controller and git remote hook that performs automated operations on the Kubernetes cluster.
Heighliner provides GitHub Flow for Kubernetes, where each new GitHub pull request will automatically be deployed into a target Kubernetes cluster, "making it easy to review [...] changes in the real world". When developers create a new GitHub Release, Heighliner automatically distributes the changes to staging or production environments. ksync aims to speed up development with Kubernetes by transparently updating containers running on the cluster from a local build. It does this by synchronising a local filesystem directory with storage within the cluster (implemented via a locally run binary and a remote DaemonSet running on each node within the cluster).
More information of Skaffold can be found in the project's GitHub repository. A Getting Started guide for GKE is available, alongside a local installation guide (using Minikube) by following the instructions in the README. For discussion and feedback join the mailing list or open an issue on GitHub.
