Viele erinnern sich noch an Zeiten, wo man direkt auf einem Webserver seinen HTML-Seiten und Scripts geschrieben und getestet hat. HTML ging meistens schon lokal, aber wenn es um PHP oder anderes ging brauchte man einen Server. Dann schwenkte man auf XAMPP um, wo man einen lokalen Apache nutze. Linux brachte den Apache und PHP direkt mit. Aber man hatte oft kein Linux und half sich mit VirtualPC oder VirtualBox, so man entweder eine shared Speicher hatte oder ganz klassisch per FTP oder später SCP/SSH seine Dateien aus der IDE ins Zielsystem bekam. Dann kam Docker und die Welt wurde gut.. über all gut? Nein, dann erstaunlich viele gerade im Agentur-Bereich arbeiten immer noch mit einem Server und einem FTP-Sync. Gut heute oft mit SFTP oder SCP, aber ohne Docker oder lokalen Webserver.
Während ich klassische vServer mit Apache und ohne Reverse-Proxy und Docker für veraltet halte, sind sie noch öfter Realität als Docker-/K8n-Umgebungen. Selbst shared-Hosting für produktive Umgebungen sind noch öfters anzutreffen.
Nach einem Gespräch, wo noch direkt auf dem Server gearbeitet wurde und nicht mal eine lokale IDE einen Sync in Richtung Server vornahm sondern direkt die Datei vom Server aus geöffnet wurde (da kann man fast direkt mit vi auf dem Server arbeiten...), hier eine einfache kostenlose Lösung, wo man wenigstens die Dateien lokal hat und so auch ohne Probleme mit Git arbeiten kann.
Genutzt wird VisualStudio Code (die Intellij-IDEs bringen so einen Sync direkt von Haus aus mit, kosten aber in den meisten Varianten Geld).
Ein Plugin installieren:
FTP-Config anlegen (wird geöffnet nach dem ersten Sync-Versuch):
Wenn uploadOnSave aktiviert ist am Besten die IDE noch mal neustarten.
Geht auf jeden Fall besser als WinSCP parallel zum Sync laufen zu lassen.
Würde ich so entwickeln wollen? Nein. Besonders wenn mehr als ein Entwickler an einem Projekt arbeiten, geht nichts über Docker. Für Shopware habe ich gute Images oder man nimmt Dockware, was gerade für Entwickler an sich vollkommen reicht.
Falls man seinen Shopware 6 in einem Shared-Hosting Paket von Cyon (Schweiz) betreibt, ist man es ja schon fast gewohnt, dass es Probleme beim Bauen der Administration über CLI gibt. Momentan gibt es wohl Probleme mit Puppeteer. Die Lösung hier ist es vor eine entsprechende Umgebungsvariable zu setzen:
export PUPPETEER_SKIP_DOWNLOAD='true'
Dann geht es wieder.. nicht schnell aber das war es dort ja noch nie.
Einfach den Inhalt der id_rsa.pub zu nehmen und dort einzutragen funktioniert leider nicht, da das Format nicht übereinstimmt. Eine Datei mit mit dem entsprechenden Key kann man sich aber sehr schnell erzeugen.
Nachdem ich wieder einmal Keys von Windows auf ein Linux-System umgezogen haben und wieder erstmal herausfinden musste wie die Rechte gesetzt sein müssen.. hier einmal ein kurzes Script dazu:
Manchmal muss man z.B. das Kopieren von Dateien auf einen Server per SCP testen. Oder auch einfache Deployments auf einem Server. Hier ist ein kleines SSH-Server Image mit Bash und Rsync.
FROM sickp/alpine-sshd:7.5
RUN apk update
RUN apk add bash
RUN apk add rsync
Und in einer docker-compose.yml
version: "3.0"
services:
ssh-server:
build: .
ports:
- "2222:22"
User: root
Password: root
Man kann aber auch authorized-keys hinterlegen, wie auf der Seite des Base-Images erklärt wird.
Nachdem ich meine wichtigsten Projekte in Docker-Container verfrachtet hatte und diese mit Traefik (1.7) als Reserve-Proxy seit Anfang des Jahres stabil laufen, war die Frage, was ich mit den ganzen anderen Domains mache, die nicht mehr oder noch nicht produktiv benutzt werden.
Ich hatte die Idee einen kleinen Docker-Container laufen zu lassen, auf den alle geparkten Domains zeigen und der nur eine kleine Info-Seite ausliefert. Weil das Projekt so schön übersichtlich ist und ich gerne schnell und einfach neue Domains hinzufügen will, ohne dann immer Container selbst stoppen und starten zu müssen, habe ich mich dazu entschieden hier mit Gitlab-CI ein automatisches Deployment zubauen. Mein Plan war es ein Dockerfile zu haben, das mir das Image baut und bei dem per Label auch die Domains schon angegeben sind, die der Container bedienen soll. Wenn ich einen neuen Tag setze soll dieser das passende Image bauen und auf meinem Server deployen. Ich brauche dann also nur noch eine Datei anpassen und der Rest läuft automatisch.
Dafür habe ich mir dann extra einen Gitlab-Account angelegt. Man hat da alles was man braucht und 2000 Minuten auf Shared-Runnern. Mehr als genug für meine Zwecke.
Ich habe also eine index.html und ein sehr einfaches Dockerfile (docker/Dockerfile):
FROM httpd:2.4
COPY ./index.html /usr/local/apache2/htdocs/index.html
LABEL traefik.enable=true traefik.frontend.rule=Host:darknovels.de,www.darknovels.de
Das wird dann also in einen Job gebaut und in einem nach gelagerten auf dem Server deployed. Dafür braucht man einmal einen User auf dem Server und 2 Variablen in Gitlab für den Runner.
Dann erzeugt man sich für den User einen Key (ohne Passphrase):
su dockerupload
ssh-keygen -t rsa
cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
exit
Vielleicht muss man da noch die /etc/ssh/sshd_config editieren, damit die authorized_keys-Datei verwendet wird.
Den Private-Key einmal kopieren und in SSH_PRIVATE_KEY unter Settings - CI /DI - Variables speichern. Damit wir uns sicher vor Angriffen verbinden können müssen wir noch den Server zu den bekannten Hosts hinzufügen. Den Inhalt von known_hosts bekommt man durch:
ssh-keyscan myserver.com
Einfach den gesamten Output kopieren und in den Gitlab Variablen unter SSH_KNOWN_HOSTS speichern. Nun hat man alles was man braucht.
Manchmal muss den Upload von Dateien testen. Nicht immer nutzt man etwas wie S3 sondern oft auch noch ganz klassische Umgebungen mit SCP oder sFTP. Wenn man schnell und unkompliziert den Upload auf einen sFTP-Server testen will, kann sich so einen ganz schnell und einfach mit Docker erzeugen.
docker run -p 2222:22 -d atmoz/sftp foo:pass:::upload
man kann sich dann auf localhost:2222 mit dem Benutzer foo und dem Passwort pass verbinden. Für Dateien steht das Upload-Verzeichnis bereit. Wenn man ihn nicht mehr braucht, wirft man den Container einfach weg und kann das nächste mal sauber mit einem neuen starten.
Ich bin gerade dabei eine Lösung zu basteln, damit die Bilder und Videos der Überwachungskameras, die die über FTP auf dem QNAP NAS speichern, nach 5 Tagen automatisch löschen zu lassen.
Dafür muss man über SSH auf das NAS und die Cron-Table editieren.
So bald man sich über SSH verbunden hat merkt man auch, dass am Ende doch alles immer nur ein Linux ist.. außer es ist Windows.
Wer sich einmal aus versehen in den vi verirrt hatte, weiß wie verwirrend dieser Text-Editor für die Befehlszeile sein kann. Die meisten nutzen vi meistens nur für einen Zweck.. das Bearbeiten von Config-Dateien auf einem Server über eine SSH-Session oder schnelle Anpassungen an Dateien, wenn man Dinge auf der lokalen Dev-Workstation nicht nachvollziehen kann. Dazu reichen zumeist Datei öffnen, Datei bearbeiten, Datei speichern und vi wieder verlassen.
Öffnen ist ganz einfach:
vi file.conf
Dann öffnet sich der vi und man kann über die Pfeil-Tasten schon mal die Position wechseln.
wenn man nun schreiben möchte drückt man i für insert-mode.
Nun nimmt man seine Änderungen vor.
Mit ESC wechselt man zurück in den Command-mode. Speichern geht über :w für write.
Danach kann man entweder mit i weiter bearbeiten oder gibt :q für quit ein.
An sich eine sehr logische Bedienung aus dem insert-mode und dem command-mode zwischen denen man hin und her schalten kann.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
