This is the documentation for the latest development version of Velero. Both code and docs may be unstable, and these docs are not guaranteed to be up to date or correct. See the latest version.
kubectl
installedmkdir $HOME/go
export GOPATH=$HOME/go
go get github.com/vmware-tanzu/velero
Where go
is your
import path for Go.
For Go development, it is recommended to add the Go import path ($HOME/go
in this example) to your path.
Download the archive named Source code
from the
release page and extract it in your Go import path as src/github.com/vmware-tanzu/velero
.
Note that the Makefile targets assume building from a git repository. When building from an archive, you will be limited to the go build
commands described below.
There are a number of different ways to build velero
depending on your needs. This section outlines the main possibilities.
When building by using make
, it will place the binaries under _output/bin/$GOOS/$GOARCH
. For example, you will find the binary for darwin here: _output/bin/darwin/amd64/velero
, and the binary for linux here: _output/bin/linux/amd64/velero
. make
will also splice version and git commit information in so that velero version
displays proper output.
Note: velero install
will also use the version information to determine which tagged image to deploy. If you would like to overwrite what image gets deployed, use the image
flag (see below for instructions on how to build images).
To build the velero
binary on your local machine, compiled for your OS and architecture, run one of these two commands:
go build ./cmd/velero
make local
To build the velero binary targeting linux/amd64 within a build container on your local machine, run:
make build
For any specific platform, run make build-<GOOS>-<GOARCH>
.
For example, to build for the Mac, run make build-darwin-amd64
.
Velero’s Makefile
has a convenience target, all-build
, that builds the following platforms:
If after installing Velero you would like to change the image used by its deployment to one that contains your code changes, you may do so by updating the image:
kubectl -n velero set image deploy/velero velero=myimagerepo/velero:$VERSION
To build a Velero container image, you need to configure buildx
first.
Docker Buildx is a CLI plugin that extends the docker command with the full support of the features provided by Moby BuildKit builder toolkit. It provides the same user experience as docker build with many new features like creating scoped builder instances and building against multiple nodes concurrently.
More information in the docker docs and in the buildx github repo.
Set the $REGISTRY
environment variable. For example, if you want to build the gcr.io/my-registry/velero:main
image, set $REGISTRY
to gcr.io/my-registry
. If this variable is not set, the default is velero
.
Optionally, set the $VERSION
environment variable to change the image tag or $BIN
to change which binary to build a container image for. Then, run:
make container
Note: To build container images for both velero
and velero-restore-helper
, run: make all-containers
To publish container images to a registry, the following one time setup is necessary:
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker buildx create --use --name builder
builder
$ docker buildx inspect --bootstrap
[+] Building 2.6s (1/1) FINISHED
=> [internal] booting buildkit 2.6s
=> => pulling image moby/buildkit:buildx-stable-1 1.9s
=> => creating container buildx_buildkit_builder0 0.7s
Name: builder
Driver: docker-container
Nodes:
Name: builder0
Endpoint: unix:///var/run/docker.sock
Status: running
Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
NOTE: Without the above setup, the output of docker buildx inspect --bootstrap
will be:
$ docker buildx inspect --bootstrap
Name: default
Driver: docker
Nodes:
Name: default
Endpoint: default
Status: running
Platforms: linux/amd64, linux/arm64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
And the REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry make container
will fail with the below error:
$ REGISTRY=ashishamarnath BUILDX_PLATFORMS=linux/arm64 BUILDX_OUTPUT_TYPE=registry make container
auto-push is currently not implemented for docker driver
make: *** [container] Error 1
Having completed the above one time setup, now the output of docker buildx inspect --bootstrap
should be like
$ docker buildx inspect --bootstrap
Name: builder
Driver: docker-container
Nodes:
Name: builder0
Endpoint: unix:///var/run/docker.sock
Status: running
Platforms: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v
Now build and push the container image by running the make container
command with $BUILDX_OUTPUT_TYPE
set to registry
$ REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry make container
Docker buildx
platforms supported:
linux/amd64
linux/arm64
linux/arm/v7
linux/ppc64le
For any specific platform, run BUILDX_PLATFORMS=<GOOS>/<GOARCH> make container
For example, to build an image for arm64, run:
BUILDX_PLATFORMS=linux/arm64 make container
Note: By default, $BUILDX_PLATFORMS
is set to linux/amd64
With buildx
, you can also build all supported platforms at the same time and push a multi-arch image to the registry. For example:
REGISTRY=myrepo VERSION=foo BUILDX_PLATFORMS=linux/amd64,linux/arm64,linux/arm/v7,linux/ppc64le BUILDX_OUTPUT_TYPE=registry make all-containers
Note: when building for more than 1 platform at the same time, you need to set BUILDX_OUTPUT_TYPE
to registry
as local multi-arch images are not supported
yet.
Note: if you want to update the image but not change its name, you will have to trigger Kubernetes to pick up the new image. One way of doing so is by deleting the Velero deployment pod:
kubectl -n velero delete pods -l deploy=velero
To help you get started, see the documentation.