WEBVTT 00:00.000 --> 00:19.200 So, hello everyone. Thanks for joining. So, today I'm going to make a presentation titled 00:19.200 --> 00:28.240 running containers under System G, exploring Pondman quadets and so on to the schedule, a short 00:28.240 --> 00:35.200 words about me. Then we will talk about Pondman and the interesting parts would be Pondman 00:35.200 --> 00:42.720 quadets and then we will do a demo to explore and see how we can use it to run gross Pondman 00:42.720 --> 00:51.120 resources with System G. So, about myself, I'm a software engineer at Fedat. I've joined the 00:51.120 --> 00:59.520 Pondman desktop team a little bit more than one years ago and that's my first time 00:59.520 --> 01:09.440 much for them also. So, why working on Pondman desktop and Pondman? We saw that one big challenge 01:09.440 --> 01:18.320 is moving from a local environment to a production environment. In pretty big company we often 01:18.320 --> 01:24.720 have to team the development team, which are playing with containers, starting them putting them 01:24.720 --> 01:31.680 from Docker IO and often needs other needs to orchestrate them because having one container running 01:31.680 --> 01:38.720 is nice but having them communicate is better. So, we see compost being used in a lot of 01:38.720 --> 01:46.400 projects and this is a nice tool to run things locally. But on the upstream for orchestrating containers 01:46.480 --> 01:53.520 we often use Kubernetes because it offers way more extensibility, scalability and it's not the 01:53.520 --> 01:59.200 same format. Compose is a specific kind of file and transforming it into Kubernetes. 01:59.200 --> 02:06.960 General is often a complicated complicated task. So, we have this whole of discrepancy between 02:06.960 --> 02:12.800 those two teams and in companies where or in places where we don't have two teams and on the 02:13.200 --> 02:18.640 developer, we often see compost in a production environment like when you don't want to 02:18.640 --> 02:24.800 bother having a full Kubernetes cluster or only have a small DPS or single server node, 02:26.400 --> 02:31.040 you are pretty frustrated to have to deploy a full Kubernetes. So, you find alternative solution. 02:32.640 --> 02:41.920 So, what is Pondman? Pondman for the name Pond Manager, before going into VAT in details, mainly 02:42.400 --> 02:48.800 of Pondman is managing containers and images. It's compliance with the open container 02:48.800 --> 02:55.360 initiative of CI and why you should use it? It's open source. It has been recently the nature 02:55.360 --> 03:00.960 to be a plan that you have computing foundation this year and CF and it can mostly do 03:00.960 --> 03:11.360 everything that Docker can do and it's one of its over goal but just managing containers is trying 03:11.440 --> 03:17.760 to address the challenge that I was talking earlier and by this name Pond Manager, we can see Pond, 03:17.760 --> 03:26.240 the unit resource of Kubernetes. What that means, it means that Pondman aim to support, 03:26.240 --> 03:32.400 naturally without having a full cluster environments, Kubernetes resources. So, you can, 03:32.400 --> 03:40.080 in the same five spec, take a pod, deployments, volume service or config map and run them directly 03:40.080 --> 03:48.960 onto your machine with a Pondman installed. From your demo, next, I will use Pondman Desktop, 03:48.960 --> 03:56.640 which is the UI tool for containers on giant containers with S because don't be tricked by the 03:56.640 --> 04:02.320 name. It's aimed to work mainly with Pondman but if you have Docker installed, Lima or any of 04:02.400 --> 04:09.680 a container in giant, you can explore your containers with it and this tool aimed to reach 04:09.680 --> 04:16.320 also a gap to go further because it allows you to explore Kubernetes cluster resources in addition 04:16.320 --> 04:24.800 of Pondman resources. But as I said earlier, the challenge is my local developer don't want 04:24.800 --> 04:30.640 to have full Kubernetes cluster because it's just too much, too many features, too many elements 04:30.640 --> 04:36.080 and it's taking all my CPU on my machine. So, what do you get if you squash a Kubernetes 04:36.080 --> 04:45.600 Kubernetes? You get a quadlet. So, what's a quadlet? Quadlet came pretty recently in version of Pondman 04:46.720 --> 04:55.200 to find a way to better integrate a Pondman resources with system D. So, why? So, first, we want 04:55.360 --> 05:01.520 it away, just like we do with Kubernetes to take Pondman resources and make them run with 05:01.520 --> 05:07.520 system D. So, we want it something declarative and to do that, we created something that we called 05:07.520 --> 05:16.720 a system D generator. So, this is something for system D, but anyone can write. It's an executable 05:16.800 --> 05:24.480 that is a Gipartist launch at runtime or reload time very early and it aims to transform 05:24.480 --> 05:32.720 configuration file into dynamically generate unit files. So, you write, you declare your quadlet, 05:32.720 --> 05:37.920 your container or quadlet, which will present a Pondman resources. You transform it, it is 05:37.920 --> 05:46.320 transform it, sorry. It is converted through the quadlet system D generator into a system D file, 05:46.800 --> 05:51.840 and it just run on your machine. Why? Not just writing the system D unit file, 05:51.840 --> 05:56.560 because system D unit files are often very ost specific, like where is Pondman 05:56.560 --> 06:01.680 in style, where is your container, I'm joined in style. And we want to be able to just 06:01.680 --> 06:07.280 commit this file. I want to commit this configuration file and reuse it somewhere else and update 06:07.280 --> 06:14.960 over server where I can just deploy it. Why just trying to do that with system D? Because on my 06:15.040 --> 06:21.600 GPS machine, on my small server, I want to have a lifecycle, which is predictable. If my machine, 06:21.600 --> 06:26.960 if my server is rebooted, I want my container, my resources to be rebooted. I don't want to have 06:26.960 --> 06:33.680 to do some tricky magic to have it alive. And system D is predictable, because it's what make 06:34.880 --> 06:41.520 all the services on the machine running. And for how it articulate for the configuration file, 06:41.600 --> 06:48.480 it's just using some kind of system D syntax, with some syntax sugar and addition, 06:48.480 --> 06:55.840 allowing you to define your resources. And we saw growing number of tools around this since 06:55.840 --> 07:00.960 it has been introduced such as Podlet, which if you don't want to write this configuration file, 07:00.960 --> 07:08.720 you can run your container and generate the quadlet for it. But in our world, let's see what 07:08.800 --> 07:16.640 it looks like. So for example, here it's a quadlet container, like the very basic NJX services. 07:16.640 --> 07:23.680 And you can see some very familiar option, like the Publish port, which is an option that 07:23.680 --> 07:30.160 everyone is using. The container name, the image, which is the document, images, and why writing 07:30.160 --> 07:36.960 that? As I said earlier, why not just writing the system D services, because having a full system D 07:37.040 --> 07:43.920 services for a host is very specific. And it's very verbose. And it's easier to write something 07:44.720 --> 07:52.560 like this, one on the left, and one on the right. So let's just go into the demo. 07:56.720 --> 08:06.160 So first, let's take Podlet resources. So for this demo, it's just, is it zoomed enough? 08:07.920 --> 08:21.600 So let's create a detached resources. We can name it, NJX for them. We can publish the port, 08:23.280 --> 08:27.920 and we will use this. So this is a very traditional way of running a container. 08:28.800 --> 08:34.960 I know that it's running. Now let's open Podlet Desktop. So this is a UI tool that I was talking earlier. 08:35.680 --> 08:42.080 And Podlet Desktop has been made to be extensible. It's very inspired from VS code. So a lot of things 08:42.080 --> 08:48.480 work with extension. And it has an extension to support quadlets. And it offers a few options. 08:48.480 --> 08:55.840 So as I said earlier, we have growing tools, number of tools, with run quadlets. And from here, 08:55.840 --> 09:02.640 I can just go here. And other additional option, which is generate quadlets from the resources, 09:02.640 --> 09:09.920 but I started from the terminal, generated. And we can see that we are getting back the resources 09:09.920 --> 09:15.920 that I was showing earlier. So we transformed the command the resources that we created in the terminal 09:16.560 --> 09:24.000 to a file. And if we decided to just, I could just copy this file, commit it to a repository, 09:24.000 --> 09:29.280 and reuse it on any Podman machine. Do you just need to watch system D installs of this can be 09:29.440 --> 09:38.480 hard requirements for some people. So let's load that into the machine. And seem to be completed. 09:39.680 --> 09:46.640 And I have it here. And let's open the details of this file. So this is the generated element. 09:46.640 --> 09:53.200 This is a horrible one, but system D is going to be run. This is generated, as I was saying. 09:53.200 --> 09:58.000 And this is the source file, but you should commit and reuse. You need to place it in some 09:58.000 --> 10:03.520 specific folders. So here, Podman desktop did that for us. You need to place it in the 10:03.520 --> 10:09.520 either in the user space or in the root space to have it run as root or not. You have to choose. 10:10.080 --> 10:15.920 But since it's managed by system D, you need to use Johnard's TR to be able to follow the logs. 10:15.920 --> 10:24.400 And here it is what we did. And I could just enable the services. And if we go back into the containers list, 10:25.040 --> 10:29.920 we can see here that we have a different icon. Because Podman desktop is able to detect 10:29.920 --> 10:39.520 that the container here in our case is managed by system D. And we can just stop the services here. 10:39.520 --> 10:45.280 So disabling the system D services will kill the container and remove it. 10:47.120 --> 10:54.160 But we are rarely just having one containers. We often are in the situation where we have 10:54.160 --> 11:00.480 big compos file or tons of containers that we want to orchestrate. So let's just quickly show 11:01.760 --> 11:08.880 an example here of a compos file. That I took online. There is like three big compos, three containers. 11:08.880 --> 11:14.160 One, which is an NJX reverse proxy, a backend, which is just a flask application, which is built 11:14.160 --> 11:21.440 from this folder. And a Mongo application, which act as a database. So let's just run that to see 11:21.440 --> 11:30.800 if it works. So for a lot of components, Podman is also able to act as a replacement in most cases. 11:31.840 --> 11:39.040 So let's start it. And let's go back to our Podman desktop application. And we can see here 11:39.040 --> 11:42.640 what we have our compos application running. Let's see if I can access it nice. 11:43.360 --> 11:48.000 If I can access it. So let's open in the browser. Here I will see, 11:48.080 --> 11:52.880 hello from MongoDB clients. It's working. Great. But I didn't know if you knew. I just 11:52.880 --> 12:01.120 run a compos application here. So let's go back here. Let's see if I can generate quadlets from 12:01.120 --> 12:07.680 this file. Podman desktop is able to detect that this compos application was from this compos file. 12:07.680 --> 12:14.480 And give us a few options. We can generate container cube type. Sorry, container quadlet type, 12:14.560 --> 12:20.080 cube type, or pod type. For our example here, we will generate, because I was talking about the 12:20.080 --> 12:24.960 gap between the development environment and the production environment. I will generate a cube 12:24.960 --> 12:32.400 quadlet, which is a specific kind of quadlet. So let's do that. And we can see here that we have a few 12:32.400 --> 12:39.920 options. And a lot of variables, jammals, Kubernetes like. So we can see here, similar to our previous 12:40.880 --> 12:47.920 NJX container resources. We have two resources. Podman desktop can manage Kubernetes resources. 12:47.920 --> 12:55.680 You just need to show where they are. So here we are linking our resources. And we can find back 12:55.680 --> 13:02.880 the containers. So the NJX reverse proxy, our flask application and the Mongo. And let's just choose 13:02.880 --> 13:13.600 where we want to deploy it. And load that into the machine. Go back here. But compared to our previous 13:13.600 --> 13:24.640 step, I want to change maybe something. Sorry. Could be a mail cannot rebuild containers. 13:24.640 --> 13:34.960 Podman can in our QBML file. Here, we only have flask. Flask is a folder in our working directory. 13:34.960 --> 13:39.600 Podman desktop is able to detect, but you are pointing to this. And since in the 13:40.720 --> 13:44.960 definition here, we added the build arguments. If I'm building it here, 13:47.440 --> 13:52.080 which should be, okay, we have some good logs here. We can see that it's mounting. Oh, 13:52.080 --> 13:56.160 it's doing people start opening the connection with the right. It seems it is. 14:01.120 --> 14:06.240 And obviously it felt because I have my compose application running and it's conflicting 14:06.240 --> 14:12.320 between my ports. So let's talk for a lot of that first. Let's do some cleanup. 14:13.280 --> 14:29.120 Let's go back to our ports and let's start it again. Okay, I need to restart it. It's not. 14:29.920 --> 14:42.720 Let's see, I have nothing. Okay, I have nothing now. And doing the build again. 14:43.680 --> 14:59.600 And seems to be good. Enough logs, probably running. Go back here. Oh, and we can see that we have 14:59.600 --> 15:05.520 our different containers with the icons saying that we are managed by system G. And let's see if 15:06.480 --> 15:11.600 we have the right text, open in browser. Hello, first of them. So, 15:16.960 --> 15:25.040 that was the obvious, but I hope it will get better in the future. So conclude. Podman, 15:25.040 --> 15:30.720 Podman really tried to bridge between local environments and production environments. 15:30.800 --> 15:37.280 Learning compose is something already pretty odd as learning Kubernetes. So why not just running 15:37.280 --> 15:42.400 Kubernetes resources locally without having the overwhelming complexity of a full cluster. 15:43.520 --> 15:49.760 What let's in addition of that and in combination, but allow you to type podman resources 15:49.760 --> 15:57.040 with system G. So having them predictable lifecycle and reuse resources easily. 15:57.440 --> 16:04.560 And thanks for listening. This is a link to an article of giving more details about Podman and the 16:04.560 --> 16:10.320 request. If you have any questions, I think we have a few minutes. No, we're out of time. Thank you. 16:10.320 --> 16:14.320 I will be outside if you have any questions.