Context
Rulez propria instanță GitLab cu un server suplimentar pentru CI. În cazul în care contează, gazda mea pentru gitlab runner are CentOS 8, iar gitlab runner este versiunea 14.4.0, iar instanța gitlab rulează 14.4.1. În prezent, folosesc un executor shell pe serverul CI, dar vreau să trec la un executor docker.
Configurare Gitlab Runner
Ale mele /etc/gitlab-runner/config.toml
arata asa:
concurente = 1
interval_verificare = 0
[server_sesiune]
session_timeout = 1800
[[ alergători ]]
nume = "executorul shell vechi"
url = „https://XXXXXXXXXXXXXXXXXXXXXX/”
simbol = „XXXXXXXXXXXXXXXXXXXXX”
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[[ alergători ]]
nume = „noul executant docker”
url = „https://XXXXXXXXXXXXXXXXXXXXXX/”
simbol = „XXXXXXXXXXXXXXXXXXXXX”
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = fals
imagine = „docker.io/centos:7”
privilegiat = false
disable_entrypoint_overwrite = fals
oom_kill_disable = fals
disable_cache = false
volume = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
network_mode = "gazdă"
shm_size = 0
Executorul shell este etichetat coajă
iar executorul docker este tagges docher
astfel încât să pot decide unde să-mi rulez construcția din fișierul gitlab-ci.yml.
gitlab-ci.yml
.șablon:
before_script:
- cat /proc/sys/user/max_user_namespaces
scenariu:
- Autentificare $ENGINE -u „$CI_REGISTRY_USER” -p „$CI_REGISTRY_PASSWORD” „$CI_REGISTRY”
- $ENGINE build -f container/php-71.dockerfile -t „$CI_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/$TAG:$CI_PIPELINE_ID” .
- $ENGINE push „$CI_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/$TAG:$CI_PIPELINE_ID”
build-with-docker-in-shell-executor:
se extinde: .şablon
variabile:
MOTOR: docker
TAG: build-with-docker
Etichete: [shell]
build-with-docker-in-docker-executor:
se extinde: .şablon
imagine: docker:dind
variabile:
MOTOR: docker
TAG: build-with-docker-in-docker
Etichete: [docker]
build-with-podman-in-docker-executor:
se extinde: .şablon
imagine: quay.io/podman/stable
variabile:
MOTOR: podman
TAG: build-with-podman-in-docker
Etichete: [docker]
Ale mele container/php-71.dockerfile
este banal, folosește centos:7
și execută a
buchet de yum instala
comenzi:
DE LA docker.io/centos:7
RUN yum install -y epel-release centos-release-scl
RUN yum install -y rh-php71
Prima lucrare eșuează deoarece utilizatorul meu gitlab runner nu are acces la
docker sockt:
Am primit permisiunea refuzată în timp ce încercam să mă conectez la Docker
daemon socket la unix:///var/run/docker.sock: Post
„http://%2Fvar%2Frun%2Fdocker.sock/v1.24/auth”: formați unix
/var/run/docker.sock: conectare: permisiunea refuzată
Cred că este în regulă (sau este recomandabil în prezent să acordați acces la docker pentru
utilizatori non-root?). Deci, această slujbă există doar pentru referință.
Lucrarea docker în docker eșuează deoarece yum nu are acces la rețea
pare:
Pasul 1/3: DE LA docker.io/centos:7
---> eeb6ee3f44bd
Pasul 2/3: RUN yum install -y epel-release centos-release-scl
---> Rulează în 8e41cd05bcc1
Pluginuri încărcate: fastestmirror, ovl
Determinarea celor mai rapide oglinzi
Nu s-a putut prelua lista în oglindă http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container eroarea a fost
12: Timeout pe http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container: (28, „Rezolvarea a expirat după 30548 milisecunde”)
Unul dintre depozitele configurate a eșuat (Necunoscut),
și yum nu are suficiente date în cache pentru a continua. În acest moment singurul
lucru sigur pe care îl poate face yum este să eșueze. Există câteva modalități de a lucra „remediați” acest lucru:
1. Contactați cei din amonte pentru depozit și cereți-i să rezolve problema.
2. Reconfigurați bazaurl/etc. pentru depozit, pentru a indica un lucru
în amonte. Acest lucru este cel mai adesea util dacă utilizați o versiune mai nouă
versiunea de distribuție decât cea suportată de depozit (și de
pachetele pentru versiunea anterioară de distribuție încă funcționează).
3. Rulați comanda cu depozitul dezactivat temporar
yum --disablerepo=<repoid>...
4. Dezactivează permanent depozitul, astfel încât yum să nu-l folosească implicit. Hum
va ignora apoi depozitul până când îl activați definitiv
din nou sau utilizați --enablerepo pentru utilizare temporară:
yum-config-manager --disable <repoid>
sau
subscription-manager repos --disable=<repoid>
5. Configurați depozitul eșuat să fie omis, dacă nu este disponibil.
Rețineți că yum va încerca să contacteze repo. când rulează majoritatea comenzilor,
așa că va trebui să încerce și să eșueze de fiecare dată (și astfel. yum va fi mult
Mai lent). Dacă este o problemă foarte temporară, aceasta este adesea o problemă
compromite:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Nu se poate găsi un nume de bază valid pentru repo: base/7/x86_64
Comanda „/bin/sh -c yum install -y epel-release centos-release-scl” a returnat un cod diferit de zero: 1
Iar podmanul din docker este cea mai ciudată greșeală dintre toate, deja eșuează
la autentificare podman
comanda:
time="2021-11-01T13:34:31Z" level=warning msg="\"/\" nu este o montură partajată, aceasta ar putea cauza probleme sau lipsa monturi cu containerele fără rădăcină"
nu se poate clona: operațiunea nu este permisă
Eroare: nu se poate reexecuta procesul
Întrebare
Aș dori să folosesc podman în docker sau docker în docker pentru a-mi construi imaginile.
Ce pași pot face pentru a depana și a remedia acest lucru?