Werf: Glue Together Git, Docker, Helm, Kubernetes For CI/CD Pipelines


    werf is designed to glue together Git, Docker, Helm, and Kubernetes. It is meant to be used in CI/CD pipelines. Let’s see whether it can be helpful to manage our k8s applications.

    #werf #CI #CD #Kubernetes #Helm

    Consider joining the channel: https://www.youtube.com/c/devopstoolkit/join

    ▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
    ➡ Gist with the commands: https://gist.github.com/6039be2497217a555fba5eafea076ba3
    🔗 werf: https://werf.io
    🎬 GitHub CLI: https://youtu.be/BII6ZY2Rnlc

    ▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
    If you are interested in sponsoring this channel, please use https://calendly.com/vfarcic/meet to book a timeslot that suits you, and we’ll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).

    ▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
    ➡ Twitter: https://twitter.com/vfarcic
    ➡ LinkedIn: https://www.linkedin.com/in/viktorfarcic/

    ▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
    📚 Books and courses: https://www.devopstoolkitseries.com
    🎤 Podcast: https://www.devopsparadox.com/
    💬 Live streams: https://www.youtube.com/c/DevOpsParadox

    ▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
    00:00 Introduction
    02:06 Setup
    02:33 Build, Push, And Deploy With werf
    07:13 Upgrade Applications With werf
    11:31 werf Definitions
    17:00 Deploying To Production With werf
    17:55 Other werf Features
    21:42 Doing The Same Without Werf
    24:09 Conclusion


    Previous articleDevOps : CI/CD Pipeline For Deploying APIs – Part I | Jenkins | MuleSoft | GIT | GitHub
    Next articleKubernetes Pods – Difference between containers & pods


    1. What is your preferred OpenSource, cloud agnostic application/service for Event Based Micro-Service communications? Kafka? Kafka Streams? Some MQ Implementation? I have watched almost all your videos now and so far we see eye-to-eye on almost everything… Love your thoughts on this topic.

    2. Thank you for the video and following replies, Victor! There are some important clarifications about werf we want to do as its core developers. We've discussed some of them on Reddit already but it would be good to post here since it's the actual place where the video will be watched 😉

      1. Local development is implemented in werf using –dev and –follow flags. We've seen your excitement about not allowing to converge when files are not committed (08:05). However, this very error message also states: "You may be interested in the development mode (activated by the –dev option), which allows working with project files without doing redundant commits during debugging and development." While werf was originally created with CI/CD in mind, when our Giterminism being introduced, it was extended with this local development support to make developers life easier (and more features here are ahead).

      2. "werf converge" is not the only way you can use werf. Here are also: a) bundles, b) export/render commands to implement different ways of delivery. (You can find the werf 1.2 stable announcement for more details.)

      3. "werf converge" is the default way of using werf indeed. However, it would be a big mistake to boil it down to executing docker build + docker push + helm upgrade. There is so MUCH MORE: a) inside, including separating building process into different stages, benefits from reading the Git history, content-based tagging, cleaning up the registry, synchronizing simultaneous builds (distributed building), etc. + b) outside, since werf serves as a unifying, controlling part of the whole CI/CD process. There are in-depth comparisons from which you can get a much better understanding of how the basic mechanisms mentioned in video are extended in werf — just google for "werf vs Helm" and "werf vs Docker". In terms of Git, werf is not as straightforward as you probably think (using the only monorepo as it is) since werf also supports Git submodules and remote repos.

      4. Building in werf was originally implemented using docker build. Saying this dependence kills the idea of using werf with Kubernetes (since dockershim support in K8s is deprecated) is quite odd, though. Kubernetes doesn't care how you build images, it will run any of them using with your preferred runtime (containerd, etc.). There was no issue at all with that. Running werf inside Kubernetes is another issue, though. While it doesn't seem to be the first thing you need, it's still a valid case. It is supported in werf since quite recently. To achieve this, another building mechanism was implemented in werf and it is based on buildah. It makes possible to run werf in Docker/Kubernetes, e.g., we have ready-to-use examples for using werf in GitLab CI/CD with both, Docker and Kubernetes executors.

      In general, werf might not seem a killer app for such a basic scenario provided on video, yet it has much, much more to offer if you investigate into its features. It's different from a vast majority of other tools on the market since it tries to cover the whole CI/CD process, from building to deploying and cleaning up. And it still follows the idea of not reinventing the wheel, but integrating existing well-known basic tools for each of part of the process (i.e. Git, Docker, Helm, any CI system, etc.). We now see some major problems in our high-level documentation and are super grateful for making it obvious for us with this video. Your feedback on GitOps vs. Giterminism is also much appreciated! More great work ahead for the project to help people understand how they can benefit from it 🙂

    3. As far as i know – werf does much more than focussed in the video, and these additional fetures are basically main fetures, not the simplified workflow (which is not worth to be even mentioned).
      To name a few:
      1. Werf has its own image builder not based on docker.
      2. Werf keeps your image registry clean, by deleting unused images (and doing it really smart and not like f.e. nexus scarry approach just deleting older ones)

    4. Hi, Thanks for your videos Viktor. I really like them. What about "store git" step? Do you recommend any tool? For instance: 2 repositories, one with my application and another to be a control repo (for argoCD or flux). How can I add my manifest into my control repository using CI? Or it's better to keep a bash script to make all git add+commit commands. What do you think? Any ideas?

    5. I'm not sure how it adds when considering the functionality discussed is redundant. That said, their documentation is absolutely stunning and very well put together. I feel like every "Giterminism/GitOps CICD" doesn't focus enough on things like hot reloading from local-to-remote, local development options, and better integration with Imperative configuration generators like cdk8s.

    6. Despite the correct facts, the review is very one-sided, as if it was done carelessly. Victor does not describe what problems the werf is trying to solve and how. Perhaps he himself did not figure it out because some of the materials are available only in Russian.

    7. Great video as always! But I have a question.
      Wouldn't a CI pipeline manage by Argo Workflows + Events / Tekton (kaniko or buildah for building and pushing images) and cd with ArgoCD accomplish what werf is trying to accomplish, only with much greater customizability and more control + scale?

    8. What do you think about werf? Do you share my opinion or you found it to be useful?

      I made a mistake by missing the `–dev` argument that allows you to use Werf during local development and without committing files to Git.

      IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), YouTube tends to delete comments that contain links. Please do not use them in your comments.