Beiträge von Paul

Zitat von Bevor

Eines würde mich dabei noch interessieren: Muss das initiale Setup mindestens aus 2 Nodes bestehen, oder kann das komplette Replication-Konzept problemlos nachinstalliert werden für den Fall, dass ich mal mit einem Single-Server-Setup starte?

Du kannst das Replikations-Setup auch ruhig später noch einrichten und erst einmal mit einem Single Node starten. Du kannst auch (beliebig) viele Slave Nodes einrichten, dann wählt der Repmgr im Falle eines Ausfälls irgendeinen Node aus, der als neuer Master ernannt wird.

Beachte nur, dass es mit dem Umschalten der IP immer einen kleinen Moment dauert. Bei mir hat das immer so 20-30 Sekunden gedauert bis das Routing auf die neue IP funktionierte. In dieser Zeit wäre die DB nicht erreichbar. Die Applikation müsste das dann verkraften können.

Was mir so spontan einfallen würde: PostgreSQL Master/Slave Setup mit einem Replication Manager (https://repmgr.org/) für die Umschaltung. Dann würde im Fall, dass der Master heruntergefahren wird, der Slave durch den repmgr zum Master ernannt. Die Failover IP könntest du dann z.B. mit keepalived ebenfalls umschalten. Alternativ gäbe es auch noch den pgpool, welcher ebenfalls die Replikation verwalten kann, damit habe ich aber weniger gute Erfahrungen gesammelt.

So ein Setup würde ich aber sehr intensiv testen. Das könnte u.U. auch sehr wackelig werden und mehr Probleme verursachen als es eigentlich löst. Generell sind 2 Node HA Cluster eher weniger gut geeignet, da du nie ein eindeutiges Quorum hast.

@2n55YMYSwMYGxc

Wenn dir die Installation von K8s Schwierigkeiten bereitet, schau dir auf jeden Fall mal Rancher (v2) [1] an. Das ist sicherlich die einfachste Variante einen (produktiven) K8s zu installieren und vor allem auch auf Dauer zu betreiben, weil es ein komplettes Lifecycle und Patchmanagement zur Verfügung stellt. Zudem bietet es eine Management-Weboberfläche für den K8s Cluster an, welche vor allem zu Beginn recht hilfreich ist.

Die Installation erfolgt folgendermaßen:

1. Installation von Rancher v2 (auf einem zentralen MGT Node) über Docker (Ein schlichtes "docker run" mit Volume Mounts)
2. Konfiguration (URL, User, ...) von Rancher v2 über die Weboberfläche
3. Anlegen eines Clusters in Rancher (dieser gibt einem dann einen Copy&Paste Befehl, den man auf allen k8s ausführen muss).
4. Fertig

Rancher kann auch direkt bei bestimmten Cloud-Providern VMs über die API anlegen, so dass man hier gar nicht erst die VMs selbst vorbereiten muss. Hier bei Netcup installierst du die VMs halt schnell mal selbst (inkl. Docker) und wählst in Rancher die "Custom Provisionierung". Dies nur noch kurz als Info.

Etwas schade finde ich nur, dass Rancher v1 damit abgekündigt wurde. Das war eine sehr schlichte Docker-Orchestrierung, die auch für kleinere Umgebung gut geeignet ist/war. K8s selbst ist halt für wirkliche große Umgebungen gedacht (kommt von Google und ist genau für diesen Scale auch ausgelegt) und für viele Zwecke einfach nur ein viel zu großer Overhead. Gerade wenn man es selbst betreiben möchte/muss.

[1] https://rancher.com/docs/rancher/v2.x/en/

Zitat von chaosrind

Ich sehe gerade wieder einen spannenden Nachbarthread....

forum.netcup.de/system/attachment/2539/

Oh man, Microsoft, ist ja ok, wenn ihr meine Mails ablehnen wollt. Aber immerhin TLS könntet ihr doch anbieten...auch wenn das in diesem Fall nur der Türsteher ist und die normalen Mailserver das wohl können.

TLS is required, but was not offered by host outlook-com.olc.protection.outlook.com[104.47.38.33]

Zitat von mfnalex

Ist mir bewusst, aber wenn ich für 8 vCores zahle dann habe ich auch kein schlechtes Gewissen diese zu nutzen. Natürlich wollte ich keine utopische Load erzeugen. Ich dachte eher an ein paar Kleinigkeiten, die man nebenbei laufen lassen könnte, eben z.B. wie den NTP Pool

Nur so ein persönlicher Gedanke: Ich würde einen Server, der primär für eigene Backups gedacht ist, vielleicht nicht unbedingt gleichzeitig für "public services" nutzen wollen. Nutze ihn lieber für eigene Dienste wie oben schon mal erwähnt z.B. Monitoring oder auch als Repository oder Mirror und beschränke den Zugriff auf eigene Server. Diesen Sicherheitsaspekt sollte man durchaus in Erwägung ziehen.

Mein Backup Server ist auch gleichzeitig mein Monitoring Server (Zabbix). Das benötigt zwar jetzt auch nicht wirklich viel Leistung, aber immerhin langweiligt sich so der Server nicht mehr 23h am Tag und macht noch etwas vernünftiges

Wie wäre es denn mit https://www.netcup-sonderangeb…osting/webhosting-autumn/ Das sollte doch bestimmt noch ins Budget passen

Ich bin jetzt schon viele Jahre Kunde bei Netcup (>10 jahre) und habe in dieser Zeit noch nie Daten verloren aufgrund von Hardware-Defekten. Zwar wurde ab und zu mal ein Server auf einen anderen Node migriert, weil es wohl Probleme mit der Hardware gab, aber es hat definitiv nie Datenverlust gegeben. Ein Restrisiko besteht natürlich immer, auch bei einem Raid 10. Auch ein menschlicher Fehler könnte mal dazu führen. Aber genau dafür sollte man ja auch immer Backups haben

Ich finde, Netcup macht diesbezüglich einen super Job! Und das ist sicherlich auch mit ein Grund, warum ich hier sehr zufrieden meine Server miete

Naja, die Frage ist im Grunde: Worauf laufen die Seiten denn jetzt und was heißt für dich "hoher Traffic"? Die RS G8 haben laut Beschreibung 80TB Traffic inklusive. Danach wird u.U. gedrosselt. Prinzipiell sollte das auf einem RS 2000 G8 eigentlich gar kein Problem sein. Wenn doch, ist ein einzelner Server vielleicht eh die falsche Wahl und man sollte anfangen bestimmte Dienste auszulagern.

Ein (Netcup) Root Server ist für Webseiten und Foren eigentlich sehr gut geeignet. Ok, oft reicht vermutlich auch schon ein VPS, weil man in diesen Fällen nicht unbedingt dedizierte CPU Ressourcen benötigt. Aber wirklich falsch machen kann man damit nichts. Hast ja dafür auch eine Zufriedenheitsgarantie.

Ich würde den "/tickets/" Block mal aus dem "/" raus nehmen und parallel konfigurieren. Ebenso auch die anderen Blöcke. Ich bin mir nicht ganz sicher, ob diese verschachtelte Konfiguration evtl. zu Problemen führt. Normalerweise braucht man das nämlich nicht. nginx sucht sich den passenden Block schon selbst.

Dein Problem ist, dass die Bilder/Anhänge öffentlich sichtbar sind? Das erklärt sich durch das "allow all;" in dem location Block

Da ich selbst in der Brancher arbeite, kann ich aus Erfahrung sagen, dass es immer besser ist, Wartungsarbeiten tagsüber (während den Bürozeiten) durchzuführen, da

1. Die Mitarbeiter wach und konzentriert sind (Nachts ist das "menschliche" Fehlerrisiko deutlich höher)

2. Wenn wirklich mal was schief geht, ist zur Not die ganze "Mannschaft" da und kann helfen.

3. Der Kunde ist besser zu erreichen (Mitteilungen) und kann die Systeme leichter kontrollieren.

Systeme, die wirklich keine Downtime vertragen, sollte nach Möglichkeit HA gebaut werden, da es auch sonst jederzeit zu einem Ausfall kommen kann.

Downtimes und Reboots sind immer unangenehm. Keine Frage. Aber sowas gehört leider dazu. Gerade bei produktiven Systemen muss man sowas mit einplanen.

Zitat von da_benzel

LDAP geht auch in der CE

Du hast recht (https://about.gitlab.com/pricing/). Das war früher aber wohl mal anders Seit sie ihr Preis-Modell etwas angepasst haben, geht das wohl auch in der CE Edition. In dem Core/Starter/Premium/Ultimate Dschungel muss man sich auch erst mal zurecht finden

Zitat von H6G

Das sieht so stark nach Enterprise Edition aus, bis auf das Site-Building-Feature. Kannst du das bestätigen?

Die Gitlab CI Funktionalität ist auch in der CE-Edition vorhanden (https://about.gitlab.com/features/gitlab-ci-cd/), Gitlab Pages ebenfalls. Was es dafür braucht, sind zusätzliche Gitlab Runner, aber das ist alles auch in der kostenlosen Version vorhanden. Die Enterprise Editionen bieten dann eher sowas wie LDAP-Integration, Geo Replikationen oder Docker Image Security Scanning. Das o.g. Hugo Beispiel ist so auch mit der CE-Edition problemlos möglich.

Zitat von H6G

Ich nutze gitea, bin damit sehr zufrieden.

Einige UI Features sind diskutabel (Read / Clone Access für alle authentifizierten Accounts auf ein Repo ist möglich, wenn das Repo auf 'Visible' gestellt wurde)

Ansonsten ein sehr schönes Werkzeug.

Gitea nutze ich privat auch,vor allem weil es so schön schlank ist (im Vergleich zu Gitlab). Läuft bei mir in einer Docker Swarm Umgebung. Bin damit ebenfalls super zufrieden. Dafür ist es halt wirklich nur ein reines Git Hosting Tool.

Gitlab kann halt darüber hinaus noch sehr viel mehr, weswegen es durchaus was für eNBeWe sein könnte. Sowas meinte ich z.B. https://gitlab.com/pages/hugo. Das baut die Hugo Webseite mit Hilfe einer .gitlab-ci.yml automatisch bei jedem Commit und deployed sie bei Wunsch auch. Man muss nicht unbedingt Gitlab Pages dafür verwenden, wäre aber auch eine Option.

Zitat von eNBeWe

Ich habe vor einiger Zeit ein CI-System gesucht um mein Blog automatisch mit Hugo zu bauen, wenn ich etwas committe.

Meine Anforderungen waren a) self-hosted b) kein Java c) kein Docker. Im Endeffekt bin ich bei Buildbot gelandet, aber komfortabel ist was anders...

Kennt ihr vielleicht noch irgendwas anderes?

Wie wäre es mit (einem selbst gehosteten) Gitlab? Das hat mittlerweile echt nette CI Funktionalitäten. Damit solltest du das recht komfortabel einrichten können.

Zitat von mainziman

welchen Sinn hat es, wenn eine Site down ist,

daß man die DNS-Einträge aufrecht läßt?

Vermutlich einfach nur Schlamperei Vergisst man sicherlich schnell mal (nehme mich da selbst nicht aus).

Zitat von H6G

Docker bietet ja eigene Repositories an. Warum gibt es docker-compose dann nicht in diesen Repos sondern man muss sich die Binary wgetten oder per pip installieren?

docker-compose stammt ja noch aus der Zeit vor Docker Swarm. Docker Swarm ist ja das, was man heute eigentlich nutzen möchte. Das (alte) docker-compose Tool hat ja im Grunde auch nur standalone Container gestartet. Docker Swarm nutzt ja weiterhin Docker Compose Files, allerdings in Version 3 und neuer, ist nicht komplizierter als docker-compose, bietet aber viel mehr Funktionen. Ich würde docker-compose eigentlich als "deprecated" bezeichnen und verstehe daher schon, dass Docker das nicht im offiziellen Repo anbietet. Einzelne Distros haben das aber noch in ihrem Repo.

Achja, man darf das docker_service Ansible Modul nicht mit dem "docker service" Befehl verwechseln, das hat nichts miteinander zu tun, worüber ich selbst schon sehr unsanft gestolpert bin am Anfang Da braucht es dringend eine Anpassung/Namensänderung.

Die IP(s) und die Email Adresse stehen eh im Mail Header (und das vermutlich für immer. Wer löscht heutzutage noch Emails...). Das scheint auch niemanden zu stören. Oder eben noch nicht ;-).