CLI tool does not work when SSHing into the container due to missing env vars #2057
-
Shlink version3.7.3 PHP version8.2.13 How do you serve ShlinkDocker image Database engineMicrosoftSQL Database version18_18.1.1.1 Current behaviorI deployed Shlink on Azure using the docker image on a Linux alpine-based container. When trying to use the cli tool, no db objects are found: The same image does not have this problem when running locally with the same environment variables. I think it's worth noting that I had to extend the base image of shlink to add SSH support since the selected stack did not support SSH out of the box. Expected behaviorUsing cli tool commands works. How to reproduceSet up shlink on an Azure app service on a Linux based image, with a production MSSQL database. |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 1 reply
-
Very likely related to your custom docker image. Please, provide a docker compose config which uses that image where this can be reproduced. I don't have an Azure account. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick reply! I completely understand that not everyone will be able to reproduce the exact scenario. The custom image also works well locally though. Dockerfile for the image:
contents of ssh_setup.sh
sshd_config
start.sh then starts the ssh service, followed by shlink.
And, finally, the docker-compose to run it locally
So when testing locally, I open a cli in the folder where all these files are, and run:
|
Beta Was this translation helpful? Give feedback.
-
You are stating that this works locally, but in there you are neither using all the SSH stuff, nor running any Shlink command, so you are not doing the same locally and in Azure. That difference is where the problem is. If I have to blindly guess, by SSHing into the container, the working directory gets messed up somehow and Shlink cannot load its configuration, but as mentioned, in those three steps you are not using SSH. |
Beta Was this translation helpful? Give feedback.
-
I suspected it could be due to the SSH setup. |
Beta Was this translation helpful? Give feedback.
-
Nop, that approach works, both locally and in any cloud provider. When SSHing into the container you are at the very least, using a different system user, which is also likely related with the problem. You need to provide some steps to do the exact same thing you do in Azure, but locally, otherwise I won't be able to debug what's going on. |
Beta Was this translation helpful? Give feedback.
-
I will try to do that and comment here when I am able. |
Beta Was this translation helpful? Give feedback.
-
pwd is "Docker!" |
Beta Was this translation helpful? Give feedback.
-
The problem is that when logging-in as root via SSH, it does not inherit the environment variables passed to the container, which makes the You can use this for testing: version: "3"
services:
shlink:
image: shlinktest
restart: always
environment:
- DB_DRIVER=mssql
- DB_HOST=ms_database
- DB_USER=sa
- DB_PASSWORD=Passw0rd!
- DB_PORT=1433
- DEFAULT_SHORT_CODES_LENGTH=8
- IS_HTTPS_ENABLED=false
- SHELL_VERBOSITY=3
- DEFAULT_DOMAIN=localhost:9999
- INITIAL_API_KEY=12345
ports:
- 9999:8080
- 2223:2222
links:
- ms_database
ms_database:
image: mcr.microsoft.com/mssql/server:2019-latest
environment:
ACCEPT_EULA: Y
SA_PASSWORD: "Passw0rd!" Once you SSH into the container with On the other hand, if you open a shell in the container via docker, those will print the expected values. |
Beta Was this translation helpful? Give feedback.
Adding the required env vars to
/.profile
seems to work!Looks like I do need to force it to load by running
source /root/.profile
once in the ssh session. But after that aprintenv
shows that all exported vars are loaded correctly. Testing on Azure it also looks like these are persisted for the user which is nice as I don't need to run it everytime I want to use the CLI.