public/pipglr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resolve TODO, update volume names, update docs.

Browse Source 
Signed-off-by: Chris Evich <chris_gitlab@icuc.me>
This commit is contained in:
Chris Evich
2022-11-18 21:52:08 -05:00
parent 0e51bfdf8e
commit cbddc54007
2 changed files with 75 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

97
README.md
View File

@@ -12,54 +12,84 @@ made available as:
It's purpose is to provide an easy method to execute a GitLab runner,
to service CI/CD jobs for groups and/or repositories on
[gitlab.com](https://gitlab.com). It comes pre-configured to utilize
the gitlab-runner app to execute with rootless podman containers,
the gitlab-runner app to execute within a rootless podman container,
nested inside a rootless podman container.
This is intended to provide multiple additional layers of security
for the host, when running potentially arbitrary CI/CD code. Though,
the ultimate responsibility still rests with the end-user to review
the setup and configuration relative to their own situation/environment.
This is intended to provide additional layers of security for the host,
when running potentially arbitrary CI/CD code. Though, the ultimate
responsibility still rests with the end-user to review the setup and
configuration relative to their own security situation/environment.
### Quickstart
### Operation
Several labels are set on the built image or manifest list to support
easy registration and execution of a runner container. They require
defining several environment variables for use.
This image supports `podman container runlabel`, or if your version
lacks this feature, Several labels are set on the image to support
easy registration and execution of a runner container using a special
bash command. See the examples below for more information.
#### Volume Ownership Bug
Some versions of podman contain a bug where named volumes aren't owned
by the namespaced user within a rootless container (i.e. in conjunction
with the --user option). Since the `podman` user/group inside the `pipglr`
container is known, it's possible to manually set/reset ownership:
```bash
VOLUME=pipglr-podman-root
podman volume create $VOLUME
cd $(podman unshare podman volume mount $VOLUME)
podman unshare chown 1000:1000
podman volume unmount $VOLUME
```
#### Runner registration
Each time the registration command is run, a new runner is added into
the configuration. If your intent is to simply update or modify the
configuration, please edit the config.toml file within the
`gitlab-runner-config` volume.
Note: These commands assume you have both `podman` and `jq` available.
Instead of `eval`, if your podman version supports `container runlabel`,
you may use that.
the configuration. If however, you simply need to update/modify the
configuration, please edit the `config.toml` file directly after mounting
(default) `pipglr-runner-config` (`/home/podman/.gitlab-runner/`) volume.
For modern versions of podman, registration can be performed with the
following commands:
```bash
$ echo '<registration token>' | podman secret create REGISTRATION_TOKEN -
$ export IMAGE=<image FQIN:TAG>
$ eval $(podman inspect --format=json $IMAGE | jq -r .[].Labels.register)
IMAGE="=registry.gitlab.com/qontainers/pipglr:latest"
echo '<actual registration token>' | podman secret create REGISTRATION_TOKEN -
podman container runlabel $IMAGE register --secret REGISTRATION_TOKEN,type=env
```
Where `<actual registration token>` is the value obtained from the "runners"
settings page of a gitlab group or project.
Note: Some versions of podman don't support the `container runlabel` sub-command.
If this is the case, you may simulate it with the following command (in addition
to the other example commands above):
```bash
eval $(podman inspect --format=json $IMAGE | jq -r .[].Labels.register)
```
#### Runner Startup
With one or more runners registered and configured, and `$IMAGE` set,
the GitLab runner container may be launched with the following commands.
With one or more runners successfully registered and configured, the GitLab
runner container may be launched with the following commands:
Note: The first time this is run, startup will take an extended amount
of time as the runner downloads and runs several (inner) support containers.
As above, instead of `eval`, if your podman version supports `container runlabel`,
you may use that.
```bash
podman container runlabel $IMAGE run
```
Debugging: You may `export PODMAN_RUNNER_DEBUG=debug` to enable inner-podman
debugging (or any other supported log level) to stdout.
As above, if you're missing the `container runlabel` sub-command, the following
may be used instead (assuming `$IMAGE` remains set):
```bash
$ eval $(podman inspect --format=json $IMAGE | jq -r .[].Labels.run)
```
#### Debugging
Before starting the runner, you may `export PODMAN_RUNNER_DEBUG=debug` to enable
debugging on the inner-podman. Whereas `export LOG_LEVEL=debug` can be used to
debug the gitlab-runner itself.
## Building
This image may be built simply with:
@@ -119,3 +149,16 @@ Several build arguments are available to control the output image:
configuration), and determines where jobs are run.
* `RUNNER_UNTAGED` - Defaults to `true`, may be set to `false`. Allows
the runner to service jobs without any tags on them at all.
### Environment variables
Nearly every option to every gitlab-runner sub-command may be specified via
environment variable. Many important/required options are set in the
`Containerfile`. However it's entirely possible to pass them in via
either of the `podman container runlabel...` container commands. To
discover them, simply append `--help` to the end of the command.
For example:
```bash
podman container runlabel $IMAGE register --help
```