4 ms·
The best part of running your own in-house gitlab instance is fiddling too often with the configuration after updates because something broke again. The gitlab
by tpetry 7y ago
The best part of running your own in-house gitlab instance is fiddling too often with the configuration after updates because something broke again. The gitlab ci runners with docker:dind are a constant pain in the ass.
- steveazz 7y agoGitLab employee here, specifically on the Runner team! What kind of problems are you facing with `docker:dind`? We had a recent problem where jobs were hanging due an update in Docker itself, where things halt when running on single core machines as explained in https://gitlab.com/gitlab-org/gitlab-runner/issues/6697 https://gitlab.com/gitlab-org/gitlab-runner/issues/6697. It's being fixed upstream in https://github.com/moby/moby/issues/40514 https://github.com/moby/moby/issues/40514. In the meantime to prevent you from having problems like this, it's always better to use a specific version of Docker for example `docker:19.03.5-dind`. Like this, you have control over which dind version you use and can upgrade when you have tested it beforehand. In retrospect, we could have caught this issue earlier and informed our users if we had automated pipelines pulling latest images and testing them out, which we started working on yesterday https://gitlab.com/groups/gitlab-org/-/epics/2674 https://gitlab.com/groups/gitlab-org/-/epics/2674 and we started monitoring dind specifically in https://gitlab.com/gitlab-org/ci-cd/tests/dind-image-tests/ https://gitlab.com/gitlab-org/ci-cd/tests/dind-image-tests/
- mikewhy 7y agoMy experience hasn't been anything like this. Countless upgrades, rarely a change to configuration. Any changes that did happen were communicated. Nor with gitlab-runner (and I even fork it to add stuff), and use docker-in-docker.