Changes

Page history
move docker image builds above the playbooks, better visility authored by anarcat's avatar anarcat
Show whitespace changes
Inline Side-by-side
service/ci.md
View page @ 1015c0a2
...@@ -84,6 +84,31 @@ Note that this feature was deprecated for a while but re-enabled. It ...@@ -84,6 +84,31 @@ Note that this feature was deprecated for a while but re-enabled. It
is being [redesigned](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797) to be more complete, as the above has is being [redesigned](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797) to be more complete, as the above has
important limitations. important limitations.
## Build Docker images with kaniko
It is possible do build Docker images in our Gitlab CI without requiring user
namespace support using [kaniko](https://github.com/GoogleContainerTools/kaniko).
The Gitlab documentation [has examples](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html)
to get started with that task. There are some caveats, though, at the moment:
1. One needs to pass `--force` to kaniko's executor or use a different
workaround due to a [bug in kaniko](https://github.com/GoogleContainerTools/kaniko/issues/1542)
2. Pushing images to the Docker hub is not working out of the box. One rather
needs to [use the v1 endpoint](https://github.com/GoogleContainerTools/kaniko/issues/1209) at the moment due to a bug. Right now passing something like
```
--destination "index.docker.io/gktpo/${CI_REGISTRY_IMAGE}:oldstable"
```
to kaniko's executor does the trick for me.
Additionally, as we want to build our images reproducibly, passing
`--reproducible` to the executor is recommended as well.
One final note: the Gitlab CI examples show that a debug image is used as a base
image in Gitlab CI. That is important as the non-debug flavor does not come with
a shell which is a requirement for Gitlab CI.
## FAQ ## FAQ
* do runners have **network access**? **yes**, but that might * do runners have **network access**? **yes**, but that might
...@@ -228,31 +253,6 @@ jobs it is currently running will be lost. Otherwise artifacts should ...@@ -228,31 +253,6 @@ jobs it is currently running will be lost. Otherwise artifacts should
be present on the GitLab server, so to recover a runner is as "simple" be present on the GitLab server, so to recover a runner is as "simple"
as creating a new one. as creating a new one.
## Build Docker images with kaniko
It is possible do build Docker images in our Gitlab CI without requiring user
namespace support using [kaniko](https://github.com/GoogleContainerTools/kaniko).
The Gitlab documentation [has examples](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html)
to get started with that task. There are some caveats, though, at the moment:
1. One needs to pass `--force` to kaniko's executor or use a different
workaround due to a [bug in kaniko](https://github.com/GoogleContainerTools/kaniko/issues/1542)
2. Pushing images to the Docker hub is not working out of the box. One rather
needs to [use the v1 endpoint](https://github.com/GoogleContainerTools/kaniko/issues/1209) at the moment due to a bug. Right now passing something like
```
--destination "index.docker.io/gktpo/${CI_REGISTRY_IMAGE}:oldstable"
```
to kaniko's executor does the trick for me.
Additionally, as we want to build our images reproducibly, passing
`--reproducible` to the executor is recommended as well.
One final note: the Gitlab CI examples show that a debug image is used as a base
image in Gitlab CI. That is important as the non-debug flavor does not come with
a shell which is a requirement for Gitlab CI.
# Reference # Reference
## Installation ## Installation
... ...
......