Docker container developer best practice guidelines for unRAID


NAS

175 posts in this topic Last Reply

Recommended Posts

  • Replies 174
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I would use alpine, debian or Ubuntu depending on which software you try to run and then use the S6 overlay process monitoring and init of software. 

As best it can.  It's not like it can read the directions or anything.  If the container author included the various environment variables, paths, etc within the dockerfile, then it should properly fi

If you have a docker of your own on dockerhub, then just use the Add Container page in unRAID to specify all the docker run parameters such as volume mappings, etc. Then when you have the Add Containe

Added:

 

The dock should not contain any data or settings specific to the builder (i.e. quirks of their specific setup). All user specific data should be passed in from the command line as per Docker best practice.

 

The idea being that docks should be freely publishable to the repo with no sensitive data or quirky builder specific settings e.g users should not have to rebuild it to insert data such as certs or config files. Doing that is IMHO a complete fail in any dock design but I can see how new users may think it was an easy solution to certain problems.

Link to post

photo.jpg

 

EDIT:

Couldn't help it....

 

Did this mean you took up NAS on his challenge? If so, how is it coming along?

 

GF is out shopping and doing girls night out so I am free the rest of the day / night. I have some other Dork / Nerd stuff to work on if you are in the process of creating some Tiny Core Linux Docker Apps for us to see / test. If not, I will geek out on creating some docker apps.

Link to post

Oh no, it was how I figured you looked when you responded to your earlier post. Have fun geeking out with TCL and docker!

 

My GF said geeking out on TCL and docker isn't exactly what she would call a panty dropper. Perhaps I should go wrestle a bear instead. In case you do not hear from me again, you know why.

Link to post

Oh no, it was how I figured you looked when you responded to your earlier post. Have fun geeking out with TCL and docker!

 

My GF said geeking out on TCL and docker isn't exactly what she would call a panty dropper. Perhaps I should go wrestle a bear instead. In case you do not hear from me again, you know why.

 

I hear you! My wife looks at me like I have 3 heads when I start talking about the "server"...

Link to post

I hear you! My wife looks at me like I have 3 heads when I start talking about the "server"...

 

"the plex/roku/internet/tv thing is broke MAKE IT WORK!!!!!"

 

Do you remember when you took her out for a steak, she was grateful and thought you were a certified stud?

 

I remember those days fondly.

Link to post

We are getting off topic here interesting as it is there are plenty of other threads for this debate.

 

Lets come back to looking at a best practice recommendations list as set out in the opening posts.

 

ta :)

 

pretty please

 

Added a line:

 

apt-get update  autoremove autoclean recomendations

 

Since 9 out of 10 containiners are debian based so far and of them all run apt-get update  and few run the rest

Link to post

As far as I can tell no.

 

I believe that whilst TCL containers may be the optimal technological solution the skill required to create them creates a barrier for dev uptake. I dont think this can really be argued as whilst new Debian based containers continue to be released here no one has made a TCL container.

 

What it needs is a developer who is passionate about it to covert the 10-20 or so we need as the cornerstone for all future work. I doubt that will happen and personally I dont want to commit to the effort and support.

 

So TCL is off the table for now at least.

 

The current winner is Phusion and whilst that is not my personal choice I dont care enough to argue that all the work is redone. However it is not impossible that at some point Limetech will release roadmap info that may steer us a certain way.

Link to post

What it needs is a developer who is passionate about it to covert the 10-20 or so we need as the cornerstone for all future work. I doubt that will happen and personally I dont want to commit to the effort and support.

 

I haven't caught Docker fever yet or else I would probably create a bunch of them for the community. Not to say that Docker doesn't work or inferior... I just have VMs (Docker on roids) and do not feel like converting.

 

I'm sure one of us Linux Dorks will get bored and create Docker Containers in other Linux OSes in the not too distant future. I suspect around the time Debian 8 is released or when one of the main apps (Sickbeard, CouchPotato, etc.) has a dependency problem (Debian runs older packages compared to most other Distros).

Link to post

Yeah I suspect you are probably right.

 

I reckon it is best though that we work with what we have/know this now and should a better base come around (or be recommended by upstream Docker/Limetech) we deal with that when it happens.

 

I just dont want this best practice guide to be either unachievable by normal devs or unrealistic based on what our community is actually doing.

Link to post

Thinking about making a recommendation that asks devs/users think about using the stable version of apps.

 

I can see a trend to using bleeding edge and updating constantly which IMHO is exactly not what container distribution is about. It is definitional a valid use case but not where the real power in containers resides. I "think" we should actively encourage users to stick with the stable versions of thing or at least present the risks better for an informed choice.

 

I just worry, I remember the edge case sab bug that deleted users video collections :)

 

One day this will all certainly be point and click from the web gui so even the computer illiterate can install containers. That is why best practice recommendations put in place now are important... or we going to end up again with a geeky solution for geeks.

Link to post

There is nothing wrong with using latest code in the containers so long as they are clearly labeled as "latest" and the others labeled as "stable". That way the users can make the choice for themselves.

Link to post

Your right there is nothing wrong for the right people to use bleeding edge code. However normally those users should be beta testers and not normal users.

 

There within lies my concern. For this to be more than a geeks free for all and be at its heart a quality successor to addons (and all the things addons should have become) it needs to have at its core some overriding principles.

 

Ideally we want the default to be stable and opt in to bleeding edge only.

 

We definitely dont want rules that stifle use or development.

 

This is why I think a good "guideline" would be to request that development code dockers also tagged with stable code. This lends itself to some sort of peer review process where containers get promoted to the official repository which I assume will exist at some point.

 

 

Edit: or keep dev containers in a different forum or repo. Suggestions for something simple?

 

 

 

Link to post

Added:

 

Where possible use the traditional port for a service within your container e.g. www port 80. Mapping to bypass port clashes is the job of the user not the container.

 

Docker best practice

Link to post

Here's a suggestion for a best practice... always add a .gitattributes file to the root of your project that contains these lines:

 

# Auto detect text files and force unix-style line endings
* text eol=lf

 

That forces unix-style line endings on text files, which solves problems for people who use Git for Windows to checkout a repository to an unRAID share.  Without that line, Git for Windows uses Windows-style line endings, which causes errors when running shell scripts in Docker.

Link to post

Here's a suggestion for a best practice... always add a .gitattributes file to the root of your project that contains these lines:

 

# Auto detect text files and force unix-style line endings
* text eol=lf

 

That forces unix-style line endings on text files, which solves problems for people who use Git for Windows to checkout a repository to an unRAID share.  Without that line, Git for Windows uses Windows-style line endings, which causes errors when running shell scripts in Docker.

 

added as a quote this now will tidy it once it makes the wiki. nice one

Link to post

it seems setting locale is another important think that needs to be done in dockers, see discussion here...

 

http://lime-technology.com/forum/index.php?topic=34168.msg317791#msg317791

 

Also, do we need/want versioning for dockers?  If needo needs/wants to add/update locale in his dockers, the versions I have installed/running now would benefit from updating, but how would one know that?  Perhaps versioning can help with the docker plugin knowing we need updates, and prompt us to do so.

Link to post

it seems setting locale is another important think that needs to be done in dockers, see discussion here...

 

http://lime-technology.com/forum/index.php?topic=34168.msg317791#msg317791

 

Alresdy in the list but will add that link as well.

 

Also, do we need/want versioning for dockers?  If needo needs/wants to add/update locale in his dockers, the versions I have installed/running now would benefit from updating, but how would one know that?  Perhaps versioning can help with the docker plugin knowing we need updates, and prompt us to do so.

 

I would hang fire on this as I cannot see a future where Docker themselves dont add this to their repo and tool.

Link to post
  • 2 weeks later...

I think it would be a good to implement a more compatible umask setting in dockers that create files on unRAID. The default umask in unRAID is 0000 which results in files with wide open permissions (directories: 0777 or drwxrwxrwx, files: 0666 or -rw-rw-rw-). In phusion/baseimage the default umask is 0022 which results in files that are only writeable by the owning user (directories: 0755 or drwxr-xr-x, files: 0644 or -rw-r--r--). These more restrictive permissions can cause problems when user share security is enabled.  Many of the applications that are run in these unRAID dockers have internal settings to control permissions, but it would be nice if we did not have to rely on all those separate internal settings.

 

A few possible methods to implement this:

[*]Set the umask for each application.  For example, in phusion/baseimage, a "umask 0000" command could be added to the run script that starts the application.

[*]Set the default umask for the user nobody. I don't know to do this but it seems like a good way to go if one were to create an unRAID baseimage.

[*]Set the default umask for all users. In ubuntu 14.04 this is done in /etc/login.defs. This seems heavy-handed; it doesn't seem like a good idea to have all files created within the container to have wide open permisions.

 

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.