Search the Community

Flux’s Native Support for HashiCorp Vault If you love HashiCorp Vault, then you know its benefits and popularity as a way to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API. If you love the CNCF Flux project for its enterprise-grade and secure GitOps capabilities, you'll be excited to know that Flux provides native support for Hashicorp Vault token-based authentication when decrypting SOPS encrypted secrets! View the full article

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project we strive to inform you of what’s landed every month, including new possibilities that are available for integration and where you can get involved. Read last month’s update here. Let’s recap what happened in September. There has been quite a lot. Flux v1 is in maintenance mode As already mentioned in the announcement of our Flux v2 and GitOps Toolkit plans, Flux v1 (and Helm Operator) are in maintenance mode and have been for a while. This means we are focusing all of our attention on v2 and we’ll only be working on Flux and Helm Operator v1 for critical updates and fixes. If you have important PRs that you want to land or if you are considering helping out with v1 maintenance, please talk to us. We want to make this transition work for everyone. GitOps Toolkit about to reach a big milestone: 0.1.0 We have been working on the GitOps Toolkit for about six months and we have largely reached feature parity with Flux v1 (in read-only mode) and Helm Operator v1. The 0.1.0 milestone will mean that the APIs will be promoted to beta and that we will want more widespread testing and experimentation of Flux for those two sets of use-cases. Going forward, changes to the API will be accompanied by a conversion mechanism. With the v0.1 release the API becomes more stable but while in beta phase there are no guarantees about backwards compatibility between beta releases. We will also be working on migration paths and guides. You can expect the release in the next couple of days and we would welcome any feedback you might have. Check out the “Get Started” guide (including others) on https://toolkit.fluxcd.io/. This is a great achievement, so thanks a lot Bianca Cheng Costanzo, Daniel Holbach, Dinos Kousidis, Erik Hollensbe, Hidde Beydals, Ihor Dvoretskyi, Kevin McDermott, Leigh Capili, Lucas Käldström, Manuel Morejón, Martin H Berwanger, Michael Bridgen, Michael Cristina, Mike Beaumont, Philip Laine, Sara El-Zayat, Scott Rigby, Sean Eagan, Simon Howe, Stefan Prodan and Yiannis Triantafyllopoulos for your help thus far! go-git-providers adding new maintainers and Gitlab support Another Flux project that has seen new maintainers pick up the work is go-git-providers. Mike Beaumont, Simon Howe, Dinos Kousidis, Yiannis Triantafyllopoulos and Sara El-Zayat all work for Weaveworks and they stepped in to pick up where Lucas Käldström left off. Dinos says: “The project offers a common interface to run operations on different git providers. It defines an abstraction and mapping on repositories, organizations, and teams so that projects don't have to combine provider specific ones (go-github, go-gitlab, etc.). We just released 0.0.3 which adds the gitlab provider alongside the github one that was added by Lucas. A BitBucket provider is also being discussed.” In other news The list of improvements and new features is long, so check out the links below to find out more: We implemented S3 compatible storage in GOTK. On the premise of being able to implement features and complementary implementations using different APIs and service providers more easily, this will likely be useful for many.ARMv7 for the GitOps Toolkit has landed, this means it now works on Raspberry PI. A long standing feature request for Flux v1 resolved. ARM64 support was merged too.The kustomize controller health assessment was extended to custom resources that are compatible with kstatus.Homebrew formula for GOTK CLI, here’s how to install it. We added a new guide “Manage Kubernetes secrets with Mozilla SOPS” to our library. Please check it out and give us feedback.We are very happy we received quite a bit of user feedback, so we were able to land many fixes and improvements to GOTK.The list goes on. We are particularly pleased with the thoughtfulness and tone of our growing community that is spec’ing out future features and integrations over in our Github Discussions section. There are many great things to come and we will showcase some of the work in our next episode. We also created the /fluxcd/community repository. This is in response to a number of discussions which happened recently where we realised we want to better express our project-level governance and community docs - expect more discussion about this in future meetings, on Slack and elsewhere. If you would like to participate in this effort, talk to Daniel Holbach and Scott Rigby (or anyone else in the project really). Get involved If you like what you have read and would like to get involved, here’s how: Join our upcoming dev meeting on Oct 8.Talk to us in the #flux channel on CNCF Slack.Join the planning discussions.And if you are completely new to the GitOps Toolkit, take a look at our Get Started guide and give us feedback.We are looking forward to working with you. View the full article

This is the first blog post in a series which accompanies the development of the GitOps Toolkit on the road to delivering Flux v2 and more. We want to highlight what has been happening in development in the past weeks, who has contributed and what you can look forward to. And if you are curious, how to try it out for yourself. It has been three weeks since the Flux community announced their plans for Flux v2 that has been rebuilt from scratch and based on top of the new GitOps Toolkit. If you haven’t heard the news yet, here’s what we are planning on doing: The GitOps functionality in Flux and Helm Operator is now delivered by individual components, to enable and support far more use-cases and to simplify development.Everything is driven by Custom Resources for more control and better observability.We built the GitOps Toolkit from the ground up incorporating the most requested features:Support for multiple source Git repositoriesOperational insight through health checks, events and alertsMulti-tenancy capabilities, such as applying each source repository with its own set of permissionsIn April this year we started with early experimentation for building a proof-of-concept, which was first shown at the GitOps Days virtual event in May, followed by a request-for-comments period and roadmap discussions in June. Since then the Flux community has come a long way. Our highlight in this episode: the road to Helm Operator v2 Since the announcement, the team has made great strides, especially in the area of Helm: around 90% of all the work related to building the “Helm Operator v2” is done. The Helm Controller now has support for values from Secret and ConfigMap resources, and support for strategies for handling different kinds of failure. Its API package is also available as an independent Go Module. Failure handling is a big one. It means that you can extensively configure how to automatically remediate an installation, test, or upgrade failure. This includes actions that should be performed to remediate (rollback or uninstall), the number of retries, and even if the release has failed and retries have expired, you can debug the issue more easily. In addition, it is possible to ignore test failures if necessary (as opposed to remediate after a failed “helm test”). Also the API to support Helm releases, based on source API, has been discussed and designed. In particular, providing values from sources and support for Helm charts from Git. So what’s left for Helm Controller to be on par with today’s Helm Operator? Only implementing support for referring to an alternative chart values file. And of course lots of testing. Before we tell the world they can transition to Helm Operator v2, we need to hear from current users and integrate their feedback. If you are using Helm Operator right now, it would be fantastic if you could test the Helm Controller: simply check out https://toolkit.fluxcd.io/guides/helmreleases/ and give us feedback on how the journey went for you (find contact info at the bottom of this blog post). In other news Here’s a recap of what happened in the project overall in the past three weeks: Support for HelmChart artifacts built from GitRepository sources.Various bug fixes, e.g. Notification Controller: fix to the Prometheus scraping endpoint.We were approached by members of the Grafana Tanka project who decided to call their binary “tk” so we decided to go with “gotk” from now on.In the future we will also be able to enable ARM support; one blocker for this is that Flux shelled out to the kustomize binary, which has been fixed now.Mozilla SOPS decryption support is coming!More projects starting to look at using go-git-providers: eksctl, libgitops, and through libgitops: ignite, cluster-api-provider-existinginfra and wksctl. Since Flux become a CNCF Sandbox project about a year ago, we formally started the process to review the project with the CNCF - the PR is worth a read if you are interested in where the project stands as a whole and what happened in the last year. The amount of care and contributions our large community of users and contributors has shown is somewhat mind-boggling. We are certainly very pleased with what we have achieved. Development-wise the focus for the next few weeks is going to be: Figuring out the final form of Flux v2The next big milestone: Bringing the image automation on par with Flux v1Increasing general test coverageIf you want to help us shape the future of any of these, please reach out - we would love to hear from you. Special thanks to our contributors - here’s what they landed: Martin H Berwanger improved the gotk install script and automated the upgrades of controller component dependencies in the Toollkit.Sean Eagan contributed the conditional remediation on failed actions to the helm-controller.Philip Laine implemented notifications for Github commits.We also had many folks jump into conceptional work in our Github Discussions:Shane Sveller is looking into non-curl-bash installation methodsMoshe Immerman had a look at the image update automation designSean Eagan has been working on various parts of the Helm controller planning. Calle Petterson, Jonas Arneberg and Steve Hipwell as well.Daniel Morgan in SOPS support and Philip Laine in e2e testing, exposing image fields in kustomization resources and a possible Job controller.There is still lots where you can help shape the future of the GitOps Toolkit. Some of the important discussions are: What is the final form of Flux v2?Prometheus metrics for resource statusDesign for image update automationReconciling errors vs failure to make progressWe are looking forward to working with you. Here is how you can get involved: Join our upcoming dev meeting on Sept 10Talk to us in the #flux channel on CNCF SlackJoin the planning discussionsAnd if you are completely new to the GitOps Toolkit, take a look at our get Started guide and give us feedbackView the full article