2:41 Introduction and Speaker Welcome

2:41 Hello, and welcome back to the Rawkode Academy. My name is David. It's so long since I've done one of these. I forgot my own name. My name is David Flanagan, although you may know me as Rawkode. And today, we're taking a look at more open source cloud native Kubernetes container, all the cool things technologies. Today, we're taking a look at Portainer, and I am joined by cofounder, maintainer, developer, all the hats, Neil Cresswell. Hey, man. How's it going? It's going very good. I'm gonna correct you though. I'm definitely not a developer. Oh, no. Oh, god.

3:16 I'm definitely not a developer. I am an engineer and a consultant, but I'm definitely not a developer. And to be fair, you don't want me anywhere near code. Alright. Well, apologies for that. Maybe you could give us a little bit of background on yourself then and correct me at the same time. Sure. So, yes, I I am the cofounder of Portainer. And I I I built Portainer to solve a problem that I had a number of years ago, which was how to make the transitional jump from someone managing virtual infrastructure to someone who now needs to manage container

3:31 Portainer Origin Story and Rapid Growth

3:51 based infrastructure. My entire career has been spent in the infrastructure world. I was a engineer at IBM. I was a consultant at IBM. I was consultant at VMware. I I I lived and breathed, you know, infrastructure and virtual infrastructure technology. And seven years ago, v m VMware themselves opened my eyes to the wonderful power of Docker, and I'm like, this thing is amazing. It's an absolute game changer. But we're going from a very, very mature and well tooled ecosystem around virtual infrastructure. I mean, they they were you know, VMware had had the tooling nailed for virtual infrastructure

4:34 to this new world of of containers. And, oh my goodness, it was like, we have just gone back in time, you know, ten, fifteen years there because we've you know, it to me, Docker at the time felt like the early early versions of of of VMware ESX way back in the day. And I'm like, okay. Let's not try and have this experience be ten years and leap and and go from nothing to highly adopted. Let's try and create a bit of tooling to help people make that leap, make that jump from being virtual, you virtual engineers to container engineers.

5:10 So I built it for me predominantly, and it's gone nuts. I I I like to tell a a story. We yeah. Anthony, my cofounder, and I, we we we built this thing. We put it out there, open source, not knowing what that meant, of course. So yeah. Because we were using it internally. Put it out there. Somehow, it got picked up on Hacker News. This was in September. I woke up on Christmas day six years ago, and we had a million a million downloads of the products. And I'm like, wow. Jeez. What happened there? New Year's day, ten million downloads.

5:49 It as is the power of of open source, as is the power of things like Hacker News' ability to propagate a good story, and from there, never stopped. I think we're at 3,400,000,000 downloads of the products over over the life now. So it's ridiculous. So there you go. It was a long winded way of saying hello. Yeah. Wow. I had no idea just how quickly the growth was. I mean, I definitely remember when Portainer was announced. I don't know if it was the hacker news, maybe it was a bit longer or a bit shorter after. I have no idea.

6:23 But when I was going to user groups up and down The UK, it felt like everybody was running Portainer in their house. They were running containers using Portainer as the UI. Like, I imagine it spread pretty much like wildfire. I mean, 10,000,000 downloads in what space of a week or two weeks is that's wild. It's nuts. Yeah. It was nuts. And at at that stage, was just two of us and we we seemingly became the de facto docker help desk. And so, yeah, our our our internal communications, everything else, we we spent so much time

6:54 it this was kind of a a side a side hack. Right? And so we're spending so much time answering questions because we were we were spending a lot of time understanding the technology. And so we we were able to answer questions pretty pretty rapid fire, you know, problem solution, problem solution, problem solution. So You kind of addressed this, but I'm gonna ask you and see if can get a bit more detail. Like, you you said that the technology containers, it felt like you were back ten years. You were used to this very, I don't know, VMware with lots of tooling

7:10 The Problem Portainer Solves: Complexity of Container Management

7:23 environment where things maybe just worked or were easier. But was there a specific need that you were trying to solve with Portainer as you were adopting containers, you and you and Anthony? Like, what what was the the the drive? What pushed you into building this new tool? You know, I've I've always described and I I still describe it to this day because I don't think much has changed. I mean, there's more tooling now, but in fact, it's more complicated in my view because there's now so many tools to choose from. But I've always said a Docker host or a Kubernetes

7:53 cluster, it's it's just very raw. Right? A Docker host is like, in VMware speak, an e an an ESXi host. A Kubernetes cluster is like a a a vSphere cluster. You would never, in a million years, go into mission critical production with just just the bare metal e s s x I host, and very, very few people would go into mission critical production with just a VMware cluster. You would have vCenter around the side to help you with managing it. You'd you'd have some some you know, something like Veeam or some other tooling to give you backups. You'd

8:28 have some probably a product like SRM to give you to give you Doctor replication or or Doctor failover. You'd have things like like VMware v v Realize to give you, you know, insights into your into your your application. And one of one of the important things is is VMware, you know, recognized very early on having a bunch of % disparate tools, each with their own UI, was not a recipe for success. And that's why you find inside vCenter, they added all of the plug ins and they let you bring everything together. So from within the vCenter screen,

9:01 you could configure things like like your NSX storage, your vSAN sorry. Your your NSX networking, your vSAN storage, all of your observability, everything else you could do from within the one tool because they realized that was the way. And one of the things I I I saw in the container ecosystem was, one, at the time, there was no tooling. There was just nothing. There was just the the raw Docker and raw Kubernetes. Over time, and we still see it now, you know, go go log in to the CNCF landscape. There's a bunch of disparate tooling,

9:31 but it's disparate tooling. There's no there there's nothing stitching all that tooling together into a single experience that makes it really easy for someone to jump in and actually manage everything. And, yeah, my my whole my whole ethos in life is remove complexity. You know, complexity causes issues. It just does. And I I hate complexity with an absolute passion. And so I I try to remove complexities, and and I do that by by pulling tooling together into one place. That's why in Portainer, you've got GitOps, you've got UI interfacing, you've got policy engines, you've got everything you can

10:03 imagine, because I just hate the idea that you have to go out into a bunch of separate disparate tools to achieve what you should be able to achieve within within one tool. Nice. So would it be fair to summarize that as Portainer is your single pane of glass for containers in Kubernetes? Is that your mission? Is that the goal? It is. A single pane of glass is massively overused. I I prefer the I I prefer the term manager of managers. So, yeah, we we we like to be or or to use to use Lord of

10:13 Portainer's Mission: Manager of Managers / Single Pane of Glass

10:35 the Rings, we wanna be the the the one tool to rule them all kind of thing. So we we wanna be this this one piece of tooling that that your internal staff have to learn. So so you learn Portainer. And by the way, Portainer is very intuitive. There's no need to be certified in Portainer because you just don't need to be. It's so intuitive. And so once once people get get a taste of Portainer, they don't they don't need to use anything else. I mean, you could if you wanted to. We we don't we don't lock you in. If you wanna go

11:01 use other tooling alongside us, feel free. But what we say is for 80% of of organizations, Portainer's native capability is is enough. Right. You've already mentioned a bunch of features that I had no idea existed in Portainer. Like, you you said get ups. Like, I had no idea there was that kind of level to it. And I've seen something on your blogs that I thought was quite interesting too about being a management platform for Kubernetes. But it sounds to me like Portainer has kind of evolved greatly over the last number of years. I'm I'm kind of excited to what we're

11:06 Evolution of Portainer

11:33 gonna see now today because it could be contained like, container was, you know, the UI, I see go run this container for me. It does it and I'm like, cool. Awesome. But, you know, it it has evolved a lot then. Right? So you wanna maybe share a bit more details on what that's been like for last couple of years? You have no idea how hard it is to to to actually change people's perception of a brand that's been around a while. I I genuinely believe it might have been easier for me to have stopped using the brand

12:02 Portainer, kept kept the same product, simply change change the name to something else, and and and we we would have been some some cool new new application out there on the market. If you if if you ask people about about Portainer, they'll almost always respond with what we were three years ago. In in the last two years, we've spent over $10,000,000 re reengineering the product to be this this Kubernetes, in fact, universal management platform. So Kubernetes, Docker, Docker Swarm, of course, Nomad, any Kubernetes, any cloud, anywhere, laptop, data center, edge, anything. You know? It it's this this universal

12:42 management tool set that just simply says, if if you are dealing in containers, then Portainer is the tool that you need to to get your get your applications developed fast, into production fast, safe, secure. That's it. Alright? So, yes, there is there there there's a GitOps engine built in. There's basic observability built in so you can see what your application's doing. You can see if things are up or down. You can see see the events. We make it really, really easy to discover what's going on in your environment. One of the big things. Right? If if

13:17 you don't know the commands to type in, then you can't type in the commands. So if you don't know Kubernetes can do something, then you don't know the command to do that something, then you're ignorant to the fact that there is this amazing piece of capability. Well, Tana makes it blatantly obvious because there's a button that says show this and you oh, what's this do? I'll click this. And now you can you've just you've just discovered a new piece of native capability of Kubernetes or Docker. So we make it really, really easy to to explore what's what's

13:47 there. Yeah. I'm assuming, and you can correct me if I'm wrong, but the 10,000,000 that you've invested did not come from $1 from three of the five 3,500,000,000 people that downloaded it. So I'm assuming the the enterprise business is is quite successful. The people would know are taking Portainer and shipping real production applications. Is that correct? Like We are VC backed, so the the the money comes from from from VC companies who believe in our vision and believe that there is a commercial demand for our Portainer business edition period. And that's the uptake of that is growing

13:50 Portainer Business vs Free Editions

14:27 nicely. So, absolutely, there there is there is definitely demand for people who want to take what's available in the free version and expand on it. You know, we we've expanded a lot in regards to policy and controls and and security and governance and all sorts of things. We've built off the free version and sell a commercial version out there for those who want more than what's in the free version. The free version is still very feature rich, by the way, and we've got, you know, roughly 700,000 users who use the free version every single month.

14:54 They log in and do something every single month. So the the there's a there's a quite a big loyal global following of the free version, but the free version isn't isn't really enough when when you get beyond one one team using it. You you want a bit more governance and control. So that's where the business edition now comes in. Yeah. That's amazing. That's awesome. That's exciting to hear as well. Like, I I speak to a lot of people that are struggling with Kubernetes. A lot of people ask me for advice, they want help. And I'm

15:21 actually seeing this trends now where where people just don't actually want Kubernetes. They want a platform to run their containers. And it feels like Portainer should just be that option that I'm giving to people. It should be like, there's the UI, there's the cut off operator to it. So I'm I'm gonna just let you hand over to the screen share and show me some awesome things with Portainer if you're ready to go. I am. The it it so you're right. Portainer Portainer's goal is to try and make the underlying technology irrelevant because at the end of the

15:44 Portainer Makes Container Tech Accessible

15:51 day, it kind of is irrelevant. It it kind of is. You actually want your application live. You know, the the the the business that employs you as a developer or the business that employs you as an ops person or what it you know, whatever role that that you wanna be in. The business that employs you doesn't really care about the tech. That's unless, of course, you Google or whatever else. Right? But most organizations, they don't care about the tech. What they want is a highly available system that delivers digital applications to market. That's what they care

16:18 about. They don't care about the tech. You know, we as we as techies care about the tech, but the business doesn't. But more and more often now, people are saying, you know what? The tech is actually causing me headaches. It's a little bit too complicated for some use cases. I really wanna try and and divorce myself from the from as more of the tech as I can. There's there's, of course, still a subset of people who just love the tech because the tech is good fun to play with. That doesn't necessarily help to help the businesses that

16:44 employs them grow. So, you know, we we we're trying to say for those organizations who just wanna use the damn thing, Portainer is right for you. If if you're one of the one of those organizations or one of those people who really, really wants to get in turn every dial, and flick every switch, Portainer probably isn't for you. So we're we're we're a bit bit more honest and direct and clear with our our ideal user. You know, a a raw a raw expert who wants to able to flick every dial and and and and turn every switch is

17:12 not it, you know, Portainer Portainer abstracts away with the goal of making it really easy to consume. Yeah. I consider myself a bit of an expert. I also think that I'm so done of fiddling knobs and and playing with switches. I mean, I think I just want things to work now. I don't know if that's just me getting older or not and tired perhaps, but I I am very salty. I I I have run I've I've run mission critical cloud services. I was CEO of a of a public cloud provider. One of the worst things to happen is

17:35 Why Simplicity is Crucial (Outages, Skill Shortages)

17:46 an outage. You know, everyone has outages, and anyone who says that there's they they don't have outages is lying or hasn't yet had one. But outages happen at three in the morning when there's an outage. You wanna be able to pick up the phone and say, who who can get in here and help me right now? And if it's one person, because only one person has the actual depth of knowledge of the platform, man, you're in trouble. You you wanna be able to get to get fifteen, twenty, a hundred people, everyone in IT wake up and get in here

18:13 now. And everyone in there can can roll up their sleeves and get in there and try and solve their problem. If if you have a piece of infrastructure or a platform that's so complicated, only one person or two people can support it, man, you're in trouble. You really are. And, you know, I I I had that lived experience. I had this beautiful public cloud, and I had problems with my my underlying storage platform. It was it was beautifully engineered, but very difficult to triage and troubleshoot. And so I'm like, man, you know, once we got out of that

18:42 outage, it's like, okay. I need I need to make this thing way easier. I've gotta I've gotta take away complexity so that I've got I've got, you know, more more ready access to people who can help me triage and solve problems. So you you will see you will see you will see lived lived scars, blood, sweat, and tears all throughout Portainer because I've I've I've experienced those. I'm old enough to have have lived through all of that pain and suffering, and I'm trying to stop other people having to live through it too. Awesome. Alright. We got a a couple of

19:11 Q&A: Future of Container Platforms (Podman, WASM, Edge)

19:12 comments I'll tackle just now. So we got one from Russell saying, referring back to your Lord of the Rings quote, but Portainer is a siren's tool for managing container systems. There you go. Cool. And we have a question for our brilliant guest. Nicely phrased, Murat. How can I not ask that question now? But they wanna know about the future of container platforms and whether maybe something's going to replace containers. And they mentioned LXC Podman cat containers. I mean, do you have any thoughts on what comes next? Or do you think, you know, those containers are just perfect?

19:45 They're also containers. Yep. But Podman is just, in speech marks, a fork of Docker. You know, for for whatever reason, Red Hat decided that the the direction Docker was taking was the wrong direction. So they they forked or the it it's basically built off of Moby, and it's it's their own thing. So, yeah, Podman is very, very compatible to Docker. So it's still the same underlying tech. They're all based off the same underlying principles. You know, even even container d from Kubernetes is it's the same underlying thing. Now LXC containers are somewhat different. Containers in general, I think, are are quite

20:18 universal. You know, is there gonna be a new version, a better version, a more secure version? % sure. You know, containers today are still a little bit too wild west if you ask me. With it without without a bunch of external controls, a container can be used to take complete complete control of the underlying platform. I'm just gonna while I've got my screen share up, I'll show you what I mean here. Yep. Let me just push that over. There you go. So, like, for example, here, you know, in Portainer, we let you sit some some Docker

20:50 security settings here because there are certain things containers will let you do things that are actually dumb. They're actually really, really dumb. Like, for example, I can spin up a a container that bind mounts the root file system. No. That that's a terrible idea. So so we yeah. In Portainer, we actually let you say, well, hang on a second. Because Portainer sits between your users and the underlying infrastructure, we're we're going to disallow, and we we basically intercept requests for blind mounts and say, mm-mm. Not allowed. Yeah. Like, you you can actually ask a container

21:22 to run-in in the host PID namespace. And then once you're in the host PID, you can do anything on the host. That's a dumb idea. Terrible idea. So block that too. So that same thing with device maps. You you can actually you can actually say map device slash dev slash h d zero or s d zero to a container, and then you can do if there's gonna container and erase the hard disk. That's a terrible idea. So the so yeah. All that stuff, we we basically saying, mm-mm. We gotta intercept that that and block it. Now things like Podman

21:53 and even Docker rootless mode now can run-in a way that they don't have root access to the host. So some of this is starting to be mitigated, but more and more often now, I think I think I think I think we're gonna be crying out for a more secure version of containers, the next generation of containers. But from a end consumer or any user point of view, I think I think you find things like serverless containers become more and more popular. Things like Cloud Run or the old the older and slightly less popular Azure ACI,

22:25 where you just simply ask the system, here is my container. Here are the SLAs that I want you to run this container within. Go run it for me, and the platform takes care of it. I think I think you're gonna see that kind of thing take off a bit more where you simply say, hey. I want this container to deliver a response times to my to my users of below x milliseconds. The system says, okay. I'm I'm seeing a bit more load. I need to add more replicas. I'm gonna go ahead and do that. You you shouldn't have to say, I want

22:53 three replicas and turn on auto scaling, and here are here are the criteria for auto scaling. The system should know should be able to determine that from SLAs. And I think that's that's that's kind of the future as we as we mature. And if you look at a Google Cloud Run, that this is this is a very nice first version of that. Yeah. Definitely. Alright. I hope that helps, Bharat. Russell suggested maybe WebAssembly could be a future technology there. And I think Firecracker falls into that too. But we have such an ecosystem, such a community

23:24 around containers and so much tooling that I I think containers have got a lot of life left at them yet. Yeah. Wasm at the edge or or wasm wasm, however you wanna pronounce it. I've I've got a a crazy Kiwi accent. So, yeah, wasm at the edge, I think, definitely has potential. That this whole this whole assembly on demand, I think, has potential at the edge. For some reason, Kubernetes at the edge is getting a lot of love. Kubernetes at the edge is very overweight. You know, it's very hard to to use Kubernetes at the edge unless you have a

23:57 relatively large node. I actually produced a blog just recently where I actually benchmarked all of the nano or micro Kubernetes distros out there to say, can they run on a device with one gig of RAM? The answer is absolutely not. Well, they they run, but you can't you can't you can't do anything. The moment you try and it start even a basic NGINX container, the whole thing implodes. So you can't. Whereas, you know, Docker, Podman, and Nomad are perfectly adequate. They need need nothing at the edge. So, you know, until until much larger hardware starts to propagate the PLC and the edge

24:33 device retailers and know a Raspberry Pi is not everywhere. So we're talking about, you know, the the multi billion dollar PLC vendors out there that we all know that run industry. Until until the the hardware propagates down to that level, we're still very, very limited in resource. And so there's still still a real focus on how do how do I, as an operating system, as an operating platform, use as little resource as possible so there's more resources for applications. Sweet. Awesome. Thank you for sharing. I have very strong opinions on Kubernetes at the edge just because it's it seems like

25:07 we're we're forcing a technology into a use case where it doesn't doesn't naturally make sense, but we're trying to trying to tell ourselves it does. Yeah. That's actually Anyway Yeah. I mean, we're seeing I'm assuming I haven't read your blog post, but I'll find that up. A link to it to show notes for anyone who's watching. But I'm assuming the ones you tested there were like k zeroes and k c s, and these are the ones that claim to be kind of edge compatible Kubernetes distributions. But Correct. Correct. And yeah. To yeah. A spoiler alert, they they all need greater than than

25:38 700 mega RAM to to even idle to idle. So and if you've only got a gig of RAM, 700 mega RAM used up just to idle. In all honesty, once you get around 900 mega RAM, then the kernel starts starts blowing up anyway. There's really no RAM to do anything. So Yeah. No room to work with the toll. So you're just but almost always, they're a single single CPU. If you're lucky, may maybe a a quad core, but it's a quad core low throughput CPU. One gig of RAM, two gig of RAM, really. So it's you're still very limited. Now I

26:26 understand that there's the edge edge is a very large use case. You've got network edge, which are servers. You've got edge gateways, which are, you know, far larger I sevens with eight gig of RAM and mini clusters. Those ones are fine, but true edge, far edge, you know, I IoT type use cases, very, very limited hardware resource. Alright. Let's jump over into your your are you starting with Portainer? Are you doing some slides first? How are we doing this? I can do anything. I have I have some slides that I can run through if we like.

26:59 I literally just shared these these slides last night. I built them just for the session. I can I can run through these things at a blistering pace and then go and show you live? Well, yeah. You failed them. It'd be a shame not to show them. Come on. It it would be. Containers managing containers shouldn't be hard. It and, unfortunately, it is hard. And anyone who says it's not hard, either hasn't gone deep enough yet, it's not fully in production, or they are absolute ninjas and are able to comprehend the complexity. But for the average IT

27:18 Portainer Product Overview (Slides)

27:35 person, managing containers is far harder than it it it needs to be. And so our whole ethos is it shouldn't be hard. Yeah. We we like to to sit in the middle and be this universal tool set. We don't care where you run Kubernetes. If you run Kubernetes in any of the cloud provider managed managed Kubernetes offerings, we don't care if you run Kubernetes on prem. We don't care even if you don't run Kubernetes and you run Docker or Podman. For us, it doesn't matter. What we care about is helping you get your container based application into production in a

28:06 safe and secure way. And our whole our ethos is for those organizations that are just getting started, we wanna help them. I I have many times described Portainer as as a tool that enables the have nots to compete with the haves. And what I mean by that is there are a bunch of organizations, the have nots, who who don't have the financial ability to go and invest in highly skilled experts to to support Kubernetes. They don't have the ability to go and invest, you know, large sums of money in in very expensive enterprise products like OpenShift potentially

28:10 Portainer's Ethos & Target Audience

28:44 to to try and offset. So the these these have these have nots still need to try and compete against the much the they're much larger competitor organizations, and our goal is to try and enable them to succeed. So another way I'd like to describe us is we are the Robin Hood of cloud nay of of cloud native. I like that. So we describe ourselves as a container management platform. And a container management platform is something that lets you manage all of these component trees. They let you manage orchestrator. They they give the ability to to get observability

29:07 The Need for a Container Management Platform

29:21 of the systems. They let you see the logs. There's a CICD engine. They they let you they let you better better manage the networking service discovery. You know, all of these things need to be addressed in some way by the container management platform. Because like it or not, you actually need one. Now you can go and choose to build one yourself, and this is the CNCF eye chart. I think it last time I checked, it was actually an a one printout. I think it may even now be an a zero. So, you know, you as an engineer or the

29:55 company that employs you needs to make a decision to go and build a management platform. You will need one if, you know, if if you just think that you're gonna go Kubernetes, Rawkode, Rawkode, you're you're you're solely mistaken. You absolutely will need a management platform. Now you will either go and build one yourself. You'll go and get Argo CD. You'll you'll probably go and get with your Grafana. You'll probably go and go and get some HashiCorp Vault. You're going to get a whole bunch of these products, and you'll you'll assemble yourself a management platform. You've just built yourself an ongoing maintenance nightmare.

30:24 Now now you need to make sure that all of these products well, for a start, you need to need to make sure the products that you've that you've chosen actually have life in them. So they've been actively developed. They're they're well funded. They're they're not they're not gonna vanish tomorrow because you're gonna have to replace them. But then you need to sure that they are interoperable with each other, that they're in that they're inter interoperable with the version of Kubernetes or Docker that you're running, and you have to maintain and and patch them as a case of unit. You have

30:49 now created a a maintenance overhead to manage this platform. So you can do that or you can choose Portainer. That's kinda where we're at with this thing. You know, why skilled labor shortages? You know, if if you go look at any CNCF survey, what are the barriers to adoption? It's pretty much these six. It's very hard to find people. When you do find them, they're they're eye watering and expensive. It takes a long time for people to to come up to speed with with containers in general. Things like Kubernetes, they're not secure. I'm not gonna use the

31:03 Addressing Barriers to Container Adoption

31:25 term insecure by default because that that has negative connotations, but they are not secured by default. They expect you to know what you're doing to secure them. You have to go in and and lock them down. They're not locked by default. You have lock them down. If you don't know what you're doing, platform's insecure. There was there there's so many examples or or surveys that have been taken where completely open Kubernetes clusters are exposed to the Internet because people just didn't realize they have to lock it down. Things like like Kubernetes are back. It's pretty

31:56 easy to actually configure users and roles for one cluster. You can you can go and manually correct users. You can go and manually create roles and role bindings, But that's one cluster. When you got 20 clusters or 30 clusters or 200 clusters, oh my god. To do that across that, now now now they need a tool like Okta or something else to try and take care of all of the federated user identity and and how you can do all the RBAC management. So it's tricky. Data operations, again, if you don't know the commands to go and to

32:25 go and triage the the view the events, you know, you know, you you really are struggling, so we wanna try to make that easier. And, yeah, providing secure access to the environment, you know, a lot of people say the the only the only safe way to give a developer access to Kubernetes is to not give a developer access to Kubernetes. Really? How how then are they supposed to triage their application in production? Really, you wanna give them secure access. Now the reason a lot of people don't give dev access is because it's actually quite hard to go and configure

32:53 the roles and role bonding successfully so that they don't have don't have accidental too many rights. So they're they're they're just main six reasons. We have three now I've called them product variants, but you could actually think of these as use cases. It's actually the same product. They're just different different use cases. So Portainer, it it being used as a universal management platform. If you have the need to to manage Docker on your local machine, maybe you've got some Docker swarm because you've got some legacy environments or or whatever. You've got some Kubernetes. Maybe you've got some

33:00 Portainer Use Cases: Universal, Kubernetes, Edge

33:26 Nomad. The Portainer, as a single platform, can do all of that. Maybe you're all in on Kubernetes, but you want you want a way to centrally manage Kubernetes. No problem. We can do that for you as well. Or may maybe maybe you're actually got a really large edge use case, I IoT or IoT type use case, network edge, call it what you like, smart city. Portainer is very, very strong in the edge management as well. So we have three distinct use cases. We're calling in three three different variants of the product. It's the same product under the

33:56 cover, so you don't you don't you don't choose one and then then you're locked in. It's the same base product. But and, again, at a nutshell, the main the main benefit of Portainer is to facilitate the the transition from VMware or VMs into containers. We help you or help your team with that that mental transition by giving familiar tooling, you know, that's a familiar experience. We make it really easy to see what's possible with with the tech. It's very easy to discover capability because there's a button that does something, and you're like, oh, what's this

34:03 Key Benefits of Using Portainer

34:27 button do? And so you now realize that there's actually some underlying capability that's amazing. And the the time to learn Portainer is very, very, very short. I was talking to to to somebody just recently who said they spent two weeks looking at one of our competitor products and hadn't really got it working. And he said within five minutes, had Portainer up and running, integrated with his active directory. He'd configured a couple of classes, and he had RBAC running. I was like, yeah. That's pretty cool. That's what we wanna do. So, you know, we we want once once

34:56 you get going real quickly. So get get you going fast. You know, Kubernetes, multi cluster management, really simple. No lock in. Yeah. Portainer just works with any Kubernetes API. We help you secure the environment through through policies and controls. We make it really easy to triage, and it's very easy to drive Portainer. Edge, massive scale. You know, a a single instance of Portainer can actually manage 45,000 remote environments, and we are scaling that. The target is a hundred thousand by sort of middle of next year, and we're gonna keep scaling beyond that. So you can actually

35:34 add, you know, a lot of clusters or a lot of individual nodes because we we develop Portainer to be easy to understand. OT engineers, which, you know, systems engineers in industry, It's easy for them to understand. We have things like device management as well. We've got integrations with Intel, AMT for lights out. That's like a a BMC card for server people. Zero touch device onboarding. Portainer is self hosted, so we can run safely behind your firewall. You don't have to give the keys to your kingdom to some SaaS service. It's all inside your firewall. Portainer needs about 20 mega memory to run,

36:15 so it's really efficient. So, naturally, it works well in an edge. And we have a lot of async controls, you know, API controls, so we actually work really well over networks that are highly latent or unreliable. And our goal is basically to make things really, really easy. Really easy. You don't have to try and remember all of the command line. You don't have to try and know how to write YAML. Mean, if you wanna write YAML, go ahead. We can we can help you do that with that GitOps engine. But if you don't want to, you don't have to. I'm always on

36:45 the UI. Yep. There's a there's a there's a UI that that will do it all for you. Makes it nice and easy. G two says we're awesome. And so because g two says we're awesome, I say we're awesome. G g two, unlike Gartner, is actually something that's done by the community. So the community votes and ranks it rather than a independent company like like Gartner, basically saying you are where you are. G two is actually is actually crowdsourced, and people go and actually submit votes and comments and vote for who they believe and where they should be. So this is actually

37:22 direct feedback from our users. We are really the only tool that spans every cloud provider, every Kubernetes, Docker, serverless even. So, you know, we're if you have a very hybrid world, we're the only tool of choice for that. And and we're really the only tool that can go from from data center to edge to my laptop to cloud, any cloud. So it's very, flexible in that regards. Portainer sits in between your users and the platform. So when you when you deploy Portainer, users interface with Portainer. They don't interface with the underlying platform anymore. So it's very good

37:51 Portainer Architecture & Security Model (API Proxy)

38:03 because it means that you don't have to expose your Kubernetes APIs externally. Portainer takes over and is the API endpoint for your users to interface with. So if they're using third party tools, maybe like OpenLens or KubeCTL or the the Azure I mean, the the Azure DevOps tooling or anything like that that wants to talk to an API, it could talk to Portainer, and Portainer will proxy that to the back end based on relevant permissions. That means that you can really lock down API access to your clusters in the back end. So we sit in between. We take care

38:37 of all of the user authentication. We we basically, you know, provide a safety blanket around all all of the environments to make sure that users can't do dumb things. We we make it really easy to do to do hard things, and we make it very hard to do dangerous things. Portainer's set self hosted, can run multiple things, connect it to your auth. We support OAuth and LDAP, so you can go to any kind of OAuth provider. SSO is built into the product even in the free version. We don't believe in in a SSO tax. So SSO is available.

38:47 Authentication and User Management

39:16 Roles and teams are back in native proxy. And, again, Portainer sits in between everybody and connects through to agents that run-in remote environments. So really, really flexible tooling. And I'm not gonna go anymore on slides. I'm gonna actually show you the thing. Awesome. Great. Any questions come up through that? No. I think that was very informative. I had no idea that you actually processed the Kubernetes API, and I could still leverage kind of my, you know, standard tooling. So that was a nice little treat. So now I'm just looking forward to actually seeing the demo and the UI and what

39:49 Live Demo: Portainer UI and Kubernetes Management

39:50 we can actually do with it. We got a comment from Eddie just saying, hey. And saying great t shirt. Although, we've spoken about the complexity of Kubernetes so much, I may have to hide my Kubernetes t shirt. I don't know. Right. Yeah. I'm just jumping the command line, but I'll stop doing that at this point in time. So, yes, we do. You see when when you log in I'm I'm logged in as an admin, and you wouldn't normally log in as an admin. So you're seeing more of the UI than you would do, and I

40:17 could probably log in as a user to show you, but for in in the interest of time, it won't for now. But here, I've got a bunch of Kubernetes environments. And if I click kube config, I can go and generate a kube config file that will allow me to connect to all of these environments. And if I download that file and open it, you'll see here all of the Kubernetes endpoints are actually Portainer. So they're all connecting through. So no matter which cluster I'm talking to, I'm actually talking through. So here, I've got a line node,

40:50 I've got a CVO, I've got a GKE, I've got a DigitalOcean, I've got an AKS. All of them, you're actually connecting through to Portainer as the API proxy. So from kubectl on my machine or OpenLens on my or whatever are the tooling you choose to use on your local machine, then you can you can connect to these back end clusters through Portainer, and we we basically just get in the middle and and make sure that the RBAC roles are applied and everything's working just fine. So in that regard, it's nice and easy. So if I come into a cluster, as

41:20 Namespace Management & Policies (Quotas, Ingress, Restrictions)

41:22 an example, I'll come into a DigitalOcean cluster. We have the ability again, I'm an admin. Right? So I have I have god mode access to this environment. I have the ability to create namespaces for in here. I can actually say, I wanna create them from a manifest so I can link this back to a Git repo and have a Git repo, you know, a GitOps engine that, you know, controlling the net the namespace. Or if I don't want to, I can use our form. And from the form, you can go and things set things like like

41:53 quotas for the namespace. So can say, okay. This namespace has this kind of quota. I wanna actually say there's a load balance of quota. They can only actually spin up a request through load balances in here. So that, you know because load balances are expensive. I I look at our our cloud bill every month and a huge portion of it goes go goes on load balances. So maybe just maybe you wanna control that. Do we want people to be able to use the ingress controller? If so, what what what domain names are allowed? So we might wanna say, okay. You can only

42:21 use this these domain names. Are there any registries that we wanna give them access to and we'll propagate the registry credentials? Do we want them to actually have access to persistent persistent storage? If so, how much persistent storage can they assign? So we can go and set all of these things, or we can just do a raw one and say, you know what? There's there's actually nothing. No no restrictions. We're gonna create a really, really simple namespace. And off we go, you go and create it. Once you have a namespace, you can actually see, well, who has access to the namespace?

42:49 So you can see, well, you know, who which which teams, which users, or which teams have access to that namespace. So it makes it nice and easy to grant access to it. And, again, coming back to us trying to be a bit of a guardrail at a cluster level, we can actually say, you know what? We don't want our people to have access to the the default namespace. Yes. So many people can, yeah, continue to use the default namespace. Don't use the default namespace. If when you when you are deploying applications, put the application in a namespace. Don't use

43:23 the default namespace. It's just dumb. So we actually say, you know what? As an admin, we're actually gonna flick a switch, and then no one can use the default namespace. It's just blocked. If they try to deploy into it, we'll say, uh-uh. Not allowed. So that is very good practice and something that we strongly recommend. We even do things like you know, Kubernetes, because of its infinite flexibility, it doesn't wanna say no to anything. So you can have a a a Kubernetes cluster running on three Raspberry PIs, and then a user can ask that cluster, hey. I

43:41 Enforcing Resource Limits & Preventing Failed Deployments

43:58 wanna deploy an application. I want that I want that application to have a gig of RAM or 256 gig of RAM. And Kubernetes will say, okay. And then in the background, it'll go and fail because the because, you know, a Raspberry Pi cluster doesn't have 256 gig of RAM. So it'll just fail. It'll sit there in in a in a crash back loop because there's no there's no resource. And the reason Kubernetes lets you do that is because it says, well, if you have auto scaling enabled here, like, your node auto scaling, right now, you might not have enough resource.

44:30 But thirty seconds from now, when more nodes have been added to the cluster, you might. So what we'll do is say, fail now, but we'll but we'll keep retrying in case in case you actually add more nodes. If you don't use node auto scaling, then your ability to over to to ever service requests that are beyond the cluster's capability is zero. So we actually let you flick a switch to say, don't let users ask for things that that the cluster in its current state can deliver. Again, we're just trying to make it substantially easier for for users. So you users don't do

45:04 things that then immediately fail and, like, well, it succeeded, and now it's failing. What's going wrong? So they they're they're going immediately wasting time triaging when, really, they shouldn't be wasting time triaging. We should just stop them doing things that's gonna immediately fail because because the cluster isn't equipped to deliver it. Same thing like load balances. It doesn't in Kubernetes, you you you can ask your micro case cluster or whatever else. Hey. I want an application, and the application needs to be published with service type load balancer. You have no load balancer. It'll sit pending

45:33 forever. Well, it's just dumb. It's gonna go back you're gonna go to triage mode. So we can say, don't use a load balancer. And then if a user asks for a load balancer, we won't we won't let them actually submit the request. We all say, this this this cluster has has no load balances. Choose another service type, ingress or something else. So, again, we're we're trying to stop people doing things that we know will immediately fail. Does that make sense? It does did. Yeah. We're just it's just trying to trying to trying to save time. Again, there's nothing

46:02 worse than saying yes and then failing immediately, and the user has to go into triage mode. It's just that's just crazy. But, also, things like like like constraints here. If you turn on pod pod constraints, we will we will go and we will go and deploy automatically in the cluster for you, things like o like, OPA gatekeeper. And here, we're setting OPA policies to restrict what users can do in in the cluster. Again, trying to stop users doing dangerous things. So you you don't have to have OPA with but when you when you flip the

46:11 OPA Gatekeeper Policy Integration

46:32 switch and click okay, we'll go and deploy the o p the OPA gatekeeper service for you and configure all these rules for you automatically. So, again, we're just trying to make it trying to make it really, really quick and easy to do to do relatively complicated things. Like, if anyone's configured, they'll be a gatekeeper. It's not easy. So we we try and do this for you. Yeah. I'm just glad you have the toggle button so I don't have to remember how to write RIGO because I'm terrible at writing RIGO. Yeah. We we likely will provide you the

46:59 ability to upload a a YAML file if you already have one that will basically, you know, answer boxes for you, you know, like, boxes for you. Because one of the things that we've been criticized of is that we're we're not not asterisk as code enough. So we we will we will provide the ability to to leverage code in the future. So somebody really really wants to write YAML to configure Portainer. They can configure Portainer with YAML. Correct. So we we we will we will be iterating that capability in the future and more and more, you know, things in Portainer are gonna gonna

47:32 start getting a a YAML ability rather than click to enable. But at the moment, we're we're trying to make things so so crazy simple. And the way to make it crazy simple is tick boxes or or or switches. Okay. And we have a a couple of questions if you're happy to tackle them just now. Got it. So Russell was asking if there is a Portainer managed service or whether they run it themselves. There is not. Everything is run yourself. If there is enough demand for a managed service, then I then I would consider it. Never never say never to a commercial opportunity.

47:45 Q&A: Managed Service, Resource Visualization, CRDs

48:09 There is not currently a managed service primarily because we don't believe there needs to be. Portainer is so easy to use and so lightweight that we don't believe that there there needs to be a managed service, but happy to happy to offer one if there's enough demand for one. Alright. And, Russell, following up with the second question and was asking, is there a way to filter all resources attached to an application? So, like, if we have a a pod, can we see that there's a namespace attached, some storage attached, network policies, and all that? So if if we come into an application,

48:40 for example, and I choose one, this test one, you can come in here and you can see here's the pod. If there's persistence, you can see that there's persistence. You can see there's any configurations. You can see there's always scaling. Could you submit little bit on that page? Sure. I forget that I have a terrible font size. Is that better? I will I'll deploy one. Right? So if I do NGINX, and it's just a simple NGINX image, I am going to have an environment variable of foo and bars. It's not gonna do anything. I'm going to persist

49:16 slash data. It's gonna be 10 gig in size, and it's gonna come from this DO block storage. I am going to have one instance. I could turn on auto scaling if I wanted. I'm going to publish it as a load balancer for 80 and deploy. So you can see here, we're gonna create a service of type the name engine x of type load balance. We're gonna create a service called this of type cluster IP. We're gonna create a stateful set called engine x. This is what we're doing behind the scenes for you. You don't you don't

49:49 know or care that we've done that, but that's what we've done for you. And deploy. It's gonna deploy, and this is gonna go and ask DigitalOcean to give me a load balance. So it's gonna go and ask DigitalOcean to give me some persistent volume. And now if I come into this application, you'll see here that you can access this through the cluster IP. You can access it through the load balancer. You know, the XML IP is still pending, we gotta wait for DigitalOcean to deliver it. You can see here here's the configuration. You can see here here's the data persistence,

50:22 the container name, the pod name, system folder, and here is the the the back the the back end volume. So we've automatically created the PVC for you and assigned it. It's gonna wait to be scaled up. Eventually, you can see the logs. You can go and see all of the metrics information for it. Now I'll come back and get one that is actually already up. Oh, it's actually already up. Well, I should've just refreshed. I'm just impatient. So you can see here, you can already see the stats. So this is now talking to the Kubernetes metric server and pulling in

50:54 metrics around this application. So it's not doing anything, obviously, because it's just a dummy genetics container. But, yeah, this this is talking to metrics and pulling in some metrics. We can actually come back here and see the application. I can go and get the logs for the application in one place, which does make it easy. And if I need to, I can get a console into that into that pod and triage that pod if I need to as well. So you're actually in and doing things. So it makes it nice and nice and easy to interface with it. So I don't

51:25 know if that's answering the question. So here, we're still waiting. No. Okay. Anyway, we're still waiting for it. So it's pulled the image. It's scaling. You can also see the YAML, by the way, if you if you care enough about it. I think that's question. We we can see all the kind of attached resources. Is there any special record sorry. Is there any visual representation, you know, like a graph, main map, and if like that? That could be a cool feature. Absolutely. No. But it's a good feature. By the way, if you come to the

51:59 namespaces, click on the namespace. You can actually see the applications running within the namespace as well. Or if you want another view, you can come to the cluster, and you can click on the nodes of the cluster if you wanted to, and you can see the applications that are running on that on that node as well. So there's a whole bunch of differing differing views if you want to to look at it as well. K. And, again, from the cluster, you can see things, you know, with, you know, the memory reservation, memory use, CPU. You can see

52:27 the node stats as well, and, again, talking to metric server. So it it's a very deep experience. It really is a very deep experience. Again, the volumes so you can see here the that this is the the the claim that we've created here against the block storage. So here we are here up and running. So it does make it easy. And, if you if you really, really want to, you can click the kubectl shell and you can you're actually in that cluster. Kubectl get nodes. You're actually in that cluster inside Portainer directly engaging with that cluster should

53:01 you want to actually use the command line because there's something you wanna do that's that's beyond what's available in the UI, should you need to. Cool. So pretty pretty easy to to go and configure, you know, like, to go and configure a stateful set with a load balancer and a config and and and and and, you know, that that manifest that that helm file would be quite large. I I actually deployed that in a very, very short amount of time. Now is this is this infrastructure as code? No. Would you would you would you do this

53:34 in production? Probably not. But for a dev who wants to experiment on their machine or a dev who just needs quickly spin things up in a dev cluster, nothing wrong with the UI to get things done quickly. In production, obviously, you would create a a a manifest file and you'd use things like like a GitOps engine, you configure automatic updates. So you're gonna poll Git, look for changes, and force redeploy any changes in the cluster. So, you know, you in production, you'd use GitOps. But outside of production, ain't nothing wrong with a good old fashioned UI saving you

54:06 time. Argue argue against that. Go on. No. I'm not arguing about it. I think I I think we definitely need more simplicity in this in this space. Like, things are wildly complicated. It just. Absolutely. It it I mean I mean, how how long would it take you to go to to go write a a manifest from scratch? In fact, I can I can show you the manifest? Right? So, yeah, how long would it take you to go go and write a manifest from scratch that that does all the stuff? And the unless you're an absolute wizard or or you're

54:36 starting from one that you already have and you're just simply copying a manifest and and modifying a couple of things. And, you know, you really you really gotta gotta be a a pretty pretty special you know, oh, here you go. The load balance is already up. So there you go. We've got the IP address from DigitalOcean and and NGINX is up and running. So Cool. And as you'd expect, if you delete the application, we go and clean up after ourselves. If you remove it, we'll we'll go and tell DigitalOcean, go and go and delete the volume, go

55:06 go and delete the load balancer, and it'll go and clean up after itself as well. So, yeah, it's all all legit here. Alright. You ready for the hard question? Go on. Does Portainer provide any convenience around custom resources? CRDs, not yet. So if you are installing operators, you can install them using Helm charts. But, no, we don't currently have any native support for CRDs. Little honestly, though, most CRDs are either available as a manifest that you can install, just add add add application, create for manifest, and even paste in a operator YAML if you need to. Yeah. What I

55:57 was thinking was, like, I wonder if you know, because once you apply the CRD to the cluster, you have those open API spec available over the API. It's, a Portainer could consume that and then get me a web form for those fields based on the open API spec. That would be a pretty cool feature. Not yet, but happy happy to take that. Failing what I should. Happy happy to take a feature request. Absolutely. Any any anything that actually makes it easier to consume? Absolutely. It's really funny. Like, we we we added Helm support push push Helm support out.

56:31 And, yeah, Helm Helm is is is a very cool tool. Right? You know, it makes it very easy to deploy stuff, but you still need to know how to modify the values dot YAML file. So we make we make it really easy to edit values dot YAML directly inside Portainer so you can you can, you know, edit it directly and deploy. It's really funny. We actually really we we we actually released this feature, and then we got commentary back. Why why are you actually releasing features for Helm? Helm's dead. It's now all about all about customized. So, like, what?

56:59 It's like this that this thing that this this this environment changes so quickly. So anyway, the Helm is not dead. Helm is definitely not dead. Helm is so easy. So yeah. So you you you can see here's here's the the values file. You can make changes to to the values file, hit hit deploy, and we'll go and deploy it in into the cluster. So it makes it really, really easy to work with Helm as well. You can head add other other Helm repos should you should you need to. So it makes it nice and nice and

57:26 easy. So you're logged in to Portainer right now. What what sign on mechanism is used for this instance that we're looking at today? This one, if I go to settings authentication, is using local or internal just because it's my demo environment, but there's absolutely nothing. And by the way, you can change your password characters if you want. We got some we got some beat ups for trying to enforce good practices for passwords. So we made we we made it fixable because some people wanna pass with length of one characters. In fact, some people wanna pass with length

58:01 of zero. So that that this one uses internal. In in all honesty, in production, I would strongly recommend something like OAuth. Yeah. Because if you if you do OAuth, you've got things like single sign on that you can do automatic user provisioning, automatic team mapping. So if users are in a team or sorry, in a group in OAuth, we will we will automatically associate them to a team inside Portainer. So it makes it really easy for management. You don't you don't manage users in Portainer or Teams at that point anymore. It's all managed upstream. So in all honesty, you'd you would use

58:32 one of these primary providers, and it's pretty easy to go configure against the primary providers in this regard. So I probably should change my devo to actually use to use something a bit more reliable. Alright. No worries. We we have things like authentication logs so you can see who has tried to log in to the environment. And when they have logged in, what have they done? So, you know, this isn't a audit log. There's no delete button. There's no purge. We keep this log for seven days and cycle it. So, you know, your your c a your

58:47 Additional Features: Audit Logs, Registries, Custom Templates

59:02 CISO can log in and see who caused the outage at two in the morning and what do they do. So you come in here and inspect the payload and see what was what was sent to the back end cluster. So that's sits here in a really nice, yeah, audited audible way. This is the paid version I'm using, by the way, not the free version. So there's a few more features in here. Registries, providing access to registries is quite quite quite a burden. So we let the administrator define registries here so you can add a registry. And once

59:34 you add registries in here, you can come into a cluster and say, I want to enable this cluster to to use this registry. And then want these users in this cluster or this namespace to have access to it, and then we'll we'll actually propagate the image pull secret into the namespace automatically for you. So your so your dev users don't need to worry about it. So makes it nice and easy to to work with with private registries. And if you so desire it, because we're getting a of people ask for it, you can actually hide

1:00:03 access to Docker Hub. So we actually hide it from the UI so people can't see the public Docker Hub registry. So just a lot of lot of really interesting features there. We have another question for Russell who is asking, is there anything like alerting? Or do would you expect people to manage them through other tools? I'm assuming that being if a pod is crashing back off, and is there a way to kind of alert that for someone? So we we make it obvious in the UI. So in the UI, we make it obvious that it's it's failing. Like,

1:00:42 you can see here, this is this is healthy. If if there is a zero of one, this goes bright red to show you that there's a problem. That's not alerting, but that's making it that that there's a visual cue. By the way, this green dot here is if you are using an image. So the green means the image that is running is the same version as the image that's in the registry. If if they differ, this little green dot goes red just as a as a complete tangent there. So there's no native alerting per se in

1:01:13 Portainer, but what we are actually doing is integrating with a product called SOSIVO, s o s I v dot I o. So Portainer is building or has built and will be releasing imminently in a in a native integration with Sausavo. And when you inside a cluster, you will be able to turn on Sausavo monitoring. We will deploy the Sausavo collectors. In fact, if you noticed, there's probably a nice space called Salsavo in here because I've been playing around with it. You can actually turn on Salsavo alerting, and it'll it does all of that really cool

1:01:47 stuff. Salsavo is what Prometheus and Grafana should be. The the re the reason reason why we've decided to partner with Sausavo is they share a very similar ethos to us. If you have a wall of metrics from Prometheus and Grafana, unless you know what you're looking at, the metrics are relatively meaningless. Salsavo ingest the metrics, has a has a whole rules engine inside it, and says this means that. So rather than just giving a wall of metrics that says, hey. There's a problem with the cluster. This is the problem, and this is what you should do to fix

1:02:18 it. So I I kinda really like that that, you know, ease of access to true observability. You can still see the raw data if you want, but but they they they spend a lot of time building the front end. And so we're we're gonna pull all of that information into Portainer and that you see it, but also you can see the alerts. So right now, you can't, but so serve.io. These guys. By the way, absolutely no commercial relationship with these guys at all. Just like their product and wanna integrate with them. So pretty cool. So no. No. No native alerting. But once

1:02:54 we have the source of our integration, we will be able to do that. Yes. Alright. Cool. Other quick other questions? What's the custom templates thing? Did we look at that? Custom templates are awesome. And in fact, I probably should've talked about them sooner. So Portainer's goal is to enable those who need to be enabled. So even inside an organization. Right? So let let let's let's say that you're you're a company, and the company has a luxury of being able to hire one person who knows about Kubernetes. That one person can actually go and set up a bunch of stuff

1:03:29 for the the the less empowered members of their team. I'm I'm I'm choosing my words carefully here. And so a an expert user could come in here and say, I'm actually going to go and create a bunch of templates, which could be they're they're all manifest based. It could be you you you might paste in a manifest that that defines an ingress. You might define you might paste in a manifest that deploys an application with a whole bunch of Bushtash variables. You can you can you can basically add manifest in here and save them as a template that then other

1:04:03 users can go and consume, click deploy, click deploy, click deploy. So it's it's a very, very simple and easy way to consume advanced capability that an expert inside your organization has created for you. So really, really, really, really nice way to to share things. Similar similar concept, by the way, with the namespaces when I said the ingress controllers. Right? You may say, you know, the expert person will say, I'm actually we we only only own the domain, you know, testtestdomain.com. So I'm gonna only allow users to request that. And so once this is done, when users

1:04:40 inside the namespace go to create a service of type ingress, the only drop down are the domains that the expert has pre preauthorized or pre validated. So a a user can't go and create some random domain and and push it out. So we we we we try to make it really easy. So, again, custom templates are a way to share things. And so as as a user, I can actually go and deploy this. So I can I can come into this this one here, and I can see, for example, I've got a bunch of stuff in here?

1:05:13 This is this is a PVC claim, deploys an engine x. So there's a bunch of things in here, and I can go and deploy the thing from here pretty pretty quick and easy. Cool. So it's just it's just shared. So does that make sense? Yeah. It does make sense. Definitely. Especially for those things where, you know, people like to think that Kubernetes deployments are unicorns and super unique. But actually, deploying most applications to Kubernetes can be templated relatively easily. Like, we all just need to specify a container image at a port and maybe some, like,

1:05:45 CPU limits. Like, nothing really is that special or unique. Yeah. Especially when you're using using using variables. So in inside the variable, you can actually put in just basic Bushtask variables. And then, basically, when when you go to deploy, you can that, you know, you there's a nice input box here, and you can actually replace the the the variables at deploy time. So it makes them able to be to be reused in a really, really simple way. So it's just it's just a nice easy way to say, you know, I've I've I want expert in

1:06:15 my team. I'm one I'm one person. I can only work seventy hours in the day. I I I I need to I need to make myself infinitely more efficient or effective by propagating my knowledge through to other members of my team through things like templates, And that that's kind of the goal. So even though I said Portainer is a tool that almost always an expert might shy away from, an actual true expert, a true expert realizes the the the infinite time savings that's gonna make and say, actually, you know what? I'm sick of getting dumb questions from my my my

1:06:48 my colleagues. I'm gonna put Portainer in here and actually provide provide a means to abstract away stuff that I get asked all the time as base templates. So at your exit, I say, you know what? This is actually really, really interesting. I can now I can now get back five hours of my day. I'm not answering dumb questions, building building templated manifests. Cool. Are there any other features you want? Sorry. Let me go. No. One one of the most important things is dark mode. Everyone wants dark mode, if I don't click it if if someone will ask, is there a dark

1:07:20 mode? Yes. It's dark mode. I I prefer light mode, but there is a dark mode. There's also a high con high contrast mode for visually impaired, but you can choose to this. So we have API tokens. If you have automation, external automation, you can add API tokens, and then you can automate Portainer. By the way, we're an API first product. Everything in the front end has an API, and you can you can control it through API. Very cool. Yeah. It's weird how we went through this phase where, like, biggest complaint people had about any better software

1:07:50 was it didn't have dark mode yet. And it's like I just see that for every like, even random products that were just it's just why is that your complaint? Like, it just makes no sense. That's just where we are now. It is. We we haven't talked about Edge and I I probably won't in any depth, but Edge lets us manage Edge devices. Edge devices are simply devices out there on the public Internet or out there across the other end of a very, very slow WAN connection. Call it what you like. They're devices that are not that are not in the

1:08:07 Edge Computing Management Features

1:08:25 data center. In fact, they're very far away from the data center. We have the ability to group them so we can group them based on whatever makes sense for you, either manual grouping or dynamic grouping. And then you can go and deploy a manifest or a Nomad job or a composed file against a group, and Portainer will then go and say, hey. All of the devices in that group, go and run this application and make sure it make sure it stays running. So it's a way to do to actually say, take this application, go and deploy it a thousand times,

1:09:00 10,000 times, whatever you want to all these devices, go do it. And if it fails, tell me. But, basically, just keep trying until it works. So it's a really nice way to essentially manage the deployment of applications on mass. You can also run edge jobs, which lets you run commands on the remote node directly. So you could do things like, you know, d f and pull in pull in anything you like to it. So you can go run things on remote devices, and they're basically just just batch scripts that run. I guess I could choose that if I

1:09:30 had, like, the Kubernetes clusters, one in Asia, 1 in Europe, 1 in The US, and I want you to replicate all the workloads across them, would I use %. You could use it for that. Yeah. %. And I know it's not really as you say. Still, I think a use case I would have at least. %. Right right now, we're the feature is called Edge. It it really should just be called multi cluster management or multi device management. But right now, it's just Edge stacks just just because it makes sense. Yeah. So, yeah, it's a it it it's it's

1:10:01 a very, very powerful tool, and I can spend days going through every feature because we've we've built something that is just monster. There's so many so many features, so many capabilities of the product. It's near limitless in its power. You know, I I am I am near near useless in front of a kubectl command prompt. I just don't know how to do anything because I don't need to. I just do everything in Portainer. I've forgotten all the commands. But you could you could set me any kind of challenge. You could say, hey, Neil. Go go deploy this application like this,

1:10:31 and I'll I'll be able to do it in Portainer. There's very, very few examples where I couldn't do something using Portainer, and and I'll be forced to go back to to a command line. Sweet. Alright. Are we done with the demo? Is there anything else you would like to show before we finish up? No. We can stop there. Alright. Yeah. There was a lot to cover there. I I like the simplicity that Portainer brings to Kubernetes clusters, but even more special than that is that it's not restricted to Kubernetes clusters. You know, we we don't play with Nomad, we've seen the option

1:10:49 Portainer's Power and Ease of Use Recap

1:11:01 pop up a few times. There was Docker Compose stuff. It's like Portainer as a management interface for kind of universal containers. And I I I like that approach. I think it's gonna empower and enable many many people as I'm sure already as you said what? There's like over 700,000 active users or something like that. So Every month. That is a staggering number, but it's very good to see. So we got a couple of sorry. On you go. Let's say we we we definitely see people who are are net new to containers making a start with Docker and then over

1:11:36 time transitioning to Kubernetes. And so we we really do help them with that process. You know, they they can they can learn how to use it, learn about microservices, learn learn about triaging microservices in Portainer. And then when they're ready, then they they we we're with them as as I make the jump to Kubernetes. A lot of the other tooling out there is only Kubernetes, and you have no choice to go from zero to a thousand with you know, in the site. If if you're not ready, good luck to you. You got you got you got some some serious, you know, headwinds

1:12:07 ahead of you, whereas Portainer really tries to say, well, actually, you know what? We can we can actually crawl before we walk before we run. We we're kinda, you know, guiding people on what what I've determined a relatively sense sensible progression from no knowledge to advanced knowledge. Awesome. A noble and good mission. We have some thank yous in the chat. So Russell and Morat both say thank you. Really nice demo, and thank you again. So I will echo their statements. Thank you, Neil, for joining us, for guiding us through Portainer. Before we finish, do you wanna is there

1:12:34 Portainer Roadmap and Future Development

1:12:36 anything you can share about Portainer's roadmap? Anything you're stated about for the next three to six months? Anything you wanna share with our audience before we finish up? We just launched a new website. Go have a look at it. It is lean, mean, and clean. Inside there, we have a home and student offer. So right now, if you're not aware, we have Portainer CE, the open source version. We have Portainer Business, the closed source licensed version. We make our closed source biz the the closed source version available for free for anyone who has under five nodes in

1:13:11 their cluster. Right? So anyone with under five nodes can go and get a license for for Portainer business right now and use it, and I would strongly recommend if you have under five nodes, use that version rather than CE version. You get a lot more capability. If you are a home user or student user and you have more than five nodes, we have a home and student license, $249 a year. Go buy that. We give you 15 nodes. You can do everything you want. So, you know, for those of us who like to tinker at home, myself included,

1:13:37 go go and use Portainer business in your home setting, learn about all of its its rich capabilities. You'll love it. And if you're more than five nodes, it's relatively inexpensive to get a 15 node environment. There's a free trial available if you have a much larger use case on that, but it's it's very, very simple and easy to get going. Road map, we're looking at things like that front end form based wizard that we had there that direct that actually direct deploys. One of the things we're gonna use we're gonna do is try and use that front end

1:14:07 form as a YAML generator and then push the result in YAML to a Git repo and then later deploy from the Git repo. So it's gonna be a cluster context aware YAML generator. So you can actually use it to generate YAML. That's just quite interesting. One of things I didn't show you is we have the ability in Portainer to actually create Kubernetes clusters natively from within Portainer. So you can you can go into environments, add environment, CAS, and then get put your credentials for any cloud provider, and we'll spin you up a CAS cluster. We're adding support for micro k eights for

1:14:39 on prem there as well. And that that will also transition to be more as code based. So, yeah, there's there's a a lot of lot of stuff coming for Portainer, but we're we're really focused on making it super easy to to use. So, yeah, everything we do, you know, the the the the the number one rule in in our product team is can we make it easier? And if the answer is yes, then we we we keep iterating our our product ideas until we can make it easier. Awesome. Well, that's a pretty solid road map. I'm

1:15:07 Conclusion and Thank You

1:15:09 excited to see all those things coming soon. And I'll say thank you again for joining me. It's been an absolute pleasure. And hopefully, we'll do another one of these again soon. Thank you very much, Neil. All good. Appreciate it. Thank you all for watching. Have a great day, and we'll see you next time. Bye. See you.