Cool, thanks for the feedback! I will make edits in the morning :-). A few responses:

1. Argh, but good of course... Will try and upgrade in due course :). In the meantime, I'm glad I wrote to use the :bl.2.82_cu_10 tag and not :nvidia ;-).

2. Noted. Actually, if anyone followed my instructions from part one they don't need either, so it's a bit belt-and-braces anyway. I'll amend when I update it.

3. Unfortunately, while this is true, the errors that had me tearing my hair out weren't in the container logs (i.e. weren't coming from the startup script.) After stratup, it's pretty much silent, hence having to dig into the container image to find the actual logs in /root/cr/logging. It would be nice if the runtime logs were also output to stdout for container logging.

4. To be honest, I'm just glad someone else has experienced this bug - it was driving me to question my sanity.

5. Uhuh, noted - I'll update the post to explain this as well.

6. Personal habit/policy - anything long-lived on this machine should be managed by Kubernetes (indeed, if I ever get round to a Part 3 it'll be the helm chart I write to do this). Running directly with "docker run" comes under the heading of quick hack (in the nicest sense of the word - I mean that includes most of my CI build jobs), so I like to clean up after as much as possible :-).

7. Good to know - although is there some CR server component in the matchmaking (as it were?) (And if not, then any ideas why I have two zombie instances for the same server in my connection list..?) I should say when I was writing the post, the CR site was down, meaning I was having to go entirely on my notes and couldn't actually double-check anything - so that comment was born out of tangible frustration :-D. I'll update to include that (and remove the -rm accordingly...)

Thanks very much - will post an updated version tomorrow, much appreciated.

@tim.walls

1. true this is actually good advice to use a stable tag, hence I offer them

2. --

3. I fully agree, I actually requested this feature multiple times to @James Crowther , do you have any updates on that? ;) It would be awesome to have errors in STDOUT when passing a certain CLI argument

4. --

5. You might link to the documentation: https://docs.blender.org/manual/en/dev/render/eevee/limitations.html#headless-rendering under "Headless Rendering" section at the bottom I am still trying to find a workable solution, this is a huge problem for my own renderfarm as well

6. fair enough, was just curious

7. AFAIK there were additional features planned, when you connect the client with your account, but as of now I am not aware of any, but I could be wrong, maybe @James Crowther can answer that question better.

Also I personally have to add, that I would like to be able to render completely offline too, so hopefully we can do that once the client gets open sourced.

I thank you for the good writeup, since now I can point ppl to it, when they are searching for a complete setup guide. 👌