You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 27, 2019. It is now read-only.
For releases after roughly tag 2.2.0, when we launch vault-ui in our Mesos/Marathon cluster, it seems to be listening on a random port rather than 8000 by default (as is specified in the README). I was able to resolve this by adding the PORT=8000 env variable via our Marathon template, which seems to force the port to 8000. But otherwise, it was spinning up on a random port and then failing our marathon health checks (which assumed 8000)
The text was updated successfully, but these errors were encountered:
On marathon looks like container port must be bound to the same host port, if you leave host port to 0 in marathon app definition (allowing marathon to pick a random port) the server won't respond to requests. As 8000 is not in the list of offered port I had to force let's say 17000 in host and container port and add the var env "PORT=17000" to have it work.
For info it turns out marathon add automatically PORT as var env in the container of the HOST port. Since vault-ui consider this value for an override of default value, docker correctly bind the port but vault-ui start locally on the bad port, host instead of local. That explains why in marathon (1.5.6 at least) we MUST force this PORT var env to be same as bound and host.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For releases after roughly tag 2.2.0, when we launch vault-ui in our Mesos/Marathon cluster, it seems to be listening on a random port rather than 8000 by default (as is specified in the README). I was able to resolve this by adding the PORT=8000 env variable via our Marathon template, which seems to force the port to 8000. But otherwise, it was spinning up on a random port and then failing our marathon health checks (which assumed 8000)
The text was updated successfully, but these errors were encountered: