Tutor MFE seems to use outdated caddyfile

Development
1

I’m working on setting up tutor to support reverse proxying MFEs hosted on the host machine by using caddy reverse proxies.

On the branch I’m working on, I have updated the tutor mfe dev config to only have 1 mfe container and utilize caddy similarly to how tutor local handles it.

I also updated tutormfe/templates/mfe/apps/mfe/Caddyfile to have

reverse_proxy host.docker.internal:1999 {
    header_up X-Real-IP {remote_host}
}

and tutormfe/patches/local-docker-compose-dev-services to have

caddy:
  [...]
  extra_hosts:
    - host.docker.internal:host-gateway

With this in place, I have been able to access the authn MFE when it is running locally on my host machine using npm start

I recently rebased my changes on latest tutor nightly and tutor mfe nightly, and was able to get back to where I was before the rebase (able to access authn MFE when running locally on host with npm start)

I then continued on to try to modify the caddyfile, but none of my changes seemed to take effect.

The most recent thing I tried was fully removing the extra-hosts from local-docker-compose-dev-services and fully removing the reverse_proxy from the Caddyfile, but even after

  • reinstalling both tutor and tutor-mfe via pip install -e . in their respective directories
  • running tutor config save
  • running tutor images build all --no-cache
  • running tutor dev launch

I’m still able to access the authn MFE running locally through the reverse proxy.

I’m very confused as to why the caddy config is seemingly not updating. Any suggestions for things I should try to help diagnose this would be amazing!

Thanks in advance!

2

@brian.smith The first thing I do when Tutor gets in a weird state is to go into "$(tutor config printroot)/env/" and make sure that rendered files look the way I’d expect them to.

Since you’re doing tutor config save, I imagine that everything will look as expected in your env, but I think it’s worth trying just in case.

Assuming everything looks right in your env, the next guess I have is that your browser is caching redirects, so perhaps trying in a different browser would yield a different result. That also seems unlikely, though, given that you’re changing reverse_proxy directives, not redirect directives…

3

It does seem the env is being updated correctly. Searching for extra_hosts turned up nothing, as did searching for reverse_proxy host.

After re-adding the lines to the Caddyfile and local-docker-compose-dev-services and running tutor config save they did show up in my search of the env directory.

Edit: Also tried using Firefox, Chromium, and Flatpak Google Chrome - same issue on all browsers.

4

@brian.smith sanity check: if you add an egregious syntax error to the Caddyfile, and then tutor config save && tutor images build mfe && tutor dev reboot, does Caddy still manage to run?

5

I tried adding SUPER TERRIBLE SYNTAX ERROR to local-docker-compose-dev-services and docker compose failed as expected.

I tried replacing the last } in the caddyfile with SUPER TERRIBLE SYNTAX ERROR and when running reboot I did see

Error: adapting config using caddyfile: /etc/caddy/Caddyfile:108 - Syntax error: Unexpected token 'ERROR', expecting '}'

but once everything was up and running the reverse proxy seemed to still be working (local.overhang.io:1999 was still loading the npm start version of the authn MFE.

I thought that might imply it’s pulling from somewhere else, but after doing a full search of my tutor and tutor-mfe workspace I only found the one instance of host.docker.internal (in tutormfe/templates/mfe/apps/mfe/Caddyfile)

6

Hm, maybe there is OS-level caching of the local.overhangio.io:1999 -> localhost:1999 association going on. Try clearing your DNS cache?

edit: and restarting the Docker daemon?

7

After digging into the docs a bit I think I have a better sense of what’s going on.
From Open edX development — Tutor documentation

local.overhang.io (a convenience domain that simply points at 127.0.0.1)

“points at 127.0.0.1” links to https://dnschecker.org/#A/local.overhang.io, which shows DNS servers around the world resolving local.overhang.io to 127.0.0.1