Mit Travis CI automatisch auf Staging- und Produktiv-Server deployen

Vor zwei Wochen hatte ich bereits einen Beitrag zum Deployment via GitLab CI geschrieben. Nun habe ich für ein öffentliches GitHub-Repo dasselbe Verhalten mit Travis umgesetzt und zeige euch hier, wie ich dabei vorgegangen bin.

Das Ziel ist wie bereits angerissen dasselbe wie im GitLab-Beitrag – ich möchte ein Theme auf einen Staging- oder Produktiv-Server laden, je nachdem ob ein Push im staging- oder master-Branch gemacht wurde. Für öffentliche GitHub-Repositorys ist die Nutzung von Travis CI kostenlos, für private Repositorys muss etwas gezahlt werden.

Travis arbeitet mit einer .travis.yml-Datei, in der die Schritte für die CI definiert werden. Die fertige Datei sieht in meinem Fall so aus:

language: php

addons:
  ssh_known_hosts:
  - $STAGING_SERVER
  - $PRODUCTION_SERVER

before_script:
  - echo -e "Host $STAGING_SERVERntStrictHostKeyChecking non" >> ~/.ssh/config
  - echo -e "Host $PRODUCTION_SERVERntStrictHostKeyChecking non" >> ~/.ssh/config

script:
  -
before_deploy:
  - openssl aes-256-cbc -K $ENCRYPTED_KEY -iv $ENCRYPTED_IV -in deploy_rsa.enc -out /tmp/deploy_rsa -d
  - eval "$(ssh-agent -s)"
  - chmod 600 /tmp/deploy_rsa
  - ssh-add /tmp/deploy_rsa

deploy:
  - provider: script
    skip_cleanup: true
    script: ssh -p22 $STAGING_SERVER_USER@$STAGING_SERVER "mkdir -p $STAGING_PATH_STABLE" && ssh -p22 $STAGING_SERVER_USER@$STAGING_SERVER "mkdir -p $STAGING_PATH_TRUNK" && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./ $STAGING_SERVER_USER@$STAGING_SERVER:$STAGING_PATH_TRUNK && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./ $STAGING_SERVER_USER@$STAGING_SERVER:$STAGING_PATH_STABLE
    on:
      branch: staging
  - provider: script
    skip_cleanup: true
    script: ssh -p22 $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER "mkdir -p $PRODUCTION_SERVER_THEMES_PATH/_tmp-bornholm"&& ssh -p22 $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER "mkdir -p $PRODUCTION_SERVER_THEMES_PATH/bornholm" && rsync -rav -e ssh --exclude='.git/' --exclude=scripts/ --exclude='.travis.yml' --delete-excluded ./ $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER:$PRODUCTION_SERVER_THEMES_PATH/_tmp-bornholm && ssh -p22 $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER "mv $PRODUCTION_SERVER_THEMES_PATH/bornholm $PRODUCTION_SERVER_THEMES_PATH/_old-bornholm && mv $PRODUCTION_SERVER_THEMES_PATH/_tmp-bornholm $PRODUCTION_SERVER_THEMES_PATH/bornholm" && ssh -p22 $PRODUCTION_SERVER_USER@$PRODUCTION_SERVER "rm -rf $PRODUCTION_SERVER_THEMES_PATH/_old-bornholm"
    on:
      branch: master

Zunächst legen wir als Sprache des Projekts php fest und fügen die beiden Server-Adressen als known_hosts ein, wie in der Doku im Beitrag »Adding to SSH Known Hosts« beschrieben – die Variablen könnt ihr in den Settings beim dem entsprechenden Repository in Travis anlegen.

Achtet darauf, keine sensiblen Daten direkt in die Datei zu schreiben sondern die Travis-Variablen zu nutzen, da die Datei ja öffentlich im GitHub-Repo liegt!

In dem before_script-Teil verhindern wir anschließend, dass wir den Fingerprint des unbekannten Servers bestätigen müssen. Wenn kein script angegeben ist, führt Travis je nach Sprache eine Standard-Prozedur aus (im Fall von PHP beispielsweise PHPunit) – wir wollen hier aber nur deployen, deshalb geben wir einen leeren Befehl an.

Wie die Vorbereitungen für die SSH-Verbindung vorgenommen werden können, ist anschaulich im Beitrag »SSH deploys with Travis CI« auf oncletom.io erklärt (auf Windows funktioniert die Verschlüsselung nicht so problemlos, ihr könnt hierfür auf Windows 10 das Windows Subsystem for Linux nutzen. Die von mir benötigten Kommandos, um es damit hinzubekommen, habe ich am Ende des Beitrags aufgeführt) – das Ergebnis ist unser before_deploy-Part.

Im deploy-Abschnitt geben wir abschließend zwei Unterbereiche an – einen für staging und einen für master. Die Befehle für script: entsprechen im Prinzip denen aus dem GitLab-Deployment-Beitrag.

Schritte für die Verschlüsselung des SSH-Keys im Windows Subsystem for Linux (auszuführen im entsprechenden Git-Repository):

apt-get install ruby-dev
gem install travis -v 1.8.8 --no-rdoc --no-ri
sudo travis login
ssh-keygen -t rsa -b 4096 -C 'build@travis-ci.org' -f ./deploy_rsa
sudo travis encrypt-file deploy_rsa --add

Danach den öffentlichen Schlüssel bei eurem Server eintragen und die Schlüssel-Dateien löschen (und in keinem Fall im Git-Repo lassen und aus versehen auf GitHub pushen!):

rm -f deploy_rsa deploy_rsa.pub

Das könnte auch interessant sein

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.