Is docker of NZBget been updated to NZBGet 13 yet?

NAS · July 24, 2014

checkout

https://github.com/gfjardim/docker-nzbget/blob/master/edge.sh

will show you exactly what it is doing

neilt0 · July 24, 2014

This suggests development version?

svn://svn.code.sf.net/p/nzbget/code/trunk

No-one should be using that. The testing version is what people use.

NAS · July 24, 2014

see line 11

then see this for useful tags

http://sourceforge.net/p/nzbget/code/HEAD/tree/tags/

neilt0 · July 24, 2014

I looked at both and still have no idea. I'm not a coder. Can you just tell me?

I mean, I love a good riddle and everything...

butlerpeter · July 24, 2014

neil - looking at what gfjardim has done - like he says if you pass 13.0 to the edge parameter it will checkout and build the version of the source that is tagged "13.0" - the current stable release.

If you pass "1" to the parameter it checks out the main trunk which, as you suspect could be in a state of developmental flux.

If hugbug were to tag the testing releases then passing, for example, "14.0-rxxxx" to the edge parameter would get that version of the source. Unfortunately I don't think that will work as I can't see any evidence of tags for testing releases.

I think what could be needed is another environment variable that is passed to the container to specify the revision of code to checkout.

Then the logic would be along the lines of (pseudo code cos my bash scripting skills aren't up to much)

if (EDGE == "1" or REVISION != "")
  SVN="svn://svn.code.sf.net/p/nzbget/code/trunk"
else
  SVN="svn://svn.code.sf.net/p/nzbget/code/tags/${EDGE}"

...

if (REVISION != "")
  svn checkout -r ${REVISION} ${SVN} /tmp/nzbget-source
else
  svn checkout ${SVN} /tmp/nzbget-source

I might have a go at coding that up and see what I get - unless gfjardim does it first

neilt0 · July 24, 2014

OK, I'm surprised this is so tricky. How did overbyrn do it?

He managed to put both stable and testing in his plugin.

butlerpeter · July 24, 2014

It's not that tricky really - it's just a case of working around the way docker works.

For his nzbget plugin, I believe overbyrn took the latest released source packages (that are downloadable from nzbget.net) and built them. Or he may have done something similar to we've just discussed and checked out the relevant branches/revisions from the source repository. Either way he had 2 sets of source code that he compiled and build slackware packages from.

The problem is that there aren't any pre-built packages (of the latest nzbget) that are compatible with the environment in the docker container. Because of that somebody has to build it and make it available - as overbyrn did for his plugin.

The changes gfjardim has made to the docker container take that step away. Now the container will build nzbget itself, it just needs to be told what to build. This removes the reliance on somebody else to keep something updated. To move to a new version you'll just stop the container, remove the instance of it and then run it again with the new version specified.

neilt0 · July 24, 2014

That sounds awesome. I will start playing around with that soon. Need to install 6.x first, I guess... [emoji16]

NAS · July 24, 2014

someone clear this up for me?

..

does this not result in a big bunch of interim containers and one randomly named final container or does the fact the we set --name="nzbget" do something clever in docker land

gfjardim · July 24, 2014

Nice work. Looks like Debian has accepted the par2 patches upstream hence why you no longer need to patch the source (that was a complete pain and often caused clashes in a nomral Deb install).

A few questions for my own sanity:

So once the user checks out and runs this they get v12 stable by default. However if they set the EDGE variable this passes in a environmental variable into the docker. When edge.sh runs (as defined in the dockerfile) its sees this variable and checks out the relevant code, compiles it and installs it.

I have not run this yet (as I am not at docker) but I have a question:

does this not result in a big bunch of interim containers and one randomly named final container or does the fact the we set --name="nzbget" do something clever in docker land

This is a common misunderstanding on how docker works. In simple words:

Make a small linux image that have the kernel and the base utilities is painful, so docker invented the "base images". But "base images" have a very small set of tools, so, to allow the user to configure the "base image" to their needs, docker relies on "images". "Images" normally picks a "base image" and applies to it some changes, those that are described in the Dockerfile script. This is the point that many of us don't understand very well.

Each command in the Dockerfile generates a intermediate container, that will be committed to the image if it runs successfully. This is why docker is a development tool: if anything goes wrong at some point of the Dockerfile script, you just have to fix it and rebuild the image. Docker will automatically resumes the build from the point of change (it makes a diff and resume the script just before the new code). The result is the merge of those intermediate containers in a final build.

So, now that we have our image, we have to run it. Each time you run a image (docker run), a new container is created. That container will not be automatically merged into the "image", unless you told it so (docker commit). Otherwise many may think, containers are NOT read only. They are a kind of "pre-images" that can be run (docker start) with a set of different commands from the "image", and generate a set of files that will be permanent to that container, but volatile towards the "image".

Now, responding your question: the --name operator will do just that, name the container created by the "docker run" command. We use this to facilitate our lives. We could create a randomly named container each time, but it would be almost impossible to track that container to the app it carries.

About the EDGE thing, this will impact the way the container will run on the first time. If you don't set the EDGE variable, the container will be created based on the image, plus those commands that exist on the "firstrun.sh" and "nzbget.sh" scripts. If you set EDGE, the container will be impacted by those commands too. But will be just one container.

Pducharme · July 24, 2014

@gfjardim :

I set the EDGE to 13.0 with your docker, I see it downloaded the compiler package, etc. But since a while, this is what I see on the console output of docker :