Puncte:0

Docker/Podman în Docker eșuează ca job GitLab CI

drapel cn

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?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.