Beiträge von devsen

Zitat von H6G

das ist kein absoluter, sondern ein relativer Pfad.

Die Inhalte des Volumes werden demnach daher bestimmt, von wo aus du das Docker Compose startest.

Somit bekommst du unterschiedliche Inhalte je nachdem, ob du es manuel im aktuellen Verzeichnis startest, mit systemd startest, oder der Docker Daemon es selber startet.

Ist zumindest meine Vermutung.

Danke für's genaue Hingucken. Das wäre eine mögliche Erklärung!

#bestesForumEver

Update: Hmm.. Ich habe ein paar Docker Container mit --force-recreate neugestartet - jetzt scheint alles wieder zu funktionieren.

Merkwürdig.

Danke für die Unterstützung!

Okay, ich bin ein bisschen "weiter".

Wie gesagt betreibe ich mehrere Wordpress Websites (hinter einem reverse Proxy) mit diesem Konstrukt.

Ich habe festgestellt, dass der Zustand der Seite A eher dem Zustand von Seite B entspricht. Dann habe ich mal ein bisschen getestet und festgestellt, dass die Verzeichnisse (oder Volumes?) scheinbar falsch benutzt oder irgendwie (von Docker?) falsch verlinkt werden. Sorry falls diese Terminologie nicht passend ist, aber ich habe wie gesagt nicht die größte Ahnung und kann nur beschreiben, was ich sehe.

Sprich: Wenn ich in dem lokal gemounteten Volume (also innerhalb der Wordpress Verzeichnisstruktur) von Instanz A eine Änderung mache (z.B. ein die("Test") in die index.php packe), taucht diese auf Instanz B auf.

Das verwirrt mich ehrlich gesagt mehr, als dass es mir weiterhilft. Ich hab das Gefühl, dass die Volumes irgendwie vertauscht wurden..

Allerdings weiß ich nicht, wie das passieren konnte - und auch nicht, wie ich das wieder hinbiegen soll.

Hat jemand eine schlaue Idee?

Hallo zusammen,

ich betreibe eine Website auf einem Root-Server. Grundsätzlich läuft die Website über Docker Compose in zwei Containern:

  1 version: "3"
  2 
  3 services:
  4    mysql:
  5      image: mysql:5.7
  6      volumes:
  7         - ./data/db:/var/lib/mysql
  8      restart: always
  9      environment:
 10         MYSQL_ROOT_PASSWORD: "${DB_ROOT_PASS}"
 11         MYSQL_DATABASE: ${DB_NAME}
 12         MYSQL_USER: ${DB_USER}
 13         MYSQL_PASSWORD: "${DB_PASS}"
 14      container_name: "db_${DOMAIN_CONTAINER_SUFFIX}"
 15 
 16    wordpress:
 17      depends_on:
 18         - mysql
 19      image: wordpress:latest
 20      expose:
 21         - 80
 22      restart: always
 23      volumes:
 24         - ./data/wordpress:/var/www/html
 25         - ./data/php-conf/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
 26      environment:
 27         VIRTUAL_HOST: "${DOMAIN}"
 28         LETSENCRYPT_HOST: "${DOMAIN}"
 29         LETSENCRYPT_EMAIL: "${LE_MAIL}"
 30 
 31         WORDPRESS_DB_HOST: "db_${DOMAIN_CONTAINER_SUFFIX}:3306"
 32         WORDPRESS_DB_USER: ${DB_USER}
 33         WORDPRESS_DB_PASSWORD: "${DB_PASS}"
 34      container_name: "wp_${DOMAIN_CONTAINER_SUFFIX}"
 35 
 36 networks:
 37   default:
 38     external:
 39       name: "${NETWORK_NAME}"

Die Platzhalter werden entsprechend über die .env mit Werten gefüllt, da ich dieses Konstrukt für mehrere Websites benutze. Nun ist es so, dass die Website plötzlich (heute festgestellt, vielleicht schon länger so ) in einem Zustand von vor langer Zeit ist. Ich habe keine Ahnung wieso, möchte aber mich erst mal auf die Wiederherstellung konzentrieren; Die Ursachenforschung kommt später.

Ich habe Backups vom gesamten Dateisystem jeweils der letzten zwei Tage. Nun ist meine Frage: Kann ich den Zustand der Docker-Container damit wiederherstellen? Die Website wird angezeigt, nur die (in Wordpress gepflegten Inhalte, also die DB) scheint im falschen Zustand zu sein.

Wenn ich richtig verstehe, müsste das Volume des Datenbank-Containers ja lokal gemountet und somit unter /data zu finden und damit auch in den Backups enthalten sein. Reicht es, die Inhalte dieses Verzeichnisses wiederherzustellen oder muss ich noch mehr beachten? Docker schreibt ja auch einigen Krempel unter /var/lib/docker.

Ich kenne mich leider in Docker nicht sooooo gut aus bzw. hatte diese Problematik noch nicht, weshalb ich mich über alle sachdienlichen Hinweise freue.

Besten Dank im Voraus und ein verspätetes, aber dennoch frohes und gesundes neues Jahr!

LG, Deniz

Hallo zusammen,

ich möchte dafür sorgen, dass Anwendungen, die in Docker-Containern hinter einem Reverse-Proxy liegen (jwilder/reverse-proxy) auch über eine Weiterleitung von "nicht-www" auf "www" erreichbar sind. Dazu ein paar Gedanken und Fragen...

Gedankenansatz bisher:

• der Docker-Container mit der Anwendung bekommt die Varibale VIRTUAL_HOST mit dem Wert "domain.de" (statt bisher "www.domain.de")
• im gemappten Volume des Reverse Proxy Containers liegt eine Config-File für den VHOST, die im Container dann unter /etc/nginx/vhost/domain.de liegt
  In dieser Config findet eine Weiterleitung statt: rewrite ^/(.*)$ http://www.domain.de$1 permanent;

Davon abgesehen, dass ich mir nicht sicher mit dem Setup bin (bisher hat alles ganz gut out of the box funktioniert, und ich hab es bisher geschafft, das Konstrukt nicht aufbohren zu müssen), wie muss ich im CCP den Domain-Eintrag entsprechend einstellen? Brauche ich einen A-Record, der im Host @ hat und einfach auf die IP zeigt? Bisher habe ich als VIRTUAL_HOST immer www.domain.de angegeben und den Domain-Eintrag dafür entsprechend mit www im Host eingetragen.

Vielleicht ist noch erwähnenswert, dass ich verschiedene subdomains habe, die wiederum auf andere Container (hinter dem Reverse Proxy) zeigen. Diese haben dann entsprechend sub.domain.de als VIRTUAL_HOST eingetragen und werden durch die vom nginx Container generierte Config automatisch ans richtige Zeil weitergeleitet.

Besten Dank im Voraus!

LG, Deniz

Zitat von m_ueberall

Unabhängig vom obengenannten Problem ist es in der Regel nicht wünschenswert, wenn derselbe Inhalt einer Website unter mehreren Domänen verfügbar ist – dies wird von vielen Suchmaschinen bzgl. des abgeleiteten Rankings "bestraft". Es empfiehlt sich aus diesem Grund, alle Aufrufe einer Domäne auf die andere umzuleiten (mittels HTTP-Code 301, "moved permanently").

Danke für den Hinweis. Ich habe es nun so gelöst, dass ich einen kleinen Docker-Container dazu gebaut habe, der die DE-Domain bekommt und nichts anderes tut, als alles an die COM-Adresse weiterzuleiten. Scheint zu funktionieren.

Besten Dank und ein schönes Wochenende!

LG, Deniz

Hallo zusammen,

mein Problem beinhaltet wohl zu viele Buzzwords, als dass ich hier oder bei Google zu aufschlussreichen Ergebnissen komme, deshalb möchte ich es hier versuchen (vielleicht bin ich auch einfach unterbelichtet :P)

Folgendes Szenario: Ich habe hier einen Root-Server und zwei verschiedene Domains angemeldet (nennen wir sie SEITE.de und SEITE.com), die auf die selbe Website zeigen sollen. Beide Domains haben also einen DNS Eintrag mit dem Host www, der als A-Record auf die ebendiese IP zeigt. Auf dem Server läuft ein Reverse-Proxy mit Let's Encrypt Companion (https://github.com/nginx-proxy…ypt-nginx-proxy-companion), der sich bisher eigentlich sehr zuverlässig und automatisch um die Zertifikate gekümmert hat.

Dazu muss man nicht mehr tun, als den Containern der Anwendungen hinter dem Reverse Proxy (in diesem Fall Wordpress) entsprechende Umgebungsvariablen mitzugeben: VIRTUAL_HOST und LETSENCRYPT_HOST.

Nun heißt es in der Doku (https://hub.docker.com/r/jwilder/nginx-proxy) im Abschnitt "Multiple Hosts", dass man genau das durch kommaseparierte Angaben tun kann. Wenn ich den Wordpress-Container neustarte, hat der Letsencrypt Companian aber Probleme, die zweite Domain zu authentifizieren (die erste läuft durch). Die Detailseite zur fehlgeschlagenen Authentifizierung sieht so aus:

{
  "identifier": {
    "type": "dns",
    "value": "www.SEITE.de"
  },
  "status": "invalid",
  "expires": "2020-05-16T07:32:40Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:unauthorized",
        "detail": "Invalid response from http://www.SEITE.de/.well-known/acme-challenge/##################### [###.###.###.###]: \"\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e503 Service Temporarily Unavailable\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody bgcolor=\\\"white\\\"\u003e\\r\\n\u003ccenter\u003e\u003ch1\u003e503 Service Tempora\"",
        "status": 403
      },
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/##########/########",
      "token": "#######################",
      "validationRecord": [
        {
          "url": "http://www.SEITE.de/.well-known/acme-challenge/#####################",
          "hostname": "www.SEITE.de",
          "port": "80",
          "addressesResolved": [
            "###.###.###.###"
          ],
          "addressUsed": "###.###.###.###"
        }
      ]
    }
  ]
}

Wenn ich SEITE.de aufrufe, bekomme ich nur "503 Service Temporarily Unavailabe" vom nginx zu sehen. SEITE.com funktioniert einwandfrei.

Mein Problem ist, ich weiß nicht so recht, wie ich die Ursache des Problems eingrenzen kann.

Daher wollte ich hier mal in die Runde fragen, ob jemand eine Idee hat, wo ich zu suchen anfangen kann.

Vielen Dank im Voraus, ein schönes Wochenende und bleibt gesund

LG, Deniz