2:59 Introduction to Acorn

2:59 Hello, and welcome back to the Rawkode Academy. I am your host, David Flanagan, also known across Internet as Rawkode. Today, we are taking a look at a new tool to help simplify deployments to Kubernetes. The tool is called Acorn, and and tradition to to us today and giving us more context and insights is Darren Shepherd, the chief architect and vendor. Hey, man. How's it going? Hello. Good. Good. Excited to be here. Excited to show off Acorn. Awesome. Well, thank you for joining us today. I think I I'm particularly excited for this one. I'm looking forward to seeing how we

3:34 can kind of change the way that Kubernetes apps are deployed today. We are in a a very interesting landscape. I don't know if that's the right way to phrase it. But I remember speaking to Brian Grant once at Google, and he said he has a spreadsheet and has over a thousand tools to deploy to Kubernetes customers. That's a lot my gosh. Yeah. Yeah. A lot of opinions. So before we take a look at Acorn, do you wanna give us a a quick introduction into who you are and what you're up to? Yeah. So so, yeah, so I'm Darren Sheppard.

3:59 Introduction

4:06 I'm the chief architect at Acorn Labs labs. So we're a new startup doing Acorn. Previously, I was at Rancher, so I've kinda been in the Kubernetes space for a while. Currently, k three s. That's probably the most popular thing that I've that I've done. So, yeah, that's kind of my background. Been doing k three s for a while. And and if you follow me on Twitter, I'm on Twitter at I Build The Cloud. I'm I'm pretty well known for just complaining about everything. Just frustrated and complaining about everything. And so so yeah. Yeah. That's that's not a bad thing. Like,

4:43 when we get frustrated at software, we get to bring our opinions and hopefully make the entire community and ecosystem better by solving some of those frustrations. Right? And I I'm hoping that's what Yeah. Is to some degree that as you take a look at this landscape of Kubernetes, this can be better. Yeah. I mean, that's, like, their basic idea is, like, it's just try to you know, it's like I complain a lot, but I also do write software and try to fix things. And so the idea with with Acorn is to try to, you know, make deploying apps

5:12 on Kubernetes, you know, just a simpler experience. Well, yeah. I mean, you've got that bit of a legacy behind you now with KCS. Like, deploying and running a Kubernetes cluster is cumbersome at best and painful and sleep deprived at worst. And that single lane deploy of KCS really made everyone's lives a lot simpler and easier. So, you know, hopefully, you're bringing that same kind of frustration solving approach driven development to Acorn, and hopefully, it's helping everybody as well. Yeah. Yeah. So, I mean, so, like, when I announced Acorn, the kind of the the blog, I I I wrote a blog that

5:46 Acorn's Focus: Simplifying Application Deployment

5:51 kind of told a little story about with my son where I he wanted a Minecraft server. He wanted me to run Minecraft server. So I went and I ran a k three s. So, you know, it's like I created k three s. I can go and run it. It's really simple. And then I started, like, creating the Minecraft server on there, and and I just got frustrated with it. I was just like, this is just way too much effort. And I went back to Docker Compose, and I'm just like, there's there's gotta be a better, you know, a better way to

6:17 run applications. Because, like, for just some simple little side thing, like running the Minecraft servers, like, this is just way too much effort. So I kind of look at it as, like, you know, k three s was my best attempt at making running the cluster really easy for just kind of like a random person or or there's a lot of, you know, amazing production use cases for it. But so this is like, now I wanna move up the stack and just focus on deployments. Like, how do you actually make consuming and using Kubernetes easier? Awesome.

6:46 So I'm going for a a correction before I get something really wrong. I think that's thousand tools. I know it's, it's a hundred. I'm starting to doubt myself, but I can't remember. So I'm gonna clarify that later. But just in case anyone's sitting right here Okay. Ridiculous. Well, all you have to do yeah. Just just look at the CNCF landscape, and, like, that convinces you of the complexity. It's like, you know, that thing just the icons just keep getting smaller and smaller on there. So Yeah. More and more things to learn all the time. But I'm not I'm not gonna

7:14 run up with that today. Alright. Let's talk about, you know, kind of I wanna touch on the inspiration behind Acorn. Like, I'm assuming your your first Kubernetes application deployment wasn't with Acorn, of course. So I'm curious about Oh, no. Of course. Yeah. You know, what's your what's your journey there? Did you if you always just use straight up YAML, have you played with other tools? How did we get to where we are Yeah. So, I mean, I've so honestly so the my biggest focus within, like, the Kubernetes world has actually been helping people deploy clusters. And

7:48 so I haven't spent, like, a significant like, I haven't spent a significant time, like, myself having to write and manage deployments on top of Kubernetes because I've, you know, last five or six years at at Rancher, which is all about running clusters, so the infrastructure ends. So I haven't you know, my my past is not so much running applications specifically. Because, like, honestly, whenever I got into that space, I would just get frustrated. But at Rancher, like, we did our best to really try to standardize around Helm. We did a lot of Helm. So I know

8:23 Helm, like, through and through every little trick with it. Know the guts of that very, very well. And so we kind of did our best to try to make you know, like, how can we manage deployments with Helm? And so that's kind of one of the like, just looking at the complexities of, creating Helm charts. But the thing that was interesting when I looked at Helm was it was like, well, how could I do Helm better? And it's like, well, you know, you could definitely improve, like, the syntax or something. You know? The the templating is kind of difficult.

8:55 But, fundamentally, the the thing with Helm was that Kubernetes can do anything, and, therefore, Helm can do anything because it's designed to just package anything. And so that kind of led to this problem of, like, well, I can't really actually make Helm better because it has to do absolutely everything. So, like, when I started Acorn was like, well, what if I just focus on application? Not like I wanna deploy a CNI driver or, you know, like, the storage system, the real low level stuff that needs, like, privileges and, like, you know, low level like, what

9:24 if I just focus on applications? Can I make that better? And so, like, as I looked at that, it's like, oh, yeah. This becomes drastically easier if we just kinda look at the application domain. And so that's, you know, that's kinda where Acorn sits. It's like Helm does absolutely everything, you kinda get the the pros and cons of that, but Acorn is is focused more on just the application deployments. Yeah. Yeah. I mean, this is no surprise to people who have watched my channel before, but this is our first conversation. My my not I don't wanna say hatred of Helm,

9:54 but I have a not a lot of pretty happy things to say about Helm. And it's not because it's tool. It's because every option in a Helm chart now becomes a point of configuration. And we end up with this explosion of interpolation and templating and conditionals and a huge values Yep. You know, which now needs a schema, which now have baked the comments. And I'm just like, we've went down a very dark path here and we're we're kinda not doing best practice. We're not even doing good practice. We're just retrofitting something. I'm also not a fan of code template

10:27 language either. I think, you know Me neither. Yeah. Mean Yeah. Go for it. Yeah. Go ahead. I mean, I've made the comment before. Like, I think the only reason why it's popular is because it's in the SDK. It's like it's it's just part of Golang itself, so people are like, oh, I'll just default to that. I don't have to have another library. But it is one of the, yeah, kind of oddest I don't know how to say it nice. I'm not a fan either. You know? Yeah. I mean, we don't need to go into start discussing template in languages, but a

10:58 lot of other languages have kind of just adopted Jinja or some form of Jinja, and that works relatively well. But Go, we just went a completely different route. And it goes against Yeah. What I'm familiar with for So all these tool it's like all these tools, like because I get frustrated too. It's like I get frustrated with Kubernetes because, like, Kubernetes fundamentally just is kind of, like, raw verbose thing you have to deal with. Or I get frustrated with Helm. And and it's like you know, because people have said, like, well, you know, why don't

11:24 you commit to, like, core Kubernetes and make it better? And it's like, well, I can't necessarily make it better because, like, it is what it is. Like, it is as powerful and as successful as it is because of the raw and verbose nature because it's like, it's a platform that does everything for everyone. So, like, I don't think there's anything, like, funded like, because all I'm saying, like, I'm trying to make running apps on Kubernetes easier. It's like, I don't think there's anything fundamentally wrong with Kubernetes. It's just there's not a proper, like, application abstraction on top of Kubernetes that exists

11:53 today. And, like, everyone who's done that has basically kind of failed. And, like, my kinda hypothesis there is that is people that focus too much on CRDs and Kubernetes APIs, that that kinda laid you down a dark path that's, like, kind of not compatible with a lot of things. Because I I failed in the same way. There was another project I did a couple years ago called Rio where I was trying to address kind of this application layer. And that you know, there were some interesting things we did there, but all in all, it was not what I wanted it to

12:22 be. And kinda my takeaway from that was, like, if I'm really focusing on application, you can't get too much into the weeds of Kubernetes. Like, you need to abstract yourself. So, like, with Acorn, we took a stronger approach of, like, let's provide a proper abstraction layer. Like, we're not doing with Kubernetes YAML. We have our own DSL. You can largely survive with just like, if you're, like, an, just deploying apps, you can largely just survive with, like, the Acorn tool. But it was yeah. Yeah. You're right. Kubernetes kinda gives us these, like, primitives to pods, replicates, deployment services. I think

12:59 there is, like, pretty much 90% of what any application developer really needs to deploy your application, but we do have this whole what that I mean, that's probably less than 1% of the number of resource definitions that are actually out there for the Kubernetes environment. And we have seen Yep. Other composite style resources. Like, I'm pretty sure there was an application CRD spec from at one point or was being developed. But I don't think I've ever seen a Yeah. Date. So But, like, that's like, that like, so the problem is, like, when you get to

13:29 this application layer is, like, you really have to start applying some opinion. Like, it's really hard to come up with, like, let's create the specification that everyone agrees on and can do everything. You know? Like, there's gotta be so it's very difficult. Like, I don't expect, like, the app sync to, like, you know, kind of be able to do that kind of design by committee of the of figuring out, you know, this layer because it becomes so much a nuance. Because a lot of people ask, like, well, you know, there's tons of solutions that try to simplify the application layer.

14:00 You know, why is Acorn different? And it's like, can tell you a bunch of, like, technical differences in our approach or whatever. But, fundamentally, it's like, well, I I think we have a unique approach, and that's subjective, and we'll see if people like it. So it's like, you know, hopefully, try Acorn, and they like it. And if they don't like it, then it wasn't good. Know? Nice. We we actually have a a comment in the chat for Bob then who was about to ask if you know about Rio and whatever happened to it. So at least

14:28 there's a couple of people watching that are familiar with the work there. Oh, yeah. Well, I mean, I mean, I don't know I don't know if you realize. So I wrote Rio. Like, that was my that was so the the the backstory is k three s came from Rio. So it was kind of like Rio was a failure, but as a side effect of that of that project came k three s. So we're like, well, I guess that was a success in that, like, we got something out of it. But Rio, it was fundamentally, I don't think that the timing was right

14:53 for it because we started Rio as being a a more abstracted thing, but users just consistently wanted the raw access to Kubernetes. They're like, no. I wanna be able to have access to Kubernetes. And and we I mean, I didn't think that was the best so it's like we basically kinda morphed it to be more Kubernetes like, which then basically kind of destroyed any of the things we were trying to do. So so now I think the timing's different in that, like, one, the shiny cool factor of of Kubernetes is going down. It's not like the new

15:27 hotness. So there's a lot of people who are just, like, you know, been there, done that. They're like, I've done deployments a million times, and I would just like something easier. The other thing is Kubernetes continues to, you know, get adopted. Like, there's no there's, like, no slowing it down right now, And there's just more and more users coming into the space who don't you know, they're not like the early adopters who level you know, it's like, they just kinda wanna get things done. They're looking for simpler approaches. So there's there's a so the kind of the the timing is different now

15:56 where we can actually, I think, produce a tool that's provides a more abstracted experience that's that's simpler. Okay. So one last question, and then we'll we'll actually let you share your screen, and we'll take a look at Acorn. But I'm curious about not that I need that minute by minute account of the night you went, screw this. I'm gonna write on your tool. But I'm assuming you said you were frustrated. And there are tools out there that I think are quite decent, you know, that we got Pulumi, which of course I work for, so I'm

16:06 Comparing Acorn with Other Deployment Tools

16:25 always gonna mention them. And CDK Yeah. Which has been growing adoption, which allows us to build these kind of abstractions. Are these things that you've played with? And then there was, like, this point where you went, well, that's not what I need. I need something else. So what was Yeah. Yeah. So I I mean, there's a good point, like, Pulumi, CDK, Terraform. Those kind of tools in my mind, they all kind of operate at the infrastructure space. So they're really good for, like, managing clouds and and things like that. I think when you get because, like, what you see

16:53 a lot of times is, like, those kind of tools are basically setting up all the infrastructure, the cloud, and all that, like, the all the cloud resources. And then it's kinda like those will then basically set up a pipeline, and now your pipeline for your application deployments is following, like, a different a slightly different procedure using, like, GitOps and or tilt or or whatever dev spaces. There's there's a couple different dev tools I fooled around with. So I think, you know, I like, I don't think, like, those those tools are are really the same domain as, like, the application

17:29 deployment and, like like, just the pure app layer. I mean, I could be wrong, but that's kind of my my my opinion on it or whatever. But the when you get to the like, the just Kubernetes development tools, the problem that I see is that, like I mean, they're very they're raw. They're very diff like, basically, like, let's say, like, something like Tilt. It's kind of like what you need to do to use something like Tilt is you first kinda have to have a Kubernetes deployment. Like so you already have to have an expert in Kubernetes

18:02 who could kinda define how this application is gonna be deployed. So then you kinda move that back into development, and then you set up the tilt file to say, okay. How am I gonna iterate on this this this application in in development? So it's kind of like it it starts from, like, the ops side or somebody who really knows Kubernetes and then moves back to the developers. And so it's like, by the time you get to the developers, it's like it's kind of an odd experience. Like, it works for someone who just, like, basically, like, I can

18:31 do a git clone, and I just run this thing. But they don't really know what's going on. They don't really change anything. It's just like you know, it's it's just basically insert code here. So there's, like, that approach, but and I I don't see those tools have been, like, super popular. They haven't really caught on. Like, the the biggest container oriented dev tool that I've seen is is that's by far the most popular is Docker Compose. And but so you see still today a lot of developers are using Docker Compose on their laptop. But then once they go to production, they

19:00 still do Kubernetes, or maybe they're still in ECS. But if they move to Kubernetes, it's like then they switch to, like, Helm and and customize and whatever, and then it like, there's a lot of disconnect and friction there. Okay. Yeah. I think maybe in my head then, I I had Acorn slightly in the the wrong place. I wasn't thinking about it as a tool similar to DevSpace until Docker Compose, but now that I'm thinking about it, it does kind of satisfy that local experience. Does it move into the cluster as well? Like, is Acorn a tool that can use?

19:14 Acorn Architecture: Packaging as OCI Artifacts

19:35 Yeah. Yeah. So it's both. So the thing is is, like so fundamentally, what Acorn is technology is, like, at the heart of it, it's an application package. So it's like we actually build and package up an application as an OCI artifact, like a Docker image. You can push and pull the whole thing as a Docker image. So it's kind of like it's it's like a two headed beast. It's like on one side, we have a package that's easy to create for like, development can interact with it. If you can do Docker Compose, you can interact with Acorn.

20:01 But then on the other side, it's a package that, like, the ops or DevOps team can take and very easily deploy. It's a very well known unit. It's well defined. It's secured by default. It has, like you know, it's like the it's like something you can trust because well, you know, it's alpha software, so don't trust it very much. But, like but the idea is is to get there because it's like I I wanted you know? So it's like it's kinda like as as applications are coming from your app teams. Because I see this within the enterprise perspective. Like, they have

20:31 difficulty onboarding a lot of app teams. So you have, like, this one central, like, team that manages Kubernetes, and they have to onboard all these app teams. And so it's like, if the applications are developed using Acorn, then they can just very easily give that to the op team, and they'll know exactly how to run it. It integrates very well into all the Kubernetes stuff, GitOps, everything, but it's, a very well known unit. Whereas, like, a Helm chart is kind of, like, giving like, if you had the Helm chart to, like, your op you know, just, like,

20:57 deploying production, it's the equivalent of basically giving a shell script. It's just like you know, it's it's very difficult. It's like you don't really know what it's gonna do, so then you have to put in a lot of, you know, guardrails around that, you know, auditing and and, you know, make sure you the RBAC and, you know, all this stuff. So but, yeah, hopefully, as I demo it, like like, it'll become a little bit more clear what it is. Well, yeah, you you said lots of really cool things there that I'm quite excited about. The fact that you're pushing

21:26 things to as an OCI artifact to registry, I think, of where we're moving. I see all these gaps. So those are the nests. Now we're seeing this from flux. We're seeing it from Argo. This just seems to be like the new the new standard. So I think what we do is we let you share your screen. You give us the Yep. Overview of how this all works, and and then we can get some more questions back. Okay. So let me share share my screen. Minimize that so we don't get nested. I'm gonna do just one slide so you get a

21:47 Live Demo: Installing Acorn and Acornfile Basics

21:54 visual representation, and then I'll go into just programming. I'm not gonna do, like, slide where Oh, your slides are up, so either way. Yeah. Let me see. Did that work? From okay. Yeah. Whatever. You can just see it. So, basically, the whole idea of the Acorn is, like, we start with an Acorn file. You notice, like, Acorn file kinda sounds like Dockerfile. It's even written in the same style. You'll see as I demo this, like, we took tons of inspiration from Docker and Docker Compose in the user experience because, honestly, I think those are incredible tools.

22:25 From a like, I haven't seen any other tool. Like, I mean, just the fact that the way that people can pick up and learn Docker so quickly and use it, become productive, you know, it's like there's something to be admired there, and so we kind of copied a lot of that. So the the basic idea is you have an Acorn file, which is like your the the equivalent of, like, the Docker file today will build an image, whereas the Acorn file will build, an application. And the Acorn file can reference Docker files, so you can also build the images as

22:53 you're building the the application. So, basically, we run that. We create the Acorn image, which is an OCI artifact, and so it does include all of the Docker images associated. So you get one image, like one digest, one thing to sign. That's completely you know, as you're moving around environments, you you can you know, you know it's the exact same thing. It's it's not like a Helm chart where, like, the Helm chart is just the metadata, which then references images, and then those images can change as you move around. And you have to worry about, like, mirroring con mirroring content

23:26 if you wanna do offline, like, air gap setups and stuff like that. But, anyway, so we we push that image to an OCA registry. So once it's up there in the registry, then you can run it from any cluster, any Kubernetes cluster. We just need, like, the Acorn runtime, which is effectively just an operator or controller, whatever you wanna call it. So it does require admin privileges to install that. I'm fooling around with, like, a solution that doesn't require admin. But, like, right now, it requires admin to install the runtime on the on the Kubernetes cluster. But once you have that, then

23:58 then you can you can run these apps. So, like, that's, like, the 10,000 foot view of kind of what Acorn is. I can just go right into demoing it now if you want. Okay. Yeah. And please, like, stop me, ask questions, or or whatever. Yeah. Of course. Because I I have a 10 like, I'll just keep going and talking and do out a million things. So if you wanna so the way to install this, the easiest way is just through Brew, or you can go to the the GitHub page, and there's binaries you can download. So

24:34 we have Windows Windows, Mac, and Linux and the architectures, whatever. So you just install with Brew. I already have it installed, obviously. Once you have it, you do need a Kubernetes cluster. So if you're fully on this on your laptop, Docker desktop or Rancher desktop should work just out of the box. You know, if you have any weird issues, you know, go to our GitHub issues, discussions, or Slack channel, and we'll help you out. We're doing our best because, like, you know, there's so many different styles of clusters. And so it's like if you do,

25:12 like, minikube or kind, there's a couple more steps you need to do because we need an ingress controller. But we're trying to document that all. But I just know if, like, the simplest experience is Docker desktop or Rancher desktop right now. Yeah. Okay. But to install it, you're just gonna run, like, Acorn install. And this is where I said you need the runtime. So this is gonna install the runtime on the cluster. I already have it installed, so that just, you know, went super fast or whatever. But so now now I have this, and I can start

25:42 fooling around with it. So if let me just show you kinda the high level of the commands. I'm not gonna go through each one individually, but it's like you see things like log in, log out, push pull, tag, run, build. So, basically, it follows a very similar type. So if you're familiar with building Docker containers and pushing and pulling those, Acorn's gonna feel very comfortable because you're basically doing, like, a very similar thing. We're building eight application images and running them. So let me show you this little this sample that we have. So this I'll I'll I'll go through. If we have

26:22 enough time, I'll show you kind of, like, two different things. Like, this first is, like, a a good like, this is actually the app from our getting started guide, but it's gonna show you kind of, like, a development flow of, like, packaging up, like, a Flask app or something like that. I have another example in here, which is, like, gonna make more sense to someone who's more, like, DevOps oriented, which is gonna be running Jenkins, like, a a, you know, a Jenkins with the Kubernetes cloud and configuration code, like, that whole setup. And and that one's, like, more complicated, but

26:54 I'll I'll get to that. So for this little application, so we have, like, just some dumb little Flats gap in here. And then we have a Docker file to build this app. So, again, very simple. Just, you know, copying this over, running TIP. Okay. So now let's look at our Acorn file. And there's quite a bit in here to begin with, and I'll kind of walk through so you can get an idea of, like, what we're seeing in here. Because this is kind of, like, somewhat of, like, a tour de force of the syntax. It's just throwing in a lot

27:25 Syntax

27:27 of things at once. But the first thing you'll notice is the syntax. So the syntax is it's kinda like a JSON. It's a superset of JSON, so it kinda follows JSON. We're we're really heavily inspired by q. I can go into quite a, like, a a long spiel about why exactly it's not q, but, like, we very much like q. We're huge fans of q. I've done a lot of work with q. And so the syntax here is kind of inspired greatly by q, but it it is it is not actually q. So but the syntax since it's like it's kinda

28:03 like JSON like. It should I I we haven't really seen much people, like, struggle with, like, learning that. It's all documented if you go to our docs. But what I have here in this Acorn file, I'll start off. We have ARMs at the top. So ARMs are it's kinda like the equivalent of your helm values. If you wanna pass in parameters at build or deploy time, the you can define ARGs, and then people can can reference those. I'll show you the ARGs, how they work after I build this. But so at this top level here, I've

28:33 defined containers, and I have basically three containers. I have this first one, which is the app, which this is the the Postgres app. No. I'm sorry. The Flask app that talks to Postgres. And and so there are couple things going on here. First is I'm doing build. I'm gonna build this from the Docker container. I'm setting some environment variables. You'll see some interesting syntax here. Like, I'm pulling in some secrets. I'll just explain that just a little bit. And this here's where I'm referencing that bar to get the the welcome. And then you can see a little condition

28:51 Environment Variables

29:05 here of, like, if args, whatever. This is this this is so, like, when we're running this in development mode, it's gonna be slightly different than if we build it for production. And I'll show you what I'll talk about what development mode is later. You can have depends on. This just starts this is controls the update and starting order of things. In development, we wanna cop live sync over some files, and this is how we basically publish the port. So these other ones here, this is a Reddit cache, and this is Postgres. I'm not gonna go into detail on

29:13 Development Mode

29:37 those, but let's get into actually building the application. So if I wanna build this, I can I can tag it as something? I don't really need to yeah. I'll I'll tag it just as, like, demo right now. So we'll go and build this. So this is going it's doing, like, it's doing the Docker build that was include that the Acorn file referenced, and then it's also building the final, application, which is the the one the one image. So, so I should see now when I view this oh, I just it was this one right here. I just built that demo image.

30:07 Live Demo: Running the Application (and Troubleshooting)

30:12 So now I can run this. So I can just say Acorn run, demo. And now if I just kinda watch the output here oops. Mac's on that watch, I guess. So this is coming up, and then, hopefully, this is oh, this is Docker. Can I pop in for a second? Yeah. So the first thing is we're kinda missing the first line and the last line of your terminal. Could you, like, just Oh, shoot. Roll your window a little bit so it's not as tall? I don't know. I think the aspect ratio is a bit weird, and I've been trying

30:14 Run Demo

30:49 to work around it, but I can't quite get it. Okay. Sorry about that. Well, what I can do let me not let me do what's the there's, like, a diff no. There's another may no. Is that better? Is it is it or is it still chopped off? Yeah. The bottom the first line and the last lines need to be chopped off. If you just, like, make it less tall, so just drag it up a little bit. Yeah. Yeah. Yeah. Alright. Come on. Why can't I select alright. Okay. There we go. That's it. Okay. Perfect. Thank you. Is that

31:27 it? Oh, okay. Oh, that's terrible. So you couldn't see the commands I was typing? Well, we we were lucky. We could see, like, 90%. It was just when you, like, cleared the screen, the first command, and then when it got filled the screen, we missed the last. But it was okay. We we followed along. We're still working. So Okay. So so you can see here so I built the application, and then I ran it. So now I'm running it. And you'll see, like, we we in the application definition let me go back to the Acorn file real quick. I defined

31:58 publish HTTP. If you do HTTP under the hood, it's gonna use ingress, which then, requires, like, DNS. And so we automatically do a bunch of tricks with DNS. So you get oh, wow. The default terminal is terrible on a Mac. I can even click on the URL. I don't use Macs. I I I use a I use Linux, but I had to switch to it for this for this thing. I had some problem. Internal server error. Oh, okay. Wait. Here's the server. Why is it doing that? Let's see let's see why that's. Oh, oh, okay.

32:53 Okay. We'll we'll we'll fix that. So there's there's a little problem in the in the apple in the application. But but, anyways so we'll I'll I'll show you. We'll fix that. And so we can kind of go into the the development mode. Okay. So so the idea is as I said, you can, you know, you rerun run the app, and then we give you a URL, and then you can get get into it get into the app. So if I wanted to update this application, like, if I made some some change or whatever so, basically, you would just go through the

33:26 flow. Like, you know, if I wanted to, you know, put some something in here, then you can go and, you know, build this again. I'll do. So, like, this will go build your application again. And then I can just go and update. I think I missed the. Update. Let me say image, right, demo two, and then that will then update it. So the that's kinda like the manual flow of, like you know, so you can build, push, and whatever. So this is all, like, going to the CLI. I want to point out under the hood, this is, like, a % Kubernetes architecture.

34:17 There's a Kubernetes API under there and all that stuff. So if you, you know, you wanna get into, like, and GitOps and all this stuff or whatever, it's all completely compatible. The the Acorn like, the CLI is just, like, a really nice experience on top of the API, but it's it's all standard stuff under the hood. But so so what I wanted to show is so I just did, like, a manual of, like, build it and then then update it. What you can do is if you're running this, like, in a development mode let me just delete the app.

34:52 Let me just delete everything. Okay. So what we can do is we can run this in a development mode, and this is gonna be much closer to, like, a Docker Compose app. So you can do dash dash dev. The short form of that is I, which is kind of a little weird, but and I'm gonna actually I'm gonna call it, a demo so we have a nice little name or whatever. So now this is gonna run this in a in a in a, development mode. And so what you can do is, like, this will build it

35:17 and bring up the application, and then it will live you know, tail everything that's going on. Let's wait for the the it Ingress control or NGINX Ingress controller is super slow to provision. Like so that it's that's why it says pending. It's waiting on the ingress controller to assign to assign something. There we go. So now it's up. Okay. Just copy that. Go back here. Oh, I don't know. I don't know what the deal is. Scram authentication requires version 10 or above. Am I running let me just see if I'm running them. Guess okay. And your requirements.

36:16 Yeah. I don't know. So why is it even doing authentication? I think it's Okay. Well, let's let's talk to like, maybe let me look at this. I don't know. This is one of those things. You know? It's like, well, it was working yesterday. So let me talk about, like, the authentication and stuff. Like, this is the authentication of what's what's failing. So you can see here, where we started up Postgres, and we're using oh, let me make sure okay. I'll get back get back to that one in a second. I might be using an old data volume.

36:39 Acornfile: Secrets and Configuration

36:54 But so so you can see here the secrets. So we've defined the secret here called quick start PG pass or whatever, and it's of type token. So what we do with secrets is, like, we wanna by default we want apps to kinda work out of the box and securely. So we have a couple of built in secret types that will just generate a value for you. So this one, it just generates a token, and there's parameters. You can control what characters and how long, but it just generates a random a random token. So so what this is doing so this

37:27 secret, it generates this token, and then we can pass that secret, the token value to the password here, and then we can also pass the same thing here to the the password up here. So that works for, like, development. It'll automatically, like, like, generate the secret. At in production, you can then bind in secrets. So, like, as part of, like, the run command, you can do things here where you bind in secrets. So if you have an existing secret, like, you know, it's you can create the secret if you want using the RCLI, but under the hood, they're they're still just

37:49 Bind in Secrets

38:05 Kubernetes secret. So it's like, you know, if you're doing sealed secrets or external secrets or, you know, whatever whatever crazy way you wanna manage secrets, you can manage those independently and then just bind them into the application, and you'll use them. Okay. So so let me show let's see if we can I wonder if we can figure out why this? It says SCRM authentication requires libpk version 10 or above. So I wonder if, like, it's a new version of Postgres. Should we try? Do you know anything about about Very good. Let me check. Let me see. I wonder I wonder let

38:56 me try, like, not the PostgreSQL. No. Let's see. Is your Kubernetes cluster on is that local? Is it Docker for Mac? Yeah. Yeah. It's just a Docker for Mac. Yeah. Okay. So it apparently is an m one problem. It's an m one problem? Oh, okay. Yeah. Yeah. That makes sense. So, apparently, if if you're happy to rebuild your images, you have to export docker underscore default underscore platform equals one app slash e m d 64 and then do a rebuild of your images, and that will remove the error. So I'm assuming your Python app has been

39:32 But I can't It's not 64. But I can't yeah. So that won't work. Well, okay. Well, that that's fine. I mean, that whatever. So the app is failing. That's an arm arm issue, whatever. But at this point, we can talk about multi arc. We basically we we can like, if you wanna build like, if I want to build this I mean, I can I can build it for AMD sixty four, but the problem is I won't it doesn't really help because I can't run it? But right? I don't think I can run an AMD sixty four on I don't think that

40:05 works in Docker or whatever. But but, anyways but, yeah, so if, like, I actually wanted to build am I still in this app? So if I wanted to build this application and I wanted to support, both, Linux AMD sixty four and Linux ARM 64, and then let's just tag this as we'll actually show, like, pushing the I build the cloud. Demo test. So this will actually go and build both architectures and then combine it into one image. So, I mean, we're this is all standard OCI stuff, so we are using manifest lists and all that under the hood. So we

40:45 just basically are pulling in the different the requirements from from different I mean, we're sorry. No. The requirements. I just read that. We're pulling in the images from different architectures and then just linking them all together. So I think that just did the AMD one, and now, yeah, it's probably doing that. Or, yeah, now it's doing the arm one maybe. But if I actually wanna push this so, like, I just built this image as so now I can actually push it. And this first one that will fail because I don't have oh, sorry. There's one one tiny little thing

41:23 that I forgot. You have to put the full registry in there, like Docker.io. We don't have a default namespace. Like, that's been, like, a big problem with Docker in general is the default namespace always goes to Docker IO. So so we just decided we're just not gonna have a default namespace. So that's why that that push failed, but this will fail also because I haven't logged in. It's gonna it'll end up oh, wait. No. I guess I have. Oh, I already used this. That was that was nice. Oh, yeah. Because I already had this set up.

41:56 Okay. So so that's that's kind of the basic flow. I mean, are you kind of getting the the the over kind of the overview of kinda how Acorn works? And Yeah. I think so. I I'd like to take a few steps back and slow down and just kinda cover everything. Although, I'm slightly worried that you've frozen these now there. Oh, yeah. Let me let me just cancel that because it's trying to push up the content. Yeah. Yeah. Got it. So let's take a few steps back. Let's pop open the Acorn file, and I've got a couple of questions

42:23 Acornfile Language Design Philosophy (Why not Q?)

42:27 from and there, and then we'll take a look at the template. And if anyone watching us live has any questions, feel free to drop them into the comments, and we'll get around to them Yeah. Shortly. Alright. So the first question is, you mentioned us earlier. It looks like q. You like q, but it's not q. I also like q. So I'm curious. Why have you got why is it not just q? What were the what was the thinking there? So the scope of queue, like, queue I mean, it's an amazing language, and the scope of queue, like

42:58 basically, what it comes down to is queue the whole fundamental thing about is, like, unification. It's, like, unification disjunctions. It works so it's combining the idea of, like, schema and data into this one thing, and it's, like, really beautifully well done. I very much like it. So kind of the problem with queue is that all of the unique and cool features of it, we don't actually need. We really just need a language that's kinda much closer to to JSON. But we like the style of queue better. Like, they're it's kinda a little more elegant and

43:33 simpler in the in the approach. So when so one of the number one feedbacks we got as we kind of started building Acorn, we showed it to people, is, it's, like, basically the difficulty of queue because you start getting into all of, like, the schema and all those other things that basically they didn't need. And so there's all this stuff in queue that we don't need that basically kinda confuses users. But then on top of it, it leads to a lot of unexpected behavior for people. Like, so, fundamentally, what we got back there he's like, there's

44:09 two there's two feedback we always got. Was one is they want an else statement, which is funny, but a q doesn't have an else statement. Statement. Just has if. And then the second one was was that they really wanna be able to override data. But, fundamentally, you can't override data in queue. But, like, when you get into more complex examples where you're dealing with config files and stuff, that it it becomes kind of obvious that you wanna be able to change keys in different in different situations or whatever. So, basically, as, like, we went through it, like,

44:41 our needs like, I love q, but, like, our needs of what we need for Acorn don't really fully align with, like, what q is and where q is going. Because even, like, those two little small things, like, overriding data or the if blocks, there's reason or the else blocks. The reason why they don't exist is because of, you know, good reasons for q, but, like, those reasons are not applicable to us. So in order to, like, kinda optimize the user experience for users like, this was a difficult decision, but we basically came to a conclusion that we should

45:12 just kinda charge for our with our own language. And so far, we've gotten kind of really no pushback or issue with that. Yeah. I mean, I I like the release the queue. It feels yeah. It works well for me. In fact, I'm pretty confident I could run queue eval on that file, and it probably would just work most, at least from what I can see right now. And being right about the test junctions, those are runs that still trip me up, and I've been using q a long time, and I'm sure even worse for people that

45:38 are new to the language. Because the error messages from q can sometimes lead you down some awkward paths. Very confusing. Yeah. Yeah. So, I mean, I've written, like, thousands and thousands of line. Yeah. It's like, I I've done a lot of queue. And internally, we actually still use queue for some data, like, SKU validation and things like that. But, yeah, like, the the error messages are are kind of difficult, and it's not just because yeah. And it's kind of hard hard to solve solve those things because the the it's just, the fundamental nature of what they're trying

46:06 Security: Secrets, TLS, and Permission Handling

46:13 to do, like, unifying data or unifying the the the values or whatever. So Cool. But but I very much so it's like it's like a very much like queue, but it just didn't work out for this use case. Alright. I'm happy with that. Alright. I've got a couple more questions from here, and then we'll jump into the comments. So we've got these I'm gonna call them generators, but your secret stuff here. What I'm really curious about is we've seen the token type which generates some arbitrary string, which I think you said could be configured, which is really cool.

46:45 Does it do x five zero nines? That would be pretty awesome. Okay. So we actually had x five zero nine built in, but we ended up deleting it because we can't it's kinda weird. We couldn't find, like, a super obvious thing. So what like, what's your use case where you want x five zero nine? Because you couldn't find, like, cause I built it. So I'm like, oh, I could totally use that. Yeah. Maybe it's it's super niche, but working on mutation mutation and mission controllers where you have to have to see and then drop the bundle into the CRD. And I know

47:22 that cert manager has the injector, and you can do that. I don't have cert manager in my local Yeah. Yeah. Development clusters. So that would be my use case there. But maybe that's too niche for what this product is done. Yep. Well, so so I had this the same thing where it's like, I've done all these things where it's like, oh, it'd be cool if I had x five zero nine. So it's like, we actually built it in. You could generate CA certificates and then sign certificates from it and all this stuff. But we ended up taking it out because

47:50 it seemed like the the majority of those use cases ended up being very infrastructure oriented, and they weren't really needed for the application. So, like, the way that we're kind of taking the approach on on encryption and all that stuff is that well, one, like, the application doesn't like like, what I don't like, what we don't really want is, like, the application to, like, let's say, generate a TLS certificate and use that for serving, like, serving out because, like, that's handled by, like, the ingress controller, like, the ingress infrastructure or, you know, something external to Kubernetes. So it's like

48:20 the application doesn't really need to be aware of, like, encrypting its public endpoint. I'm sure there's corner cases where you you'll you'll say I'm wrong. But, like, for the general general case, it's like, it doesn't seem like, most of that stuff should be handled by the platform. And so, like, one of the features that's coming out in the zero dot two or zero dot three release of of Acorn is gonna be, like, automatic TLS generation. Like, we already integrate really well with cert manager. So if you're already using cert manager today, like, the integration is pretty straightforward.

48:41 Automatic Tls Generation

48:50 But, like, we wanted to make it even easier for our users where, like, for the default use cases, the simpler use cases, we just automatically create TLS. So so we do that on the public side. Now if you look at the internal communication of, like, container to container within the cluster, we're leaning much more towards service mesh in that situation because it's like we've designed Acorn such that we can plug in a service mesh and then then wire up all of the service RBAC rules. And then so it's like, basically, you'll get MTLS plus service authorization,

49:19 like, for free, basically. You just run, like, the, you know, like, STO Acorn plug in, and we'll program all those rules. So, like, when we look at, like, container to container communication, like, I kinda also don't want containers to be doing TLS themselves because it's like, well, I can still hardly do that with with service mesh and basically do a better job. So Okay. Yeah. But if if the use case comes back up, like, if we get, like, request for it from users or whatever, then we'll bring it back. We just yeah. It's in Git the Git history. We just

49:48 we kinda deleted it right now. So Alright. No. Your that makes sense. Definitely. Okay. Couple more questions for me and then comments. What's the difference between local data and ARDs? Yeah. Yeah. So local data. So this is, like, kind of, like, a just a total gratuitous use of the syntax. And so so, basically, ARDs is information that you pass in. So this can be passed into the user. I didn't actually show this. It's, like, when you build the application. So, like, I built this application here from this. I can say, run and then help. And then it creates the args on the

49:56 What's the Difference between Local Data and Arts

50:34 application. So this is like so when I deploy this application, I can pass in an argument and change it. Okay? So so the args are are designed for, like, external or your input. Local data is just, like, just random stuff that you can just put in here. So a lot of times when we build things, like, I'll go to a a more more complicated example, which is the Jenkins one. Let's see. So, like, in the local data, like, here, I have, like, the tax the configuration as code configuration in there. And so I have that data in there,

50:44 Local Data

51:17 and I can do, like, you know, logic and manipulation of that. But then afterwards, I then basically turn that into YAML and stick it into a secret. So local beta is just kinda help help you can just put crap in there whenever you want to kinda help with your package. Okay. One last question then. Can we go back to the simple Acorn file? And that you list a bunch of containers. Yeah. Yeah. We got, you know, cache DB. Can you run, like, web control get pods? Is that one pod with multiple containers, one pod, multiple pod?

51:37 Mapping Acorn Concepts to Kubernetes Resources

51:54 Like, what does that Oh, no. So, like yeah. So yeah. So under the hood let's see. So under the hood let's see. I'll first show you the namespace so you understand. So when we deploy an application, we actually like, this how does what's the syntax here at? No. No. No. Sorry. Yeah. There we go. Okay. So the the CRD that we're actually creating under the hood is just Acorn app. Okay. So this is created in the Acorn namespace. But when we create the application yeah. There's too much garbage in there to to show you. But but, basically, every

52:05 Namespaces

52:32 app gets deployed into its own namespace. So, like, you create the app like, the the app CRD is in is in, like, the user namespace. And then for each each application, we then create a new namespace. Okay. So if I look at the namespaces because this, like, this keeps the service discovery keeps the service discovery very clear, like, very simple and portable, and it also helps with security. It's very easy to lock down the applications because we have one namespace per app. And then we handle all the heavy cross service discovery across namespace and stuff like that. That that's, like,

53:06 more advanced topics. But so I have this app in here. So it created this namespace. So if I look in here, you'll see I have three different pods. If I look at the deployments, you can see the deployments are, like, exactly so it's like the app. So the container is actually mapped to the to pods. And so the the reason why we called it containers is it just makes a lot more sense to users than getting into, like, the difficulties of pods. But you can do if you want, you can do sidecars. Okay. So you can put in, like, sidecar

53:37 foo, and then so you can still get the full power, and you can also do you can create init containers. You just say init true. Wow. So you can you can, you know, use the full power of pods. But, like, we don't enter like, we don't because, like, the side like, the pods and the sidecar pattern or something is super powerful. Right? But it's kind of like it's like, you don't get it until you actually need it. So it's like, we don't shove it down people's throat. Like, you need to understand a pod. It's like, no. Just want containers.

54:09 And then at some point, they're like, oh, but I really want this container to always be next to it. And it's like, oh, that's a sidecar. You know? So, anyway, so that's that's that's what we have. So you also see, like, under the hood, like, what it's doing of, like if I look at services. Okay? So it's like, we create services of the exact same name, like, like, this so it's like under the hood, we're creating standard Kubernetes objects, and they're using the same names as what's in the the Acorn file. Because, again, since we're using our own namespace, we can do

54:38 that. It's, like, they're unique within the Acorn files, and they're they're also unique within the namespace. So it's, like, most of the stuff that we're wiring up is pretty straightforward. It's, like, ingress services, config maps, secrets. We just deal with all the, like, the core types. Yeah. So it's like, if you understand Kubernetes, like, what this produces is pretty straightforward and obvious. Like, it's not madness. It's not like this super heavy layer on top of Kubernetes. It's a very light layer. It's just enforcing, like, a lot of good standards and and stuff like that. Sweet. Okay.

55:11 Security Features and Philosophy Deep Dive

55:12 Let's talk So it's like from a security purse sorry. Yeah. Go ahead. I was just gonna say we could tackle a few of the comments that I've come in from the people watching. But if you wanna tackle some if you wanna mention some security stuff, please feel free. Oh, no. I was saying from, like, a security perspective, like, the things that we do, it's like, can't run privileged containers. By default, the applications have no access to Kubernetes. You don't, like, you know, get permissions. There is I can show you a way to get permissions, and then it's very controlled if

55:42 you wanna get permission permissions to the to the Kubernetes API. And then on top of that, when we create like, so I said, like, we create a new namespace for each app. So we go and if you look at the namespace that's created, we automatically do the baseline profile for pod security. So those pods are are already enforced that by Kubernetes that they can't do anything. And so we're adding more things. Like, we're gonna automatically program network policies, so you'll automatically get the network policies. Because the definite the definition of how Acorn is is, like, all

56:14 communication is explicit. Going back to the Acorn file. Where was it? Like, if I don't have this port here, then nothing can talk to it. Like, we don't expose that port. But technically, if you know the details of Kubernetes, it is technically exposed. If you know the IP, you can hit it or whatever. But but so the idea is, like, the the the DSL describes all the communication paths and what's exposed. So then we can then go and enforce that with, like, network policies or Cillium or Calico or Istio. We can enforce all that stuff,

56:45 and we're building on kind of those integrations into the lower levels. Okay. Yeah. Okay. Yeah. We can go into the questions. Yeah. Well, I think we have a question that kinda touches and kinda segues off this quite nicely. So you said that you can't have a privileged container, and that's because the DSL doesn't provide any sort of interface to generate a privileged container. So what Bob then asked very early in the session was the issue here potentially is how the comment's gonna scroll off the screen. Sorry about that. But what do you do if you need

56:56 Handling Advanced Use Cases and Breaking Abstraction

57:15 to break out of the abstraction? What do I need to do something that isn't exposed by the Acorn interface? You got any any thoughts there? Well, I mean so there is a way to request permissions, and then you can do that. But, like, the intention okay. So there's a bigger there's a bigger goal with Acorn in general. It's like because, also, it's like, we have a company, and we're gonna eventually try to make money and stuff like that. Oh, yeah. About this. Like, about that, just I just wanna make something clear. Acorn, the project is

57:48 open source. It will never be, like, open core. We're not gonna do crap like that. Like, if you know our history with Rancher, the people at Acorn Labs, it's a lot of the same people. Actually, it's all the same cofounders as Rancher. We're very dedicated open source. Okay. So you don't have to worry about that. Like but but it's, like, our fundamental premise of, like, what we're trying to do is, like what we see is that it's effectively, the operations of Kubernetes is is too difficult. It's like, there's just there's so much power and flexibility in Kubernetes

58:20 that it leads to, a lot of operational complexities of everyone is kind of building, all of this stuff around Kubernetes to, like, how to deploy applications and validate it and and do upgrades and create pipelines and all this stuff. And so our fundamental premise is basically if, like, we can create a simpler application unit that is fundamentally abstracted from Kubernetes, then we can drastically reduce the operational side. And then at the end of the day, that's what big enterprises and companies care about. That's what they're gonna pay money for is is if we can reduce the operational side.

58:52 So it's it's when you say, like, breaking through the abstraction, it's really important for us that the abstraction actually works for all applications. So where we draw the line is basically if you need to do infrastructure oriented stuff, that's gonna be, like, more of, like, a that's that's gonna be, like, right now, you can still just do everything in Kubernetes, but we will be building kind of, like, an Acorn system type thing where you can do extensions and drivers and stuff that will be more privilege oriented. But for the Acorn file, it's like, we don't do any, like, driver infrastructure

59:28 or store you know, like, don't do that stuff. If your application needs access like, a good way to look at it is, like, if your application needs access to the Kubernetes API, then it's probably not just a pure application. It's probably very oriented towards Kubernetes. But there is a way to request permissions, so you can request permissions and get access to the Kubernetes API. But, like, once you do that, you have to realize you're already, like, kind of you're breaking the abstraction because that thing can now do a lot of things that could be really

59:59 bad. So we're trying to actually create a fairly strong abstraction layer, which I knew was extremely difficult. And and one of the the biggest questions we always like, whenever we show Acorn to, like, a real diehard Kubernetes thing, the first thing Kubernetes uses, the first thing they're gonna ask is what about CRDs? And so CRDs is something where it's like, well, if we allow you to just create any CRD, then it makes it such that, like, this unit, this this Acorn app app that we're deploying, it no longer has a predictable behavior because CRDs can do anything, and they don't have

1:00:34 a standard way that you interop interact with them. Like, a very basic example is, like, let's say I'm using the Kafka operator and I wanted to create a Kafka instance. If I put that CRD in my application so when I deploy that app and then I delete that app, it's gonna delete the Kafka instance. You know? That's bad. So, like, we go through things where it's like like the way the Acorns are designed is, like, if you deploy the Acorn and then you delete it and then you redeploy it, the the state was stored in volumes and

1:01:02 secrets, which are not by default deleted when the app is deleted. So if you, like, mess up and accidentally delete it, which, like, happens from, like, GitOps, people like, oops. You know, wrong commit, and then they delete something. You know, we protect you from that. So it's like, you know, if you'd start doing all these crazy things, then it's like, don't you lose all the guarantees. Okay. I think in line with that, you mentioned something there and earlier. You said the word driver there, but you also mentioned, like, Linkerd or Istio plugins earlier. So there are extension points to kind of

1:01:23 Future: Extension Points and Integrations

1:01:35 Yeah. Alright. Okay. Is that something that Acorn and Acorn Yeah. So that Sorry. So that's the the extension points, that's all in the works right now. So, like, we're designing that out and doing that of, like, how do we integrate all into. So, yeah. So we're designing basically what's the plug in mechanism so that you can augment because the idea is, like, if you have this application definition, can I create plug ins that basically take that definition and then generate more resources? So this is kinda, like, more of the route that we're going with with CRDs

1:02:17 is, like, if you need to do CRDs, like your app let's say you're using a very custom ingress controller or something, and so you need to be done a certain way. So we would look at, like, the plug in extension model of, like, how do we generate different resources or modify the existing resources based on your specific configuration. So so that's keeping the abstraction of, like the application doesn't change, but, like, you have a plug in in the infrastructure layer, which can then kind of modify it. And that will most likely like, we'll have a an an approach where

1:02:50 you could you know? I don't I I I won't talk too much about it, but it's it's gonna be really cool. The the the it's very it should be really simple to write these extensions, but I don't wanna get too much into it. Okay. Let's tackle a couple more questions then. So we got one from Javier here who's asking, how do I handle scale? I'm assuming they're looking for HPA support perhaps. Well, I mean, so just the basic thing is you can just put scale in here. So you can just scale see, I'm saying scale

1:03:06 How Do I Handle Scale

1:03:20 is two. And then if you wanna make it so that's changeable, then you can say, you know, scale to here and then reference it like that. So then when you deploy, you can change the scale. But so so HPA support is definitely coming, but it's not there yet. I mean, this project's only, like, about three weeks old. So, yes, we will be doing HPA and auto scaling support. Like, that's definitely on the road map, but just not there yet. Because that's another one where it's like yeah. It's super hard for people to to get auto scaling right, and so

1:03:51 we wanna make this. So it's like auto scaling blue green deployments, kind of, like, canary and those type of things. Those are all definitely on the road map of, like, addressing it. Because, again, it just goes to the idea of, like like, blue green or or canary. Those are just, like, update models. Like, fundamentally, your app definition shouldn't change. Like, that's more of a how do you deploy and run it? So it's like, you don't have to build that into your you shouldn't have to fundamentally build it into your application how to do that. Like, the the platform

1:04:18 and runtime should be able to take care of most of that. Alright. Next question. What access to the cluster do I need to be able to deploy an Acorn app? Yeah. So right now, you do need admin access. If you don't have admin access, you can right now. It's just a shortcut, is use vCluster. So you can just run vCluster and then run run Acorn inside of vCluster, and there's no overhead or downside to that. That's what, like, I was saying I'm looking at a way of trying to make it work for just regular users, and that's what

1:04:23 Installation Permissions and vCluster Workaround

1:04:53 we'll do as we'll effectively just wrap it in vCluster. But but yeah. So you do need you do need kind of admin access. I will show you specifically what we need if I can figure it out. What's sorry. This is not my normal work working machine. Okay. So this is specifically what what we require, which is access basically to our API groups, some standard core stuff, and then we need to be able to see the nodes, CRDs, API. Yeah. So, anyways, those those are the the roles. So there's an actual, you know, we do set up, like, a proper role

1:05:54 and role finding and all that stuff. But, yeah, so you do need admin access right now. But, again, if you don't have admin access, you wanna try this out, run vCluster. VCluster doesn't require admin access at all. V cluster from Loft, those guys. Yeah. Alright. Next question. Am I limited to create deployments as a base for the resource application? I guess they're looking or talking about stateful sets, daemon sets, etcetera. Okay. So yeah. So we do we do it's so okay. We can do stateful applications, but we don't use stateful sets. So this is kind of a

1:06:11 Stateful Applications and Manual StatefulSets

1:06:33 little different. And there's a lot of reasons for that, and maybe we'll find out that our reasons are bad. But in our example let me see. So dogs, there's, let's see. How how does one do this? I know there's, like, advanced topics. Stateful applications. Okay. So what we do is okay. Fundamentally, the idea of a stateful application or what stateful sets do is, like, why they're fun. Why stateful sets are fundamentally different from deployments is that a stateful set gives a gives a an identity a fixed identity to each container that's running. And or and that and that identity is,

1:06:53 Stateful Applications

1:07:17 like, persistent. So if you delete it, it will come back and has the same identity. The identity is effectively just the DNS name. So the problem with stateful sets in in my mind is that, like, it's kind of there's not just one way to run stateful applications. So sometimes stateful sets work, but sometimes, like, your app is still more complicated than it will work for a stateful set. So our approach to stateful applications is what we do is a little bit more manual, but it gives you a huge amount of flexibility. Because, like, we've tried, like,

1:07:46 running, like, Kafka, Cassandra, MySQL, Postgres, Redis, like, complicated setups, multi master. We've we've tried running all these things in in in Acorn, and we've gotten, you know, largely to work. Like, you know, we've we've we haven't run anything fundamental issue. Like, we're not experts on all those systems, so it's not all production grade. But, like but we've been able to get them all set up and everything. And so the approach of what we do is is kind of this trick here. It's like, you you say, okay. If I want, like, two replicas, you just this is all again, this is,

1:08:19 like, queue queue syntax or whatever. We go through well, it's close to queue. This is not queue right here. But we go through and we create a like, you create a range of, like, you know, three, and then you actually create three separate, like, in like, containers. So you say, like, container one, container two, container three, and then each one of those is going to bind a different volume. So you get volume one, volume two, volume three. So it, like, effectively just created a stable set. Each one has a stable identity, and it has volumes associated with it. And

1:08:51 then there's also little tricks under the hood where it's like, if it's if it's an application of scale one if it's a container of scale one and it's using a rewrite only a rewrite once volume, then we do, like, a replace strategy so you don't get two two things trying to access the data at the same time. So, anyway, so our approach right now is we're not actually using stateful sets under the hood. You know, again, maybe we'll find out that that was a stupid idea. But, like, what we found is this pattern of effectively

1:09:18 kinda manually creating your stateful set ends up being very powerful. So, again, like, one of the reasons why it's so powerful is what you can do is, like, in this if loop here, is a lot of times you have to bootstrap a system. So, like, the first replica, you wanna run that in the bootstrap mode, and the other replicas you don't wanna run-in, like, the bootstrap mode. So by basically looping through, you can say, like, if I index is zero, like, the first one, like, if I equals zero, then add the Bootstrap Bootstrap arguments. So you can configure

1:09:47 like, with the logic, just doing the logic in here, you can configure the instances slightly different, which ends ends up being very useful to, like, bootstrap clustered system. So it's like we've been able to bring up yeah. So it's like things like because, like, Cassandra or Cluster, you know, those type of things. So I can actually show you, like, a more realistic what this would look like because it it starts getting you know, like, as your apps like, running the Stateful thing is is complicated. It's never it's never easy running Stateful stuff. So these these examples are more complicated, but

1:10:24 it does get into the, like, what's capable. So here, it's like oh, yeah. Sure. But, yeah, this is actually a fully working MariaDB that does Galera cluster onto the hood. So, again, you can see this pattern of we're doing that. But we can we're also like, we do it so, like, each each replica depends on the previous one, so we get a nice startup behavior. But this handles, like, also, like, recovery. So, like, basically, you can scale down to one. You can run a recovery, like, when you break the cluster state and stuff like that.

1:11:01 But you can see here, like, the args here, the design and recovery, and it equals the bootstrap bootstrap indexes, which which one you wanna bootstrap from. Because when you're doing a recovery, you might like, if if you screwed up your whole cluster, then go, oh, crap. I wanna recover and then bootstrap from, you know, the second one, not the first one. So anyways. So but, yeah, so there's all, you know, all of all of that crap. So, like and and this is like I haven't talked about jobs at all, but you can do jobs on a schedule. So it's like, this is

1:11:31 actually running a backup. This runs a a backup of MariaDB and stores it into a a volume. But, yes, there's a lot of things in here. If if you look at this read me file for this, it goes into more details on how to, do all this stuff, like act active active application. Yeah. Removing replicas, whatever. Kind of all the ops stuff you would need to know. It's really cool. Like, can it it keeps the backups, and it'll show it it actually has a list of the backups that are available because there's some really fancy things you can do because, like, there's

1:12:10 sorry. I'll I'll show you this. There's a really cool secret type, which is just called generated, which you just run a job. Let me go down here to secrets templates. Oh, crap. Where is it? Nope. Nope. Nope. I think it's in here. Generated. Okay. Yeah. So there's a secret here, which is called backup list, which is generated, and it's off of the job called you know, it runs off of the the backup job. So what happens is when this this job runs and it does the backup, the output of this this script, there's a special

1:12:48 file you write to. It's like run secrets output or something like that. In that job, you write to that file, and then we pick that up and throw it into the secret. So this was, like, an interesting hack of, like, when we run the backup, the output of the backup gets stored into the secret, and then you can just list it. So, anyways, that was a fun little hack that Bill found. One of our engineers. Right. Awesome. Anyways yeah. So that was a very long long approach to Alright. We don't have any more questions in

1:13:17 the comment section right now. So before we jump back, just to, like, quick face mode, is there anything else you would like to show us that you think is really cool about Acorn? Well, so I I was gonna show you this, but, like, I think we're probably running out about time, so I don't wanna go go much further. But I'll just kinda point you. So this was something, somebody had asked me for a Jenkins, to do, what would it look like to run Jenkins and Acorn. And so I wanted to show this real quickly. This is like, you can run this,

1:13:48 Acorn. So, basically, build it, run this, and then you just say expose the admin user, and that will give you the password. But in here, like, this is super, cool. This is running j Jenkins, and it's using the, configuration as code approach, which integrates with Kubernetes. And it's also using the Kubernetes, cloud plugin. So it's pretty most of the stuff seems pretty straightforward. Like, set up a bunch of directories. These are ephemeral. These are coming from secrets. This This is the file, and then a bunch of probes. Oh, the formatting. This is terrible. But so I just wanna show you. So this

1:14:25 Request Permissions

1:14:25 is where you can actually request permissions. So this is, like, a short syntax which just says, like, basically, give me read, write access to pods. This is read only to pods log. This is, like, the more verbose syntax, which will give you you know, you can ask ask for anything you want. So you can get privileges. And so that this uses it because this internally is using the Kubernetes cloud thing. So, like, when you run this, it's really cool, little Acorn. Because, like, when you run it, it comes up, and it's already wired up to Kubernetes. So if you set up a

1:14:54 job, it's gonna launch a pod in Kubernetes and, you know, start running the the Jenkins jobs or whatever. But I just wanted to show you, like, the way that's controlled, like, kind of the security. Because, like, when you ask for permissions, as I was mentioning before, like, that is kind of breaking the abstraction. So it's very explicit of let's see if oh, this might take a little bit. K. Won't tell long it'll take to build this. Because this is this internally is actually doing a it has a custom a custom image for the builder because I was trying to

1:15:32 get it to work for my own thing. So the the image has, like, go in it or something. So it has to do that. But I don't think it should be that that take that long. Let's let's see. But I just because I just wanted to show you the experience. Like, when you go to run it, it's going to it's very explicit of, like, this thing is asking for permissions. So you can't run something without basically saying saying if it asks for permissions, you have to explicitly agree to letting it have permissions. And then on top of that, you can't

1:16:01 give permissions you don't have, like, just regular Kubernetes escalation checks, like that type of stuff. It will it will do that. Okay. Let's see. Wow. GCC. Oh, because I installed. I'm just like, what in the world? I thought I just well, I was just installing curl. It's like, need to compile it for curl. So do you see a future here where we're, like Watching. Acorns are gonna be published to, like, their effect hub, and people can just say, I wanna deploy Jenkins or Postgres, and the Acorns are publicly available and easily consumed. Yeah. Yeah. And that's what we'd like to

1:16:30 Vision: An Ecosystem of Shareable Acorn Apps

1:16:47 get to because it's like Docker, you know, Docker did a decent job of, like, you know, creating shareable Docker images. But, honestly, like, the Helm chart ecosystem of running apps, I mean, if anybody's, like, realistically used a lot of the Helm charts out there, you'll know that, like, they basically will never run the first try. And, you know, it takes quite a bit to finally get the arguments right and eventually figure out. And then it's, like, a lot of reading and knowing what the best you know? So it's like, I don't think the ecosystem is very good in terms of, like,

1:17:20 you know, these applications and stuff like that. What what you see right now is, like if you look at, like, let's say, like, hub, what's available for operator, the majority of the things are all, like, Kubernetes infrastructure oriented. You know? So, like, security scanners or operators that you know? So it's, it's not really applicate you know? So it's, I don't know. I'm I'm, and I'm in general, like, not a big fan of operators. I don't think that's, like, a very good pattern. Like, I'm not saying don't use operators because it's kinda, like, the best thing that exists

1:17:50 right now. But hope to see that we can basically create a stronger ecosystem around Acorns than what Helm or operators has done. Okay. So, finally, that took forever. So when you go to run this, this is what it's gonna do. It's gonna it's gonna warn you. And so, like, this is very dangerous, but it's saying, like, okay. This app is requesting these scope like, these these permissions, and then you have to agree to it. But if I agree to it, then this is basically this is gonna bring up my my this will bring up Jenkins.

1:18:26 Anyway so yeah. So that was probably, like, the last thing I wanna show. Awesome. I'm gonna pop this back over then here. Okay. So that was really cool. If anyone has any more questions before we finish up, now is your time to drop them into the comment section. That end, I'll I'll kinda give you one more for myself. But you said this project is really young. It's really early. Things are moving fast. Like, what's coming up? What's on the road map for the next kinda couple of months? So just minor so, like, we're adding just, like, a bunch of, like,

1:18:36 Roadmap and Upcoming Features

1:19:03 little minor things, like, of so TLS support is coming so that, like, out of the box, we'll just automatically wire up TLS. Again, certain manager already works, but so that's coming. You know, being able to label and annotate everything because people wanna be able to put, you know, different annotations that do weird things under the hood in Kubernetes. So, we're adding support to basically label and annotate everything. You know, the the language, as I said, is, like, it's it's queue right now, but we're trying to form like, it's a sub it's kinda like a fork of queue right

1:19:35 now, but we're trying to formalize that into our into our own things so it becomes very clear, the scope of what we're using and everything. But the bigger stuff that's coming is and, you know, let's see where we we're almost in September. Right? Like, it's the August. Yeah. So, like, of course, we're, like, conference driven, so conference driven development. So we're shooting for, like, cube con time. We'll have a much bigger features in the realm of kinda like CICD and stuff. So, basically, once you have the Acorn, how do you very quickly wire up the pipeline?

1:20:12 Right now, it already works very well. Like, I didn't show this, but when you do Acorn run, you can do dash o YAML, and it will just basically spit out the CRD, and you can put that into your GitOps flow. So it's like, if you're already doing GitOps today, Acorn integrates super well into into any GitOps flow. But, like, we kinda believe the the entire everything could be significantly easier. So how do you do, like, automated builds and deployments and and, CI? Like, like, one of the one things that we've we've already talked about this one. This

1:20:43 feature is, like, the idea of running, like, Acorn test. So the idea of Acorn test is, like, within a CI flow, you wanna test your application. So it's like with Acorn, it's very easy to just spin up your application. You know, you just do Acorn Run, and you can run it anywhere. It's kind of self contained or whatever. You can very easily spin it up. So we wanna add basically a test mode where we spin up the application, but then you define a series of jobs, you know, and you can basically when you you say test foo, it'll run the test

1:21:12 job, which can then do, like, an integration test suite or or or whatever. And so you can very easily test your application within, a CI flow Okay. You know, to to do, like, integration tests really easily. Awesome. No. So those that's some of the stuff coming. Well, it sounds exciting. And I've been called out by Russell in the chat who asked the question five minutes in. So eighty minutes ago, and I didn't throw it to you. So I'm gonna do that now. But Russell wants to know what's actually in the OCI image slash artifact. Oh.

1:21:28 Acorn Image Structure (OCI Artifact Details)

1:21:45 Yeah. Yeah. Okay. So I can describe it. So because if we get this the question comes up a lot too because they're like, oh, are you copying all the image? Like, okay. So when we built the when we build the Acorn image, the top level like, I'll get into, like, the OCI details or whatever. Because, like, OCI has basically manifest and lists or index. I think it's called an index. So an index is a thing that just points to a bunch of other things, and then, the manifest, describes basically like a like a a container,

1:22:16 a Docker image that has layer refers to layers. Okay. So, when we build the Acorn image, we create one layer which has the Acorn metadata in it, and then we create a list which links to the metadata and then to all the existing Docker images by digest. And so if we built an image, like, we'll build that, push that, and then link it. If it's an image you just referenced in your Acorn file, we just reference the the same like, the exact same one. So we don't duplicate any content. It's not a new structure. So if you have an existing

1:22:47 Docker image, like the digest that's there, we use that digest directly. The only thing is that, like, the manifest list, if you're doing multi arc, will will change because, like, we dereference to find the architectures. But, anyway, so, like, the the layers and the content, like, those digest don't change. There will when you use Acorn, you will see if you push somewhere. Like, if you didn't like, let's say you just built an Acorn image and it just has the metadata and it's referencing existing Docker images. If you push it somewhere, you'll see it's pushing tons of content. That has to

1:23:21 do with, like, more of, like, a bug right now in the implementation because the content already exists in the in the registry, but it doesn't necessarily exist in your repo. So we're doing a push pushing content that we don't need to push. This is, like, there's a a feature in in the API called mounting, and we're not doing that properly in some scenarios. So it looks like you're pushing a bunch of content, but it's, like, basically, you push, like, all the content, and then the registry throws it away because it it already exists there. Anyways Alright.

1:23:53 Okay. So followed up with a question, which I think you've just answered, which is that do the images remain the same? Oh. Yeah. Because then I think he says that you've answered that, and then he says And then there's a question about how does it handle So for the interregistry images okay. So this is really important. Is that, like so what we're doing is, like, is if you're pull if you're when we push the Acorn, all the content for that Acorn and all the reference docker images go to that target one. So if you've pulled from, like, five different registries, it's

1:23:56 Handling Images from Multiple Registries

1:24:27 going to pull all that content and push it into your one registry. That is very much done by design because, like, the idea is once you have your Acorn, it's fully encapsulated. So if anyone's done air gap setups, you'll you'll understand the pain of this. Like, when you do let's say you deploy a Helm chart and you try to do an Helm in a air gap, that Helm chart references three Docker images. You have to configure each one of those Docker images of, like, well, what's the repo to pull from? You know, where to get that? You're like, you have

1:24:55 to find all that content and and mirror it offline. So this basically just turns your app into one artifact. And so it's like, you can just basically do Acorn pull and then Acorn push to a different registry, and that's it. Or you you don't have to use Acorn. You can use, like, a tool like Scorpio or Crane to do some of that stuff. Don't use Docker because Docker mutates stuff as you push and pull. But if you use a tool like Scorpio or Crane, you can just move things around. Awesome. Well, we've gone a little bit over time,

1:25:24 Conclusion and Farewell

1:25:26 but we have no more questions. So I just wanna say thank you for joining us today, for sharing all of your knowledge and the history behind Acorn and for walking us through a couple of different demos and how it works. I hope people are excited to check it out. And definitely reach out to Darwin with your feedback. I'm sure he'd love to love to have. Yeah. Yeah. And so I'm on I'm on Twitter. I build the cloud on Twitter. I'm pretty active there. If you have anything, just ping me there. That's that's, like, the main

1:25:54 thing I usually check is Twitter. Alright. Well, thank you again for your time. Have a wonderful day, and I'll speak to you again soon. Have a good day. Okay. Thanks.