Hey All,

 

Thought I'd pull this out of NAS's thread on best practices.  There is a reason the developers of the original containers did not pull from master and pulled from a specific build, or made an edge case to pull the newest. 

 

I don't want to call out anyone. I've just noticed a lot of requests for it and a few builds showing up and thought it would be good to start a discussion.

 

Maybe NAS can expand on this?  My take is if the source updates and has a major change, your docker will not work.  Pulling from a specific version will ensure it always works.

 

Guidelines

 

Please choose the following base OS and version " phusion/baseimage:0.9.11" unless you have a specific reason you cannot.

 

Releases with multiple versions (e.g. stable/testing/development) should be handled in a single dockerfile with the appropriate tags/scripts to allow the user to choose.

 

The use of "git clone master" and "OS:latest" type commands that result in different code as time passes should be avoided unless the implications are understood. Usually it is better to clone a specific git/svn build number or avoid git completely using tarball downloads which are typically also available.

Run your containers as the user "nobody" and group "users" and NOT root. Pay attention of UID and GID differences between OSs (uid=99(nobody) gid=100(users))

 

Decide and explicitly set within your scripts the UMASK you want to your applications with (typically umask 000)

 

Develop your Dockerfile on github and follow git commit best practices so that users can track you e.g.

 

commit only tested code

commit comments should be short and descriptive

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

 

Include a license file at github so that users are free to consume your work and developers fork if needed.

 

Timezones can be handled with

-v /etc/localtime:/etc/localtime:ro

 

Dealing with locales (TBC) http://lime-technology.com/forum/index.php?topic=34168.msg317791#msg317791

 

Lightly comment your Dockerfile with relevant information.

 

Verified Dockerfiles only TBC

 

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.

 

Future updates of Dockerfiles that cause an upgrade of setting files and/or databases should be highlighted where possible (i.e. if an upgrade makes it impossible to roll back as non Docker protected config files have been upgraded)

 

apt-get update  autoremove autoclean recomendations

 

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.

 

 

 

Your forum announcement for your Dockerfile should contain a maintained list in the first post:

 

• 
  A link to your docker repo
  The application version numbers you are providing
  The base OS if you have chosen to diverge from stock and why
  A sample start command
  Any other relevant information e.g. why you need to run as root etc.
  

 

 

Deprecating

==========

 

Where possible use the "--" version of all command switches within your Dockerfile as they are far easier for the less Linux fluent to review. e.g. --quiet rather than -q

*No one is doing this and its not valuable enough to waste time trying to enforce it.

 

A link to your github repo

*Link to docker repo is enough

Was about to post a question in the forum why the dockered apps don't auto-update, then saw this post.

So the best way to go if I do want an automaticly updated app is a VM?

Was about to post a question in the forum why the dockered apps don't auto-update, then saw this post.

So the best way to go if I do want an automaticly updated app is a VM?

 

Yes, if you truly want bleeding edge and all the hassles that go with it, go for a VM.

If you want stability and apps that continue to work, go with Docker.

The problem with all this stuff IMHO is support and stability.

 

A cornerstone of Docker is that "what I run you can run". So regardless of our hardware, unRAID versions or anything else if we run the same container we have the EXACT same app. All these bleeding edge kludges break that fundamental design tenant.

 

From a support standpoint this is actually much much worse than the old addon system.

 

It is always the case that most users on bleeding edge have no real need for it or any interest in being a beta tester other than asking for support to keep their live system alive when it breaks and this is where i think we focus.

 

Telling users and developers not to do x or y will never work because it takes away choice and that is something we should not do. What we should do is have stable and unstable repos so that all users are by default using on stable tags and have to actively opt out of that branch. If this cant be done with repos then dockerman should be altered to be aware of unstable ENV variable and show clearly that users are running unsupported software.

 

Early days but this will become a serious problem for us soon enough.

Actually, I don't mean Bleeding Edge, but stable version update.

For instance - CrashPlan updated it's client to ver3.5.4, or SABnzbd updated to 0.7.20.

Will the Docker based CrashPlan update itself and stay persistent after a reboot, or the docker builder will have to update the version inside the container and the users will have to manually update their dockers ?

Thanks

The whole point of docker is we all get a point in time build. It is then up to the docker maintainer to test and maintain newer builds which we then regrab so we all get a new point in time build.

 

Currently what a lot of people do here is essentially grab the container from the repo and then fill it up with code from elsewhere (i.e. git) resulting in everyone having a different version.

 

It is up to the docker maintainer to update app not the consumer of the container.

The whole point of docker is we all get a point in time build. It is then up to the docker maintainer to test and maintain newer builds which we then regrab so we all get a new point in time build.

 

Currently what a lot of people do here is essentially grab the container from the repo and then fill it up with code from elsewhere (i.e. git) resulting in everyone having a different version.

 

It is up to the docker maintainer to update app not the consumer of the container.

 

I'm guilty to a degree of doing this, but when i've ironed out the kinks in headless xbmc i'll fork the xbmc git to my own github and pull from there.

I dont think we should ever suggest we try and stop people doing this only make sure developers understand the extra support commitment they are taking on but more importantly allow users to make an informed choice before they decide to "opt in".

 

This now it is a bit like the wild west and users dont really understated what they are giving up by blindly following forum posts.

 

Not sure what the right answer is just that we need to get to one ideally before v6 stable (even if it is only in principal)

I dont think we should ever suggest we try and stop people doing this only make sure developers understand the extra support commitment they are taking on but more importantly allow users to make an informed choice before they decide to "opt in".

 

This now it is a bit like the wild west and users dont really understated what they are giving up by blindly following forum posts.

 

Not sure what the right answer is just that we need to get to one ideally before v6 stable (even if it is only in principal)

 

I agree. I didn't post this to scare people away... just wanted to make sure this was discussed