Skip to content

Feature/simple custom proxy domain - #189

Open
marcomc wants to merge 19 commits into
0.5.xfrom
feature/simple-custom-proxy-domain
Open

Feature/simple custom proxy domain#189
marcomc wants to merge 19 commits into
0.5.xfrom
feature/simple-custom-proxy-domain

Conversation

@marcomc

@marcomc marcomc commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Summary

Make the Global Proxy domain configurable while keeping support limited to one domain at a time.

The default remains my127.site, but it can now be replaced via a normal global Workspace config file:

# ~/.config/my127/workspace/proxy.yml
attribute('global.service.proxy.domain'): dev.example.test
attribute('global.service.proxy.https.crt'): https://example.test/certs/dev.example.test/fullchain.pem
attribute('global.service.proxy.https.key'): https://example.test/certs/dev.example.test/privkey.pem

Changes

  • Added configurable proxy domain and cert/key filenames.
  • Updated proxy/mail/logger/tracing Docker labels to use the configured domain.
  • Generate Traefik tls.yaml at proxy startup instead of hardcoding my127.site cert paths.
  • Refresh mail/logger containers with docker-compose up -d --build so label changes are applied.
  • Added docs for custom proxy domain setup, including public GitHub raw URL examples.

Fixes

  • Fixed Workspace::offsetGet() to return mixed, since attributes can be arrays.
  • Fixed attribute metadata source ordering so latest same-precedence source wins and numeric precedence sorts correctly.
  • Added regression tests for both fixes.

run docker-compose -p my127ws-logger start
fi
run docker-compose -p my127ws-logger up -d --build
touch .flag-built

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proxy domain is now part of the Docker Compose labels.

With the previous flow, after the first build enable only ran docker-compose start. That starts the existing container as-is, so label changes are not applied.

If global.service.proxy.domain changes, mail/logger could otherwise keep stale labels such as mail.my127.site or kibana.my127.site.

Using docker-compose up -d --build keeps the command idempotent while allowing Compose to recreate the container when the labels/config changed.

Comment thread home/service/logger/init.sh Outdated
run docker-compose -p my127ws-logger start
fi
MY127WS_PROXY_DOMAIN="$(ws global config get global.service.proxy.domain)"
export MY127WS_PROXY_DOMAIN

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker Compose resolves ${MY127WS_PROXY_DOMAIN:-my127.site} only from the environment of the docker-compose process.

So setting the value only at a higher command-wrapper level is not enough, because services can also be started through direct paths:

ws install
-> Installer.php
-> ws-service mail enable
-> home/service/mail/init.sh
-> docker-compose

custom command
-> ws-service mail enable
-> home/service/mail/init.sh
-> docker-compose

In those paths, the global service command wrapper is bypassed.
Load/export the configured proxy domain inside the affected service init script immediately before docker-compose runs guarantees that the service has the environment set.

That keeps all entry points consistent and avoids relying on callers to remember to provide MY127WS_PROXY_DOMAIN.

Comment thread box.json
"home/service/mail/.env",
"home/service/proxy/.env"
"home/service/proxy/.env",
"home/service/tracing/.env"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

home/service/tracing/.env already exists in the source tree and is required by home/service/tracing/docker-compose.yml because Compose reads TRAEFIK_NETWORK from that file.

The phar packaging explicitly whitelists hidden .env files, but tracing was missing from that list. As a result, an installed ws could create ~/.my127/workspace/service/tracing/ without .env, causing ws global service tracing restart to fail with an empty TRAEFIK_NETWORK.

sed 's/\[inactive.tracing\]/\[tracing\]/' "${TRAEFIK_CONFIG}.before-tracing-active" > "${TRAEFIK_CONFIG}"
rm "${TRAEFIK_CONFIG}.before-tracing-active"
passthru ws global service proxy restart
passthru "${MY127WS_WORKSPACE_BIN:-ws}" global service proxy restart

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MY127WS_WORKSPACE_BIN is only guaranteed when the call came from bin/workspace.
home/service/tracing/init.sh can still be reached via

~/.my127/workspace/bin/ws-service tracing restart
~/.my127/workspace/service/tracing/init.sh restart

In those cases MY127WS_WORKSPACE_BIN may be unset. The fallback keeps the old behavior

Comment thread bin/workspace Outdated
install();
}

putenv('MY127WS_WORKSPACE_BIN='.($_SERVER['argv'][0] ?? __FILE__));

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gives internal service wrappers a deterministic way to call back into the same ws executable that launched the current command.

Without it, nested calls inside ws-service / service init scripts would fall back to resolving ws from PATH, which can pick a different installed version. That is especially risky during tests, local branch validation, or when multiple ws binaries exist on the machine.

Comment thread bin/workspace

$workspaceBin = $_SERVER['argv'][0] ?? __FILE__;
$workspaceBin = realpath($workspaceBin) ?: $workspaceBin;
putenv('MY127WS_WORKSPACE_BIN='.$workspaceBin);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This keeps nested service calls using the same Workspace executable that launched the top-level command.

ws-service changes into the installed global Workspace directory before resolving global proxy config.

Comment thread home/bin/ws-service
shift

cd "$DIR"
populate_proxy_environment "$service"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That preserves the original behaviour: config lookup happens from ~/.my127/workspace

@marcomc
marcomc marked this pull request as ready for review June 25, 2026 13:15
@marcomc marcomc added the enhancement New feature or request label Jun 25, 2026
@marcomc
marcomc requested a review from coledave June 25, 2026 13:15
@marcomc

marcomc commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

@andytson-inviqa is this PR close to what you were suggesting on the other PR?

@marcomc

marcomc commented Jul 8, 2026

Copy link
Copy Markdown
Contributor Author

@andytson-inviqa did you have time to have a look at this PR by any chance?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant