NAS
-
Posts
5,040 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by NAS
-
-
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
-
Has anyone looked into Newznab+ ?
Thanks
I am not sure the licensing would allow it.
-
bjp999 I think you probably just made seagate lose a lot of money and the community here save it.
Personally I think this is forum news worthy as one person not seeing it and buying one is one too many.
Do we have perms to add it to news?
-
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
-
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?
-
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.
-
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.
-
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.
-
yup see the sticky in this forum.
I am all for variation and preference but rT + ruT + www server + flexget is not exactly slick.
it is so easy to try something in docker you might as well have a shot and if an app is lacking then push for an alternative.
-
Would it be possible to have a rtorrent/rutorrent docker?
I would also love that!!
For it to be universally useful a flexget container would also need created.
I have used rTorrent for as long as I can remember and rutorrent for a 3+f years and TBH i find deluge better now. I got fed up with how stagnant rTorrent is e.g webseeds are available in every client but has an open feature request for 8+ years in rT
Do yourself a favour checkout deluge. It used to be crap but now it good now.
I think we should change this thread to a poll and use it as a poor mans voting system
-
Second on the Logitech Media Server. Also would like to see MySQL and Dropbox (Just saw that hurricane has one for Dropbox).
mariadb has been created already probably best just to use that
-
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
-
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.
-
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
-
As i posted previously I like the elegance of TCL but I worry that the skills required them develop one out weight the benefits they bring to the unRAID community.
I think the proof of this is that so far no one has produced even one. Until we see at least a proof of concept I suspect it will always stay in the "wouldn't it be cool to do pile" and I dont think we should dwell on it.
Lol! You are laying down the gauntlet and challenging us Linux Dorks to prove our manhood.
I have a feeling your tatic will work. If someone doesn't do one by Sunday, I will dive on the grenade and create a few Sunday.
lol wasnt my intention but yeah it kinda looks that way reading back. It kinda hints at the crux of it though... even a new docker user could cobble together a POC dock based on Debian as fast as I type this reply. I strongly suspect TCL will present some hurdles. Lets wait and see if anyone wants to try it.
-
As i posted previously I like the elegance of TCL but I worry that the skills required them develop one out weight the benefits they bring to the unRAID community.
I think the proof of this is that so far no one has produced even one. Until we see at least a proof of concept I suspect it will always stay in the "wouldn't it be cool to do pile" and I dont think we should dwell on it.
-
Reasonable enough.
I was considering that the git/latest thing be restricted to the experimental tag docker. My fundamental concern with docker and git is the python apps that everyone here seems to use. They invariably all have complex config files and sqlite database that are NOT backwards compatible. So the meta effect is some poor smho runs a one line docker command because they are a user with no intimate back end knowledge end up with no option to use git form then on because they have altered their non docker files. Also I think Docker misses the trick in that there is almost no way to know what version of an app you are being offered without trying it.
Happy to remove the git URL requirement if required. The reason i include this is IMHO the docker repo page sucks at presenting a user with meaningful change control messages and I want to actively encourage review by pushing this link to users.
"-- rather than -" I would still like to leave the recommendation in for those that dont care. If in time no one does it we can remove the recommendation.
"verified" - can you give me a one liner i can include here
As for phusion. My stance has been I dont think it is the right way to go either but for long term support reasons. Having just read this "http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/" I am more convinced than ever that its not as sexy a choice as the project summary page makes out.
Why do we need a base OS? Because every dev has to choose one and in many cases it makes zero difference which one they choose. So really the base OS recommendation is simply to limit differentiation for differentiation sake. If i had two docks to choose from and one used the OS i already had docks off i would choose that one. Its not a big deal but might as well make it if only to inspire ongoing conversations like this.
-
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
-
-
This is a work in progress. It is currently unofficial. Nothing is set in stone. Nothing is a requirement, only a set of suggestions. Eventually this will be ported to the wiki; until then it will be heavily edited as we debate.
Some points may never reach a general consensus as they are personal preference. That’s fine don’t worry about it... it’s only a set of suggestions anyway. If this list proves impractical or a development hurdle it may be deprecated later.
I would really appreciate some help on this as it should make things easier for everyone.
-
Maybe we need to fork this off and speak to limetech about an alternative location on the cache drive.
yah keen to discuss as many options as possible but want to keep this thread clean just on devices if possible
-
NO
...kingston FCR-MRG2, this DOES boot but the guid is NOT unique, although at first glance the guid looks valid, as it is neither all zero's or a number sequence.
http://www.amazon.co.uk/KINGSTON-FCR-MRG2-MicroSD-Reader-Generation/dp/B0028R3NCU
-
all i can say is it works perceptively fine for me
-
Do we have any thoughts on how we can derive the number on a system by system basis. For instance one of my machines has 16GB of RAM now so I dont want to hobble the system artificially.
On a happy note it is nice have cache_dirs back. My move to v6 had been seemless but the lack of cache_dirs made a tremendous difference to the real world "responsiveness" of the v6 system. Now I have cache_dirs again subjectively it is even better than v5.
Everyone should run this.
-
Joe looks good.
Out of interest does the 30k come from anywhere other than it being bigger?
Docker requests
in Docker Containers
Posted
No more off topic posts please