Can a container make an https request to whatever in orb is providing the SSL proxy for web containers?

[pjv]

I hope the title of this discussion isn’t an XY thing.

The problem I am trying to solve is a long-standing issue in Wordpress local development environments where you define multiple services in a compose file (db, wordpress, nginx or apache proxy, etc). When run in this manner, the wordpress container cannot make what it calls “loopback connections” which are the basis of some of its behaviors, including the Wordpress REST API.

The symptom is that with the stack running you go to the WP “Site Health” page and see this:

This issue has been a problem in my local dev stack for years under Docker Desktop and I was hoping orbstack’s container domain names and HTTPS proxy would let me finally solve it, but so far I have failed.

I’ve tried defining an extra_hosts for the container that is making those “loopback” requests pointing the hostname that I'm using to connect to the site in my browser (e.g. myhost.local which I have defined using the label dev.orbstack.domains=myhost.local for the nginx service in my compose file) to the internal docker IP address of the nginx container. I’ve tried pointing it to the IP of the host (my mac) - both its LAN IP as well as its internal docker gateway IP. None of these manipulations have worked. I see the same error in the screenshot above and if I shell into the wordpress container making the requests and try to curl https://myhost.local it gives me the same error.

I was thinking that if a container could make https requests directly to the orb reverse proxy I could try sticking that host’s IP into the extra_hosts definition for myhost.local.

[slinorb]

@pjv Can you provide a bare minimum docker compose file which can reproduce the issue? We can look into it and see how to solve it.

[pjv]

@slinorb I knew that was coming. My stack has a lot of “stuff” in it and 90% of it will not be relevant so i’ll have to grind away a bit to pare it down. I’ll post here when i have it.

[slinorb]

@pjv Thanks. Take your time. I will search for some Wordpress docker compose files to see whether they can reproduce the issue.

[pjv]

you can look at https://github.com/wodby/docker4wordpress because my stack is a heavily customized (now more customized for running under orbstack with container domain names and https proxy) derivation from there.

[pjv]

@slinorb as a quick check I just followed the instructions here for bringing up the wodby “Vanilla WordPress” stack (my own is based on their “Mount my codebase” pathway) which is pretty simple and it demonstrates the same issue on the Site Health page.

(As I mentioned above my customized stack now uses orbstack container domain names and https proxy and the wodby vanilla wordpress stack does not. But it still has the same issue. I’ll still work on a stripped down version of my compose file.)

[slinorb]

@pjv Brought up the "vanilla Wordpress" stack and reproduced the issue. Do not worry about stripping down your compose file.

[slinorb]

@pjv For vanilla version just set PROJECT_BASE_URL=docker.orb.local in .env file and do a docker compose down to remove old reference. The site health should show "Good". Using https may be a bit different and may need to know your setup.

[pjv]

@slinorb I’m able to replicate what you reported using PROJECT_BASE_URL=docker.orb.local. After some messing around I am able to access the site at http://docker.orb.local and also the admin site health page at http://docker.orb.local/wp-admin/site-health.php and I no longer see the loopback and REST API errors in that case.

Unfortunately, that fix does not map to my customized compose stack where I have eliminated the traefik reverse proxy and the PROJECT_BASE_URL is not used in my compose file. Also, a big part of what I am really hoping to accomplish is connecting via orbstack’s https proxy.

I think I can reproduce a close enough facsimile to my stack by making a few changes to the vanilla compose and .env file (the main thing in my stack that would make it complicated for you to reproduce is that I am running against an external docker named volume with the wordpress files on it but I am 99.9% sure that’s not relevant to my issue here so the “vanilla” stack that has the wordpress files in the php container should be fine for these purposes). I’ll try to post a modified compose and env file here today and will tag you.

[pjv]

@slinorb ok, that was pretty simple, actually. I’ve modified the wodby vanilla wordpress stack as follows:

In the .env I’ve set PROJECT_BASE_URL=mysite.local

And then I’m using this simplified compose file:

services:
  mariadb:
    image: wodby/mariadb:$MARIADB_TAG
    container_name: "${PROJECT_NAME}_mariadb"
    stop_grace_period: 30s
    environment:
      MYSQL_ROOT_PASSWORD: $DB_ROOT_PASSWORD
      MYSQL_DATABASE: $DB_NAME
      MYSQL_USER: $DB_USER
      MYSQL_PASSWORD: $DB_PASSWORD

  php:
    image: wodby/wordpress-php:$PHP_TAG
    container_name: "${PROJECT_NAME}_php"
    environment:
      PHP_MAIL_MIXED_LF_AND_CRLF: On
      PHP_SENDMAIL_PATH: '/bin/busybox sendmail -t -i -S mailhog:25'
      DB_HOST: $DB_HOST
      DB_USER: $DB_USER
      DB_PASSWORD: $DB_PASSWORD
      DB_NAME: $DB_NAME
      PHP_FPM_USER: wodby
      PHP_FPM_GROUP: wodby
    volumes:
    - ./:/var/www/html:cached

  crond:
    image: wodby/wordpress-php:$PHP_TAG
    init: true
    container_name: "${PROJECT_NAME}_crond"
    environment:
      CRONTAB: "0 * * * * wp cron event run --due-now --path=/var/www/html"
    command: sudo crond -f -d 0
    volumes:
    - ./:/var/www/html:cached

  nginx:
    image: wodby/nginx:$NGINX_TAG
    container_name: "${PROJECT_NAME}_nginx"
    depends_on:
    - php
    environment:
      NGINX_STATIC_OPEN_FILE_CACHE: "off"
      NGINX_ERROR_LOG_LEVEL: debug
      NGINX_BACKEND_HOST: php
      NGINX_VHOST_PRESET: wordpress
    volumes:
    - ./:/var/www/html:cached
    labels:
    - dev.orbstack.domains=mysite.local

  mailhog:
    image: mailhog/mailhog
    container_name: "${PROJECT_NAME}_mailhog"
    ports:
      - 8025:8025
      - 1025:1025
    labels:
    - dev.orbstack.domains=mailhog.local

I can connect to the site with https://mysite.local (which is excellent - already a big step forward from Docker Desktop).

…and when I go to https://mysite.local/wp-admin/site-health.php, I am seeing the familiar REST API and loopback request errors.

The requests that are creating those errors are coming from the php container. If you shell into it (make shell) and try to curl https://mysite.local you will see that you get the same error that is reported in the Site Health page. My naive idea is that since I can connect to https://mysite.local on my host, if I could make the php container connect to the same “place” that I am connecting to on my mac (whatever place that orbstack is supplying that SSL proxy in front of these running containers), then it should all work. But that’s me treating however orbstack is proxying those requests as a black box and I have no idea how that magic is actually working.

[slinorb]

The OrbStack tls proxy can not be used by the containers for now. The feature will be implemented later.
Here is a workaround for your setup:

• Save and run the following script to create a self-signed certificate and ssl conf file for nginx

#!/usr/bin/env bash

if [[ -f .env ]]; then
    source .env
fi

mkdir -p ssl

openssl req -subj "/CN=${PROJECT_BASE_URL##*/}" \
    -x509 -newkey rsa:4096 -nodes -days 365 \
    -keyout ssl/key.pem -out ssl/cert.pem \
    -days 365

cat > ssl.conf <<EOF
server {
  listen 443 ssl;

  ssl_certificate /etc/nginx/ssl/cert.pem;
  ssl_certificate_key /etc/nginx/ssl/key.pem;

  root /var/www/html;
  include preset.conf;
  include defaults.conf;
}
EOF

• Append the following two lines to the volumes for nginx container:

    - ./ssl:/etc/nginx/ssl
    - ./ssl.conf:/etc/nginx/conf.d/ssl.conf

[pjv]

Thanks @slinorb I understand your work-around and appreciate not having to write that code myself (or try to prompt an LLM to write it).

For sure making the TLS proxy available to containers would be an extremely elegant solution. Looking forward to when that happens.

[pjv]

FWIW for anyone following along, generating the self-signed certs using openssl as in @slinorb’s script works but it’s a little less than perfect if you happen to be using some flavor of chrome as a dev browser. It will begrudgingly allow you to use the cert but it doesn’t like it and it times out your acceptance of it frequently (requiring you to click through a couple pages to re-accept what you already accepted) and pukes on CORS issues with many ajax requests.

I installed Filo Sottile’s mkcert, ran mkcert -install, and then modified the script like this:

#!/usr/bin/env bash

if [[ -f .env ]]; then
    source .env
fi

mkdir -p ssl

mkcert -key-file ssl/key.pem -cert-file ssl/cert.pem "${PROJECT_BASE_URL##*/}"

cat > ssl.conf <<EOF
server {
  listen 443 ssl;

  ssl_certificate /etc/nginx/ssl/cert.pem;
  ssl_certificate_key /etc/nginx/ssl/key.pem;

  root /var/www/html;
  include preset.conf;
  include defaults.conf;
}
EOF