Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/artur-borys/podman-builder

Container image meant for use in gitea-actions to build container images with buildah/podman
https://github.com/artur-borys/podman-builder

buildah ci cicd gitea gitea-actions podman

Last synced: about 1 month ago
JSON representation

Container image meant for use in gitea-actions to build container images with buildah/podman

Awesome Lists containing this project

README 

        
# Podman Builder Image



This image is meant to be used with Gitea Actions when building and managing container images using buildah and podman.

I couldn't find any existing image from trusted entities, which has both podman and buildah setup properly for use in Gitea Actions.



The image is based on official podman and buildah images:



- https://github.com/containers/image_build/tree/main/podman

- https://github.com/containers/image_build/tree/main/buildah



There are two flavors of the image, depending on the base image:



- `rocky` - based on `rocky:9` image. I recommend using this as a base image if you want to add more tools to it

- `rocky-minimal` - based on `rocky:9-minimal`. I recommend using this image for running the jobs requiring only nodejs, podman and buildah. Rocky minimal images contain `microdnf` instead of `dnf`, and you may encounter issues with that.



There are three tag variants:



- `latest-${variant}` - the latest build of given flavor

- `${github.sha}-${variant}` - specific git commit hash build

- `${version}-${variant}` - specific version (i.e `v1.0.0`) build



`latest` is not recommended. Version-based tag is better, but it's always the most secure to use the commit hash tag.



## How to use it



If you're running `act_runner` via Docker (and I assume the same applies for Kubernetes, but I haven't tried it yet), it's important to:



- set `--security-opt seccomp=unrestricted`

- bind `fuse` device via `--device /dev/fuse`

- when running on Fedora/RHEL/CentOS/Rocky, or any OS with SELinux, you may also need to add `--security-opt label=disable`



When act_runner spawns a container where a job will run, it also has to pass the same options as above, so now you have to make a choice:



- add the options to act_runner config file, so that they will be automatically added to all containers

- specify the options in `jobs..container.options`



The first option might be less secure, but you can always have two runners - one with options in config file - for podman jobs, one without those options - for other jobs.

Then you can assing jobs requiring podman or buildah to the first runner.



If you want to configure your runner to use this `podman-runner` image, the `config.yaml` must contain this section (adapt it to your needs):



```yaml

runner:

  labels:

    - rocky-minimal:docker://aborys/podman-builder:latest-rocky-minimal

    - rocky:docker://aborys/podman-builder:latest-rocky



container:

  options: --security-opt label=disable --security-opt seccomp=unconfined --device /dev/fuse:rw

```



Example:



```bash

docker run --rm -it \

  --security-opt seccomp=unconfined \

  -v $PWD/config.yaml:/config.yaml

  --device /dev/fuse \

  -e GITEA_INSTANCE_URL='<>' \

  -e CONFIG_FILE=/config.yaml \

  -e GITEA_RUNNER_REGISTRATION_TOKEN='<>' \

  --name runner \

  -v /var/run/docker.sock:/var/run/docker.sock \

  gitea/act_runner:nightly

```



Alternatively, see [Docker Compose example](./example)



You can then run jobs with this image:



```yaml

jobs:

  <>:

    runs-on: rocky-minimal

    # Add this if you didn't set container.options in config.yaml

    # container:

    #   options: --security-opt label=disable --security-opt seccomp=unconfined --device /dev/fuse:rw

    ...

```



You can see a full working workflow example in [.gitea/workflows/build.yaml](.gitea/workflows/build.yaml)



## Security



I know that the built images have some high level vulnerabilities and I plan to fix them. At a first glance most of them look like issues with Node.js, which is unfortunately required by a lot of actions.



The container itself runs as a `build` user by default.