Archiv der Kategorie: Linux

Git und GitHub für Windows mit Sourcetree, Teil 2: Stages, Commit und Push

In dieser Fortsetzung des ersten Teils (Git und GitHub für Windows mit Sourcetree, Teil 1: Grundlagen) möchte ich zeigen, wie man die allererste Datei bearbeitet, im lokalen Repository speichert und danach zu GitHub überträgt.

Wir rufen uns zunächst die Startseite von Sourcetree in Erinnerung, nachdem wir unser erstes Repository geklont haben.

Wenn wir auf „Open in Explorer“ klicken, öffnet sich das bekannte Explorer-Fenster im Verzeichnis des angelegten Repositorys/Projektes.

Momentan befindet sich dort erst die Datei „README.md“. Wir öffnen diese direkt mit einem Editor ihrer Wahl.

Im Editor sehen wir, dass es sich um eine simple Textdatei mit speziellen Formatierungsanweisungen handelt. Das Gatter „#“ kennzeichnet dabei zum Beispiel eine Überschrift erster Ebene.

Wir ergänzen jetzt den Text um einen beliebigen Text (hier: Hello World!) und speichern diesen.

Und jetzt vollzieht sich ein elementarer Schritt in Git bzw. Sourcetree. Wenn wir auf die Software blicken, sehen wir, dass sich etwas geändert hat.

Sourcetree hat erkannt, dass sich die Datei „README.md“ geändert hat. Und wenn wir den Namen der Datei im Feld „Unstanged files“ anklicken, sehen wir oben rechts die zeilenweise registrierten Änderungen.

Wir können sehen, dass die Zeile „A nice description.“ entfernt wurde, dann wurde die Zeile „A nice description. Hello World!“ hinzugefügt. Git registriert Änderungen im Code immer zeilenweise und nicht zeichenweise, daher die auf den ersten Blick umständliche Darstellung.

Exkurs: die Zustände in Git

In Git gibt es drei Bereiche (oder Zustände), in denen Änderungen an Dateien verfolgt werden: unstaged, staged und committed.

Unstaged: Hier werden alle Änderungen angezeigt, die seit dem letzten Commit an einer Datei vorgenommen wurden, aber noch nicht zum Staging-Bereich hinzugefügt wurden.

Staged: Hier werden Änderungen angezeigt, die mit dem Befehl „git add“ (oder dem Äquivalent in Sourcetree) zum Staging-Bereich hinzugefügt wurden, aber noch nicht zum Commit vorgesehen sind.

Committed: Hier werden alle Änderungen gespeichert, die mit dem Befehl „git commit“ (oder dem Äquivalent in Sourcetree) vorgenommen wurden und somit in der Git-History festgehalten sind.

Der Unterschied zwischen den Bereichen ist also, ob Änderungen noch gespeichert oder nur vorgesehen sind. Durch das Hinzufügen zum Staging-Bereich kann man einzelne Änderungen separat commiten und somit die Git-History übersichtlicher gestalten.

Zu Beginn des Arbeitens mit Git wird sich unweigerlich auf die Frage auftun: „Warum gibt es einen Staging-Bereich, warum committe ich nicht sofort?“

Die Antwort erschließt sich, wenn man einen kompletten Arbeitstag mit Git hinter sich gebracht hat:

Der Staging-Bereich in Git ermöglicht es Entwicklern, bestimmte Änderungen an ihren Dateien zu wählen und separat von anderen Änderungen zu commiten. Dadurch kann man gezielter arbeiten und Änderungen besser organisieren.

Ein weiterer Vorteil des Staging-Bereichs ist die Möglichkeit, Änderungen zu überprüfen und sicherzustellen, dass sie korrekt sind, bevor sie endgültig commitet werden. Auf diese Weise kann man sichergehen, dass man keine unerwünschten Änderungen in das Repository hochlädt und die Versionsgeschichte des Projektes sauber bleibt.

Der Staging-Bereich ein wichtiges Werkzeug ist, um Änderungen effektiv und sicher in Git zu managen.

Mit „Stage all“, „Stage selected“ oder dem Pluszeichen neben dem Dateinamen befördern wir jetzt die Datei „README.md“ aus dem „Unstanged“ Bereich in den „Staged“ Bereich. Die Unterschiede in der Datei sind weiterhin einsehbar.

Übrigens können wir mit „Unstage all“, „Unstaged Selected“ oder dem Minuszeichen neben dem Dateinamen die Datei wieder in den Zustand/Bereich „Unstaged“ zurückversetzen. Probieren Sie es aus, es kann nichts passieren. Befördern Sie die Datei aber danach wieder in den Bereich „Staged“, denn wir sind noch nicht fertig mit unserem kleinen Workflow.

Schreiben Sie jetzt einen Kommentar in das untere Feld. Dies ist wichtig, um später noch zu wissen, warum Sie welche Änderungen veranlasst haben, und drücken Sie „Commit“.

Wie Sie sehen, ist die Software nach wenigen Augenblicken in den Bereich „History“ gesprungen. Diese Commit-History hilft Ihnen, die Branches- (der Begriff wird später noch erklärt) und den Commit-Verlauf zu visualisieren. Er hilft, die jüngsten Git-Aktionen im Projektarchiv zu überprüfen, und zeigt, wer wann welche Codeänderungen vorgenommen hat, sodass es einfach ist, herauszufinden, wann ein Fehler eingeführt wurde und zu einer früheren Version zurückzukehren.

Der finale Schritt wird jetzt sein, diese über den Commit erfolgten Änderungen auf GitHub online zu stellen (im Jargon von GitHub: pushen). Dazu gibt es den Button „Push“ in der Menüleiste von Sourcetree. Hier ist bereits eine kleine 1 zu sehen, die sich auf die einzelne zu pushende Datei „README.md“ bezieht.

Nach einem „Push“ erscheint ein schwebendes Fenster, das nach weiteren Angaben fragt. Wir können jetzt vorerst die Default-Einstellungen übernehmen und erneut „Push“ drücken.

Der History-Bereich hat sich scheinbar nicht geändert. Aber beim genauen Betrachten ist zu erkennen, die Markierung “origin/HEAD” in der History eine Position nach oben gerutscht ist. Das “origin/HEAD” bedeutet, dass es sich um den aktuellen Commit des entfernten Repositorys handelt, auf das unser lokales Repository verweist. Das remote Repository in GitHub und das lokale Repository auf unserer Festplatte befinden sich jetzt also wieder auf dem selben Stand.

Und um zu prüfen, ob die Änderungen tatsächlich korrekt bei GitHub angekommen sind, öffnen wir den Browser und öffnen das Repository. Wie wir sehen, hat sich der Text der README.md-Datei geändert. Und das wollten wir erreichen.

Zusammenfassung: Wir haben gelernt, wie wir eine Datei in unserem eigenen, lokalen Repository speichern und wie diese Datei dann auf GitHub übertragen werden.

Vorschau: Im nächsten Beitrag beschäftigen wir uns mit dem Thema, was passiert, wenn mehrere Personen parallel an einer Datei arbeiten. Wer gewinnt? Wie wird entschieden, was übernommen wird?

Git und GitHub für Windows mit Sourcetree, Teil 1: Grundlagen

Ich möchte hier eine Schnell-Anleitung (eventuell mit Fortsetzung) zur Nutzung von Git (und GitHub) allein mit Windows-Tools aufzeigen, wobei bewusst auf Linux-Mitteln wie z.B. die Konsole, wo möglich und zweckdienlich, verzichtet wird.

Die Software

Wir benötigen: Sourcetree

Sourcetree ist ein Git-Client, der eine grafische Benutzeroberfläche bereitstellt. Mit Sourcetree können Benutzer Repositories erstellen, klonen, committen und pushen sowie alle Änderungen protokollieren und vergleichen. (Git-)Repositories sind Speicherorte, in denen Git-Projekte verwaltet werden, einschließlich aller Dateiversionen und des Projektverlaufs.

Die Installation gestaltet sich einfach. Einen Bitbucket-Account benötigen wir nicht, daher drücken wir „Skip“.

SourceTree Installation

Im nächsten Schritt deaktivieren wir „Mercurial“, das ebenfalls nicht benötigt wird. Aber ich würde empfehlen, den Haken bei „Configure automatic line handling …“ zu setzen. Das ist praktischer, falls wir irgendwann einmal zwischen dem Windows- und Linux-Universum Dateien austauschen möchten. Ansonsten würden sich bei jedem Auschecken von Code die Zeilenumbrüche verdoppeln, das liegt an der Art und Weise, wie Windows Zeilenumbrüche speichert und würde jetzt en détail zu weit führen.

SourceTree Installation

In den Preferences geben Sie zum Schluss noch ihre Daten ein.

SourceTree Installation

Die Startseite der Software sollte sich uns folgendermaßen präsentieren:

SourceTree
Sourcetree

Um nun weiterzukommen, müssen wir unbedingt verstehen, was es mit SSH-Schlüsseln auf sich hat, daher an dieser Stelle ein kleiner Exkurs über das Thema. Kenner können darüber hinweglesen.

Exkurs: SSH und SSH-Schlüsselpaare

SSH steht für „Secure Shell“ und ist ein Verschlüsselungsprotokoll, das für die Kommunikation zwischen zwei Computern verwendet wird.

Zur Anwendung kommen dabei SSH-Schlüsselpaare, die jeder Nutzer zunächst individuell erzeugen muss. Dieses Schlüsselpaar ist weltweit einzigartig. Ein Schlüsselpaar besteht immer aus einem privaten und einem öffentlichen Schlüssel. Nur der öffentliche und der private Schlüssel desselben Schlüsselpaares passen zusammen. Besitzt man nur einen von beiden Schlüssel, kann man nichts damit anfangen, man benötigt immer beide.

Der öffentliche SSH-Schlüssel ist für alle zugänglich (so verrät es ja der Name) und sollte allen Parteien, mit denen man kommunizieren möchte, zur Verfügung gestellt werden, indem man ihn zum Beispiel auf der eigenen Website veröffentlicht.

Der private Schlüssel hingegen – auch das verrät schon der Name – darf unter keinen Umständen in fremde Hände geraten, denn sonst wäre das gesamte Schlüsselpaar kompromittiert.

Möchte man also mit einem Server kommunizieren, muss man dafür sorgen, dass der Server den öffentlichen Schlüssel erhält (wie das funktioniert, erkläre ich gleich). Man selbst identifiziert sich dann mit dem auf dem eigenen Rechner verbliebenen privaten Schlüssel. Wenn man alles richtig eingestellt hat, erfolgt die weitere Arbeit bzw. Kommunikation von da an reibungslos und automatisch.

Wir erzeugen ein Schlüsselpaar

Ich empfehle, auch wenn man dafür mit der Kommandozeile arbeiten muss, das Schlüsselpaar mit Windows-Bordmitteln zu erzeugen, da es mit Sourcetree meinem Erachten nach zu kompliziert ist.

Wir öffnen die Kommandozeile auf Windows und geben folgende Befehle ein:

cd %USERPROFILE%
mkdir .ssh
cd .ssh
ssh-keygen

Kurze Erklärung: Wir legen in unserem Benutzer-Verzeichnis den Ordner „.ssh“ an. Bitte den Punkt nicht vergessen! Wir wechseln in das Verzeichnis und legen ein Schlüsselpaar an.

Als Ergebnis erhalten wir zwei Dateien:

  • id_rsa – das ist der private Schlüssel
  • id_rsa.pub – das ist der öffentliche Schlüssel

Wer möchte, kann den privaten Schlüssel mit einem Passwort absichern (siehe roter Pfeil). Dies verschafft zusätzliche Sicherheit, falls der private Schlüssel doch einmal in die falschen Hände geraten sollte. Allerdings hat das auch den Nachteil, dass fortan bei jeder verschlüsselten Kommunikation nach dem Passwort gefragt wird, was den Arbeitsfluss unterbrechen kann. Das zusätzliche Passwort ist keine Pflicht, jeder muss für sich selbst darüber entscheiden.

Der öffentliche Schlüssel erhält die Endung „.pub“, der private gar keine.

WICHTIG: Denken Sie daran, für beide Schlüssel Backups anzulegen. Denn sollten Sie einen von beiden verlieren, müssen Sie wieder ein neues Paar anlegen.

Was ist denn jetzt GitHub und was haben wir damit zu tun?

GitHub ist eine Webplattform, die auf das Git-basierte Versionskontrollsystem spezialisiert ist. Mit GitHub können Entwickler, Teams und Organisationen ihre Softwareprojekte hosten, verwalten und mit anderen teilen. Die Funktionen von GitHub erleichtern die Zusammenarbeit zwischen Entwicklern und die Fehlerbehebung und Verbesserung von Softwareprojekten. GitHub bietet Entwicklern und Teams eine Plattform zur Verwaltung von Code, zur Zusammenarbeit und zur Integration in Workflow-Tools.

Damit wir jetzt mit GitHub kommunizieren können, müssen wir dort unseren öffentlichen Schlüssel hinterlassen. Dazu können Sie entweder selbst ein Konto bei GitHub anlegen oder Sie nutzen ein bereits bestehendes Konto, z.B. ein Konto ihres Unternehmens. Im letzten Fall müssen Sie ihren öffentlichen Schlüssel an den Administrator des Kontos schicken, damit dieser die folgenden Schritte erledigt.

GitHub bekommt unseren öffentlichen Schlüssel

Um einen öffentlichen SSH-Schlüssel Ihrem GitHub-Konto hinzuzufügen, können Sie die folgenden Schritte ausführen:

Kopieren Sie den Inhalt der öffentlichen Schlüsseldatei (hier: .ssh/id_rsa.pub) komplett in die Zwischenablage. Das können Sie wie gewohnt mit der Maus erledigen: Markieren und mit STRG+C kopieren.

type id_rsa.pub

Gehen Sie zu Ihrem GitHub-Konto und klicken Sie auf das Dropdown-Menü in der oberen rechten Ecke. Wählen Sie „Settings“ aus.

Klicken Sie im linken Menü auf „SSH and GPG Keys“.

Klicken Sie dann auf „new SSH key“

Geben Sie einen Titel für den Schlüssel ein (z.B. „RSA Schüssel von Martin Mustermann für Maschine 1“). Behalten Sie die Auswahl „Authentication key“ bei. Fügen Sie den Inhalt des öffentlichen Schlüssels in das Feld „Key“ ein. Klicken Sie auf „Add SSH key“.

Danach sollten Sie folgenden Bildschirm erhalten:

Mehr Informationen zum Thema SSH und GitHub

Der private Schlüssel für Sourcetree

Damit nun die verschlüsselte Kommunikation mit GitHub und Sourcetree erfolgen kann, müssen Sie in Sourcetree ihren privaten Schlüssel hinterlegen.

In Tools->Options->General nehmen Sie unter „SSH Client Configuration“ folgende Anpassungen vor:

Und natürlich geben Sie in „SSH Key“ ihren privaten Schüssel an, nicht den öffentlichen.

Das sollte es dann schon gewesen sein.

GitHub – der erste Kontakt

Wenn wir jetzt zum ersten Mal mit GitHub arbeiten möchten, gibt es zwei initiale Möglichkeiten, die den allergrößten Teil der Varianten abdecken. a) Entweder es existiert schon ein Repository auf GitHub, weil z.B. schon andere Kollegen damit arbeiten oder b) Sie legen selbst ein Repository dafür an, weil Sie selbst der Verantwortliche sind.

a) Das Repository existiert bereits.

Sollten Sie neu zu einem Projekt dazustoßen, so müssen Sie zunächst dafür sorgen, dass sie das entfernte Repository von GitHub (man sagt auch „remote Repository“) auf ihren lokalen Rechner kopieren. (Kleine Anmerkung: Sie können das auch auf mehrere ihrer Entwicklungs- und/oder Testrechner parallel machen, Git und GitHub koordinieren das automatisch.)

In der Sprache von Git heißt dieses Kopieren „Klonen“.

Der Verantwortliche für das Repository sollte Ihnen eine spezielle URL mitteilen, die in unserem Falle folgendermaßen aussieht:

git@github.com:martin-mustermann-firmenname/sourcetree-tutorial.git

Wenn Sie die URL nun in das Feld für „Source Path/URL“ eintragen, sollte Sourcetree keine Beanstandungen melden. Das lokale Verzeichnis auf ihrem Rechner wird automatisch vorgeschlagen, Sie können hier auch ein anderes wählen. (In diesem Beispiele sieht die URL etwas anders auf. Aber grundsätzlich ist der Aufbau identisch.)

Nach dem Klonen sollte ihr Bildschirm noch recht „jungfräulich“ aussehen.

Wie wir die ersten Dateien lokal verändern und zu GitHub hochladen, werden wir im nächsten Artikel besprechen. Kommen wir nun zu dem Fall, dass Sie das lokale Repository selbst anlegen.

b) Wir legen das Repository selbst an

Dazu wechseln wir zur Website von GitHub und wählen uns dort mit unseren Konto-Daten ein. In dem Menü rechts oben legen wir mit „New repository“ ein neues remote Repository an.

Den Namen des Projekts dürfen Sie frei wählen, sofern nicht schon ein gleichnamiges in ihrem Konto existiert.

Ich würde bei Projekten in Unternehmen auf jeden Fall die Option „Private“ aktivieren, weil sonst der Code jedem Nutzer weltweit zum Download bereitgestellt wird. Dieser Umstand rührt daher, dass GitHub ursprünglich eine Website zum gemeinschaftlichen Erstellen von Software-Projekten im Open-Source-Bereich war.

Damit wir wenigstens schon eine Datei im Repository haben, lassen wir die Datei „README.md“ automatisch anlegen. Diese können wir dann nachträglich noch anpassen.

Die README.md Datei ist eine zentrale Komponente eines jeden GitHub Repositories. Sie ist ein Markdown-Dokument, das im Hauptverzeichnis platziert wird, und dient dazu, eine Beschreibung des Projekts zu geben. Ferner kann sie als Einstiegspunkt in das Projekt dienen, indem sie den Benutzern Informationen zum Einrichten, Ausführen und Testen des Codes gibt. Die README.md Datei kann auch genutzt werden, um Links zu wichtigen Ressourcen wie Dokumentation, Demo-Videos, Support-Websites und anderen Projekt-Tools bereitzustellen.

Auf der Startseite des Projekts wird dann automatisch der Inhalt der README.md-Dateien angezeigt.

Unter dem grün hinterlegten Knopf „Code“ können wir jetzt die URL aufrufen, wie wir sie aus dem Kapitel „c) Das Repository existiert bereits“ schon kennen. Bitte verfahren Sie damit analog, um das neue Repository auf ihren lokalen Rechner zu klonen.

Zusammenfassung: Wir haben jetzt gelernt, wie wir für Git und GitHub eine einfache Software (Sourcetree) installieren, die zur verschlüsselten Kommunikation wichtigen SSH-Schlüssel nutzten und wie wir ein erstes Repository anlegen und mit GitHub verknüpfen.

Vorschau: In den nächsten Beiträgen wird es darum gehen, Dateien im Repository zu ändern, sie in der History mit Kommentaren abzulegen und für unsere Kollegen auf GitHub zur Verfügung zu stellen, und das möglichst konfliktfrei und automatisch.

Bash Script Vorlage mit Parameter-Verarbeitung

Wer Skripte für die Bash auf Linux selbst erstellt, wird früher oder später den Wunsch verspüren, Parameter und Argumente verarbeiten zu können, um die Skripte flexibler zu gestalten.

Ich nutze dazu diese Vorlage:

#!/bin/bash
# /usr/local/bin/.../...
# Handy one-liner that explains what the program does.

function usage()
{
   cat << HEREDOC
   
   Handy one-liner that explains what the program does.
   
   Usage: $progname [--parameter1 NUM] [--parameter2 STR] [--parameter3 TIME_STR] [--verbose] [--dry-run]
          argument1 [argument2] [argument3] [ ... ]
   
   Example: $progname -d=5 /tmp/folder1/ /tmp/folder2/
            explain the example in detail

   optional parameter:
     -p, --parameter1 NUM        explain this parameter
     -q, --parameter2 STR        explain this parameter
     -r, --parameter3 TIME_STR   explain this parameter
     -h, --help                  show this help message and exit
     -v, --verbose               increase verbosity
     --dry-run                   dry run, dont change any files, folders or values

HEREDOC
}  

# parse the arguments before getopts, otherwise they will be lost
for i in "$@"; do
	if [[ $i = "-"* ]]; then
		:
	else                
		arguments+=("$i") # append the arguments to array
	fi
done

# initialize default parameter
progname=$(basename $0)
verbose=0
dryrun=0
parameter1=10
parameter2="Hello World!"
parameter3="2023-01-22 17:40:33"

# use getopt and store the output into $OPTS
# note the use of -o for the short options, --long for the long name options
# and a ":" for any option that takes a parameter
OPTS=$(getopt -o "p:q:r:hv" --long "parameter1:,parameter2:,parameter3:,help,verbose,dry-run" -n "$progname" -- "$@")
if [ $? != 0 ] ; then echo "Error in command line arguments. See '$progname -h/--help'." >&2 ; exit 1 ; fi
eval set -- "$OPTS"

while true; do
  # echo "\$1:\"$1\" \$2:\"$2\""
  case "$1" in
    -h | --help ) usage; exit; ;;
    -p | --parameter1 ) parameter1="$2"; shift 2 ;;
    -q | --parameter2 ) parameter2="$2"; shift 2 ;;
    -r | --parameter3 ) parameter3="$2"; shift 2 ;;
    --dry-run ) dryrun=1; shift ;;
    -v | --verbose ) verbose=$((verbose + 1)); shift ;;
    -- ) shift; break ;;
    * ) break ;;
  esac
done

if (( $verbose > 0 )); then

   # print out all the parameters we read in
   cat <<EOM
   p/parameter1=$parameter1
   q/parameter2=$parameter2
   r/parameter3=$parameter3
   verbose=$verbose
   dryrun=$dryrun
   arguments=${arguments[@]}
EOM
fi

# Now starts the magic

Wie nutzt man mehrere GitHub-Accounts auf einem Rechner?

Wenn Sie mehrere GitHub-Accounts haben und auf demselben Rechner arbeiten möchten, können Sie Ihre Git-Konfiguration anpassen, um sicherzustellen, dass die richtigen Anmeldeinformationen für die jeweiligen Repositories verwendet werden.

1. Legen Sie für jeden GitHub-Account, den Sie verwenden möchten, ein neues SSH-Schlüsselpaar an.

Zunächst prüfen wir, ob schon ein SSH-Schlüssel auf ihrem Rechner existiert:

ls -al ~/.ssh

Sollte kein Schlüssel angelegt sein, müssen wir eben einen erzeugen:

ssh-keygen -t rsa -b 4096 -C "Ihr Kommentar"

Es ist nicht unbedingt nötig, das Schlüsselpaar mit einem Passwort zu sichern – vorausgesetzt, Sie sind sich sicher, dass keine unbefugte Person Zugriff auf Ihr Home-Verzeichnis hat. Ich gehe folgendermaßen vor:

mkdir ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "Schlüssel 1 auf masch1"
ls -la

Das Schlüsselpaar nenne ich beispielhaft „id_rsa_01“

Im Verzeichnis befinden sich dann zwei zusammengehörende Dateien: „id_rsa_01“ und „id_rsa_01.pub“. Erstere beinhaltet den privaten und Letztere den öffentlichen Schlüssel.

Generierung eines RSA-Schlüsselpaares
ssh-keygen -t rsa -b 4096 -C "Schlüssel 1 auf masch1"
Generierung eines RSA-Schlüsselpaares

Man sollte sich den Inhalt beider Dateien einmal anschauen, um den Aufbau zu kennen.

cat id_rsa_01
cat id_rsa_01.pub
Der private RSA-Schlüssel
Der private RSA-Schlüssel
Der öffentliche RSA-Schlüssel
Der öffentliche RSA-Schlüssel

WICHTIG: Sie dürfen den privaten Schlüssel „id_rsa_01“ niemals an Dritte geben, schon gar nicht ohne eine Passwortsicherung. Ich werde nach dem Schreiben dieses Artikels das Schlüsselpaar löschen und ein neues anlegen, damit niemand es aus der Grafik kopieren kann.

2. Fügen Sie jeden öffentlichen SSH-Schlüssel Ihrem GitHub-Konto hinzu.

Um einen öffentlichen SSH-Schlüssel zu Ihrem GitHub-Konto hinzuzufügen, können Sie die folgenden Schritte ausführen:

Kopieren Sie den Inhalt der öffentlichen Schlüsseldatei (hier: ~/.ssh/id_rsa_01.pub) komplett in die Zwischenablage.

cat ~/.ssh/id_rsa_01.pub

Gehen Sie zu Ihrem GitHub-Konto und klicken Sie auf das Dropdown-Menü in der oberen rechten Ecke. Wählen Sie „Settings“ aus.

Klicken Sie im linken Menü auf „SSH and GPG Keys“.

Klicken Sie dann auf „new SSH key“

Geben Sie einen Titel für den Schlüssel ein (z.B. „RSA 1 Key für Maschine 1“). Behalten Sie die Auswahl „Authentication key“ bei. Fügen Sie den Inhalt des öffentlichen Schlüssels in das Feld „Key“ ein. Klicken Sie auf „Add SSH key“.

Danach sollten Sie folgenden Bildschirm erhalten:

Mehr Informationen zum Thema SSH und GitHub

Da wir mindestens zwei Schlüsselpaare für diese Aufgabe benötigen, legen Sie bitte gemäß Schritt 1 und 2 ein neues, zweites Paar an und nennen es „id_rsa_02“.

Anschließen öffnen Sie ihren zweiten GitHub-Account und fügen diesem den zweiten, privaten Schlüssel hinzu.

3. Konfigurieren Sie Git so, dass es den richtigen Schlüssel für jedes Repository verwendet.

Nun legen wir die Datei „~/.ssh/config“ an (wenn sie noch nicht existieren sollte) und bearbeiten sie.

nano ~/.ssh/config

Hier ein Beispiel

# Private github account: 1manfactory
Host github-private
   HostName github.com
   IdentityFile ~/.ssh/id_rsa_01
   IdentitiesOnly yes

# Company github account: Umbrella Corporation
Host github-umbrella
   HostName github.com
   IdentityFile ~/.ssh/id_rsa_02
   IdentitiesOnly yes

Falls Sie ihre Schlüsselpaare mit einem Passwort gesichert haben, sollten Sie beide Schlüssel dem SSH-Agenten hinzufügen. Somit werden Sie in dieser Session nur einmal nach dem Passwort gefragt, wenn Sie mit GitHub kommunizieren.

eval $(ssh-agent) # Sonderbefehl zum Start des SSH-Agenten
ssh-add ~/.ssh/id_rsa_01
ssh-add ~/.ssh/id_rsa_02
SSH-Agent: Schlüssel hinzufügen
SSH-Agent: Schlüssel hinzufügen

Damit es nicht zu einer Fehlermeldung kommt, müssen wir jetzt auch den öffentlichen Schlüssel von GitHub herunterladen. Der Befehl „ssh-keyscan“ sammelt öffentliche Schlüssel und speichert sie in der Datei „~/.ssh/known_hosts“, so dass Sie bei zukünftigen SSH-Verbindungen nicht mehr danach gefragt werden.

ssh-keyscan github.com >> ~/.ssh/known_hosts

Jetzt testen wir beide Verbindungen.

ssh -T git@github-private
ssh -T git@github-umbrella

4. Der Beweis: Wir klonen ein Repository und pushen eine Änderung

Wenn alles geklappt hat, sollte es inzwischen kein Problem mehr sein, ein Repository zu klonen.

eval $(ssh-agent) # den SSH-Agenten starten
cd ~
git clone git@github-private:1manfactory/demoprojekt.git # ein simples Demo
cd demoprojekt
dir
cat README.md
Ein Repository aus GitHub klonen per SSH-Schlüssel
Ein Repository aus GitHub klonen per SSH-Schlüssel

Bei Bedarf kann/sollte man noch die E-Mail-Adresse und den Namen für dieses lokale Repository anpassen:

git config user.email "name@domain.org"
git config user.name "Martin Mustermann"

Eine Datei können wir jetzt wie gewohnt ins Repository übernehmen (=commit) und zu GitHub übertragen (=push).

nano README.md # ein bisschen was ändern
git add .
git commit -m "zweites commit von lokal"
git push # und hochladen nach GitHub

Docker Container – Anlegen, Starten, Verändern

Hier zeige ich kurz und schnell auf, wie man Docker Container anlegt, startet und editiert.

Anmerkung: Ich nutze Windows 10 als Host und arbeite mit Docker Desktop und der Linuxumgebung für Windows namens WSL bzw. WSL2. Diese Befehle funktionieren aber selbstverständlich auch auf nativen Linux-Systemen.

Ein Image herunterladen

Docker Container sind selbstständig lauffähige Instanzen von Images, die editiert, dupliziert, getestet, verschickt oder (später) wieder entfernt werden können. Um also einen Container zu starten, muss man zunächst ein Image anlegen oder herunterladen. Dazu kann man etwa das Repository von docker.com, das Docker Hub, benutzen. (Später wird noch gezeigt, wie man Images selbst erstellen kann.) Das Image verbleibt als Blaupause dabei unverändert.

Im Online Docker Hub gibt es tausende verschiedener Images. Ich nutze hier das thematisch naheliegende Image „docker/getting-started“.

Wir geben in der Kommandozeile ein:

cd ~ # ab ins Homeverzeichnis
docker pull docker/getting-started

Folgendes sollte zu sehen sein:

docker pull docker/getting-started

Um zu überprüfen, welche Images in unserem lokalen Repository vorhanden sind, nutzen wir das Kommando docker images.

docker images
docker images

Den ersten Container erstellen

Nur erstellen wir unseren ersten einfachen Container.

Da es anfangs zu Missverständnissen führen kann, weil man fälschlicherweise die Befehle run und start als Synonyme versteht, muss ich auf den entscheidenden Unterschied hinweisen: run = Abkürzung für create + start

Daher macht

docker create <image_id>
docker start <container_id>

dasselbe wie

docker run <image_id>

Der Befehl run erzeugt also einen neuen Container von einem Image und startet ihn automatisch.

Wir gehen einmal Schritt für Schritt vor.

docker create -p 80:80 docker/getting-started # Container wird angelegt, aber nicht gestartet
docker ps -a # Auflistung der vorhandenen Container

Mit „-p 80:80“ werden die Ports 80 von Container und Gastsystem miteinander verbunden, das ist wichtig, um gleich per Browser auf den Container zugreifen zu können. Wie gewünscht und erwartet wurde ein neuer Container angelegt. Nun wollen wir diesen starten. (Wir können Container über deren automatisch generierten Namen ansprechen.)

docker start eloquent_haslett # Namen kann man leichter nutzen als IDs
docker ps -a # Kontrolle
docker start

Die IP des Containers ermitteln

Um die IP des gestarteten Containers zu ermitteln, müssen wir uns zunächst per Shell verbinden. Dies geschieht mit dem Befehl docker exec. Bei dem von Docker bevorzugten Alpine Linux liegt die Shell auf dem Pfad /bin/sh – andere Linux nutzen z.B. /bin/bash.

docker exec -u 0 -it eloquent_haslett /bin/sh
hostname -i # IP des Containers ausgeben
exit # Verbindung wieder trennen
docker exec

Exkurs: Die IP für Windows Systeme ermitteln

Sollte der Container auf einem Windows Host laufen, dann müssen wir die IP des Containers anders ermitteln.

Dazu müssen wir in der Windows-Konsole (nicht in Unix!) den Befehl ipconfig nutzen. Die IP findet sich dann unter dem Eintrag für den Ethernet-Adapter WSL.

Windows IP config für Docker

Der erste Aufruf eines Containers über den Browser

Wir können jetzt entweder den Container über die Adresse localhost (für Windows) oder über die ermittelte IP aufrufen.

http://localhost/ bzw. http://172.24.64.1 bzw. http://172.17.0.2 (für Linux-Hosts)

Docker Tutorial Container

Als Ergebnis erhalten wir das Tutorial, das auf dem Container läuft.

Somit hätten wir erfolgreich unseren ersten Container erstellt und gestartet.

Den Inhalt eines Containers manipulieren

Das ganze Handling mit Containern wäre nur der halbe Spaß, wenn man die Container nicht auch bearbeiten, sprich: Deren Inhalte nicht verändern könnte.

Dazu werden wir jetzt die Startseite des Tutorials ein wenig verändern.

Zuerst müssen wir uns wieder mit der Shell des Containers verbinden.

docker exec -u 0 -it eloquent_haslett /bin/sh

Auf dem Container-Linux ist leider nur vi als Editor installiert. Wer damit nicht klarkommt, sollte nano installieren.

apk update
apk add nano
Alpine Linux install Nano Editor

Mit Hilfe des Befehls find finden wir heraus, wo sich die HTML-Dateien des Tutorials befinden.

find / -name index.html #  Datei(en) suchen
nano /usr/share/nginx/html/tutorial/index.html # Datei editieren
Find index.html auf Alpine Docker Container

Im Editor suchen wir jetzt mit der Tastenkombination STRG+w nach dem String „<h1>“. Die Überschrift besteht aus dem Text „Getting Started“ wir ändern ihn in „Hallo, Welt!“. Dann bitte speichern und den Editor wieder verlassen.

Rufen wir die Seite im Browser neue auf, sollte folgende Änderung zu sehen sein:

Und natürlich sollte die Änderung auch permanent sein und nicht nach Neustart verschwunden sein.

exit # um die Shell des Containers zu verlassen, falls noch nicht geschehen
docker stop eloquent_haslett # Container stoppen
docker start eloquent_haslett # Container wieder starten

Und wenn wieder die Seite im Browser aufgerufen wird, sehen wir weiterhin die Änderung.

Der umgekehrte Weg: Image aus Container erstellen

Wenn wir nun aus dem geänderten Container ein eigenes Image erstellen wollen (um es bspw. in das Repository von Docker hochzuladen oder um es Kunden zum Testen zugänglich zu machen), wird der Befehl docker commit genutzt.

docker commit <container_id> <neue_image_bezeichnung:tag>

Praktischerweise sollten wir den neuen Namen mit einem Tag versehen, um eine Versionierung zu simulieren. Für unseren Fall also Folgendes:

docker commit eloquent_haslett docker/getting_started:edited
docker images # Kontrolle
Docker Container in Image umwandeln.

Wir sehen jetzt zwei Images, das ursprüngliche, welches wir aus dem Docker Hub geladen haben und das neue mit der Hallo-Welt-Überschrift im Tutorial.