added Dockerfile

[heywoodlh]

Assumes that you will build the image from the root directory of the repository

i.e. (using my fork/branch as an example)

git clone -b dockerfile https://github.com/heywoodlh/Spodcast 
cd Spodcast &&\
    docker build -t heywoodlh/spodcast -f docker/Dockerfile . 

Then you can run the container like this:

docker run -it --rm -v /tmp/spodcast:/spodcast heywoodlh/spodcast -c /spodcast/html/spodcast.json --root-path /spodcast/html --credentials-location /spodcast/creds.json -p -l /spodcast/spotify.rc

---

Related, I've also created a Github Action to build a multi-architecture image and push it to Docker Hub: https://github.com/heywoodlh/actions/blob/master/.github/workflows/spodcast-buildx.yml

If you merge this pull request I will update my Action to point to your repo and continue building images at heywoodlh/spodcast on Docker Hub and I'm happy to keep building them on a weekly basis on my account -- but it'd be awesome if you had an official, cross-architecture image for Spodcast. Feel free to just take my Github Action and implement it here (or I can create a PR for that as well).

Let me know if that makes sense or if I can be of any help. Thanks for a great project!

[heywoodlh]

May want to add LABEL maintainer=Yetangitu here.

[Yetangitu]

As said, I don't use Docker - the size of the image produced by your Dockerfile being one of the reasons for not doing so - so I; m not the one to ask whether this is the way to go. If it works for you I guess it'll work for others who want to use it? Fine by me, I can merge it. Go ahead and create the PR for the GH Action as well (or merge it in this PR), that being another thing I don't use - I tend to use my private repo and sort-of shun "the cloud" (i.e. someone else's computer) for most things.

[heywoodlh]

Sure, that's fair -- I could probably do more to squash the image and make it much smaller. I'll play around with it and see if I can.

[heywoodlh]

In regard to creating a PR for my Github Action, it relies on some secrets to be created -- namely $DOCKERHUB_USERNAME and $DOCKERHUB_TOKEN for the Action to work. So if I were to create a PR for it you would have to add those secrets for your own Docker Hub account -- which I assume you do not have as you are wary of using someone else's computer (which I completely understand).

So perhaps it would be best to keep my action in my own repo and then if someone wants to use Docker you can point them to my Docker Hub image?

However, if you are willing to create those secrets and a Docker Hub account I would be more than happy to PR my Github Action.

[Yetangitu]

I'll look into creating the docker-image locally and push it to the repo, that'd get around all these cloudy problems. If this turns out to be too much of a hassle we'll take one of those other routes. I will hold off merging this PR until I know what step to take next, right now I'm at the stage of apt install docker on one of my build hosts (i.e. Proxmox-hosted containers).

[Yetangitu]

I built a smaller image (using bitnami/minideb:bullseye) which seems to work just like the one created using your Dockerfile. It also shared the same problems in that it can not read the username/password from the command line:

$ sudo docker run spodcast_0.3.5-full -c /tmp/spodcast/spodcast.json --root-path /tmp/spodcast --max-episodes 0 -p https://open.spotify.com/show/3YMFdNqoNtVcCBKSUvjr8n
Username: Traceback (most recent call last):
  File "/usr/local/bin/spodcast", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.10/site-packages/spodcast/__main__.py", line 39, in main
    args.func(args)
  File "/usr/local/lib/python3.10/site-packages/spodcast/app.py", line 13, in client
    Spodcast(args)
  File "/usr/local/lib/python3.10/site-packages/spodcast/spodcast.py", line 54, in __init__
    Spodcast.login()
  File "/usr/local/lib/python3.10/site-packages/spodcast/spodcast.py", line 100, in login
    user_name = input('Username: ')
EOFError: EOF when reading a line

...nor can it read it from a text file:

$ sudo docker run spodcast_0.3.5 -c /tmp/spodcast/spodcast.json --root-path /tmp/spodcast -p -l /home/frank/spotify.rc
Can not read username/password file /home/frank/spotify.rc

If it were to succeed in logging in it would still have problems storing data on the host since the host filesystem is not available in the container. This can be solved using a bind mount but all of these things require root permissions - as does running Docker itself. Given that all Linux distributions have a working Python environment it is questionable as to whether there is much benefit in running Spodcast through Docker, or am I missing something here?

Anyway, I'll experiment a bit with bind-mounting an outside directory into the container so that Spodcast can do something useful.

[heywoodlh]

I rebased the image with Alpine from Debian and manually installing dependencies has reduced the image size from around 300+ MB to around 75MB. I think that's probably the smallest I can get it.

---

In regard to avoiding cloudy stuff you can install buildx locally and then use QEMU to build multi-arch images. And since the repo is here on Github I think you could probably use Github's container repo to host the images and avoid Docker Hub.

[Yetangitu]

Now it seems to work:

FROM bitnami/minideb:bullseye
RUN install_packages python3 python3-pip python3-setuptools

COPY . /app
WORKDIR /app
RUN pip3 install .
VOLUME ["/data"]
WORKDIR /data

ENTRYPOINT ["/usr/local/bin/spodcast"]

$ sudo docker run -v /tmp/spodcast:/data spodcast_0.3.5 -c /data/spodcast.json --root-path /data -p -l spotify.rc
frank@build:~/Projects/DOCKER/spodcast-0.3.5$ ls -al /tmp/spodcast/
total 676
drwxr-xr-x  2 frank frank   4096 Feb 19 17:10 .
drwxrwxrwt 13 root  root  638976 Feb 19 17:13 ..
-rw-r--r--  1 root  root   19339 Feb 19 17:10 .index.php
-rw-r--r--  1 root  root     336 Feb 19 17:13 spodcast-cred-deadbeefcafebabedeadbeefcafebabe.json
-rw-r--r--  1 root  root     309 Feb 19 17:10 spodcast.json
-rw-r--r--  1 frank frank     40 Feb 19 17:01 spotify.rc

Image size is 141MB.

[heywoodlh]

Whoops, I wrote my comment before I saw your comment that you rebased with bitnami/minideb:bullseye.

I think if we go with my Alpine version it reduces it the most. Let me know what you think, I'm happy to go with either one.

[Yetangitu]

How does your image deal with hosting Spodcast-related data? What about the problem I encountered logging in? The bind-mounted version I just tested seems to work, are there other ways of doing this that you know of?

[Yetangitu]

I don't care whether it is Alpine or Debian, whatever works best. Seeing how Docker seems to work I assume users will save the most space by using a base image which is used by many other images - are there statistics on this to be found anywhere?

[heywoodlh]

I think that makes sense to specify the /data directory volume so as to give users of the container a standardized direction for mounting data for Spodcast to use.

In regard to your question regarding mounting, I don't really seem to have a problem with my image in its current state -- here's how I'm running it on my server with the original, larger Debian based image (and it seems to work):

docker run -it -v /opt/spodcast/data:/spodcast --rm heywoodlh/spodcast:latest -c /spodcast/spodcast.json --max-episodes 10 --log-level info 'https://open.spotify.com/show/4rOoJ6Egrf8K2IrywzwOMk'

---

With your question on which image to base it on, I like Bitnami images and they are a verified publisher and as such are reliable but the python:3-alpine image I am using is coming from the official Docker image library. When I can I prefer using official images from Docker library.

However, one of the reasons I went with the Debian based Python image is because I have found it's a bit easier to maintain compared to Alpine (since Alpine comes with so little there is a lot that can be missing and can add extra steps for installing).

So if you stick with Debian I think it'd be easier to maintain if changes are introduced down the road but with the Alpine image it will be smaller and it's coming from an official Docker Hub image.

[heywoodlh]

My personal opinion: use the official Python Alpine image.

I've added 9519761 with the volume mount you specified and won't add anything more to the Dockerfile -- feel free to add more if you feel like.

[Yetangitu]

OK, if you can add a description (in README.md) of how to run the Docker image (w.r.t. it being interactive, needing a ptty, the bind mount and where to get it) I'll do some testing and merge if it all seems to work as intended.

[heywoodlh]

I totally can update the README with those instructions. Do you want me to write the instructions assuming the user will build the image locally?

[Yetangitu]

Add build instructions as well as a pointer to prebuilt images I'd say, just like the prebuilt pip install vs install from source.

[heywoodlh]

I added the instructions in the README -- hopefully the location made sense -- feel free to change anything.

[Yetangitu]

I'll add a LABEL with some related information to the Dockerfile