Skip to content

werf v1.1.10
Compare
Choose a tag to compare
@flant-team-sysdev flant-team-sysdev released this 24 Apr 16:36
· 6929 commits to main since this release
v1.1.10
aababd2
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Introducing distributed builds

Werf now can store stages in the docker registry by specifying --stages-storage REPO instead of --stages-storage :local.

There is no more restriction that a single host should be used to run all werf commands for a project:

  • All werf commands that need an access to the stages should specify the same stages storage.
  • It is irrelevant on which host werf command is running as long as the same stages storage is used for the commands like: build, publish, cleanup and deploy.
  • Also all hosts which run werf should have a connection to the Kubernetes cluster, because werf uses Kubernetes to synchronize multiple build/publish/deploy processes running from different machines.

"werf ci-env gitlab" default mode now is to store stages by path CI_REGISTRY_IMAGE/stages. All existing werf installations will continue to use :local stages storage because --stages-storage :local param has explicitly been specified in all CI-configs. So to use distributed builds user needs to remove this param, see guided steps below about migrating to the distributed stages storage.

Synchronization, caches and cleanup

Introduced a new parameter named --synchronization, which controls how multiple werf processes are synchronized between each other. There is a stages-storage cache and locks components that werf needs to run. Stages storage cache is an internal component used to boost werf performance for idle builds when calculating stages. Locks are needed to organize correct publishing of new stages into stages-storage, publishing images into images-repo and for deploy process also.

When --synchronization :local used (which is factually by default in the previous versions < v1.1.10), then stages-storage cache reside in the local host file system (~/.werf/shared_context/storage/stages_storage_cache/1/PROJECT) and local file locks are used.

When --synchronization kubernetes://NAMESPACE is used, then werf creates a ConfigMap for project in this namespace, stores stages storage cache in this ConfigMap and uses distributed locking over this ConfigMap to synchronize multiple werf processes running from multiple hosts.

By default, when non local stages-storage is used werf automatically use kubernetes://werf-synchronization namespace and create a ConfigMap named werf-PROJECT in this namespace. User can specify arbitrary non-standard namespace on own needs.

What about local docker images cache on hosts where werf is running? — There is such a cache, which is cleared either by the werf itself or can freely be removed by other tools (docker rmi).

New commands to sync and switch stages

  1. werf stages sync --from=:local|REPO --to=:local|REPO.

    • Command will copy stages from one stages-storage to another.
    • Command will copy only difference of stages from one stages-storage to another.
    • Furthermore command will copy multiple stages in parallel.
    • Command run result is idempotent: sync can be called multiple times, interrupted, then called again — the result will be the same.
    • There are delete options: --remove-source and --cleanup-local-cache, which controls whether werf will delete synced stages from source stages-storage and wheter werf will cleanup localhost from temporary docker images created during sync process.
    • This command can be used to download project stages-storage to the localhost for development purpose as well as backuping and migrating purposes.

  2. werf stages switch-from-local --to=REPO

    • Command will automatically sync existing stages from :local stages storage to the specified REPO.
    • Command will block project from being used with :local stages-storage.
      • This means after werf stages switch-from-local is done, any werf command that specifies :local stages-storage for the project will fail preventing storing and using build results from different stages-storages.
      • Note that project is blocked after all existing stages has been synced.

How to migrate to distributed mode

Let's say you have some project in Gitlab CI, that uses werf. Steps:

  1. Go to the directory where your project reside on the runner host.
  2. Create an MR in the project, that removes --stages-storage :local param from all werf invocations. There is no need to set this param explicitly anymore, because werf ci-env will automatically set it to CI_REGISTRY_IMAGE/stages.
  3. Run werf stages switch-from-local --to=CI_REGISTRY_IMAGE/stages where CI_REGISTRY_IMAGE is the address of container registry for your gitlab project. After this step all werf invocations from different git branches of the project that uses --stages-storage :local will refuse to work, because switch-from-local command sets a block to use :local.
  4. Merge your MR with correct stages-storage param.
  5. All git branches that need to run werf should rebase then onto the new changes to use new stages-storage, otherwise werf will refuse to use :local stages storage.

Other changes since last release v1.1.10-alpha.7

[docs] Remove --stages-storage :local from Gitlab CI docs
[ci] Cache GO modules
[tests] New tests
[tests] K8S/Cleanup Suite: test cleanup with deployed image
[tests] K8S/Guides Suite: actualize after each
Error: --stages-storage=ADDRESS param required
[tests] Helm/Render Suite: add extra annotations and labels check
[tests] Cleanup Suite: test stages storage repo

Installation

Linux amd64

Darwin amd64

Windows amd64

Assets 2