Add Docker Containers Automatic after recreate


Wuast94

Recommended Posts

Is there a way that all my docker Containers that are curently shown in docker tab are addet automaticly after recreating the docker image file ? 

I have more then 30 Containers running and to add them one by another needs time and is not the best i can think of. 

at least it would be nice to have a multi selection for adding containers back. that way i can select all containers i want to recreate after recreating the docker image file. 

Link to comment
  • 2 weeks later...
13 minutes ago, Diggewuff said:

Sorry for burying out that old one. Will this also recreate previouos sorting autostart and delays of the containers?

Where those settings are stored is not something I have researched, but in my experience if you simply remove a container and reinstall it using CA previous apps, it will indeed come back in the same sorted order with the delay.

 

However... like I said, I don't know where it's getting that info, so it's possible that won't always happen depending on what all gets blown away before you recreate things. That's a question for @Squid

Link to comment
37 minutes ago, jonathanm said:

Where those settings are stored is not something I have researched, but in my experience if you simply remove a container and reinstall it using CA previous apps, it will indeed come back in the same sorted order with the delay.

 

Answer is *maybe*  From a new docker.img file, they definitely will not be in the same start order.  From a simple remove container / add container I'm not 100% sure either way, but the safe assumption is that they will not be in the same start order.

Link to comment
10 minutes ago, Squid said:

Or,


cat /var/lib/docker/unraid-autostart

 

Well, that certainly explains the behaviour I've encountered. Apparently that list is never pruned, there are some containers in there that I haven't had installed for a long time. Lesson here is to turn off autostart and save state before removing a container.

 

@Squid, could you possibly back up and restore that file with CA backup / restore?

Link to comment
24 minutes ago, jonathanm said:

@Squid, could you possibly back up and restore that file with CA backup / restore?

It *could* be done, but then CA on a multi-install would have to then overwrite from what it more or less thinks is what you had backed up (may or may not be what you wanted).   

 

IDK.  I'd have to think about the procedure and what it would entail and what caveats may be present.

Link to comment
4 hours ago, jonathanm said:

Well, that certainly explains the behaviour I've encountered.

What exactly?

 

The function which performs the autostart checks if a container exists before attempting to start it.

Any non-existing containers are skipped.

 

Note: toggling the autostart button for any container updates the list and removes any non-existing containers.

 

Link to comment
5 hours ago, bonienl said:

What exactly?

I was troubleshooting a container, blowing it away totally in the image and appdata and readding it from previous. I expected adding a fresh container to show up either at the top or bottom of the container list with auto start and delay not set. Instead it showed up in previous order set to auto start with the delay.

 

Also, the autostart list has some containers which I haven't had installed for a very long time, and I'm fairly certain I messed with auto start order and timing since then, but the containers still have templates so they show up in previous apps.

 

5 hours ago, bonienl said:

Note: toggling the autostart button for any container updates the list and removes any non-existing containers.

Non existing where, exactly? If it's checked against currently installed containers, that doesn't seem to be working as intended. If it's checked against saved templates, then a previously installed container that hasn't had its template removed will stay in the list, which is what I seem to be seeing.

Link to comment
9 hours ago, Squid said:

It *could* be done, but then CA on a multi-install would have to then overwrite from what it more or less thinks is what you had backed up (may or may not be what you wanted).   

 

IDK.  I'd have to think about the procedure and what it would entail and what caveats may be present.

I'm not talking about the previous apps portion. That would be handy, but like you say is not going to necessarily be what is intended. I'm talking about the point in time when CA Backup does its thing, and backs up your appdata. That way, if you lose your cache pool and are restoring from ground zero it gets restored with the backed up appdata set, which theoretically would match the containers you want to reinstall and get running, at least to a large extent.

 

Also, it would be handy if installing a container wouldn't immediately start it, but instead offer an option like VM's do, to set it up but not start. When I had to recreate my cache pool for real, the multi install put things back and started them in an order which created some errors and chaos, because of the way I have things set up with dependencies and scripted starts. Having everything restored but not started would be ideal.

 

I script some containers startup with logic that can't be handled with the built in binary auto start with delay. I need conditionals, some of which were handled by your deprecated auto start plugin, some of which I coded myself. Since auto start and delay are now part of the base, I just handle all the special case containers with scripts.

Link to comment

It's a two step process.  Restore the appdata and recreate the docker.img.  If you do it in this order, there's no place to restore the autostart file.  If you do it in the reverse order then the autostart can be restored.

 

3 hours ago, jonathanm said:

Also, it would be handy if installing a container wouldn't immediately start it,

It works the same way as add container.  Starts the app right away.  Unlike add container though, it automatically sets the container to autostart under the assumption that more often than not you want the app to start right away. 

3 hours ago, jonathanm said:

chaos

Convenience always comes with a price

Link to comment
5 hours ago, jonathanm said:

I'm not talking about the previous apps portion. That would be handy, but like you say is not going to necessarily be what is intended. I'm talking about the point in time when CA Backup does its thing, and backs up your appdata. That way, if you lose your cache pool and are restoring from ground zero it gets restored with the backed up appdata set, which theoretically would match the containers you want to reinstall and get running, at least to a large extent.

 

Also, it would be handy if installing a container wouldn't immediately start it, but instead offer an option like VM's do, to set it up but not start. When I had to recreate my cache pool for real, the multi install put things back and started them in an order which created some errors and chaos, because of the way I have things set up with dependencies and scripted starts. Having everything restored but not started would be ideal.

 

I script some containers startup with logic that can't be handled with the built in binary auto start with delay. I need conditionals, some of which were handled by your deprecated auto start plugin, some of which I coded myself. Since auto start and delay are now part of the base, I just handle all the special case containers with scripts.

Can you give us some examples of your scripted startup procedure? I'm really interested in that. 

Link to comment
2 minutes ago, Diggewuff said:

Can you give us some examples of your scripted startup procedure? I'm really interested in that. 

Sure. It's dirt simple. The commands for containers are just

 

docker start <container name>

docker stop <container name>

docker pause <container name>

docker unpause <container name>

 

to start a VM

 

virsh start <VM Name>

 

Here's a little script that waits on an IP to return a ping before continuing

 

#!/bin/bash
printf "%s" "waiting for 192.168.X.X ..."
while ! ping -c 1 -n -w 1 192.168.X.X &> /dev/null
do
    printf "%c" "."
done
printf "\n%s\n"  "192.168.X.X is online"
virsh start X

docker start X

 

You can insert timed pauses with

sleep <seconds>

 

Link to comment
  • 1 month later...

It sounds like the answer is yes, but just to confirm, will reinstalling from the Previous section of Community Applications find the data from the previously installed container in my cache pool and get me back to the previous state?

 

I recently upgraded my motherboard, CPU and cache drive without understanding that some data is permanently stored there. I've managed to get the contents of the old cache drive onto the new one, so hopefully this is the last step in restoring my containers.

Link to comment
3 hours ago, RichardRob said:

It sounds like the answer is yes, but just to confirm, will reinstalling from the Previous section of Community Applications find the data from the previously installed container in my cache pool and get me back to the previous state?

 

I recently upgraded my motherboard, CPU and cache drive without understanding that some data is permanently stored there. I've managed to get the contents of the old cache drive onto the new one, so hopefully this is the last step in restoring my containers.

Yes

Link to comment

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.