 Hello, everyone. Welcome to Cloud Native Live, where we dive deep into the code behind Cloud Native. I'm Annie, and I'm a CNC as ambassador, as well as a senior product marketing manager at Camunda, and I will be your host tonight. So every week, we bring a new set of presenters to showcase how to work with Cloud Native technology. They will build things, they will break things, and they will answer all of your burning questions. So you can join us every Wednesday to watch live. Another thing that's happening in the CNCF universe is the CNCF survey. So the time to answer is right now. So that is really nice, and thank you for all the replies so far and in the future. So this week, we have amazing speakers here to talk about, to talk with us about the VS Code and Flux, testing the new unreleased OCI repository feature. So, and as always, this is an official live stream of the CNCF, and as such, it is subject to the CNCF Code of Conduct. So please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of all of your fellow participants, as well as presenters. So with that said, I'll hand it over to our amazing speakers and presenters. So to kick it off. Thanks, thanks very much, Annie, for that great introduction. Hi, everyone. I'm Kingdon, Tomo is with me. Hi. I hope everyone's doing good today. Thanks for joining us. Really glad to be given this presentation. I'm very super excited to show this feature and to show Flux off to all the new users that might be on the stream at everyone who's at every level. So actually, as Kingdon is pulling up the slides, I just wanted to ask if anybody could post in the chat if you are absolutely brand new to Flux, please let us know so we know how to adjust for this. This is available for both new users and existing. So let us know in the chat. Sorry, to me. Sure, no problem. And so this is me. I'm an open source support engineer at WeaveWorks on the developer experience team. And this is a co-native live web stream. I've been working in supporting and developing Flux as well as this new BS Code extension for Flux that we're going to see as part of the demonstration of the new Flux OCI feature. So here's our agenda. Time out. Yes, so as we mentioned, there's lots of great stuff for both existing users and people who are brand new. If you just joined, let us know if you're brand new to Flux. We'll make sure that we have, it'll be very brief, but I think it's always important to the level set to just say what GitOps is, how Flux provides GitOps and a brief intro to Flux. But then we'll kind of dive right into Kingdom's demo because we think that just seeing it in action will really help and we'll continue to explain certain things along the way. But if you feel like this is so new and kind of a lot to take in, please let us know in the chat and we're happy to back up and explain a few things. But one thing that we'll reiterate several times is that there's so many benefits that people already today have been getting from Flux by getting GitOps. There's many, many more than we listed, but some of the things that will be even better with this OCI support is scalability and security. We'll also reiterate that if you're an existing Flux user, you can continue to do things the way that you're doing, but hopefully you'll be excited about some of the companies that really have pushed the limits and made it necessary to have these added benefits. And that's why Flux has been developed to add these new capabilities that we're excited to share. And then at the end, I think what we'll do is we'll do a run through and we'll answer questions at the end, both like beginning questions, as well as for existing Flux users, we'll go a little bit deeper. And then we've got Pinky who's in the Flux community online as well. We'll be monitoring. So if you have anything specific along the way, Pinky will be monitoring the chats. I think so it's both YouTube and LinkedIn. So please chat away and hopefully Pinky will follow as well. And by the way, you might notice that Kingdom is demoing this all in VS Code, which is a whole another exciting topic, but Kingdom's been working on this fantastic extension so that you can do getups from within VS Code. So if there's any extra time, then we're happy to chat about that, but we'll see how it goes. And so now Kingdom will kind of talk about the technical aspects that we'll be covering as well. Yeah, so what is the specific news that is newsworthy today? So I know that we advertised this was an unreleased feature. I'm sorry, it's released. We actually have to show a released feature. I'm actually really thrilled about that. It's gonna make things a lot easier for me rather than to try to demo something unreleased. We've also added support in the VS Code extension for the new OCI repository sources. So you'll see as we go through the demo, that is in use and it's part of the demo. And OCI manifests are a new option that's available in this release. There are many implications. It's gonna be very helpful, I think, for a lot of our users, especially those of you who might have taken advantage of the automation features. It's going to make things a lot simpler, but all of the old paradigm is stable. At this point, you should not expect anything to go away. We would not pull the rug on you. So as far as predictions about what has changed, I have two main predictions that I will share now. And hopefully that you'll agree by the end of the talk that this is going to enable users to achieve the same or better outcomes as they've been achieving with Flux, only they can use fewer boilerplate manifests. And OCI will permit Flux to reverse some guidance, also that we weren't happy about. And I'll get into that a little bit more later, but by reversing that guidance, we're doing this without losing any functionality. So you should be able to go on using Flux the way you've been using it or adopt Flux more easily today, if that's the stage that you're at. So back to Flux and GitOps, what is GitOps exactly and what specific workflow is it that we're going to see today? We're going to see workflow that pushes to two environments. So the user is going to commit some change to Git repository, CI jobs are going to run, things are going to get pushed to container registries. And then Flux will take over from there to deploy to staging or production, whichever environment the change is destined for or both as time as that goes on. But what is GitOps exactly? So these are the principles of GitOps, broadly together they say use Git as a single source of truth and there's some elaboration here about how that should be done. So like Kubernetes, the system is all built on declarative behaviors and declarative artifacts, but with the additional requirement for GitOps that you must use a version store. And if you know about Kubernetes, you'll recognize number four, which also applies there as Kubernetes continuously reconciling based on events in the system and Flux is similarly reconciling on intervals or events if you have access to them, that's all according to an alignment with the GitOps principles. Immutable artifacts are also an important part of this. We need immutable artifacts that cannot be changed once they're cast only by generating up a new version and releasing it out the door. That's how we maintain our capability to audit and describe the exact state of the system at any given time by ensuring that it's precisely described in a declarative way. And the remaining features here are a bit opinionated about how you should do your change management and with good reason we think, but these are inclusive principles. So you can adopt GitOps without taking all of these, but to be clear, three and four are specifically what Flux does here and what any tool that's in alignment with the ideas of the open GitOps working group who developed the standard should be doing to call itself GitOps. So changes are pulled automatically into the cluster based on some heuristic for determining what changes the latest according to some parameters that you can specify, we'll call that policy. And then an agent that's running in the cluster continuously observes the system state and reconciles it with the desired state, making sure that your desired state isn't forced in a continuous way. So that's GitOps done continuously and those are the fundamentals of GitOps and adoption is an iterative process, but step one is for us to install Flux on your cluster and that's a step that we call Bootstrap. This is something I've already done. I've covered in a lot of talks before. We will see if you follow this link in the docs, if you've never installed Flux before, this is how you can do it. And we will see about what Bootstrapping is. Bootstrap happens in a Git repository and there's some secret management that Flux does as part of that also. It's described in the docs. We don't need to cover that today, but what is Flux doing once Bootstrap is over? Well, Flux is synchronizing from the cluster repository. It's following principles three and four, pulling and reconciling and enforcing the configuration that you described there and it's applying it in a continuous manner on whatever interval that we configure. So what's a cluster repository? Well, this is just the Git repository that you Bootstrapped into. Applications may have their own Git repository and that's an extremely common pattern, although it's not the only pattern. We can sort of trust that the application repository when we say install pod info at version 6.2.0 that the app repo is a responsible trustworthy source for what does that mean exactly for pod info the app? So it's in our control or maybe it's a fork or some repo that we don't own or control from upstream, but we can fork it and control our deployment like this. So this is what's new in Flux V2, but in recent Flux history, this is not really news. Flux supports multiple Git repositories. So the example that we're gonna work through today is from the docs at least partially and you can find it here. If you search for OCI cheat sheet, this is about where we're starting. If you're a docs person, if you'd like to read what we're doing, you can go ahead and check that out. And here is the application that we're gonna be deploying. I've made a few adjustments to that according to these docs mostly and a few other adjustments in order to make things fit. You can fork my fork and check them out or just go ahead and look at them, but they're meant to be sort of hands-on shovel ready. So to follow along at home, if you want, this is what you need. One Kubernetes cluster of basically any kind, a kind cluster is fine. I'll be using vcluster, fork the pod info repo for my fork and then or pull changes in if you have already forked from step on put on bootstrap, flux like this substituting your own username and a repository name. You do not need to fork my cluster repository. Everything that I'm gonna show you can reproduce on a brand new cluster repo. And if you do fork the pod info repo, please take note that you will need to enable the GitHub actions there since it's a fork. So forks don't run GitHub actions by default, but we're gonna need those because we're publishing a release and we're gonna let flux deploy the release. So here's what I've done to make this a little bit simpler for presentation. I think I said that you don't need to copy from one repo to another in general, but in this case, I'm gonna do that because it makes simpler. So this is the place that I'm copying my manifests from and this is where I copy them to and you can see how to adapt these examples from the source code and we'll see right now. So we're gonna go ahead and start the demo. So let's find our pod info application. That pod info is running. I've said there's a Kubernetes cluster that's running. Let's see, pull up a monitor. So we can see that that cluster is running. We have, so this is the we've get up, I'm sorry, this is the flux extension and here's our cluster demo cluster and I'm just gonna pull up canines because it's got a little bit nicer responsiveness. We can see things happening as they happen there. So I'm gonna pull that up as well, but so what we're gonna do, we have two environments. One is staging and the other is production. I've actually lost track of which one is which and sorry, this is behind a little bit, I think. So I have to refresh these to see what's on the cluster right now. Okay, so we actually have- We also wanna give back that the text is hard to read. I'm not sure if anybody else has the issue. Yeah, let us know in the comments if you're experiencing some same issue of blurry text. In the past when this has happened, it might also be a local problem in your computer. So might try closing a few browser tabs and so forth if that's impacting the performance on your side. But let's see, okay, someone else is saying is as well and we can obviously in the back end we can see what's happening, but you can try kind of limiting your other tabs, for example, or other programs that you might have opening your computer in the meantime. Yeah, I'm sorry about that. All of these repos are public at least. So if there's anything that you wanna read, please check out the repos. I will show this again. You can see I've got a lot of commits. So past the original version. So we have made some changes here. So this is where it could look for those changes. And all right, so what we're gonna do- Just checking increasing the size helped. You could increase the resolution to 1440. You're currently on 720. Yeah, so the, I'm not sure if we can change the stream parameters. My screen is 1080p and it's about this wide. So I can't go to a smaller resolution there. Okay, I guess this is the streaming platform issue. Yeah, that's from the YouTube size side the resolution there. So it's not from Kingdom side, but I do agree. I think this side, this one looks quite nice, but then the K9S was a bit smaller in font. So maybe that's the one that I'm adding. Because we certainly don't wanna keep talking if no one can see what we're talking about. Yeah, the main reason why I want this K9S UI here is because some of the things take a little while and I wanna make sure that they're actually happening before I say we should wait and see what happens. So we really only need to see that it's all blue or that it turns red, but I didn't realize that was the thing that was too small now. So thanks for that. So the BS code side is okay. And I really appreciate people taking the time to give us the chat feedback. Okay, great, thank you. All right, so what we're gonna do to our deployment we're gonna change two things. We are going to change that logo on the screen here. So we've got this cuttlefish here. It's very cute and he's clapping. And then we're gonna change that to a different logo. And we're gonna change one more thing. We've got some scaffolding to help us change. So this version number here is gonna have to increment along with everywhere else that that version number occurs in the repo. So that's a number of places and we've got a little helper here. This is from Pod Info originally. It's part of the release process. You probably have a script like this. If you have tags in multiple places in your repo, well, let's set the version number and let's actually make these two separate commits. I don't want those. I do want that. Okay, change image. And then we're gonna increment the version number. We have one more little helper here. It just runs git tag and git tag push. The push tag. Okay, so we've tagged our new release and now it's on CI and Flux do the rest of the work. I'm gonna pull up a watcher for the GitHub tagging here. Here's our two jobs. And this is probably a good time to go and look at the release workflow itself. So let's see that workflow here. This is the release workflow. This is based on the original Pod Info release workflow but with some augmentations from this document that I thought I had handy. So from the OCI cheat sheet, this is the document I mentioned earlier here. In the workflow examples, here's that diagram that I showed and these are the GitHub actions. This is the example GitHub actions that facilitate this. So all these are really doing are they're taking a clone of the repo and they're running flush push artifact, Flux push artifact against a path. And this is the path of manifests to package up. Then we're shipping those manifests to OCI repository where they're versioned. And then what we're going to see is actually that we have two environments and we're going to see a promotion workflow. So what it's going to happen is the pre-production environment is going to receive our new. And there's a request from the audience. Yeah, to make the text a bit bigger. And I think the documentation link was provided by Pinky earlier to the chat but maybe Pinky can post it again if someone missed it. And also there was a question from the audience would this be a good time to take it or are we leaving the Christians to the end fully? Yeah, that one's fine. I think Pinky's Pinky's looking at the GitHub question which I can't access the chat because I'm in this platform but Pinky's looking at it. Yes, that's a good question. Okay, so there was a question on how can I, how I can use GitHub? Well, yeah, I'll address it later but Pinky will address it now in the chat. Perfect. All right, so we can see that our deployed is rolling out to pre-production as promised and what we should find now is in our pod info repo. And if you want this to work too you're going to have to enable issues on your fork as well. There is a manual approval workflow. This is not something specifically part of Flux. This is a GitHub actions thing. So the manual approval workflow here, it's these two lines way down at the bottom almost. And this is just waiting for our approval. So you can see the job has stopped here and it won't go into the remaining steps until we give this approval. So let's do that. And we can see, you know, here's our pre-production and here's our production. So production hasn't received the update yet. It should receive at any moment now there. We already know it's going to work at this point but come on, let's see that release. There it is. Super. All right. So that's our OCI promotion workflow that I'm showing today. And the clients were very happy with that change. Oh, what's that? I just got a message. No, the clients were not happy with that change. We actually have to roll this back. So we have to make a new release now. We're going to go in and roll that back. Instead of changing it manually here, I'm going to use the get feature to revert this commit, not that one, but the one before it or after it rather. Well, depending on how you look at the order here, this one, let's set that back. Get revert. Okay. And we're going to push another new immutable version. So you need to set a new version number and commit that change and then do the same thing. Make release for get tag and get push. And we'll see that the same thing happens, but in reverse this time and it should proceed very quickly, just as we saw before, as soon as the Docker build is done. So we'll pull that watcher up again so we can see that as it happens. And at this point, we can stop for a few questions, I think. Okay, a few questions. Come on. Yeah, I'm sorry. I was chatting with Pinky on these various ones. We wanted to kind of focus first on maybe more beginner questions and then we'll go to some deeper ones in the end. Pinky was still working on the GitHub questions. We'll see if we can pass on that until there's something else. And then is the OCI repository exactly this theme as any container image repo? Could we push to AWS ECR? That is a great question. So AWS ECR is an OCI compliant repo. It is a spec. Not every Docker registry is necessarily OCI compliant. There's a media type that makes an OCI image a little bit different. So the media type in a normal Docker container image is a root FS and it's a different media type than we use here, which is not exactly sure what it is, but it's something that contains different type of content and Flux will push whatever you decide to push. Whatever is in that directory when you run Flux push with few exceptions. There are a few things that shouldn't be pushed like a .git directory. I think that's actually a bug right now, but Flux will push whatever you tell it to push and the OCI artifact will hold whatever type of content you want it to hold. So if there's something else that you wanted to do with this besides Flux customized controller applying your manifests those things are possible too. What the OCI repository resource does like every Flux source kind it reaches out to the remote source and it creates a tar ball locally that it serves up as a local cached copy of the remote resource. So each OCI repository represents one deployment stream. So we have multiple ones here. We have one that's pointed at the tag production. So when we tag that production tag at the end of our workflow see we do a Flux tag artifact, tag production. This pushes the build out to production. So it's already been released at this point here. We did the release Flux push artifact with get tag from the actual tag. So this is our tag version. And we see that the release has gone out. Maybe you saw maybe, let's see if we can see our new release here, 6.2.13. It's done out to pre-production. So we'd like to approve it now. So let's go back to our issues and find the approval. But if we really pick this apart we're gonna find some problems in this workflow. This is a CI workflow, but it's pretty good. This is pretty much exactly what I would have wanted if I had been in an application developer role where I need something like Flux to help me deploy. And the reason for that it's a little bit of enterprise role play at this point because a lot of environments that are sensitive or regulated will have this audit requirement that the change requester must be a different person than the change approver. And a lot of times that change approver has to be someone who does not have get experience, Bob from accounting or someone who is a product owner who is not a developer. So that's what this workflow facilitates. If you don't want a manual approval step you can just take those lines out and everything else will work the same. But here we see it's gone out to production and that works. So we're back to where we started. Let's see if you have more questions. Well, if it's okay, I wanted to kind of just make sure we, you know, for the range of audience members in the beginning you talked about the get-offs principles. And so I just wanted to see like can we highlight them again? Like what makes this specifically get-offs? Yeah, sure. So the principles that we highlighted before, declarative version immutable pulled automatically and continuously reconciled. What's happening is our declarative artifacts are getting placed in our version store. Now it's an OCI repository. That's the derivative of our get repository. So it's not really not get-offs. It's still get-offs. That artifact is traceable back to get. Even if get-offs required get, which it doesn't, the definition doesn't specifically say get. All right, so we've got our versioned artifacts and we have a process that's pulling them. We have two processes while they're both flux and they're pulling through this OCI repository here. So this one is for production. And this is a tag, just like a tag on any image. So if you Docker, build and push and you get a latest tag, this is the same kind of tag. It's a mutable tag, not an immutable tag, but a mutable tag. And I wanna highlight this as something that's not inconsistent because git itself also has mutable tags. Tags are all mutable in git and branches are also mutable unless you have a branch protection policy configured, which you should do because the definition of get-offs requires immutable artifacts. And the only immutable artifacts that you're getting from git are SHA-based. So each time there's a new commit hash, that's a new immutable artifact. It can't be changed without changing the commit hash. So it's still immutable, but we shouldn't make the mistake of thinking that branches are somehow immutable because they're very immutable. So if we want, we can use, we can pull in a particular tag by version. You can use an OCI semver reference here and semver range will allow you to select. So I can put in a range here. I can say any 6.2.x or I can say any 6.x is what that would say. It's the same as this expression. And this is all according to semver. So if you go to semver.org, you can read all about the semver spec. Or you can just put in a wildcard and then you'll accept any release. And that's what I would probably do in my staging environment. That way I would accept even probably, I want pre-releases too. I'm not sure if Star would get your pre-releases or not, but that would definitely capture pre-releases, something like that. Awesome. So we're pulling automatically every time the OCI repositories reconcile every one minute interval. We're gonna pull this tag production and see if it's moved. And then if we see that it's moved, we're gonna reconcile the changes that we find there with what's in the cluster and update the cluster to reflect what is in the source. Hopefully that explains pretty well. Yeah. I just wanted to take a moment here that we've been engaging more and more with Flux users and it's just been so exciting that very, very large and enterprise companies have been relying on Flux, just getting more and more people adding themselves to the adopters list of both Flux and Flagger. If you don't know that's a sub-project and another topic but you can go check that out. And one of the things that really excites us as well is that large corporations like Microsoft, Amazon, VMware, Red Hat, D2IQ and our own Weaveworks use Flux to provide GitOps to their customers. So especially companies like Microsoft and the Amazon that just felt very validating that all the work that the maintainers and the contributors and everybody who's done together has really created a well-designed piece of software that provides that scalability and security automation, et cetera, et cetera, all these benefits that GitOps brings. And so it was really validating because we are this close to graduating in the CNCF. We went through a really great external security audit with the CNCF paid for and it definitely validated that work. So what's exciting here as we mentioned, this OCI work continues. It just shows like our continuous journey to ensure that Flux is top notch in terms of security as well as scalability. And some of that has to do with one of the questions that came in that Pinky's been answering as well, which was about mono repos. So, Edward, glad that you asked that. We were just chatting with another company this morning about how they structure their repos and how more and more people are kind of going to the mono repo model with a lot of those benefits. So, Kingdom, you wanna chat a little bit about that. The question is specifically, do you have a pattern for when you have a mono repo and you do not want to expose all of your code to the cluster for the deployment operator to access? We have separate environments for different customers and so exposing the mono repo to Fluxy is a no go. And certainly people aren't doing that. So what are your thoughts generally on repos and what this new OCI work helps to do? Yeah, so this does actually specifically address that issue in a way that hopefully you will find palatable. So what I'm doing here when I do Flux push artifact, I'm pointing it at this deploy directory. And if we go here, we see that's in the pod info repo. And this is where all of my manifests are kept. So all of my code is outside of there and Flux will not be exposed to any of my code. It will only be exposed to what's in the deploy directory. So if I wanted to go a little bit deeper and say, I actually only want this environment to have access to its own manifests. You can do that as well, not in this particular layout because of the way we have this laid out, we have bases above overlays. So if I wanted to just select this overlay, well, you can see actually this one would be okay. I can grab this one because it doesn't have any outside references and it doesn't actually reference a base. But if I wanted to select like the dev environment here, we've got a lot of these resources captured in bases because we don't wanna duplicate them in our code base. So in our dev overlay, this is a directory that you're meant to apply from. It's an overlay. You do customize build and it's gonna reach out of that directory back to here. So if you structure your repo like that, it won't work, obviously. But that is a design choice that we've made here in bot info and your model repo would obviously be structured a different way to accommodate that. And then when you actually apply from those, this is what the customization looks like. It has a reference to the source. Here's our OCI repository, bot info, the bot info production one. And here we've gone a step further to isolate. So this is not a strict of isolation. We've still got access to the entire deploy directory. We want it if we can edit this customization, but we have, yeah, so here we have the further selector that says, I'm only deploying this one environment here. So maybe you have a different one in each cluster if you have cluster separation for your environments or however you have that arranged. I see we have a question about the Flex CLI. Yeah, so the Flex CLI is definitely something that you don't need to use if you, it's a convenience wrapper for a lot of things. So Flex Bootstrap is a fairly involved process. And so Flex Bootstrap, we do recommend people actually use the CLI for Flex Bootstrap because it involves handling secrets and that can be messy. And we've got a particular opinion about how it should be done for security purposes. But another great feature of the CLI is the generator feature. If you are running FlexCreate anything, if I wanted to get one of these structures out, I can say FlexCreate customization and give it a name. And say I wanna export this and that's obviously not enough options. I haven't told it where to pull from but it will give me the entire structure. And here is where I will fill out what I need to pull from. We've got a couple of extra things here that are optional fields. I do recommend that you check those out in the docs but if you're using VS Code, as you see you don't actually have to go to the docs. You can just mouse over and assuming everything's connected correctly, you'll get one of these at the top of your file that tells you what schema is being used to parse this and then these values will pop up and you'll be able to see what these fields mean exactly and how they're used from the context. Great. We've got a few more questions but I wanted to go back to that earlier and just broadly, Flex works with all major CI systems. They work with GitHub, GitLab, Bitbucket. So remind people if you have systems in place you don't have to tear them out to use Flux. Flux works very well and has a lot of native support for things like Helm, HashiCroat Vault most recently, and others as well as many integrations that we've been working on with Terraform and as you can see VS Code, OpenShift, et cetera. And to the question of access, yes, your Git provider does have to have access but Pinkie was sharing also that you can use S3 buckets as sources as well. So that might be workaround that works for you. We can keep checking into that if there's more. So there's other questions that came in, came in, do you have thoughts? Adam, the chat just made my day. I was really hoping for that reaction. This is, here it says, this is a new source that solves the issues I ran into when previously trying to implement Flux and that was the reaction that I was hoping to get. We've been saying this is going to be big, it's going to change a lot. I was specifically instructed not to say this changes everything, but just so you know where my head is at, this is really big for Flux and it's going to make a lot of workflows a lot easier. And to remind everybody, these are optional. So if you have things set up in a particular way, you don't have to go run and change it today. But if you are like the companies that we mentioned, enterprise companies who gave us the feedback, hey, we are all in with Flux and then we have these greater needs around scalability and lower complexity. This is why Stefan and team have been working so hard to move this forward. So we're really excited about that. I lost my train of thought. I was going to mention one more thing that was the benefit. Oh, we wanted to share, we talked about GitOps and how these follow the principles of GitOps and so maybe now that you see it's not necessarily dealing with a Git repo but there's still Git under the hood, right? Kingdon, maybe you can explain a little bit that this is still, I mean, not that we have to stick to a term just because it caught on so quickly and as caught on continue to catch on but there's still Git, right? Yeah, and what I mentioned before that we want the artifacts to be traceable back to a specific commit, this is what I mentioned, what I meant specifically. So this source annotation that gets added to the OCI repository artifact tells whoever has access to the metadata of that OCI repository artifact that it comes from a particular origin source repo and at a particular revision. This is how it's communicated, what version's been deployed if you wanna go and look at the, where is that here? Let's see. One of the probably the source we need to look at to see this. Okay, so it's not quite there but here in the status, you can see the particular revision and I will make an action item here to make that surface here because you should be able to see all of the really important stuff here in the mouseover but it's actually in the status in a field. We haven't exposed yet to bubble up. So this should give confidence that your releases are traced back to Git and that you're still able to identify exactly what sources are in production at any given time. We have definitely prioritized some work around cosine and other more rigorous ways to prove those things, to prove providence and we should expect to see those landing in the next minor release of flux, more interesting things around cosine, verification of OCI sources, signatures. So it is definitely still GitOps and the OCI repository still is shaped in a lot of ways like Git. These immutable tags are persistent. They'll stick around. The immutable tag is a pointer. It's much like a Git branch ref. So if you're already pulling changes from the main branch of the Git repo, you shouldn't feel uncomfortable in any way about pulling changes from the production tag in an OCI repo. It's exactly the same thing, just a different protocol. But I did wanna highlight something that is possible in OCI that has been a little bit difficult depending on what platform you're on. Here's another CNCF project called Harbor and this is a feature that's available in Harbor. It's not necessarily available in every container registry. What you can do with this feature is to actually make certain tag patterns immutable or immutable. So if we'd like a repository that we can push to where the production tag is mutable and the staging tag is mutable and maybe we have a few other tags for different environments and then every other tag that's not on the approved list is immutable, cannot be deleted or updated, can only be pushed once and that's what we really want. But really, if you're especially paranoid, what you really want is cryptographic integrity and that's what we'll be delivering the next release. But in the meantime, understanding immutability is a very important part of making GitOps real and making it a successful implementation because if you can overwrite an artifact, that's not very secure. Just put it into production. Awesome. Ed says, oh my gosh, I wish mutability roles was a thing in ECR and other registries. So I wanna take a moment, Kingden, you had that diagram that you showed earlier about everything moving to the right. Wouldn't we wanted to take a moment to return to this and talk about why there are security benefits to this process? Yeah, thank you. So what we mentioned before is there is a feature in Flux called image update automation. And the way that this feature works is by Flux over here, monitors container registries for new image versions. And when it finds a new image version, it takes and it pushes a commit back to the Git repository which has that new image version in it. And this has at least two problems. Problem number one is, well, Git repository is our source of truth and we've just made it writable to an automation which is downstream of our code. And so it's probably okay to let Flux because Flux is trustworthy, right? Although I'm a little bit nervous about having that read-write credential on a production cluster that might be reached by nefarious traffic, could be compromised would be much better if we didn't have to have a read-write credential there at all. So what we've proposed in the past is if you want better security, what you should do instead of putting that read-write credential on the production cluster, you should probably write manifests from CI. So that make version set job is an example of a CI, something you could run in CI as part of a release script. But that is still a problem because CI is again downstream of potentially untrusted code and CI could be compromised even if it's a high security area, there's a possibility that someone can retrieve some credentials out of CI. And now that person has access to write to your source of truth again. And that is exactly what we don't want because that's where all of our, that's what we trust implicitly. It's the source of truth. So in this new model, all of the arrows point to the right. Now, when you run your CI job, you've already been pushing a Docker image. You're used to that. So your CI already has right access to a container registry and it's downstream. It's not upstream of anything. And all we're doing now is we're creating another container registry or in the future, it can even be the same registry. I don't have that example today, but you can push layers of different media types. So there would be only one container that has the app itself and also the manifests to deploy the app. So this is a way that you can kind of contain containers and the complexity of containers and wrap them back up into packages that you can distribute that have all the information necessary and they're cryptographically secure. So this right facing is really important because again, we don't wanna compromise our source of truth and we don't wanna grant right access to anyone who is not extremely trustworthy. But also all of the work that's being done on container registries in order to secure them such as cosine is all happening there. A lot of it will be still interested in cryptographic verification of Git commits, but really where the activity is happening right now is down here because this is what's deployed on your cluster. We don't necessarily need to get commits to land in the cluster. I love the response jaw drop. This is great. So Pinky's also reiterating answers in the chat. I think you did answer the question about what cryptographic methods are supported. And then yes, we have a question about UI on the roadmap. Thanks for the question. Yes, we understand. So so much of this talk that we've had about security, one key part about being able to reach our security goals meant that we wanna make sure the UI was always separate and that flux is kind of available to any UIs that are out there. Cause having it built in to the software itself into flux itself creates a lot of security issues. So we've been talking a lot with the community obviously to see where and when these are a key point. So I think the most important thing is that we've made sure that we work with companies that have UI, so there's a UI that's secure and that is supported by a company. And so that's why, as I mentioned earlier, Microsoft has ARC Kubernetes, Amazon has AWS Anywhere, our company WeWorks has Weave GitOps, which by the way, we have a Weave GitOps open source UI that the company does support. So it is free and open source, so you can try that one. And then you've seen, if you've seen any of the past talks around flux, the people at Red Hat and VMware, also the Tanzu team, we're doing different versions. And then that's why we're also looking into these IDEs where if VS Code is one way that you can get some of the information that you need, it's not necessarily a type of UI, but we'd love to have everybody's feedback on the best ways that we can make sure that people can access making changes, getting the information that they need to engage with flux, but also in a way that maintains the security levels that we want. So certainly anybody can, it's open source of people in the community in the past and in the future can continue to contribute to UIs. But right now, because security is the number one priority, we've decided to try these other paths. So if anybody's already using Azure, they can try ARC Kubernetes, if they're already using Amazon, they can try AWS Anywhere, et cetera. So, sorry, EKS Anywhere, I said AWS Anywhere. We can get feedback for that. So please keep giving us those questions of feedback and find ways that work for you. Any other questions? Oh, no, that was a comment. Manifests alongside app image layers is genius, thank you. And, oh, and then Pinky was responding to someone who was asking about places to get started. I think that our hosts here posted the links to our docs. If you go there, you can also see ways to get started as well as ways to get started contributing, if that's what the question was. We have had great feedback, especially from some of the companies that were starting to build. I think there was a talk by a Zscaler and they shared about how, of course in the beginning they were like build versus buy and they started building certain things and then they realized there is this vibrant, active flux community of users and maintainers and contributors all answering questions and thinking about the next challenge and building toward those and helping to test, et cetera, that they just said it made sense to just work with something that's in the CNCF than obviously to build their own. So that was really gratifying to hear and that's why this type of work is there. So even if you're not thinking about OCI today, it's good to know that you've got a global team of maintainers across many companies already thinking about that for the future. So I'm just doing a time check because I know we're getting to about the last five minutes. But if you have any questions, keep posting them, but I think Kingden will kind of go into a recap here. Maybe you can do a show the full slides. It's a little hard for me. Oh, sure, yeah. So I wanted to drop these links just to make sure that everyone is aware of where the examples came from. And I have done, I've taken a little bit of liberty composing these examples together to try to make them fit well with our Podinfo example app. Hopefully you all enjoyed that and you can check out the cheat sheet for the basic workflow examples that start from Flux CLI and they move on to GitHub Actions. If you're using GitHub Actions or use something else, that's fine. And there's a Docker build and tag with version in here that is very simple. So what we've done is we showed an example GitHub Actions for Docker build and push and also Flux push and tag. And we've shown that these are sort of parallel behaviors. They're meant to work together in a similar way. And only for OCI manifests. And what did we learn? Exactly how to deploy multiple environments for our application and how to automate deployment promotion workflow. And also what is an OCI repository? How do we ship those YAML manifests as OCI repository? How do we deploy from CI? Two different ways. There's a third way in there. If you look, we've chosen these ways because they seem to fit the best. So you notice, I say staging here and it was pre-production there. If you go in and check it out, you'll find out exactly what was the issue there. But there's lots of different ways you can put these things together. And as a bonus, we included this workflow for manual approvals with GitHub Actions that you hopefully enjoyed as well. So we hope that you'll join our community and if you need support, we're always open to questions. We love questions, especially hard ones. Yes. And so the links here will send you to the Slack channel that we have, if you have questions or any other ways that if you wanna get started with contributing. Just wanna highlight, even our community members who've been using Flux for a long time, sometimes they forget or if you're new to it, Flux is so fast-moving that we'll just do a couple of reminders that Flux hopefully it's clear to you how it provides GitOps and it's constantly evolving. People use it for GitOps for their apps as well as infrastructure and it is multi-everything. It's multi-tenancy, it provides multi-tenancy, multi-cluster, multi-everything. And hopefully you'll be able to see how vibrant the community is. One thing I think we didn't quite highlight is that Flux works with your existing tools and it works with Kubernetes as well. So sometimes people don't see like what part Kubernetes is offering and what Flux is offering, but Flux works very well with Kubernetes to provide all these different steps that creates the end result of GitOps. So yes, check out our website, which is fluxcd.io. And also of course we're on GitHub. I think we shared the links earlier and give us a star on GitHub if you like us. Perfect, I see a lot of thank yous from the audience coming in as well. So a really great session from, I say that as well as the audience. So really amazing to see that. Yes. Yes. Great. Thanks again to Pinky or Priyanka aka Pinky for helping with the questions in the background. Always, always great. Perfect. Thanks for hosting us, this has been great. Yes, of course. And if there's no any final notes from you guys, we can start wrapping the session up. Such a positive mood, really great to see that. Yeah, so thank you everyone for joining the latest Cloud Native live episode. It was really great to have amazing speakers here with us as well as Priyanka answering the questions on the chat, really great to see that. And we really also love the interaction from the audience. Thank you so much for all of your questions and comments as well as draw drops. Always great to see that. And as always, we bring you the latest Cloud Native code every Wednesday. So join us next week as well when we will have a session on certificate management with LinkerD. So thanks for joining us today and see you next week. Thanks everybody. Bye.