So, welcome to our next session. It's Jan talking about DNF and containers, I guess. Please.
One, two, one, two, you hear me? Okay. So, imagine this. You need to build thousands of container
images, each one tailored to meet specific customer requirements. And you need to do this in a
secure, reliable and reproducible way. Why? Because you want to prevent supply chain attacks,
want to ensure deterministic builds with consistent outputs, and you want to comply with industry
regulations by isolating your builds from external networks. So, in order to achieve such a container
build, you need to prepare and pre-fetch all the packages and dependencies beforehand in
your build environment. So, you can then seamlessly execute your like podman or Docker build commands.
And this is precisely when the DNF manifest comes in. So, the centerpiece is a manifest document,
which is basically a Yamul document containing all necessary information about your packages. So,
it contains like information about your dependencies, about the versions, about the repositories
and URLs where you can download the content from. And this manifest file is created based on the
input. And input, it's like saying, hey, DNF, I would like to describe everything I need to
install the engine, etc. And for example, curl and W get for debugging purposes. So, you
would just specify the package specs. And the output is the manifest document with all the result
packages. So, one way of specifying the input is on the command line, but for the automation
purposes, the more appropriate it method is using the so-called input files. And you could also
like dump your currently installed packages on your system into the manifest file. And so,
with such an existing manifest file, you can take it to another computer, and then or
there you can download the content or install it using DNF or even do some like static analyzes,
like security analyzes, checking for CVs, like authentication of the configurable repositories, etc.
And if you created the manifest file using the system, it's not sure you can also like
reproduce this environment on a different machine, or you can like replicate some specific
environment for debugging purposes. Okay, so let's see the next one. On some simple use case,
which will basically prepare the packages you need for your application in an environment in an
empty container. So, here's a simple manifest new command, which is basically saying hey DNF, please
prepare me a manifest file with e-links and new-duke packages, and all the necessary dependencies.
And we can look into how this manifest file looks like. So, it's basically a Yama file
containing the definition of the repositories where the packages can be downloaded from
and list of all the packages and the necessary information. And now consider we want to
do our container built on a different machine. And so here we need to like fetch the manifest
file here we are using the SCP and then we can like use the manifest install command to just
pre install all the packages defined there into an empty folder or like installed with folder.
And you can also use like any, any global options you are used to with any other DNF commands here
and this way we have like prepared the environment for example doing a built with a mock tool
or like environment with a bootstrap packages. And here is another variation of the same functionality
using a using a container file. So, in this way you can for example like manage all your
packages outside of the container file itself in the manifest files. And in other the automated
things you know and to be able to regenerate the manifest file with the new versions of packages
the better way is to use the input files. So, these are also like the Yama files quite similar to
the manifest files. So, again we can see there is the definition of repositories and the package
list of packages we want to resolve into this manifest file. So, here we want to just install like
e-links and numerical packages for this x86 architecture. And then we can just run the manifest
new command which will like look into the current folder and use the input file for generating the
manifest file. And there is also another option of doing by creating the manifest file using the
current list install packages from the system using the use system parameter. And now to provide
some overall picture of the scenario for building the container images. So, on one side we have a
maintainer which will prepare the input file like with the or requirements of the packages for
your application. This input file is used to generate the manifest file and this manifest file could
be like uploaded to some database to the internet and maintain maintainer can like update the
revisions of these files. And somewhere else we have the automated builder which will download
the manifest file and like all the packages defined there, all the content onto this machine.
And so, here we can like create the prepared isolated environment for our container build
like the same environment as on the host where the manifest file was created using a network connection.
So, here we are like preparing local repositories from the downloaded arpy and payload and
information from the manifest file for example using created will see. And then we can pass the
control to the parliament build. Yeah, and that's basically it. So, yeah, although this was the
maintainer why the project was created. It's an open source project. So, I would love to hear like your
ideas on extending the existing functionality and enabling like your use cases with the DNF manifest.
So, yeah, feel free to discuss me like on the hallway or ping me on the chatroom or I will be
available at the fedar booth like for the next hour or so. And you can also like file the issue on
the GitHub page. There is a link in the presentation or like start some discussion on this.
Yeah. So, that's it. Thanks for listening.
So, thank you. We have time for one question if there's one. Yeah.
Thank you. So, this is like a lock file for a package. Does it also lock the
base image version that I need to use in case the manifest file becomes outdated because I
use it for three years. And right now the base image goes forward and those packages perhaps are
not available anymore. No, no. Yeah, the base image. Yeah. So, the question if if is also locked the
base image like version into the in the manifest file and now here we are considering just the
the packages that are like above the image. Okay. Thank you.