2017-03-10 5 views
1

Ich verwende CD für die Bereitstellung meines Codes auf einem VPS. Dieser VPS läuft unter Ubuntu 16.04 und hat einen Benutzer 'Deployer'.Gitlab.com CI/CD ssh Berechtigungsproblem

Jetzt, wenn ich ssh [email protected] benutze bekomme ich Shell-Zugriff auf den Server und dann bei Verwendung von cd /var/www komme ich in das Verzeichnis /var/www.

Wenn ich dies aus dem Deployment-Skript, in .gitlab-ci.yml definiert, bekomme ich diesen Fehler /bin/bash: line 101: cd: /var/www/data/: No such file or directory. Ich tat auch ls -al, um die Verzeichnisstruktur von /var zu sehen, die sich herausstellte, das Verzeichnis www nicht zu enthalten. So klar habe ich jetzt keine Erlaubnis zum www Verzeichnis.

- rsync -avz --exclude=.env . [email protected]:/var/www/data/staging/home - ssh [email protected] - cd /var - ls -al - cd /var/www Dies ist der Teil des Skripts, in dem es fehlschlägt. Weiß jemand, warum mein Benutzer verschiedene Berechtigungen bei der Verwendung von SSH aus dem Terminal hat, wenn ssh in diesem Skript verwendet? Kopiere die Dateien mit rsync wenn alles in Ordnung ist und alle Dateien kopiert wurden.

Antwort

1

Meine Vermutung ist, dass die cd und ls Befehle, die Sie versuchen, tatsächlich in der Umgebung des Läufers ausgeführt werden (sei es der Host oder ein Docker-Container, abhängig von Ihrer Einrichtung), nicht auf der Maschine, die Sie ssh in.

Ich würde vorschlagen, dass Sie lieber diese Befehle ausführen mitssh. Ein Beispiel zum Erstellen einer Datei und Überprüfen, dass sie erstellt wurde:

ssh [email protected] "touch /var/www/test_file && ls -al /var/www/" 
+0

Wir verwenden diese Lösung, aber ein bisschen anders. 'ssh" [email protected] "" cd/var/www/data/staging /; anderer_befehl; anderer_befehl; ' –

+1

Ja, das ist auch möglich. Denken Sie daran, dass bei Verwendung von' && 'jeder Befehl abhängig ist von Erfolg des vorherigen, was Sie in Ihrem Fall brauchen könnten, zB mit 'ssh" [email protected] "" cd/var/www/data/staging/&& first_command && second_command "' wäre der 'second_command' nicht falls der 'first_command' fehlschlägt. – tmt

1

Am besten ist es, einen SSH-Testamentsvollstrecker zu verwenden, configured through a config.toml:

/etc/gitlab-runner/config.toml: 

concurrent = 1 

[[runners]] 
    url = "http://your_gitlab/ci" 
    token = "xxx..." 
    name = "yourGitLabCI" 
    executor = "ssh" 
    [runners.ssh] 
    user = "deployer" 
    host = "devvers.work" 
    port = "22" 
    identity_file = "/home/user/.ssh/id_rsa" 

Dann können Sie .gitlab.yml einfach schließen

job: 
script: 
    - "ls /var/www" 
    - "cd /var/www" 
    ... 

Siehe auch this example.

Verwandte Themen