In transitioning to 6b8 the first step is to make a single image to hold all of your anticipated containers.  I had some issues with that but more general:

 

What is the logic behind taking a containerized app structure and putting them all in a single image?  It seems like that defeats the point of containerization.  Is this the way it's going to be in 6.0?

 

D

In transitioning to 6b8 the first step is to make a single image to hold all of your anticipated containers.  I had some issues with that but more general:

 

What is the logic behind taking a containerized app structure and putting them all in a single image?  It seems like that defeats the point of containerization.  Is this the way it's going to be in 6.0?

this does not stop you running multiple (independent) dockers.  It is just setting up a virtual disk for storing the containers.  The rational for this is discussed in the forum post about why this is being done.  It is also addressed in the release notes and in Tom's recent blog posting.

 

 

In transitioning to 6b8 the first step is to make a single image to hold all of your anticipated containers.  I had some issues with that but more general:

 

What is the logic behind taking a containerized app structure and putting them all in a single image?  It seems like that defeats the point of containerization.  Is this the way it's going to be in 6.0?

 

D

 

What is the logic against it?  Yes this is how it will be in 6.0.  It is the easiest way to manage it.

 

 

In transitioning to 6b8 the first step is to make a single image to hold all of your anticipated containers.  I had some issues with that but more general:

 

What is the logic behind taking a containerized app structure and putting them all in a single image?  It seems like that defeats the point of containerization.  Is this the way it's going to be in 6.0?

 

D

 

What is the logic against it?  Yes this is how it will be in 6.0.  It is the easiest way to manage it.

 

The only concern I see is it puts all your eggs into a single basket, and if that img file corrupts, you lose all your apps. If you are keeping your config folder outside the img file it's not a huge deal, but still an inconvenience.

 

I still think this is a better solution than forcing everyone to reformat their cache disk as btrfs and makes it way more generally accessible to the masses.

 

 

In transitioning to 6b8 the first step is to make a single image to hold all of your anticipated containers.  I had some issues with that but more general:

 

What is the logic behind taking a containerized app structure and putting them all in a single image?  It seems like that defeats the point of containerization.  Is this the way it's going to be in 6.0?

 

D

 

What is the logic against it?  Yes this is how it will be in 6.0.  It is the easiest way to manage it.

 

The only concern I see is it puts all your eggs into a single basket, and if that img file corrupts, you lose all your apps. If you are keeping your config folder outside the img file it's not a huge deal, but still an inconvenience.

 

I still think this is a better solution than forcing everyone to reformat their cache disk as btrfs and makes it way more generally accessible to the masses.

How does installing to a cache drive directly (not an IMG file) change that eggs in one basket concern?  It doesn't. It makes it worse.

 

At least with the .IMG file you can back it up and move the whole thing easily.  Tried doing that without the .IMG?  Good luck...

 

I think the bottom line point that I'm trying to make here is that there are really no downsides to the move to a .IMG.

 

At least with the .IMG file you can back it up and move the whole thing easily.  Tried doing that without the .IMG?  Good luck...

 

I think the bottom line point that I'm trying to make here is that there are really no downsides to the move to a .IMG.

 

Thanks; I hadn't thought about bkastner's point that the image option means that many users won't have to reformat their cache drive, and yes a backup of an image is pretty simple.

Rereading what I posted, I sounded like I was coming off like a bit of a jerk, so apologies for that by the way, probably just running low on steam and was getting very direct in my communications ;-).

 

Anyhow, we hope this change, while inconvenient for some in the beta now, will ultimately be a much better move for all unRAID users in making it easier to safely manage and backup your Docker containers.

Also, the containers may be in the .img, but your configs and data for most (all?) container apps will be stored outside the container, so if you lost the img, it's pretty trivial to restore the settings etc.

 

Personally, I'm not going to bother backing up the .img, but I will back up my settings (and info on the volumes used by each container).

Rereading what I posted, I sounded like I was coming off like a bit of a jerk, so apologies for that by the way, probably just running low on steam and was getting very direct in my communications ;-).

 

Anyhow, we hope this change, while inconvenient for some in the beta now, will ultimately be a much better move for all unRAID users in making it easier to safely manage and backup your Docker containers.

 

No worries

 

I can be rather direct in the forums as well at times, so can definitely take it in return.

 

I do think this is a good solution, but am still sketchy on moving my config folders to the container, which negates the value of the backup. It's a personal decision, but again, for non-tech users it's a good, simple solution that does given them flexibility.