Score:0

Proxy a website from Docker through Nginx without acting as localhost

co flag

How can I proxy a website from Docker through Nginx without it acting as localhost?

My current setup consists of an Ubuntu host with a couple of Docker containers with exposed ports. The Docker containers are only exposed locally. The exposure on the Internet consists of an Nginx server that proxies the Docker containers to certain subdomains.

In one Docker container I run Wordpress. I pulled it from Docker Hub using this YML file:

version: '3.1'

services:

  wordpress:
    container_name: myapp-cms
    image: wordpress
    restart: always
    ports:
      - 8087:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - /srv/wordpress/cms:/var/www/html

  db:
    container_name: myapp-db
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - /srv/wordpress/db:/var/lib/mysql

This Docker container exposes to internal port 8087 which I then proxy to mysubdomain.mydomain.com. This is the Nginx configuration file:

server {
        root /var/www/mysubdomain.mydomain.com;
        index index.html index.htm index.nginx-debian.html;

        server_name mysubdomain.mydomain.com;

        client_max_body_size 1000M;

        location / {
                # try_files $uri $uri/ =404;
                proxy_pass      http://localhost:8087;
        }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mydomain.com-0003/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomain.com-0003/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
    if ($host = mysubdomain.mydomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;

        server_name mysubdomain.mydomain.com;
    return 404; # managed by Certbot
}

The problem is, that the page (in this case Wordpress) still uses localhost:8087 for every link. This destroys every possibility to click on something and also destroys CSS and JavaScript library loadings.

enter image description here

EDIT 1:

I added following two lines to the wp-config.php:

define('WP_HOME','https://mysubdomain.mydomain.com');
define('WP_SITEURL','https://mysubdomain.mydomain.com');

It successfully loads the setup page right and also adapts the domain name. I can successfully setup WordPress, but as soon as I save the setup (user name, password, email), the browser then loads an empty page. Calling curl -X GET https://mysubdomain.mydomain.com returns an empty response.

Score:1
cg flag

Try setting Site Address and WordPress Address .

  1. Go to Settings >> General
  2. Set WordPress Address (URL) and Site Address using your fqdn

enter image description here

Reference

For more oficial information: WordPress Doc

Socrates avatar
co flag
Thank you for the information. I can only load the initial page, but every link in it leads to `http://localhost:8087/...` which means that login is not possible. I then setup a Docker WordPress locally on my laptop, then set the WordPress Address and the Site Address to `https://mysubdomain.mydomain.com`, and then copied the local database and CMS content to the remote one of the web server. Even though it technically should word, it still does not for some reason. The page does not load at all and `curl -X GET https://mysubdomain.mydomain.com` results in no response at all.
Socrates avatar
co flag
Added **EDIT 1** to my initial post with a configuration that somewhat works for the beginning, but fails later (described above).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.