Deployment einer statischen Seite

Tue, 11 Mar 2025 00:00:00 +0000

In diesem Blogpost schauen wir uns an, wie wir eine einfache statische Seite via gitlab.com deployt.

Vorraussetzungen

Account bei gitlab.com
Ein Repository in welchem man Administrator ist
Git-Bash oder ein anderes Linux-Terminal, wenn auf Windows

SSH-Keys

Erstellen eines SSH-Keys

Um später den Gitlab-Runner zu berrechtigen, dass dieser per SSH auf den Ziel-Server zugreifen darf, erstellen wir ein neues Key-Pair, welches ausschließlich dafür verwendet wird.

Dieses Keypair erstellen ich nach dem vom Martin Leyrer empfohlenen Aufbau aus seinem Talk “Besser Leben mit SSH”.

1

ssh-keygen -t ed25519 -a 420 -f ~/your/own/path/id_ed25519 -C "foo@ba.de"

Bitte nicht vergessen den Pfad ~/your/own/path/... zu ersetzen, da ihr ansonsten, unter Umständenen euren bereits vorhanden SSH-Key durch den Deployment-Key ersetzt. Die Dummy-Mail foo@ba.de sollte ebenso durch eine passende von euch getauscht werden. Beispielsweise: deployment@euredomain.com oder noreply@euredomain.com.

Hinterlegen des SSH-Keys

Nachdem das Keypair erzeugt wurde, kann der Public-Key auf eurem Zielserver hinterlegt werden. Je nach Hoster kann dies über GUI oder per SSH/FTP geschehen.

Um euch den Public-Key auszugeben, könnt ihr im Terminal den cat-Befehl nutzen.

1

cat ~/path/to/your/key/id_ed25519.pub

Anschließend diesen bei eurem Hoster hinterlegen. Sollte das per SSH oder FTP geschehen, dann müsst ihr euren Public-Key in die authorized_keys kopieren, die findet ihr meist unter ~/.ssh/.

Repository auf dem Server auschecken

Mittels eines Deploy-Tokens werden wir unseren Ziel-Server berechtigen auf das Gitlab-Repository zuzugreifen.

Deploy Token erstellen

Um ein Token zu erstellen navigieren wir in Gitlab wie zu Settings > Repository > Deploy Token. Dort klicken wir auf Add token und erhalten die Ansicht aus dem Screenshot.

In dieser Ansicht vergeben wir einen Namen und Usernamen für das Token, sowie alle Leserechte. Schreibrechte werden in Regel nicht benötigt.

Nach Klick auf Create Deploy Token bekommen wir unseren gewählten Usernamen sowie ein zufälliges Passwort ausgegeben.

Git clone ausführen

Nun nachdem wir das Deploy-Token haben, können wir unser Repository auf dem Server auschecken. Dazu verbinden wir uns per SSH mit dem Server und klonen am gewünschten Ort unser Repository.

1

git clone https://tokenName:tokenPassword@gitlab.com/repo.git

gitlab-ci.yml anlegen

Nun legen wir die gitlab-ci.yml an und hinterlegen die notigen Variablen in Gitlab.

Nachfolgend habe ich ein Template vorbereitet, welches die Variablen SSH_PRIVATE_KEY und SSH_CONNECTION erwartet. Diese Variablen müssen in Gitlab in eurem Repository unter Settings > CI/CD > Variables hinterlegt werden.

Wenn diese Variablen hinterlegt sind, könnt ihr anschließende gitlab-ci.yml zu eurem Projekt hinzufügen. Diese ist so vorkonfiguriet, dass sie beim Merge nach dev auf euer DEV-System deployt und mittels release-... Tag auf live deployt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


stages:
 - Deploy

deploy-dev:
 stage: Deploy
 rules:
 - if: '$CI_COMMIT_REF_NAME == "dev"'
 image: "edbizarro/gitlab-ci-pipeline-php:8.3"
 before_script:
 - eval $(ssh-agent -s)
 - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
 - mkdir -p ~/.ssh
 - chmod 700 ~/.ssh
 script:
 - ssh -o StrictHostKeyChecking=no "$SSH_CONNECTION" "cd /root-project-dir-dev/ && git fetch && git checkout dev && git pull"

deploy-live:
 stage: Deploy
 rules:
 - if: '$CI_COMMIT_TAG =~ /release-.*/'
 image: "edbizarro/gitlab-ci-pipeline-php:8.3"
 before_script:
 - eval $(ssh-agent -s)
 - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
 - mkdir -p ~/.ssh
 - chmod 700 ~/.ssh
 script:
 - ssh -o StrictHostKeyChecking=no "$SSH_CONNECTION" "cd /root-project-dir-live/ && git fetch && git checkout $CI_COMMIT_TAG"

Shopware 6: Automatisiertes Security-Update mit GitLab

Thu, 25 Aug 2022 00:00:00 +0000

Diese Pipeline erstellt automatisch einen Merge Request mit einem Update des Shopware Security Plugins, basierend auf einem Tag.

Voraussetzungen

GitLab
Shopware 6 Composer-Setup

Variablen

SSH_DEPLOY_PRIVATE_KEY
- Der private Schlüssel eines erstellten Schlüsselpaars muss in dieser Variable gespeichert werden
- Der öffentliche Schlüssel muss unter „Settings > Repository > Deploy Key“ eingetragen werden
  - Nicht vergessen, Schreibrechte zu vergeben
SSH_KNOWN_HOSTS
- Diese aus der GitLab-Dokumentation entnehmen

Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


stages:
 - security

securityUpdate:
 stage: security
 rules:
 - if: '$CI_COMMIT_TAG =~ /security-.*/'
 image: "kellerkinder/pipeline-image:8.0"
 before_script:
 - eval $(ssh-agent -s)
 - echo "${SSH_DEPLOY_PRIVATE_KEY}" | tr -d '\r' | ssh-add -
 - mkdir -p ~/.ssh && > ~/.ssh/known_hosts
 - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
 - chmod 700 ~/.ssh
 - git config user.name "security"
 - git config user.email "ci@example"
 - git remote remove origin || true
 - git remote add origin "git@gitlab.com:path/repo.git"
 script:
 - cd ${CI_PROJECT_DIR} && composer install --no-interaction --optimize-autoloader
 - composer update store.shopware.com/swagplatformsecurity
 - git checkout -b feature/security-patch-$(date +%F)
 - git add -A
 - |
 if git diff --cached --quiet; then
 echo "Kein Security-Update verfügbar – nichts zu committen."
 exit 0
 fi
 - git commit -m "Security Update $(date +%F)"
 - git push --set-upstream origin feature/security-patch-$(date +%F)

Beispiel-Tag

security-YYMMDD

Gitlab-Ci on besserentwickeln.de