This article is the next installment in the “werf vs. …” series. In the previous article, we discussed the ways that werf differs from Helm. This article compares werf with an even more basic tool: Docker.

This article attempts to provide a detailed answer to a question we stumble upon every now and then: What is the difference between werf and Helm? At first glance, both of these tools seem to be designed with the same purpose: automating application deployment in Kubernetes. However, the reality is a little more complicated than that.

The werf tool is designed to easily integrate with any CI/CD system. The general approach to this process is provided in the epilogue, while the main part of this article discusses the practical example of organizing a CI process in Jenkins and Bitbucket.

After reading this article, you will learn how to:

• create a Jenkins Shared Library to store all CI scripts in one place and edit them via a single commit;
• integrate Jenkins with Bitbucket to trigger CI processes by committing to specific branches or by creating a tag.

GitOps is a modern way to make better IaC for delivering apps in Kubernetes. It is all about giterminism, idempotence, automation, observability… and many other exciting features! However, are you sure all this happens in the real world using existing approach and tools? Here’s our comprehensive analysis of GitOps and its features, comparison with CIOps as well as insights on how this all should be done to actually get what each DevOps engineer dreams of.

werf is a CLI tool that glues well-established software (Git, Docker, Kubernetes, Helm, a variety of container registries & CI systems) to facilitate applications’ delivery. In this webinar, developers, release engineers & SREs will learn how they can benefit from werf in their infrastructure, release management & CI/CD pipelines. Using Git as a single source of truth, we will build images of a simple Node.js application, push them into registry, deploy to Kubernetes and integrate with GitLab CI. You will also see how actual Kubernetes deployments are kept always in sync with your defined state via GitOps push-based approach.

While implementing CI/CD processes for a variety of developer teams, we've realised that container registries (Docker Registry, GitLab Container Registry, etc.) usually don't provide flexible & powerful policies to clean up the images that are not in use. As modern cloud-native applications development requires to deliver a huge amount of builds (images) to Kubernetes, you might end up with either an overfilled registry or lacking an important image in your infrastructure (or registry) when it's needed. Here are our thoughts on this issue and how we have resolved it away from the registries themselves, in our Open Source tool (werf).

This is the third post of a GitOps tools article collection. In this post, the author gets to know continuous integration and continuous deployment tool for Kubernetes — werf.

werf is our Open Source tool to build your applications and deploy them to Kubernetes — continuously & consistently. Today we are excited to announce that werf has learned to operate in a distributed mode!

Container registries tend to support the Docker Registry HTTP API, allowing their users to rely on the same tools to operate them. However, some implementations have their peculiarities and limitations. Thus, you have to take into account their specifics when using them as part of your CI/CD toolchain. That is exactly what happened when we decided to improve the way our werf GitOps utility manages the lifecycle of images.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. The v1.1 release introduced a new feature in the image builder: the content-based tagging. Until now, the typical tagging strategy in werf involved tagging Docker images by a Git tag, Git branch, or Git commit. However, all these strategies have drawbacks that are fully resolved by implementing the new tagging strategy. In this article, we discuss its advantages.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. As promised, the release of werf 1.0 marked the beginning of the era of new features and revising established approaches. Now, we are excited to announce the latest version (v1.1) of our tool which is a massive step in the development of its builder and laying the groundwork for the future. Currently, version 1.1 is available in the 1.1 ea channel.

You may already know our GitOps tool called werf — we have discussed it in several of our articles. Today, we would like to share our experience in building & deploying the site with our tool’s documentation, werf.io. Despite it is a regular static site, the building process is noteworthy as we use a dynamic number of artifacts.

In Flant, we are often confronted with the challenge of adapting applications for running them in Kubernetes. When dealing with this challenge, we usually encounter many repetitive problems. We have already discussed one of them in the “Migrating your app to Kubernetes: what to do with files?”. In this article, we’ll focus on another problem which relates to CI/CD processes for this time.

In this article, timed to coincide with the werf release, we will provide a detailed description of what this version can and cannot do, as well as discuss our plans for future versions. However, let’s start with what the term “GitOps” means and what role werf has in the process of continuous integration and continuous delivery (CI/CD).

Let’s start with a theory. What are three-way-merge patches? How they’ve been invented, and why they are so essential for CI/CD processes with a Kubernetes-based infrastructure? And later, we will discuss the 3-way-merge process in werf, what modes are used by default, and how can you manage all this stuff.

Are you struggling with implementing CI/CD for many microservices in a efficient and elegant way? Here’s our current approach in solving this task using GitLab CI (thanks to its include keyword in .gitlab-ci.yml) and werf.

Let’s imagine that your application is written in some scripting language — e.g. Ruby — and you want to rewrite it in Golang. You may ask a reasonable question: what is the point in rewriting a program that is up and running?..

This article should be useful if you create & apply Helm charts for Kubernetes using the existing solutions drawn from the chart repositories.

Better late than never. The story of how we almost made a major mistake by not implementing support for building images using regular Dockerfiles.

We are excited to announce werf — Open Source, Go-native and simply powerful DevOps tool bringing the CI/CD implementation based on Kubernetes to the next level.