2017-11-08 4 views
4

Ich habe Probleme beim Ausführen eines einfachen Jenkinsfile - z.Jenkinsfile: Berechtigung verweigert, wenn sh im Docker Container ausgeführt

pipeline { 
    agent { label 'ssh-slave' } 
    stages { 
     stage('Shell Test') { 
      steps { 
       sh 'echo "Hello World"' 
      } 
     } 
    } 
} 

den Logfiles von Jenkins auf dem Master zeigen, dass der Behälter erfolgreich gestartet wurde, aber die Build-Job stürzt mit einer Nachricht wie

sh: 1: /home/jenkins/workspace/[email protected]/durable-34c21b81/script.sh: Permission denied 

Hier sind einige zusätzliche Dinge, die wir konfiguriert/herausgefunden:

  1. Wir sind die Agenten auf einer VM mit RHEL laufen

  2. Wir verwenden die Docker Plugin für Jenkins zu starten/verwalten, die Behälter auf einem separaten Jenkins Mitteln

  3. Wir Spinnen die Docker Behälter unter Verwendung der Connect with ssh Methode im Jenkins Plugin und verwenden, um den jenkinsci/ssh-slave Docker image

  4. Jenkins root die Benutzer in dem Docker Behälter wird unter Verwendung (zumindest alle Dateien innerhalb /home/jenkins/... als root erstellt werden

  5. Wenn wir einen sleep Schritt in die Rohrleitung und in die laufenden docker exec... Behälter hinzuzufügen, wir kann kein einfaches Shellskript als root ausführen, wenn wir es mit ./script.sh ausführen wollen (auch wenn wir zuvor den richtigen Dateimodus mit chmod +x script.sh eingestellt haben) - wir erhalten auch . Aber wir können das Skript ausführen, wenn wir sh script.sh verwenden

  6. Die root Benutzer innerhalb des Docker Behälters hat ein bash - während Jenkins versucht, das Skript mit sh auszuführen.

  7. Der Fehler tritt auf, egal, ob wir die run privileged Flagge in der Docker Plugins Template-Konfiguration oder nicht

Dinge, die wir bereits versucht, zu überprüfen, aber funktionierte nicht

  1. die Änderung Login-Shell des root Benutzers im Docker-Container zu /bin/sh

  2. P roviding eine shebang im sh Schritt à la

     
    sh '''#!/bin/sh 
    echo "hello world" 
    ''' 
    

  3. den Schal Exekutor zu /bin/sh in der globalen Konfigurations Jenkins Einstellung

  4. die Dockerfile des SSH-slave Docker Bildes so ändern, dass die ENTRYPOINT tun kein bash Skript ausführen, sondern läuft /bin/sh am Ende

Jede Hilfe ist willkommen!

+0

Die Datei 'script.sh' wird vom dauerhaften Arbeitsablauf-Plug-in generiert und dann als langwieriger Prozess auf einem Knoten ausgeführt. Es wird ein bisschen schwierig sein, es herauszufinden. Welche Benutzer führen was? Mit welchem ​​SSH-Berechtigungsnachweis/welchem ​​Benutzer werden die Agenten gestartet? Verwenden Sie Volumenhalterungen oder irgendetwas? Gibt es eine Möglichkeit, hier ein minimales Beispiel zu geben? – mkobit

+0

Haben Sie versucht, sich mit dem Benutzer 'jenkins' in den Container einzuloggen? Weil dieser Benutzer in der [Dockerfile] (https://github.com/jenkinsci/docker-ssh-slave/blob/master/Dockerfile) eingerichtet ist. Trotzdem frage ich mich, wie ein Root-Login funktioniert (wegen 'PermitRootLogin no'). – StephenKing

+0

@StephenKing - wir haben uns über 'docker exec -it ...' in den Container eingeloggt, also war es kein ssh-Login oder sowas. Das hat für uns funktioniert. Ich denke auch, dass Jenkins die Jobs als "root" im Container ausgeführt hat, da alle Dateien im 'workspace' im Besitz von' root' waren. Lösung des Problems ist unten - danke trotzdem :) –

Antwort

2

Problem war, dass /home/jenkins in dem Behälter mit noexec montiert wurde:

$ mount 
/dev/mapper/rhel-var on /home/jenkins type xfs (rw,nosuid,nodev,noexec,relatime,seclabel,attr2,inode64,noquota) 

zugrunde liegendes Problem war, dass die /var auf dem darunter liegenden Wirt montiert wurde mit noexec (/var ist, wo alle Container-Dateien befinden ...) :

$ mount 
/dev/mapper/rhel-var on /var type xfs (rw,nosuid,nodev,noexec,relatime,seclabel,attr2,inode64,noquota) 

so war die Lösung für dieses Problem über

als executeable auf dem Host zu montieren
sudo mount -o remount,exec /var 

das Problem für uns gelöst.

Verwandte Themen