| Hallo, Gast |
Du musst dich registrieren bevor du auf unserer Seite Beiträge schreiben kannst.
|
| Foren-Statistiken |
» Mitglieder: 1
» Neuestes Mitglied: Joopi
» Foren-Themen: 544
» Foren-Beiträge: 825
Komplettstatistiken
|
| Benutzer Online |
Momentan sind 13 Benutzer online » 0 Mitglieder » 7 Gäste AhrefsBot, Applebot, Bing, Bytespider, DotBot, bot
|
|
|
| Mitschrift Kurs 20210829 |
|
Geschrieben von: Joopi - 24-11-2024, 12:09 - Forum: Git
- Keine Antworten
|
 |
Git-Kurs
Git
Git konfigurieren auf der Konsole:
Code: git config --global user.name "Jopii"
git config --global user.email "info@jopii.de"
git config --global core.editor "nano"
mit
das aktuelle Arbeitsverzeichnis anzeigen lassen.
Ein neues Repository im aktuellen Verzeichnis erstellen:
Damit wird ein versteckter Ordner .git erzeugt.
Prüfen, in welchem Zustand die Dateien sind:
Zeigt z.B. welche Dateien geändert wurden und vieles mehr.
In der Staging Area werden Commits angelegt (Commits sind quasi kleine Versionsbunker).
Eine Datei oder einen Ordner der Staging Area hinzufügen:
Code: git add <file>
git add <folder>
git add . (mit dem Punkt wird alles hinzugefügt, was da ist)
Eine mit add zugefügte Datei aus der Staging Area entfernen:
Code: git rm --cached <file>
Das Hinzufügen wird quasi rückgängig gemacht.
Eine mit add hinzugefügte Datei kann weiterhin bearbeitet werden.
Im Status wird gezeigt, dass die Datei in der Staging Aarea ist, aber geändert wurde (**add** wieder ausführen oder **restore**, um Änderungen zu verwerfen)
Um Datei oder Ordner in ein Repository zu bringen:
Code: git commit -m <message>
Die Option -m muss von einer Erklärung zum Commit-Inhalt, meist sind es Änderungen, gefolgt ausgeführt werden.
Wenn git commit ohne Option aufgerufen wird, dann öffnet sich eine Datei, in die man dann den gewünschten Text oben als kurzer Titel und dann als Langtext schreiben kann.
Kurze Änderungsmitteilungen werden über die Option -m gefolgt von "Nachrichtentext" in das Repository übernommen.
Änderung im Commit bzw. im Repository anzeigen lassen (Commit-Historie):
Das ist die normale Ausgabe.
Zeigt mehr Änderungen in den Einzelheiten, also sehr ausführlich.
Eher verkürzte Darstellung der Änderungen in einer Zeile.
Commits abändern, weil doch noch nicht richtig (immer nur lokal verwenden, wenn es sein muss).
Der letzte Commit wird demnach überschrieben. Bei Remote-Repositories ist das nicht gut.
Wie arbeitet ".gitignore"?
Es wird eine Datei mit dem Namen ".gitignore" angelegt, in der z.B. ganze Pfade oder eben auch nur Dateien eingetragen werden, die vom Commit ausgenommen werden sollen. Das könnn z.B. auch Dateien sein, in denen Zugangsparameter für Datenbanken enthalten sind oder andere sensible Daten.
Es können auch Datei-Extensions wie *.txt genutzt werden.
Man kann die Datei .gitignore selber schreiben. Aber man kann auch auf vorgefertige Dateien auf GitHub zugreifen: .gitignore
Diese Ignore-Dateien sind themenspezifisch vorhanden. Könnte später mal interessant sein.
Alle Änderungen au der Staging Aarea herausnehmen (das Gegenteil von add - unstaging):
das betrifft alle Dateien
Code: git reset <filename>
betrifft nur die angegebene Datei
Wenn man den reset-Befehl mit der 7-stelligen ID des Commits ausführt, wird das ganze Commit zurückgesetzt.
Alle Änderungen in der Datei Zeile für Zeile anzeigen lassen:
Code: git blame <files>
git blame --color-lines <filename>
GitHub
In GitHub wurde aus master nun main, wenn es um den Hauptzweig geht.
Das ist dann wichtig, wenn ein Repository konfiguriert wird.
Remote-Repositories clonen:
Das gilt auch für eigene Projekte, wenn das lokale git nicht mehr zuständig ist, sondern alles auf github liegt.
Zeigt an, welche remote Repositories getrackt werden.
Bei git status wird angezeigt branch master und origin/master. Der erste Master ist der lokale, der zweite Master (oder main) ist der Master vom Clone!
Prüfen, welche Branches vorhanden sind:
Code: git branch
git branch -v
git branch -vv
(zeigt an, welchen origin/master er trackt
Herunterladen von Commits und Branches von einem remote Repository:
Wenn der Clone weiter ist, da mit fetch die Neuerungen geholt wurden, wird mit dem lokalen Master zusammengeführt:
Code: git merge origin/master
Wenn ich alleine an dem Projekt arbeiten, benötige ich die obigen Möglichkeiten nicht (nur push zum Hochladen).
GitHub für eigene Projekte
Es muss ein Account auf GitHub vorhanden sein.
Das Repository muss einen Namen haben: orbitjopii
Um das lokale Repository auf GitHub zu bringen muss es heißen:
Code: git remote add origin https:/...../orbitjopii.git
Um dann die Daten aus dem lokalen Repository in das remote Repository zu bekommen, muss es heßen:
Code: git push -u origin master bzw. main
Push muss auch später genutzt werden.
Änderungen zu GitHub übertragen:
Code: git commit -m message
Code: git log --oneline --branches --remotes --graph
Prüfen, ob die Änderung im origin/master angekommen ist.
Code: git log --oneline --branches --remotes --graph
Auch hier kann man prüfen, ob master und origin/master gleich sind.
Code: (base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git pull origin
Username for 'https://github.com': xxx
Password for 'https://Janiekmulder@github.com':
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Entpacke Objekte: 100% (3/3), 858 Bytes | 858.00 KiB/s, fertig.
Von https://github.com/Janiekmulder/kleinerorbit
0f8763f..192422c main -> origin/main
Merge made by the 'recursive' strategy.
README.md | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 README.md
Code: (base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git branch -vv
* main 7c007ff [origin/main: 2 voraus] Merge branch 'main' of https://github.com/Janiekmulder/kleinerorbit into main
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ ls -al
insgesamt 24
drwxrwxr-x 3 xxx xxx 4096 Aug 28 20:59 .
drwxrwxr-x 6 xxx xxx 4096 Aug 28 20:29 ..
drwxrwxr-x 8 xxx xxx 4096 Aug 28 21:01 .git
-rw-rw-r-- 1 xxx xxx 38 Aug 28 18:09 .gitignore
-rw-rw-r-- 1 xxx xxx 491 Aug 28 20:56 index.html
-rw-rw-r-- 1 xxx xxx 169 Aug 28 20:59 README.md
(base) xxx@xxx:/media/django/webserver/meine_projekte/janiekorbit$ git push origin
Username for 'https://github.com': xxx
Password for 'https://xxxx@github.com':
Objekte aufzählen: 9, fertig.
Zähle Objekte: 100% (8/8), fertig.
Delta-Kompression verwendet bis zu 16 Threads.
Komprimiere Objekte: 100% (5/5), fertig.
Schreibe Objekte: 100% (5/5), 897 Bytes | 897.00 KiB/s, fertig.
Gesamt 5 (Delta 1), Wiederverwendet 0 (Delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/Janiekmulder/kleinerorbit.git
192422c..7c007ff main -> main
Mitschrift Shellscript von Bryan Jenks wegen Cronjob, der Shell ausführt und Git/GitHub aktualisiert
Code: ZK_PATH="Pfad zum Vault"
cd "$ZK_PATH"
git pull
CHANGES_EXISTS="$(git status --porcelain | wc -l)"
if [ "$CHANGES_EXISTS" -eq @ ]; then
exit @
fi
git pull
git add .
git commit -q -m "Last Sync: $(date +'%Y.%m-%d %H:%M:$X')"
git push -q
How to git push using gitHub token on the command line:
Code: git push https://<GITHUB_ACCESS_TOKEN>@github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git
Code: git push https://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@github.com/Janiekmulder/orbit2.git
Neuer Versuch am 29.08.2021 um 10:48 Uhr
…or push an existing repository from the command line:
Code: git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main
Alle Anweisungen, wenn ein neues Repository nackt erstellt wurde.
Quick setup — if you’ve done this kind of thing before
or
https://github.com/Janiekmulder/orbit2.git
Get started by creating a new file or uploading an existing file. We recommend every repository include a README, LICENSE, and .gitignore.
…or create a new repository on the command line
Code: echo "# orbit2" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/Janiekmulder/orbit2.git
git push -u origin main
…or push an existing repository from the command line
Code: git remote add origin https://github.com/Janiekmulder/orbit2.git
git branch -M main
git push -u origin main
Code: git push https://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@github.com/Janiekmulder/orbitjopii.git
|
|
|
| Docker neues handling 20221105 |
|
Geschrieben von: Joopi - 23-11-2024, 09:57 - Forum: Docker
- Keine Antworten
|
 |
Neue Erkenntnisse
Heute, am 05.11.2022, habe ich mich wieder intensiver mit Docker und dessen Möglichkeiten für mich befasst.
Im Moment möchte ich hier nur einige Befehl hineinkopieren, die wichtig sind.
In dem Docker-Projektordner kann der Container so gestartet werden, dass man ein Volume erstellt, welche Daten vom Host im Container zur Verfügung stellt.
Es können naütrlich auch Ordner als Volumes zur Verfügung gestellt werden, die außerhalb des Projektordners liegen. Dann muss er eingebunden werden wie im zweiten Befehl.
Code: docker run -it --name ubuntu -v "$(pwd):/home" ubuntu:22.04 bash
oder
Code: docker run -it --name ubuntu -v "/media/django/webserver/dockerdaten/ubuntu2204:/home" ubuntu:22.04 bash
Ein Container, der nur einen Service zur Verfügung stellt, wie z.B. ein Webserver, sollte detached gestartet werden. Dadurch wird die Konsole wieder frei und wird nicht durch den laufenden Container blockiert. Der Webserver muss ja nur im Hintergrund laufen.
Hinweis:
Ein Container sollte nur immer einen Prozess abbilden. Wird ein CMS und eine MySQL-Datenbank benötigt, sind zwei Container erforderlich.
Diese Container können dann über eine Datei mit dem Namen docker-compose.yaml zusammengeführt werden. Die Startreihenfolge wird durch die Abhängigkeit des einen Prozess vom anderen Prozess bestimmt. Aber es laufen zwei Container!
Wenn ich in einen laufenden Container einsteigen möchte, der im detached-Modus läuft, so muss sich folgenden Befehl absetzen:
Code: docker attach <container>
demnach
Code: docker attach 80da9e62d78e
Temporärer Befehl
Code: docker run -it --name meinubuntu --network meinnetwork -v meinvolume:/home ubuntu:22.04 bash
Update am 07.11.2022
Heute habe ich verstanden, dass gestoppte Container nicht nutzlos sind, sondern über
Code: docker start --attach container-id
wieder genutzt werden können.
Man soll zwar in Containern nicht produktiv arbeiten, aber bei entsprechender Vorsicht können in den Containern Arbeitsstände *dauerhaft* zur Verfügung gestellt werden.
Das sind 15 Dockerbefehle, die man im Alltag gebrauchen kann
Docker-Befehle
Optionen
Beim run-Befehl wird die Option -it angegeben. Diese Option steht für:
- -i = interaktiver Modus
- -t = Shell als Standardinput-Gerät
Wenn beim run-Befehl die Option -d angegebenn wird, so wird der Container als *dameon* gestartet und kann grundsätzlich nicht zu sehen. Will man in einem Hintergrundcontainer etwas tun, so muss mit
- docker exec (docker exec –it {container} {command})
- docker attach (docker attach {container})
in den Container verzweigt werden.
|
|
|
| Docker handling compose |
|
Geschrieben von: Joopi - 23-11-2024, 09:55 - Forum: Docker
- Keine Antworten
|
 |
Infos zum Handling von Docker-Compose
Wenn das Docker-Compose-File genutzt wird, entfallen einige Aktionen auf der Konsole. Das Stoppen und Löschen von Containern ist nicht notwendig.
Zum Schluss bleibt im Grunde genommen nur das Image übrig, welches beim neuerlichen Start von Docker-Compose wieder genutzt wird.
Damit Docker-Compose (separat zu installieren) arbeiten kann, muss im Dockerdatenordner diese Datei liegen (andere Dateinamen sind nicht möglich):
Zitat:docker-compose.yaml
Der Start erfolgt so als detached Ausführung:
Code: docker-compose up -d
oder
Code: docker-compse -f dateiname.yaml up -d
Das Stoppen erfolgt so:
Das Herunterfahren erfolgt so:
Sobald Docker-Compose heruntergefahren ist, werden die Container und Netzwerkverbindungen scheinbar beendet und gelöscht.
Das ist der Ablauf in der Konsole, um meine vorherige Behauptung zu untermauern:
Code: user@user:/media/django/webserver/dockerdaten$ sudo docker-compose down
Removing dockerdaten_meinghost_1 ... done
Removing network dockerdaten_default
user@user:/media/django/webserver/dockerdaten$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
user@user:/media/django/webserver/dockerdaten$ sudo docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
user@user:/media/django/webserver/dockerdaten$ sudo docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
ghost 4 b05a58075ef6 19 hours ago 448MB
|
|
|
| Docker images Nutzung |
|
Geschrieben von: Joopi - 23-11-2024, 09:54 - Forum: Docker
- Keine Antworten
|
 |
Hinweise zur Nutzung von Docker Images
CouchBase
CouchBase auf Docker Hub
Step - 1: Run Couchbase Server docker container
Code: docker run -d --name db -p 8091-8094:8091-8094 -p 11210:11210 couchbase
Step - 2: Next, visit http://localhost:8091 on the host machine to see the Web Console to start Couchbase Server setup.
CouchDB
CouchDB auf Docker Hub
Code: user@user:~$ sudo docker run -d --name my-couchdb couchdb:latest
ead0a152cfefc65ef3921534134b94d7a72cdea59dd876e231f10b5e6ac16de9
MongoDB
MongoDB auf Docker Hub
Code: sudo docker run --name mymongo -d mongo:5.0.2-focal
eb6ed078e31adca5550c4a242033aa147c29c4bcd7c0b70e8a46cd1b6b919d25
Die für MongoDB gültigen TAG sind hier:
Supported tags and respective Dockerfile links
Ghost
Ghost - free blogging plattform
Code: sudo docker run -d --name myghost ghost
06b77297a1e2fb0871aef98139127ea559e74c764d971e7ac00033a50129ddfe
Will man Zugang im Browser haben, dann ist folgender Befehl erforderlich:
Code: sudo docker run -d --name some-ghost -e url=http://localhost:3001 -p 3001:2368 ghost
Im Browser ist dann das einzugeben: http://localhost:3001
und für den Adminzugang ist das einzugeben: http://localhost:3001/ghost
Container löschen und neu erstellen
Sobald der Container beendet ist, kann er gelöscht werden, da man nur mit einem neuen run-Befehl den Container später über den gewünschten Port im Browser ansprechen kann. Daher ist es wichtig, dass Anwenderdaten nicht im Container, sondern in einem Volumen gespeichert werden.
Das ist der Ablauf, um einen laufenden Container zu beenden und dann wieder später nutzbar zu machen:
Code: user@user:~$ sudo docker stop meinghost
[sudo] Passwort für django:
meinghost
user@user:~$ sudo docker container rm meinghost
meinghost
user@user:~$ sudo docker run -d --name meinghost -e url=http://localhost:3001 -p 3001:2368 -v /media/django/webserver/dockerdaten/ghost:/var/lib/ghost/content ghost
7cb325446ab4ab7476dfe274b3a90dc5dca7ee281f4b3d66ed3583f6e56b3171
Im Standard nutzt Ghost SQLite als Datenbank. Die Einbindung von MySQL ist aber auch möglich und auf der Ghost-Dockerseite beschrieben.
Golang
golang Official Image Go (golang) is a general purpose, higher-level, imperative programming language.
Es ist wohl ein DockerFile notwendig, um dieses Image im Container laufen lassen zu können.
|
|
|
| Docker img installieren |
|
Geschrieben von: Joopi - 23-11-2024, 09:53 - Forum: Docker
- Keine Antworten
|
 |
Sammlung von Docker IMG
Die Docker-Grundlagen
Docker Grundlagen
Wie funktionieren Docker Container?
Achtung:
Docker IMG haben nur Leserechte.
Will man mit Docker arbeiten und Daten verändern, müssen die Container ran. Darin kann man arbeiten.
Ein Container entsteht immer aus einem Image. Es beinhaltet alle Komponenten, um eine Anwendung plattformunabhängig auszuführen.
Eine Bash ausführen in einem Container:
Code: sudo docker run -it ubuntu bash
|
|
|
| Docker Eigene Daten |
|
Geschrieben von: Joopi - 23-11-2024, 09:52 - Forum: Docker
- Keine Antworten
|
 |
Eigene Daten in Docker-Container erstellen und speichern
Ich habe versucht herauszufinden, ob man Daten in einem Docker-Container erstellen und speichen kann. Und ob diese Daten später noch vorhanden sind, wenn der Container gestoppt (nicht gelöscht) wurde.
Dazu habe ich mir ein Ubuntu als Betriebssystem heruntergeladen und via apt-get ein Upate und ein Upgrade gemacht. Das war notwendig, um danach den Editor nano zu installieren.
Zwar hatte ich eine Datei im Home-Verzeichnis via touch erstellt, jedoch hatte ich keinen Zugriff auf einen Editor. Komisch eigentlich.
Mit nano konnte ich die erstellte Datei dann ganz normal bearbeiten und speichern.
Dann habe ich dne Container mit exit verlassen und mit stop den Container gestoppt.
Und dann habe ich mit start den Container wieder gestartet und mich mit exec wieder in den Container eingeloggt.
Die vorher erstellte Datei und der Inhalt waren vorhanden. Somit kann man die Container durchaus produktiv nutzen. Es muss aber Möglichkeiten geben, wie man eine Sicherung der Daten außerhalb des Containers anlegen kann. Ich meine dieses im Heise-Tutorial gesehen zu haben.
Mit Docker habe ich nun den ganzen Abend probiert und habe mit CouchBase eine NoSQL-Datenbank im Container laufen. Das ist nicht schlecht. Leider kann ich MongoDB nicht starten, da ich mit dem TAG nicht klarkomme. Das muss ich morgen mal ausprobieren.
|
|
|
| Docker Infos Heise-Tutorial |
|
Geschrieben von: Joopi - 23-11-2024, 09:50 - Forum: Docker
- Keine Antworten
|
 |
Infos aus dem 6-teiligen Heise-Tutorial
Erstellung eines Volums.
Volums sind dafür da, um eigene Daten aufzunehmen. Damit diese nicht direkt in einen Container erfasst werden, legt man unter /usr/share zum jeweiligen Programm, z.B. nginx, ein Volume an.
Die Syntax wäre in diesem Beispiel wie folgt:
Code: sudo docker run --name my-nginx -v /some/content:/usr/share/nginx/html:ro -d nginx
some-nginx = Name des Containers
-v = ein Volume anhängen und deklarieren
-d = Dienst läuft im Hintergrund
nginx = Image
ro = read only
Hinweis:
In einem Dockercontainer sind nur die wichtigsten Pakete enthalten. Will man eine Textdatei erstellen, aber ein Editor ist nicht verfügbar, kann man pragmatisch folgendes machen:
Code: echo "Hallo Docker!" > index.html
Damit erstellt man eine Datei, die dann verwendet werden kann. Will man künftig mehr in dem Container machen, empfiehlt es sich, einen Editor zu installieren (und daraus dann ein eigenes Build zu machen). Das wird so aber nicht empfohlen (?). Insgesamt ist das der denkbar schlechteste Weg.
Fazit:
Mit docker exec in einen Container zu gehen und dort Daten zu bearbeiten ist nicht gut und sollte so nicht gemacht werden.
Die Anwendungsdaten werden im Container nicht gespeichert. Sobald der Container beendet wird, sind die Daten weg. Daher müssen Volumes angelegt werden, die die Anwendungsdaten speichern udn vorhalten.
Um ein Volume zu erzeugen, ist folgender Befehl notwendig:
Code: sudo docker volume create
Dieser Befehl erzeugt einen langen Name aus Zufallszahlen/-ziffern. Man kann den Volumennamen auch vorgeben:
Code: sudo docker volume create html
Mit dem ls-Befehl kann ich mir die vorhandenen Volumes anzeigen lassen:
Code: sudo docker volume ls
Das läuft analog zu den Images und den Containern.
Um nun das erzeugte Volume mit dem Namen html in den nginx-Container zu bringen, wird eine zweite Instanz aufgemacht und ein weiterer Port eröffnet (nicht zwingend erforderlich, nur zur Demonstration):
Code: sudo docker run --name myvol-nginx -p 8081:80 -v html:/usr/share/nginx/html:ro -d nginx
ro heißt readonly.
Das erzeugte Volume liegt hier:
Zitat:/var/lib/docker/volumes
Dieses Verzeichnis kann ein Normaluser, selbst wenn er in der Gruppe docker ist, nicht sehen (sudo -s)
WICHTIG:
Selbst wenn der Container zerstört wird, bleibt das Volume erhalten. Wichtig ist dann dabei, dass das Verzeichnis /usr/lib/docker gesichert wird, wenn in diesem Verzeichnis Nutzer- und Anwendungsdaten für die weitere Verarbeitung gespeichert werden, also produktiv genutzt werden.
Die Volumes müssen nicht unbedingt im Docker-Verzeichnis liegen, sondern können an jeder beliebigen Stelle gespeichert werden. Dazu wäre dann z.B. dem Volume HTML das Verzeichnis voranzustellen (Beispiel): /home/django/dockervolume/HTML
Die Prozesse, die innerhalb der Container laufen, müssen allerdings die Berechtigungen auf dieses Verzeichnis haben.
Docker und Netzwerke
Docker erzeugt ein eigenes Netzwerk: docker0
Docker hat verschiedene Netzwerke, die man sich so anzeigen lassen kann:
Beispiel, wie zwei Container kommunizieren.
Ein Blogsystem auf Basis WordPress-Blogsystem
- Container mit Webserver und WordPress
- Container mit Datenbank MySQL / MariaDB
Container für Datenbank:
Code: docker run --name test-mysql -e MYSQL_ROOT_PASSWWORD=meinpasswort -e MYSQL_DATABASE=wordpress -e MYSQL_USER=wp -e MYSQL_PASSWORD=meinpasswort -d mysql:5.7
Container für WordPress / Webserver
Code: docker run --name wordpress --link test-mysql:test-mysql -p 8082:80 -d wordpress
Hinweis:
Zitat:--link anstelle von --name
Dieser Part "test-mysql:test-mysql" bedeutet, dass der Container test-mysql auch als test-mysql angesprochen werden. Soll dieser Name dann anders lauten, müsste er angegeben werden (z.B. test-mysql:test-worpress).
Hinweis:
Docker hat einen eigenen DNS-Server laufen.
Für das obige Beispiel würde im Browser, da wir mit WordPress arbeiten wollen, folgendes einzugebenn sein:
Zitat:localhost:8082
Sodann würde die Installation von WordPress erfolgen.
Die Daten von WordPress werden in der Datenbank abgespeichert. WordPress und die Datenbank sind in zwei Containern aufgeteilt. Um mit den eingegebenen Daten weiter arbeiten zu können, müssten die Daten in ein Volume übertragen werden
Wie das geht, weiß ich noch nicht!
Wenn z.B. WordPress vom Rest der Welt trennen möchte, dann kann das über ein eigenes Docker-Netzwerk erfolgen. Das sieht dann so aus:
Code: docker network create --driver bridge test-bridge
Prüfen, ob das Netzwerk angelegt ist bzw. welche vorhanden sind, kann man mit:
Dieses neue Network kann man an den Run-Befehl für mysql hängen:
Code: docker run --name test-mysql --network=test-bridge -e MYSQL_ROOT_PASSWWORD=meinpasswort -e MYSQL_DATABASE=wordpress -e MYSQL_USER=wp -e MYSQL_PASSWORD=meinpasswort -d mysql:5.7
Hinweis:
Es gibt den inspect-Befehl. Dieser kann auf das Netzwerk angewandt werden. Um das neue Netzwerk zu inspizieren, ist folgendes notwendig:
Code: docker network inspect test-bridge
Man kann also in das Netzwerk "hineinschauen".
Wie kann man Docker vereinfachen?
Contaner mit Compose einrichten
Mehrere Container nebeneinander betreiben.
Docker-Compose ist ein Python-Script (offizell von Docke unterstützt), mit dem vereinfacht mehrere Container aufgebaut und miteinander verbunden werden können.
Ein Compose-File ist wie folgt strukturiert (Beispiel MySQL-Container)
Zitat:version: '3'
services:
db:
image: mysql:5.7
volumes:
- ./data/db/:/var/lib/mysql
restart: always
ports:
- "3306:3306"
environment:
MYSQ_ROOT_PASSWORD: secret123root
Die Inhalte sind quasi die gleichen wie in einem run-Befehl.
Die Aussage ist, dass selbst, wenn nur ein Container laufen soll, eine Compose-File nützlich ist.
Der data-Ordner des Volume liegt in dem Ordner, aus dem das Compose-File aufgerufen wird. Der Punkt weist auf die relative Lage hin. Hat mein einen eigenen Bereich auf der lokalen Festplatte eingerichtet, ruft man das File eben von dort aus auf.
Für das Beispiel aus dem Netzwerkabschnitt (WordPress und MySQL) sieht das Compose-File wie folgt aus:
Zitat:version: '3'
services:
db:
image: mysql:5.7
volumes:
- ./data/db/:/var/lib/mysql
restart: always
ports:
- "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: secret123root
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: 12345wordpress54321
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: 12345wordpress54321
working_dir: /var/www/html
volumes:
- ./data/wordpress:/var/www/html/wp-content
portainer:
image: portainer/portainer
restart: always
ports:
mehr sehe ich nicht, scheint ein volume zu sein, ist wohl eine grafische Oberfläche gedacht, also nicht in der Konsole wichtig.
So wird die yml-Datei, in der das Compose-File abgespeichert wurde, ausgeführt:
- up = starten
- stop = stoppen
- down = herunterfahren (Container werden dabei sofort gelöscht)
Damit wird wohl alles an Compose-Files gestartet.
Die Ausführung dieses Befehl ist sichtbar, da die Option -d nicht mit angegeben worden ist.
Ansonsten könnte man bei der Sichtbarkeit die einzelnen Aktionen sehen, die ausgeführt würde. Es gibt dann wohl, sobald der Datanbankserver oben ist mit der Installation von Wordpress im Browser.
Hinweis:
In einer yml-Datei ist die Einrückungstiefe immer 2 Leerzeichen. Man kann auch Tabs verwenden, aber zwei Leerzeichen sind wohl Standard.
Um z.B. auf der Shell in die Container mit dem exec-Befehl einzusteigen, kann folgender Befehl genutzt werden:
Code: docker-compose excec db sh
Damit ist man im Container anstelle des komplexen Befehlaufrufes aus den Anfängen.
Die grafische Oberfläche für Docker
Portainer ist eine bekannte grafische Oberfläche
Sofern im Compose-File der Portainer integriert ist, kann man in der Adressezeile des Browsers über den Port 9000 die Webseite erreichen.
Zitat:localhost:9000
Ich unterstelle derweil, dass das möglich ist, denn in dem Beispiel bei Heise wird mittlerweile eine echte Domain genutzt. Sollte aber auch mit localhost funktionieren.
Zertifikate erstellen
Die Anwendungen, die man in Docker erstellt, kann man sind Internet bringen. Man muss dafür aber vieles beachten, um die Sicherheit zu gewährleisten. Mit Zertifikaten kann man das erreichen.
Eine Grundlage ist z.B. Watchtower (wird niht mehr entwickelt, es gibt was neues) und gehört zu vorherigen Compose-File.
Watchtower ein Image, welches sich um die Aktualisierung von Images kümmert, was durch Docker selber nicht geleistet wird.
Code: watchtower:
image: v2tec/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
command: --interval 30
Um von außen auf die Anwendung schauen zu können, wird folgendes benötigt (Revers-Server/Proxy oder so ähnlich)
Für das nachfolgende Beispiel muss der WordPress-Container angepasst werden, da diese keine Ports mehr freigeben darf (wird weiter unten mit 80 und 443 gemacht):
Code: wordpress:
depends_on:
- db
image: wordpress:php7.1
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: 12345wordpress54321
LETSENCRYPT_HOST: mlsjam.leipsieb.de
LETSENCRYPT_EMAIL: mls@ct.de
VIRTUAL_HOST: mlsjam.leipsieb.de
VIRTUAL_PORT: 80
working_dir: /var/www/html
volumes:
- ./data/wordpress:/var/www/html/wp-content
Ob das auch auf localhost läuft, weiß ich derzeit nicht.
Code: nginxproxy:
image: jweilder/nginx-proxy
restart: unless-stopped
volumes:
- ./data/certs:/etc/nginx/certs
- ./conf:/etc/nginx/conf.d
- ./dhparam:/etc/nginx/dhparam
- ./data/vhosts:/etc/nginx/vhost.d
- ./data/html:/usr/share/nginx.html
- /var/run/docker.sock:/tmp/docker.sock
ports:
- 80:80
- 443:443
labels:
- "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy"
nginxproxy_comp:
image: jrcs/letsencrypt_nginx_proxy_companion
restart: unless_stopped
depends_on:
- nginxproxy
volumes:
- ./data/certs:/etc/bginx/certs:rw
- ./conf:/etc/nginx/conf.d
- ./dhparam:/etc/nginx/dhparam
- ./data/vhosts:/etc/nginx/vhost.d
- ./data/html:/usr/share/nginx.html
- /var/run/docker.sock:/tmp/docker.sock:ro
In meinen Tests hatte ich mehrere Male die Probleme, dass die Ports z.B. 8080 oder 8081 als belegt gekennzeichnet wurden.
Um herauszufinden, welche Anwendungen die Ports belegen, natürlich können das auch laufende Container sein, ist folgender Befehl hilfereich:
Code: sudo lsof -i -P -n | grep 8080
Das Ergebnis sieht so aus:
Somit ist für mich klar, dass ich den Port 8081 nehme.
Wie ich mit den Ports überhaupt umgehen muss, weiß ich selber noch nicht, wenn es sich um Webanwendungen handelt.
|
|
|
|