Feature/simple custom proxy domain - #189
Conversation
…ion for proxy service
| run docker-compose -p my127ws-logger start | ||
| fi | ||
| run docker-compose -p my127ws-logger up -d --build | ||
| touch .flag-built |
There was a problem hiding this comment.
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.
…and update documentation for certificate handling
…bal configuration
…st numeric precedence
…rray attribute access
…t for mail service path
| run docker-compose -p my127ws-logger start | ||
| fi | ||
| MY127WS_PROXY_DOMAIN="$(ws global config get global.service.proxy.domain)" | ||
| export MY127WS_PROXY_DOMAIN |
There was a problem hiding this comment.
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.
| "home/service/mail/.env", | ||
| "home/service/proxy/.env" | ||
| "home/service/proxy/.env", | ||
| "home/service/tracing/.env" |
There was a problem hiding this comment.
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.
…pport and update documentation
…names are valid and distinct
…ments and project overrides
…alization to use global configuration
| 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 |
There was a problem hiding this comment.
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
| install(); | ||
| } | ||
|
|
||
| putenv('MY127WS_WORKSPACE_BIN='.($_SERVER['argv'][0] ?? __FILE__)); |
There was a problem hiding this comment.
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.
…vironment population
|
|
||
| $workspaceBin = $_SERVER['argv'][0] ?? __FILE__; | ||
| $workspaceBin = realpath($workspaceBin) ?: $workspaceBin; | ||
| putenv('MY127WS_WORKSPACE_BIN='.$workspaceBin); |
There was a problem hiding this comment.
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.
| shift | ||
|
|
||
| cd "$DIR" | ||
| populate_proxy_environment "$service" |
There was a problem hiding this comment.
That preserves the original behaviour: config lookup happens from ~/.my127/workspace
|
@andytson-inviqa is this PR close to what you were suggesting on the other PR? |
|
@andytson-inviqa did you have time to have a look at this PR by any chance? |
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:Changes
Fixes