Why not NGROK_PORT?
jnovack opened this issue · comments
# Set the point.
if [ -n "$HTTPS_PORT" ]; then
ARGS="$ARGS `echo $HTTPS_PORT | sed 's|^tcp://||'`"
elif [ -n "$HTTP_PORT" ]; then
ARGS="$ARGS `echo $HTTP_PORT | sed 's|^tcp://||'`"
elif [ -n "$APP_PORT" ]; then
ARGS="$ARGS `echo $APP_PORT | sed 's|^tcp://||'`"
fi
They all do the same thing. Why not NGROK_PORT? Every other variable uses NGROK_?
Clearly it would need to be an addition, but it would standardize things.
Yes, but I'm really thinking to drop all environment variables. Marking them as deprecated for now as I see little reason to use them over using the command-line. The only advantage I see it the ability to use Kubernetes secrets directly without setting up a shell script.
Why do you prefer environment variables?
If I'm on my desktop, running tests, in development, I HATE environment variables, everything needs to be on the command line so I can see what broke. However, when doing any deployments, environment variables are so much more preferred.
In deployments, every machine runs the same docker image, with the same command line and all variables are changed with the environment. When I run a new image on a box, all I have to do is name the image, and point to the customized environment file. Done. Easy button.
Every server gets the following, no customized command lines, easy deployment.
# docker run --env-file ~/ngrok.env wernight/ngrok
I strongly encourage keeping the environment variables, if for no other reason than to provide someone a choice. You can make the primary entry into the application command line, but please keep the option of environment variables.
Now, this image is hardly deployed, but the fact it is set up for those advanced features (environment variables, exposed ports), makes you ahead of the game and a good example of a custom package.
No worries I'm not planning to remove them soon, just want to avoid people relying on them first and understand to strong needs.
Have you looked into using docker-compose.yml to perform the same thing? I have such a file on almost all my projects for development. You can also use environment variable in it.
I do use it, when appropriate, and I'm not against it.
My OCD is against having:
- NGROK_AUTH
- NGROK_SUBDOMAIN
- NGROK_PROTOCOL
- NGROK_DOMAIN
- NGROK_USERNAME
- NGROK_PASSWORD
- HTTP_PORT
Ha ha. Fair point.
I too strongly recommend against removing environment variable support. One of the great things about running docker is you can encapsulate all configuration in an environment file, which I have always used when running ngrok in docker.
Ok
Updated README and note that NGROK_PORT is supported.
Thank you kindly. I shall name a Pokémon after you.