infinityofspace / jellyfin_alexa_skill

Selfhosted Alexa media player skill for Jellyfin
GNU General Public License v3.0
71 stars 11 forks source link

what is the proper docker invocation? #85

Open artmedlar opened 1 year ago

artmedlar commented 1 year ago

Describe the bug

I am getting "FileNotFoundError: Config file /skill/config/skill.conf not found" errors no matter what i do to start the skill in a docker container.

i am probably doing something obvious wrong, but i cannot determine what from the documentation

To Reproduce

I installed the skill following the docker installation instructions with no problems:

docker pull ghcr.io/infinityofspace/jellyfin_alexa_skill:latest

I created a directory /home/art/jellyfin_alexa and the file /home/art/jellyfin_alexa/skill.conf and the subdirectory /home/art/jellyfin_alexa/data/

and made everything read/writable

when i invoke docker as per the instructions on the wiki: docker run \ -v /home/art/jellyfin_alexa/skill.conf:/var/lib/jellyfin_alexa_skill/config/skill.conf \ -v /home/art/jellyfin_alexa/data:/var/lib/jellyfin_alexa_skill/data \ ghcr.io/infinityofspace/jellyfin_alexa_skill:latest

I get the following error on the command line:

Traceback (most recent call last): File "/opt/venv/bin/jellyfin_alexa_skill", line 33, in sys.exit(load_entry_point('jellyfin-alexa-skill==0.3.1', 'console_scripts', 'jellyfin_alexa_skill')()) File "/opt/venv/lib/python3.10/site-packages/jellyfin_alexa_skill-0.3.1-py3.10.egg/jellyfin_alexa_skill/main.py", lin\ e 311, in main raise FileNotFoundError(f"Config file {config_path} not found") FileNotFoundError: Config file /skill/config/skill.conf not found

Expected behavior

I would expect that the skill would run without this error.

Versions

Yahoo-Mike commented 1 year ago

The error message says it can't find the file /skill/config/skill.conf. It looks like your volume binding is wrong in the docker run command.

The wiki says to use:

docker run \
  -v /path/to/the/skill.conf:/skill/config/skill.conf \
  -v /path/to/persistence/skill/data:/skill/data \
  jellyfin_alexa_skill:latest

The "-v" args passed to docker run "remap" the /skill/config/skill.conf file and /skill/data directory (in the docker container) to your local skill.conf file and data directory respectively.

So I think you should be using:

docker run \
  -v /home/art/jellyfin_alexa/skill.conf:/skill/config/skill.conf \
  -v /home/art/jellyfin_alexa/data:/skill/data \
  jellyfin_alexa_skill:latest
SedyBenoitPeace commented 1 year ago

I will ask here to avoid opening a new issue cause probably is related.

I'm on Windows (that as far as I know is not supported), how can I check if the docker container is properly started? From the log, everything seems fine, and if I try to put the address into the browser (e.g localhost:1456) I get "connection refused", also if I open ports and whatnot on my router.

Of course, I have already some other containers in docker that works on "localhost", but I guess it can depend on how the image is configured, but I can see that it is listening on 0.0.0.0 so it should be fine.

I have a reverse proxy with Nginx but I get "Bad Gateway" when I tried to access the domain associated with the localhost instance. I have SSL and everything in place, I just need to link the jellyfin account through the skill on the app but again I can't understand if the web service is correctly online.

From the docker terminal, I can ping the Jellyfin instance (also this one behind SSL and custom domain).

Here is the log when I start the docker image:

INFO:Cloud skill version: 0.3.1 Current skill version: 0.3.1 [2022-10-17 15:41:51 +0000] [1] [INFO] Starting gunicorn 20.1.0 [2022-10-17 15:41:51 +0000] [1] [INFO] Listening at: http://0.0.0.0:1456 (1) [2022-10-17 15:41:51 +0000] [1] [INFO] Using worker: sync [2022-10-17 15:41:51 +0000] [10] [INFO] Booting worker with pid: 10 [2022-10-17 15:41:51 +0000] [11] [INFO] Booting worker with pid: 11

Any suggestion on debugging?

Yahoo-Mike commented 1 year ago

@SedyBenoitPeace To check if the docker container is running, you can use the docker command docker ps. That will tell you the status of all the containers you are running. Status should read "healthy".

You can also check if your Alexa endpoint is running by opening https://my.skill.endpoint/healthy in a browser. Where "my.skill.endpoint" is the endpoint you set up for "skill_endpoint" in the skill.conf file. If the skill is working, it should return a webpage with just one word: "OK".

The Alexa endpoint needs to be exposed on the internet - so that Amazon's Alexa servers can see it. So make sure you can ping "my.skill.endpoint" on a device outside your local LAN. Maybe try it on your mobile phone (that's not connected to your wifi). Then test that the "healthy" webpage loads correctly on a device that's outside your local LAN. If you can't ping, then maybe your alias (CNAME) record is incorrect. If you can ping but can't see the "healthy" page, then your nginx or firewall configuration is incorrect.

You also need to make sure that port 1456/tcp is open on your local firewall (on the Windows PC running the Alexa skill). That might account for the "connection refused"/"bad gateway" message. Check your firewall logs for any "access denied" or "dropped" warnings.

Check your nginx logs for errors too. Maybe the virtual host is misconfigured. Sorry, I'm not sure where the logs are located - I use Apache on Ubuntu.

SedyBenoitPeace commented 1 year ago

@SedyBenoitPeace To check if the docker container is running, you can use the docker command docker ps. That will tell you the status of all the containers you are running. Status should read "healthy".

You can also check if your Alexa endpoint is running by opening https://my.skill.endpoint/healthy in a browser. Where "my.skill.endpoint" is the endpoint you set up for "skill_endpoint" in the skill.conf file. If the skill is working, it should return a webpage with just one word: "OK".

The Alexa endpoint needs to be exposed on the internet - so that Amazon's Alexa servers can see it. So make sure you can ping "my.skill.endpoint" on a device outside your local LAN. Maybe try it on your mobile phone (that's not connected to your wifi). Then test that the "healthy" webpage loads correctly on a device that's outside your local LAN. If you can't ping, then maybe your alias (CNAME) record is incorrect. If you can ping but can't see the "healthy" page, then your nginx or firewall configuration is incorrect.

You also need to make sure that port 1456/tcp is open on your local firewall (on the Windows PC running the Alexa skill). That might account for the "connection refused"/"bad gateway" message. Check your firewall logs for any "access denied" or "dropped" warnings.

Check your nginx logs for errors too. Maybe the virtual host is misconfigured. Sorry, I'm not sure where the logs are located - I use Apache on Ubuntu.

Hey Mike, thank you for the answer and sorry for being a total noob on the "docker ps", I should've known :)

Anyway, I believe that the problem is at container level and not with the endpoint (although this is not the first skill that I'm trying to configure and I know the troubles with https and so forth and so on).

I noticed, on the docker ps command, that although windows doesn't state "healthy" in the status column but just the runtime (like up from 16 hours, it is the same thing for other containers that I have on my laptop), that in the "ports" section the jellyfin_alexa_skill container hasn't anything, while another one that I have has something like this "0.0.0.0:80-81 -> 80-81/tcp" that I guess you know already what it means without me to explain.

I guess that the jellyfin skill should have something like this "0.0.0.0:1456 -> 1456/tcp" but considering that it hasn't probably the container is not running correctly, any tip on how I can debug here? Is there a log for the container inside the docker container terminal?

Cause I know that the "connection refused" happens also for localhost so it isn't definitely a firewall problem (although I opened the port on both router and firewall).

Again thank you for your help and looking forward for your reply.

Yahoo-Mike commented 1 year ago

To access the docker logs you need the _containerid, which you can find using the docker ps command. Then the command is: docker logs container_id (substituting the actual container_id in the command). For more detail, including timestamps: docker logs --details -t container_id .

The port mapping is configured in the "-p" argument of the docker run or docker create command.

If you are using docker-compose, the port mapping is defined in the *.yml file.

Maybe also double-check that you have the latest version of docker for Windows.

SedyBenoitPeace commented 1 year ago

To access the docker logs you need the _containerid, which you can find using the docker ps command. Then the command is: docker logs container_id (substituting the actual container_id in the command). For more detail, including timestamps: docker logs --details -t container_id .

The port mapping is configured in the "-p" argument of the docker run or docker create command.

If you are using docker-compose, the port mapping is defined in the *.yml file.

Maybe also double-check that you have the latest version of docker for Windows.

Mike, thank you again, and also here I should've been better to troubleshoot on my own but at least I knew and understood that the container wasn't up on localhost :D

So basically what you wrote about "-p" turned up the light in my mind and I remembered how to use "docker run" (the other containers that I have are with compose where ports are defined in the .yml as you said), so I ran the container again with the "-p" and now it works!

I blindly followed the documentation and I missed this small but important detail.

And also the reverse proxy works! Now I can link the skill from the Alexa App from my account (so apparently also the https is working) but the skill still doesn't work! I suspect it is something with the endpoint not publicly available despite the account linking goes fine, I guess I have to find out and debug on Amazon Console.

Thank you again!