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 command line utility
- Minimal required version is 1.9.0.
- To optionally use Git Submodules minimal version is 2.14.0.
Method 1 (recommended): using Multiwerf
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)
Method 2: download binary
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
Method 3: from source
go get github.com/flant/werf/cmd/werf
Backward Compatibility Promise
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.
stablechannel (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
stablereleases within minor branch (1.1.x).
eachannel versions are mostly safe to use and we encourage to use this version everywhere. We guarantee backward compatibility between
eareleases within minor branch (1.1.x). We guarantee that
earelease should become a
stablerelease not earlier than 2 weeks of broad testing.
rcchannel (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
rcreleases. We guarantee that
rcrelease should become
eanot earlier than 1 week after internal tests.
betachannel (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
alphachannel (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