Werf (previously known as Dapp) is made to implement and support Continuous Integration and Continuous Delivery (CI/CD).

It helps DevOps engineers generate and deploy images by linking together:

• application code (with Git support),
• infrastructure code (with Ansible or shell scripts), and
• platform as a service (Kubernetes).

Werf simplifies development of build scripts, reduces commit build time and automates deployment. It is designed to make engineer's work fast end efficient.

Contents

• Features
• Installation
  • Install Dependencies
  • Install Werf
• Backward Compatibility Promise
• Docs and Support
• License

• Complete application lifecycle management: build and publish images, deploy application into Kubernetes and cleanup unused images by policies.
• Application build and deploy specification (as many components as needed) completely described in one git repository with source code (single source of truth).
• Build images with Dockerfile or with our syntax to take advantage of incremental rebuilds based on git history and carefully crafted tools.
• Helm 2 compatible chart and complex deploy process with logging, tracking, early errors detection and annotations to customize tracking logic of specific resources.
• Kubernetes clusters scanner and different policies to keep the registry clean.

• 3-way-merge #1616.
• Content based tagging #1184.
• Distributed builds with common registry #1614.

• Conveniently build as many images as needed for a single project.
• Building images by Dockerfile or Stapel builder instructions.
• Parallel builds on a single host (using file locks).
• Distributed builds (coming soon) #1614.
• Advanced build with Stapel:
  • Incremental rebuilds based on git history.
  • Building images with Ansible tasks or Shell scripts.
  • Sharing a common cache between builds using mounts.
  • Reducing image size by detaching source data and build tools.
• Building one image from config on the top of another image from the same config.
• Debug tools for build process inspection.
• Detailed output.

• Store images in one or several Docker repositories by the following patterns:
  • IMAGES_REPO:[IMAGE_NAME-]TAG using monorep mode.
  • IMAGES_REPO[/IMAGE_NAME]:TAG using muiltirep mode.
• Different image tagging strategies:
  • Tag image by git tag, branch or commit.
  • Content based tagging (coming soon) #1184.

• Deploy an application into Kubernetes and check that application is deployed correctly.
  • Track all application resources status.
  • Control of resources readiness.
  • Control of the deployment process with annotations.
• Full visibility both of the deploy process and of the final result.
  • Logging and error reporting.
  • Periodical status reports during deploy process.
  • Easy debugging of problems without unnecessary kubectl invocations.
• Fail CI pipeline fast when problem detected.
  • Early resources failures detection during deploy process without need to wait full timeout.
• Full compatibility with Helm 2.
• Ability to limit deploy user access using RBAC definition (Tiller is compiled into Werf and run from the deploy user outside of cluster).
• Parallel deploys on a single host (using file locks).
• Distributed parallel deploys (coming soon) #1620.
• Allow continuous delivery of new images tagged by the same name (by git branch for example).

• Local and Docker registry cleaning by customizable policies.
• Keeping images that used in Kubernetes clusters. Werf scans the following kinds of objects: Pod, Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, ReplicationController.

Docker CE installation guide.

Manage Docker as a non-root user. Create the docker group and add your user to the group:

sudo groupadd docker
sudo usermod -aG docker $USER

Git installation guide.

• Minimal required version is 1.9.0.
• To optionally use Git Submodules minimal version is 2.14.0.

Multiwerf is a version manager for Werf, which:

• downloads Werf binary builds;
• manages multiple versions of binaries installed on a single host, that can be used at the same time;
• automatically updates Werf binary (can be disabled).

# add ~/bin into PATH
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
exec bash

# install multiwerf into ~/bin directory
mkdir -p ~/bin
cd ~/bin
curl -L https://raw.githubusercontent.com/flant/multiwerf/master/get.sh | bash
source <(multiwerf use 1.0 beta)

The latest release can be reached via this page

curl -L https://dl.bintray.com/flant/werf/v1.0.3-beta.9/werf-darwin-amd64-v1.0.3-beta.9 -o /tmp/werf
chmod +x /tmp/werf
sudo mv /tmp/werf /usr/local/bin/werf

curl -L https://dl.bintray.com/flant/werf/v1.0.3-beta.9/werf-linux-amd64-v1.0.3-beta.9 -o /tmp/werf
chmod +x /tmp/werf
sudo mv /tmp/werf /usr/local/bin/werf

Download werf.exe

go get github.com/flant/werf/cmd/werf

Note: This promise was introduced with Werf 1.0 and does not apply to previous versions or to dapp releases.

Werf is versioned with Semantic Versioning. This means that major releases (1.0, 2.0) are allowed to break backward compatibility. In case of Werf this means that update to the next major release may require to do a full re-deploy of applications or to perform other non-scriptable actions.

Minor releases (1.1, 1.2, etc.) may introduce new "big" features, but must do so without significant backward compatibility breaks with major branch (1.x). In case of Werf this means that update to the next minor release is mostly smooth, but may require to run a provided upgrade script.

Patch releases (1.1.0, 1.1.1, 1.1.2) may introduce new features, but must do so without breaking backward compatibility with minor branch (1.1.x). In case of Werf this means that update to the next patch release should be smooth and can be done automatically.

Patch releases are divided to channels. Channel is a prefix in a prerelease part of version (1.1.0-alpha.2, 1.1.0-beta.3, 1.1.0-ea.1). Version without prerelease part is considered to be from a stable channel.

• stable channel (1.1.0, 1.1.1, 1.1.2, etc.). This is a general available version and recommended for usage in critical environments with tight SLA. We guarantee backward compatibility between stable releases within minor branch (1.1.x).
• ea channel versions are mostly safe to use and we encourage to use this version everywhere. We guarantee backward compatibility between ea releases within minor branch (1.1.x). We guarantee that ea release should become a stable release not earlier than 2 weeks of broad testing.
• rc channel (2.3.2-rc.2). These releases are mostly safe to use and can even be used in non critical environments or for local development. We do not guarantee backward compatibility between rc releases. We guarantee that rc release should become ea not earlier than 1 week after internal tests.
• beta channel (1.2.2-beta.0). These releases are for more broad testing of new features to catch regressions. We do not guarantee backward compatibility between beta releases.
• alpha channel (1.2.2-alpha.12, 2.0.0-alpha.5, etc.). These releases can bring new features, but are unstable. We do not guarantee backward compatibility between alpha releases.

Make your first Werf application or plunge into the complete documentation.

Werf’s developers are always in contact with community though Slack and Telegram. Join us!

• English-speaking community in CNCF Slack channel #werf
• Russian community in Telegram Chat #werf_ru

Your issues are processed carefully if posted to issues at GitHub

Apache License 2.0, see LICENSE