Docker container developer best practice guidelines for unRAID


NAS

Recommended Posts

The proper way of dealing with this is versioning the docker container. That way the user can get a specific container version and know exactly which version of the container they're getting. Doing anything different is still abusing the docker purpose.

 

The only 'problem' with this is that the user is (still) reliant on the docker creator to update the docker, and some people don't have the patience to wait for this to happen.  Also, as we've seen with plugins, authors come and go, as life happens, so one day an author is likely going to disappear, and their docker won't get updated unless/until someone else jumps on it.

 

It's a difficult thing to manage, for sure.

 

Also - there is nothing that forces us to avoid "abusing the docker purpose" if our purpose is different.  Docker is just a tool.  Using that tool in a manner that is different to it's intended use does not validate the effectiveness of the tool.  Using a free wooden paint stirrer as a shim is still a totally valid use of that tool. :)

 

 

dockers though, if they are based on a mainstream baseimage are with a few quirks basically linux) so someone else picking up the reins of a dead docker is somewhat easier than a plugin, and as long as the git source isn't deleted, it can be forked.

Link to comment

I still stand by my assertion that first and foremost we need a core team to bring together the stable packages. That is what the vast majority of users will use. Sure a vocal minority here will want bleading edge and thats fine but thats a separate use case covered by the stage 2 team i mentioned in my last post.

 

There are two problems and therefor two solutions here. We keep slipping back into trying to fix them both with one solution which wont ever work.

 

Also we need to actively work on avoiding dev burn out. trying to keeping up with the unskilled beta testers (a.k.a bleading edge consumers who arent testing at all)

 

Edit: I should point out this thread is a case in point. My post calling for a show of hands for docker repo devs has been blasted a page back with talk about versioning... again. Thats fine it just another example of lack of focus causing us to get nowhere. We need to start somewhere and that somewhere HAS to be stable packages

Link to comment

I still stand by my assertion that first and foremost we need a core team to bring together the stable packages. That is what the vast majority of users will use. Sure a vocal minority here will want bleading edge and thats fine but thats a separate use case covered by the stage 2 team i mentioned in my last post.

 

There are two problems and therefor two solutions here. We keep slipping back into trying to fix them both with one solution which wont ever work.

 

Also we need to actively work on avoiding dev burn out. trying to keeping up with the unskilled beta testers (a.k.a bleading edge consumers who arent testing at all)

 

Edit: I should point out this thread is a case in point. My post calling for a show of hands for docker repo devs has been blasted a page back with talk about versioning... again. Thats fine it just another example of lack of focus causing us to get nowhere. We need to start somewhere and that somewhere HAS to be stable packages

 

 

I don't know if it's too much of a stretch, but if there were some kind of an "officialish" unraid docker repo i feel there should be some QC of sorts and a framework regarding paths and comments in the git etc... so if a dev does go walkabout it's easier for someone else to take over.

Link to comment

To be clear, I'm not suggesting we should have/offer dockers that run the 'bleeding edge'.  I'm referring to offering the current, stable version.  Occasionally most/all programs go from one stable version to another, and until the docker creator updates their docker to the new, stable version, the program will continue to run the older version. 

 

The issue is the same whether or not we're talking about the bleeding edge, or moving stable version; at some point in time a user wants to use a newer version than they have currently, and are then at the mercy of someone else to provide that for them.

 

I only brought this up as something to consider when discussing a 'standard' system for unRAID dockers.  It seems this is a consideration that needs to be incorporated into any new base system.

Link to comment

Thats why we want a team to work on a pool of stable app containers under the general framework of these best practices guidelines.

 

In most cases the effort to update a properly constructed docker container is minimal. Delays are usually just a function of availability which become less common the larger the team to container count ratio.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Link to comment

In most cases the effort to update a properly constructed docker container is minimal. Delays are usually just a function of availability which become less common the larger the team to container count ratio.

 

This 100%

 

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

I don't think it would hurt and be a good place to hash out details.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Getting in the last comment before this becomes a private party, lol , only joking.

 

I could see the point of a devo only area, but i'd like to suggest again the possibility of a submission type deal where users can put forward dockers for possible inclusion in a central repo, provided it met certain criteria.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Getting in the last comment before this becomes a private party, lol , only joking.

 

I could see the point of a devo only area, but i'd like to suggest again the possibility of a submission type deal where users can put forward dockers for possible inclusion in a central repo, provided it met certain criteria.

How we handle the repos and submissions is something we have slated to discuss and design fairly soon.  Your idea is not too far from what we've discussed internally during water cooler meetings ;-)

Link to comment

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

As a non-dev who would be excluded from this type of subforum, I think it's a great idea if it helps deliver stable, consistent and "official" unraid containers with the same sort of path structures which means anything we install would require minimal customisation.

 

Wouldn't alienate me in the slightest.

Link to comment

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

As a non-dev who would be excluded from this type of subforum, I think it's a great idea if it helps deliver stable, consistent and "official" unraid containers with the same sort of path structures which means anything we install would require minimal customisation.

 

Wouldn't alienate me in the slightest.

Thanks for your support on this dalben. Much appreciated. Will be discussing internally tomorrow.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Coincidentally I was thinking the same thing but from another angle; dev chat is usually more focussed. When you introduce consumers to this chat you get good ideas but every single time you end up talking about what will come later and much wider scope at the expense of the OT.

 

Also your Arch is well made.

 

I say have a community dev section. Read only for all and the bar for write access would be low enough for it not to seem elitist.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Coincidentally I was thinking the same thing but from another angle; dev chat is usually more focussed. When you introduce consumers to this chat you get good ideas but every single time you end up talking about what will come later and much wider scope at the expense of the OT.

 

Also your Arch is well made.

 

I say have a community dev section. Read only for all and the bar for write access would be low enough for it not to seem elitist.

Love this idea. Read only for all, but invite only for posting ability. Keeps the discussion publicly visible, but more focused.

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Coincidentally I was thinking the same thing but from another angle; dev chat is usually more focussed. When you introduce consumers to this chat you get good ideas but every single time you end up talking about what will come later and much wider scope at the expense of the OT.

 

Also your Arch is well made.

 

I say have a community dev section. Read only for all and the bar for write access would be low enough for it not to seem elitist.

Love this idea. Read only for all, but invite only for posting ability. Keeps the discussion publicly visible, but more focused.

 

I think this is the best solution but wonder if it will cause some level of PM flooding from users who can't hold their tongue.  Easy enough to ignore but may cause some ill will.

 

EDIT:  Actually, jonp you should have some experience with this.  Have you been inundated with PMs since the announcement forum went read-only?

 

John

Link to comment

I'll throw this question out to NAS and the others.  How would you feel about a invite-only developer forum in which devs can post and reply, but no one else.

 

We definitely want user feedback, but users really have no place in telling devs how things should be structured. Devs have to do the work, so their opinions on matters pertaining to repos and base images trump anything a user would have to say on the matter. This isn't a matter of egotism, its about relevance to how the topic truly matters to these separate audiences.

 

Point is that if all the users here said they want a base image for docker based off arch, but all the devs want it based off Ubuntu, the image would be based off ubuntu. Hope this makes sense and doesn't come across as trying to alienate anyone.

 

Coincidentally I was thinking the same thing but from another angle; dev chat is usually more focussed. When you introduce consumers to this chat you get good ideas but every single time you end up talking about what will come later and much wider scope at the expense of the OT.

 

Also your Arch is well made.

 

I say have a community dev section. Read only for all and the bar for write access would be low enough for it not to seem elitist.

Love this idea. Read only for all, but invite only for posting ability. Keeps the discussion publicly visible, but more focused.

 

I think this is the best solution but wonder if it will cause some level of PM flooding from users who can't hold their tongue.  Easy enough to ignore but may cause some ill will.

 

EDIT:  Actually, jonp you should have some experience with this.  Have you been inundated with PMs since the announcement forum went read-only?

 

John

Nah it hasn't been bad. The forum is back to being where anyone can reply again, but during the time it was read only, I didn't get flooded with PMs.  I think that users can still discuss and debate the same topics in the general docker forum we have.

Link to comment

Chatted internally about this and we are going to move ahead with creating a forum that will be public, but read-only by default unless you're explicitly invited.  To get an invite to participate, you must have published at least one extension for unRAID 6 (an extension being either a Plugin, a Container, or a Virtual Machine) and you must send me a PM here on the forums with a request to participate.  There are some who will get an automatic invite to this (dlandon, phaze, needo, gfjardim, smdion, and several others).  This new forum will be part of a forum reorganization that we've been meaning to get done anyway, so give us a few days to figure the big picture out and we'll get this up and going.  Thanks everyone!

Link to comment
  • 2 weeks later...

Two new best practices for consieration

 

i was having issues with this error when exec'ing into containers and trying to run commands (most notably mariadb container)

 

quick google found this really useful link.

 

https://github.com/dockerfile/mariadb/issues/3

 

with the info here, you can create your user / database from the exec command line, just like it was a regular instance of mysql/mariadb.

 

Like buses i never seen that once then i got 3 instances of it in one day.

 

Also two times now when developing in docker using exec i have made a mistake and actually installed something on the host OS.

 

I am thinking that it might be sensible to make the prompt whilst inside docker very distinguishable perhaps a combination of color and the docker container name + something else?

Link to comment
  • 4 weeks later...
  • 1 month later...

It looks like the current version of phusion/baseimage is 0.9.16.  According to the release notes, it disables ssh.  Is there a reason the recommended version is 0.9.15 instead?

 

According to the release notes:

0.9.16 (release date: 2015-01-20)

 

docker exec is now the default and recommended mechanism for running commands in the container. SSH is now disabled by default, but is still supported for those cases where "docker exec" is not appropriate. Closes GH-168.

All syslog output is now forwarded to docker logs. Closes GH-123.

The workaround for Docker bug 2267 (the inability to modify /etc/hosts) has been removed, because it has been fixed upstream. Closes GH-155.

Logrotate now reloads syslog-ng properly. Closes GH-167.

Fixed some locale issues. Closes GH-178. Thanks to David J. M. Karlsen.

Fixed problems with cron. Closes GH-115.

Contribution by Bryan Bishop.

Link to comment

It looks like the current version of phusion/baseimage is 0.9.16.  According to the release notes, it disables ssh.  Is there a reason the recommended version is 0.9.15 instead?

 

According to the release notes:

0.9.16 (release date: 2015-01-20)

 

docker exec is now the default and recommended mechanism for running commands in the container. SSH is now disabled by default, but is still supported for those cases where "docker exec" is not appropriate. Closes GH-168.

All syslog output is now forwarded to docker logs. Closes GH-123.

The workaround for Docker bug 2267 (the inability to modify /etc/hosts) has been removed, because it has been fixed upstream. Closes GH-155.

Logrotate now reloads syslog-ng properly. Closes GH-167.

Fixed some locale issues. Closes GH-178. Thanks to David J. M. Karlsen.

Fixed problems with cron. Closes GH-115.

Contribution by Bryan Bishop.

 

may be as simple as a lack of maintenance on that thread, OP is on something of a sabbitical.

Link to comment

Ahh, I looked at a couple of example dockfiles and they were pointing to 0.9.15, which is what is recommended on one of the follow-up pages of this thread.  Looks like you've already updated, so nevermind!  :)

 

there were some encouraging noises not so long ago about an unraid base image which i liked the look of.

 

although the runit system in phusion works for the vast majority of containers, i've found some instances where it is too sensitive and respawns apps that haven't crashed, i'm leaning more and more towards supervisor.

Link to comment
  • Squid unpinned this topic

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.