Changing default container auto-start behavior coming soon

[jonp]

All,

 

Just wanted to let you guys know that we are planning a change in an upcoming release that will make it so when new containers are added, the default setting for Autostart will be set to On.  We were discussing internally and feel that the majority of the time, this is what folks would want their containers to do anyhow.  Once a container is added, you can turn off the autostart setting per app the same way you would turn it on today.

 

Just thought I'd make mention of this plan here to get feedback and see if anyone could come up with a glaring reason that this should NOT be the default behavior.  Keep in mind, toggling the Docker service setting itself to "off" will stop containers from starting on boot as Docker won't start on boot.

[scottc]

I like it  +1

[NAS]

Since they autostart already on install I think this change is sensible.

 

[sparklyballs]

not that it's a minus against autostarting dockers, some of the containers with edge routines might not get git updates if they autostart.

 

i have 3 containers that do this and when i reboot with them set to autostart they don't connect to git, i don't know whether the container is coming up before whatever's needed for net connectivity.

[CHBMB]

I had never really considered it an issue that things don't autostart unless enabled, but I don't consider it an issue if they do.  I understand the reasons why the change is being implemented and I don't really have enough knowledge to comment on sparklyballs' issue, so will leave that to those that understand these things better than I.

[BRiT]

not that it's a minus against autostarting dockers, some of the containers with edge routines might not get git updates if they autostart.

 

i have 3 containers that do this and when i reboot with them set to autostart they don't connect to git, i don't know whether the container is coming up before whatever's needed for net connectivity.

 

That really shouldnt be done in Docker since that goes completely against the tenants of what a Docker is supposed to be. That is a surefire way to break everyones container when the next git update isnt fully tested or has some sort of possible bug.

 

However, if you do continue to go down that path, you really want to remove the autoupdate checks from first startup and place them in a cron job that runs hourly or some other timeframe instead, like once a day.

[sparklyballs]

Agreed as to what is good docker practice and what isn't, but people do have those types of containers and they're very popular.

 

it's just a possible gotcha.

[jonp]

Agreed as to what is good docker practice and what isn't, but people do have those types of containers and they're very popular.

 

it's just a possible gotcha.

 

My response to this is a little different than BRiT's as I'm just curious as to why autostart would affect the containers connecting to git.  Try this for me, set your containers to autostart, set your array to NOT auto-start (under disk settings), reboot your server, wait a minute after the webgui comes up and start it manually.  I'm curious if this is a race-condition with the network stack or something.

[Squid]

not that it's a minus against autostarting dockers, some of the containers with edge routines might not get git updates if they autostart.

 

i have 3 containers that do this and when i reboot with them set to autostart they don't connect to git, i don't know whether the container is coming up before whatever's needed for net connectivity.

 

That really shouldnt be done in Docker since that goes completely against the tenants of what a Docker is supposed to be. That is a surefire way to break everyones container when the next git update isnt fully tested or has some sort of possible bug.

 

However, if you do continue to go down that path, you really want to remove the autoupdate checks from first startup and place them in a cron job that runs hourly or some other timeframe instead, like once a day.

I have the same issue with my network shares not being mounted before 3 containers come up.  2 abort because the host paths don't exist yet, 1 carries on with errors.  I have to restart all three of them after a reboot.

[sparklyballs]

Agreed as to what is good docker practice and what isn't, but people do have those types of containers and they're very popular.

 

it's just a possible gotcha.

 

My response to this is a little different than BRiT's as I'm just curious as to why autostart would affect the containers connecting to git.  Try this for me, set your containers to autostart, set your array to NOT auto-start (under disk settings), reboot your server, wait a minute after the webgui comes up and start it manually.  I'm curious if this is a race-condition with the network stack or something.

 

i'll give that a whirl tomorrow, it's movie time.

[trurl]

not that it's a minus against autostarting dockers, some of the containers with edge routines might not get git updates if they autostart.

 

i have 3 containers that do this and when i reboot with them set to autostart they don't connect to git, i don't know whether the container is coming up before whatever's needed for net connectivity.

 

That really shouldnt be done in Docker since that goes completely against the tenants of what a Docker is supposed to be. That is a surefire way to break everyones container when the next git update isnt fully tested or has some sort of possible bug.

 

However, if you do continue to go down that path, you really want to remove the autoupdate checks from first startup and place them in a cron job that runs hourly or some other timeframe instead, like once a day.

I have the same issue with my network shares not being mounted before 3 containers come up.  2 abort because the host paths don't exist yet, 1 carries on with errors.  I have to restart all three of them after a reboot.

I have always had mine set to not autostart. Don't know what would happen if they did.

[bkastner]

It might also be useful to be able to prioritize containers to start. For example, if you have MariaDB and either XBMC or KODI it would make sense to have the MariaDB start first before the other kicked off. It does seem to work okay now with everything auto-starting, but this would be a nice feature to have as Docker uses get more complex.

 

[Squid]

It might also be useful to be able to prioritize containers to start. For example, if you have MariaDB and either XBMC or KODI it would make sense to have the MariaDB start first before the other kicked off. It does seem to work okay now with everything auto-starting, but this would be a nice feature to have as Docker uses get more complex.

+1.  It's only working now because I believe that Kodi waits a long time for the db to be up and running before it times out.

[scottc]

there would have to be something in place to make sure all network components are up and active before docker starts up and starts the containers. I believe ( just guessing here ) this is what causes containers that use the EDGE=1 to git pull versions do not work with autostart

[jonp]

It might also be useful to be able to prioritize containers to start. For example, if you have MariaDB and either XBMC or KODI it would make sense to have the MariaDB start first before the other kicked off. It does seem to work okay now with everything auto-starting, but this would be a nice feature to have as Docker uses get more complex.

 

read this:

 

Grouping applications together can mean simply scheduling them together and providing the ability to start and stop them at the same time. It can also allow for more complex scenarios like configuring separate subnets for each group of applications or scaling entire sets of containers where we previously would only be able to scale on the container scale.

 

From this article posted on 2/1/2015.  This will be a Docker native feature so we won't have to do any shenanigans to do that.

 

https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-scheduling-and-orchestration

[Squid]

there would have to be something in place to make sure all network components are up and active before docker starts up and starts the containers. I believe ( just guessing here ) this is what causes containers that use the EDGE=1 to git pull versions do not work with autostart

A dirt simple solution would be instead of emhttp issuing the docker start command would be to remove it from there and have it in go instead.  Then, any necessary checks etc can be performed prior to issuing it.

 

When I get motivated, I was going to add the necessary commands into go before emhttp is called and see how it goes.

[BRiT]

there would have to be something in place to make sure all network components are up and active before docker starts up and starts the containers. I believe ( just guessing here ) this is what causes containers that use the EDGE=1 to git pull versions do not work with autostart

A dirt simple solution would be instead of emhttp issuing the docker start command would be to remove it from there and have it in go instead.  Then, any necessary checks etc can be performed prior to issuing it.

 

Absolutely not. It belongs in the rc.d structure and absolutely not in the go file. If the rc.d structure is setup properly then this is a non issue. Fix the problem, dont cause additional problems via cheap hackish workarounds.

[jonp]

there would have to be something in place to make sure all network components are up and active before docker starts up and starts the containers. I believe ( just guessing here ) this is what causes containers that use the EDGE=1 to git pull versions do not work with autostart

A dirt simple solution would be instead of emhttp issuing the docker start command would be to remove it from there and have it in go instead.  Then, any necessary checks etc can be performed prior to issuing it.

 

Absolutely not. It belongs in the rc.d structure and absolutely not in the go file. If the rc.d structure is setup properly then this is a non issue. Fix the problem, dont cause additional problems via cheap hackish workarounds.

I think squid was referring to an interim solution he could implement to fix this for himself before a formal fix is provided. We wouldn't resort to that solution as an official fix...

[Squid]

there would have to be something in place to make sure all network components are up and active before docker starts up and starts the containers. I believe ( just guessing here ) this is what causes containers that use the EDGE=1 to git pull versions do not work with autostart

A dirt simple solution would be instead of emhttp issuing the docker start command would be to remove it from there and have it in go instead.  Then, any necessary checks etc can be performed prior to issuing it.

Yes

Absolutely not. It belongs in the rc.d structure and absolutely not in the go file. If the rc.d structure is setup properly then this is a non issue. Fix the problem, dont cause additional problems via cheap hackish workarounds.

I think squid was referring to an interim solution he could implement to fix this for himself before a formal fix is provided. We wouldn't resort to that solution as an official fix...

Yes

[BRiT]

Ah yes, I could see a call to "/etc/rc.d/rc.docker restart" after looping check for network in the go file as a user short term work-around.