WEBVTT 00:00.000 --> 00:12.000 So, welcome to our next session. It's Jan talking about DNF and containers, I guess. Please. 00:12.000 --> 00:25.360 One, two, one, two, you hear me? Okay. So, imagine this. You need to build thousands of container 00:25.360 --> 00:35.040 images, each one tailored to meet specific customer requirements. And you need to do this in a 00:35.040 --> 00:42.080 secure, reliable and reproducible way. Why? Because you want to prevent supply chain attacks, 00:42.080 --> 00:47.680 want to ensure deterministic builds with consistent outputs, and you want to comply with industry 00:47.680 --> 00:53.440 regulations by isolating your builds from external networks. So, in order to achieve such a container 00:53.440 --> 00:59.520 build, you need to prepare and pre-fetch all the packages and dependencies beforehand in 00:59.520 --> 01:06.240 your build environment. So, you can then seamlessly execute your like podman or Docker build commands. 01:06.240 --> 01:12.400 And this is precisely when the DNF manifest comes in. So, the centerpiece is a manifest document, 01:12.400 --> 01:18.400 which is basically a Yamul document containing all necessary information about your packages. So, 01:18.400 --> 01:24.800 it contains like information about your dependencies, about the versions, about the repositories 01:24.800 --> 01:30.640 and URLs where you can download the content from. And this manifest file is created based on the 01:30.640 --> 01:40.000 input. And input, it's like saying, hey, DNF, I would like to describe everything I need to 01:40.000 --> 01:46.800 install the engine, etc. And for example, curl and W get for debugging purposes. So, you 01:46.800 --> 01:52.800 would just specify the package specs. And the output is the manifest document with all the result 01:52.800 --> 02:00.960 packages. So, one way of specifying the input is on the command line, but for the automation 02:00.960 --> 02:08.560 purposes, the more appropriate it method is using the so-called input files. And you could also 02:09.120 --> 02:15.520 like dump your currently installed packages on your system into the manifest file. And so, 02:15.520 --> 02:19.920 with such an existing manifest file, you can take it to another computer, and then or 02:19.920 --> 02:25.520 there you can download the content or install it using DNF or even do some like static analyzes, 02:25.520 --> 02:32.320 like security analyzes, checking for CVs, like authentication of the configurable repositories, etc. 02:34.800 --> 02:39.360 And if you created the manifest file using the system, it's not sure you can also like 02:39.360 --> 02:45.280 reproduce this environment on a different machine, or you can like replicate some specific 02:45.280 --> 02:52.480 environment for debugging purposes. Okay, so let's see the next one. On some simple use case, 02:52.480 --> 02:59.600 which will basically prepare the packages you need for your application in an environment in an 02:59.600 --> 03:06.320 empty container. So, here's a simple manifest new command, which is basically saying hey DNF, please 03:06.400 --> 03:11.360 prepare me a manifest file with e-links and new-duke packages, and all the necessary dependencies. 03:12.080 --> 03:17.920 And we can look into how this manifest file looks like. So, it's basically a Yama file 03:18.880 --> 03:23.360 containing the definition of the repositories where the packages can be downloaded from 03:23.360 --> 03:30.800 and list of all the packages and the necessary information. And now consider we want to 03:30.800 --> 03:38.800 do our container built on a different machine. And so here we need to like fetch the manifest 03:38.800 --> 03:46.240 file here we are using the SCP and then we can like use the manifest install command to just 03:46.240 --> 03:52.000 pre install all the packages defined there into an empty folder or like installed with folder. 03:52.000 --> 03:58.240 And you can also use like any, any global options you are used to with any other DNF commands here 03:59.200 --> 04:05.600 and this way we have like prepared the environment for example doing a built with a mock tool 04:06.400 --> 04:12.640 or like environment with a bootstrap packages. And here is another variation of the same functionality 04:12.640 --> 04:19.840 using a using a container file. So, in this way you can for example like manage all your 04:19.840 --> 04:27.440 packages outside of the container file itself in the manifest files. And in other the automated 04:27.440 --> 04:33.760 things you know and to be able to regenerate the manifest file with the new versions of packages 04:33.760 --> 04:41.520 the better way is to use the input files. So, these are also like the Yama files quite similar to 04:41.520 --> 04:50.160 the manifest files. So, again we can see there is the definition of repositories and the package 04:50.160 --> 04:55.360 list of packages we want to resolve into this manifest file. So, here we want to just install like 04:55.360 --> 05:03.680 e-links and numerical packages for this x86 architecture. And then we can just run the manifest 05:03.680 --> 05:08.400 new command which will like look into the current folder and use the input file for generating the 05:08.400 --> 05:15.840 manifest file. And there is also another option of doing by creating the manifest file using the 05:15.840 --> 05:23.120 current list install packages from the system using the use system parameter. And now to provide 05:23.120 --> 05:30.000 some overall picture of the scenario for building the container images. So, on one side we have a 05:30.000 --> 05:35.920 maintainer which will prepare the input file like with the or requirements of the packages for 05:35.920 --> 05:43.520 your application. This input file is used to generate the manifest file and this manifest file could 05:43.520 --> 05:49.120 be like uploaded to some database to the internet and maintain maintainer can like update the 05:49.120 --> 05:54.960 revisions of these files. And somewhere else we have the automated builder which will download 05:54.960 --> 06:00.640 the manifest file and like all the packages defined there, all the content onto this machine. 06:00.640 --> 06:06.400 And so, here we can like create the prepared isolated environment for our container build 06:06.400 --> 06:13.760 like the same environment as on the host where the manifest file was created using a network connection. 06:13.760 --> 06:20.080 So, here we are like preparing local repositories from the downloaded arpy and payload and 06:20.080 --> 06:27.040 information from the manifest file for example using created will see. And then we can pass the 06:27.040 --> 06:34.080 control to the parliament build. Yeah, and that's basically it. So, yeah, although this was the 06:34.080 --> 06:40.320 maintainer why the project was created. It's an open source project. So, I would love to hear like your 06:40.400 --> 06:47.680 ideas on extending the existing functionality and enabling like your use cases with the DNF manifest. 06:48.400 --> 06:55.600 So, yeah, feel free to discuss me like on the hallway or ping me on the chatroom or I will be 06:55.600 --> 07:02.640 available at the fedar booth like for the next hour or so. And you can also like file the issue on 07:02.640 --> 07:07.520 the GitHub page. There is a link in the presentation or like start some discussion on this. 07:08.000 --> 07:10.320 Yeah. So, that's it. Thanks for listening. 07:17.040 --> 07:20.640 So, thank you. We have time for one question if there's one. Yeah. 07:29.280 --> 07:37.040 Thank you. So, this is like a lock file for a package. Does it also lock the 07:37.120 --> 07:43.360 base image version that I need to use in case the manifest file becomes outdated because I 07:43.360 --> 07:49.440 use it for three years. And right now the base image goes forward and those packages perhaps are 07:49.440 --> 07:56.880 not available anymore. No, no. Yeah, the base image. Yeah. So, the question if if is also locked the 07:56.880 --> 08:04.240 base image like version into the in the manifest file and now here we are considering just the 08:04.240 --> 08:14.400 the packages that are like above the image. Okay. Thank you.