Use gardenlinux base image

[petersutter]

What this PR does / why we need it:
With this PR, we switch from ubuntu to gardenlinux base image.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

The base image switched from `ubuntu` to `gardenlinux`. Also `pip` and `mdv` (markdown viewer) binaries are not installed anymore by default

[plkokanov]

Thanks for taking care of this!

[plkokanov]

Is nightly stable enough? This also might make it a bit hard to track on which version of gardenlinux a concrete ops-toolbelt release is built.

[petersutter]

A new 1443.0 tag was created 14 hours ago, which I have used now (eebf397).
However, before that, there was a container image with 1417.0 tag. I couldn't find a corresponding tag (or release) for this version, which I found strange. Hence, I didn't initially use that one.

Maybe @Vincinator could provide some insight on this. I notice there is a publish_container.yml workflow, but it seems to only be called by the nightly workflow.
Will there always be a container image with a tag corresponding to a gardenlinux release in the future?

[plkokanov]

Will there always be a container image with a tag corresponding to a gardenlinux release in the future?

If there isn't always a container image with the corresponding tag we'll have to take care of updating this every time a tag is dropped or a new one is created. On the other side I'm worried how stable/reliable the nightly builds are.
Let's wait a bit for the gardenlinux foks to reply.

[Vincinator]

I think you can use the latest available garden linux base container image (via nightly tag).

If our Garden Linux nightly pipeline fails (due to a build issue, missing packages, package incompatibilities, other package repo issues, failing unit tests or failing platform tests, publishing issues, ...) we do not publish this version.

Keep in mind, that if the tool belt container is based on nightly, you automatically upgrade packages also in major version, which can be exactly what you want - but you should be aware.

If you need more version stability, you need the latest supported Garden Linux released for gardener. To automatically get this, I can discuss with my colleagues that we add a latest or LTS tag to the garden linux base container image that matches the latest release for gardener (currently 1443.0).

[petersutter]

This also might make it a bit hard to track on which version of gardenlinux a concrete ops-toolbelt release is built.

In this case we wouldn't need a latest tag or such and would pin it instead to a certain versio. We would use renovate bot to propose PRs with version bumps of gardenlinux.

Just for confirmation @Vincinator: the github releases, github release tags and container image tags are always in sync, right?

[plkokanov]

And one more question @Vincinator during the build of the images we currently run:

apt-get --yes update && apt-get -s dist-upgrade | grep "^Inst" | grep -i securi | awk -F " " {'print $2'} | xargs apt-get install;\
      rm -rf /var/lib/apt/lists

The reasoning is that for ubuntu it turns out that latest security updates do not get automatically installed when you specify a version tag. Do we need to continue doing this for gardenlinux?

[Vincinator]

the github releases, github release tags and container image tags are always in sync, right?

Yes, guaranteed since 1443.0, and manually fixed for 1312.3, no container base images for 934.

The reasoning is that for ubuntu it turns out that latest security updates do not get automatically installed when you specify a version tag. Do we need to continue doing this for gardenlinux?

If you only need to apply security patches during the build, you can rely on the latest apt repository (e.g. 1312.3 containing all security patches for the 1312 release) containing all current security patches.

When we deliver security updates, we provide:

• updated base container image (you re-roll the container image)
• update cloud images (you re-roll the cloud image)
• updated apt repository

[plkokanov]

/lgtm