Public | Automated Build

Last pushed: 3 months ago
Short Description
Docker Bitbucket Deployment Image with compass and rsync.
Full Description

README

Docker Bitbucket Deployment Container Image zum automatischen deployen von Webseiten Repositories auf Server mittels rsync.
Voraussetzungen für die Verwendung des Image ist ein Webseiten Repository mit einer .rsync-include oder .rsync-exclude Datei sowie einem lauffähigen rsync auf dem Zielserver.
Wenn in der Webseite eine SASS Konfiguration vorhanden ist, wird vor dem rsync das CSS kompiliert.

Einstellungsmöglichkeiten

Die Ausführung von rsync und build kann mit folgenden Umgebungsvariabeln eingestellt werden. Beachtet dabei das es pflicht und optionale Angaben gibt.

  • PROJECT_PATH $BITBUCKET_CLONE_DIR - required
  • BUILD_CONTEXT production || development - required
  • SSH_HOST 127.0.0.1 || www.example.com - required
  • SSH_USERNAME username - required
  • SSH_KEY UG9seWZvbiB6d2l0c2NoZXJuZCBhw5...w6sIFLDvGJlbiwaHVydCB1bmQgUXVhcms= - required
  • RSYNC_OPTIONS -v --list-only - optional
  • RSYNC_PATH /var/www/typo3 - required
  • RSYNC_DRYRUN 1 - optional

Auf die Umgebungsvariabeln wie zum Beispiel SSH_HOST greift man mit $SSH_HOST zu.

PROJECT_PATH

Das ist der interen Projekt Pfad in dem Docker Container, dieser wird automatisch mit der Umgebungsvariabel $BITBCKET_CLONE_DIR gleichgesetzt.
Diese Umgebungsvariabel also bitte nicht verändern!

BUILD_CONTEXT

Der Kontext für die Build Anweisungen. Mögliche Werte sind production oder development.
Als Build Anweisung ist momentan nur ein SASS Kompilier hinterlegt.

$ compass compile --no-debug-info --force --trace --environment ${BUILD_CONTEXT=production} $PROJECT_PATH

SSH_HOST

Hier muss der remote Host angegeben werden, dabei ist egal ob es sich um eine IP oder eine URL handelt.

SSH_USERNAME

Hier bitte den SSH Usernamen für die rsync Verbidnung angeben.

SSH_KEY

Der SSH Key muss als base64 kodiert hinterlegt werden. Dazu geht ihr einfach in die Console und führt folgendes aus.
Die anschließende Ausgabe kopiert ihr und fügt den Inhalt in die SSH_KEY Variabel.

$ base64 < /path/to/the/ssh-key/id_rsa

RSYNC_OPTIONS

Mit dieser Umgebungsvariabel kann man zusätzliche Parameter zur rsync Ausführung hinterlegen werden.
Achtet darauf das bereits Paremeter in der rsync Ausführung hinterlegt sind.

Hinweis: Zum Abgleich der Dateien und Ordner wird die Checksum berechnet, weil Bitbucket bei jedem deployment einen neuen Container startet und alle Dateien dann immer automatisch einen neuen Zeitstempel haben.
Falls man die Checksum Funktion nicht benötigt muss rsync ohne den Checksum Befehl (-c, --checksum) ausgeführt werden.

RSYNC_OPTIONS=-airzbhc --no-perms --backup-dir="/backup${RSYNC_PATH}" --delete --include-from="${PROJECT_PATH}.rsync-include" --exclude-from="${PROJECT_PATH}.rsync-exclude"

RSYNC_PATH

Hiermit wird der absolute remote Pfad definiert wohin die Webseite hochgeladen werden soll. Wichtig ist dabei das der Ordner bereits existiert, ansonsten schlägt der rsync Befehl fehl.

RSYNC_DRYRUN

Wenn diese Umgebungsvariabel gesetzt ist wird der rsync Befehl nicht ausgeführt sondern nur simuliert und das Ergebnis zurückgegeben.

BACKUP

Die Standard Option von RSYNC_OPTION ist so eingestellt das die Option -b und --backup-dir angegeben sind, damit werden alle modifzierten und gelöschten Daten unter --backup-dir gespeichert.
Solltet ihr also mal ausversehen etwas über eine falsche include Anweisung löschen, findet ihr unter dem --backup-dirdie gelöschten Dateien!

RSYNC VS. GIT

Es gibt immer wieder die Diskussion was man zum synchronisieren von Dateien auf einem Server verwenden soll. Auch ich habe mir darüber Gedanken gemacht und fande anfangs die Git Variante als die einfachste und schnellste und das stimmt auch weiterhin.
Sollte jemand eine schnelle und einfache Variante zum aktualisieren seiner Dateien auf einem Server benötigen, empfehle ich die Git Variante. Für komplexere Projekte halte ich rsync für den richtigen Weg. Warum?
Nunja mit der Git Variante kann man bislang meines Wissens nach nur Dateien synchronisieren die auch im Git Repository liegen. Wenn man also so wie ich das kompilierte CSS nicht mit versioniert sondern in den Repository nur die für den Build notwendigen Dateien versioniert, hat man schon ein Problem mit der Git Variante.
Desweiteren würden auf einem Produktivsystem bei der Git Varianten viele unnötige Source Dateien liegen (.gitignore, .gitattributes, .git, SASS, ...) mit der rsync Methode kann nachdem Build des Projektes, genau definiert werden was auf den Server übertragen werden soll und was nicht.
Natürlich ist rsync nicht das schnellste System, für mich reicht es aber aus da ich nicht alle 5 Minuten 20 Änderungen synchronisieren muss. Wenn der Vorgang bis zu 5 Minuten dauert ist das für mich in Ordnung.

Beispiel Projekt Struktur

Umgebungsvariabel via Bitbucket Environment Variables

SSH_HOST      example.com
SSH_KEY       UG9seWZvbiB6d2l0c2NoZXJuZCBhw59lbiBNw6R4Y2hlbnMgVsO2Z2VsIFLDvGJlbiwgSm9naHVydCB1bmQgUXVhcms=
SSH_USERNAME  example

Repository Struktur

ProjektName/
├── images/
|   └── logo.png
├── js/
|   └── script.js
├── index.html
├── .rsync-include
├── .rsync-exclude
└── bitbucket-pipelines.yml

.rsync-include

+ images/
+ images/*
+ js/
+ js/*
+ index.html
- *

bitbucket-pipelines.yml

image: phinz/bitbucket-deployment

pipelines:
    default:
        - step:
            script:
                - export RSYNC_PATH=/html/
                - /deploy.bash
Docker Pull Command
Owner
phinz