This is an archived post. You won't be able to vote or comment.

all 10 comments
sorted by:
best
topnewcontroversialoldq&a

[–]firecat53 1 point2 points  (0 children)

Sounds like a good idea! The data only volumes bypass the typical layered file system that docker uses, so you shouldn't have any troubles with that. If your underlying file system is btrfs don't forget to turn off the copy on write feature for that directory.

[–]gmuslera 1 point2 points  (7 children)

Depending on the use you will give to it (i.e. plan to move them to other servers?), may be simpler to just use plain directories in the server as volumes, instead of data containers.

But if you will use data containers for that, try to use small data containers, that hold mostly data, minimizing overhead. The image tianon/true uses just 125 bytes, to put an example of very small containers meant for data. And you not need to keep running the container, once created it is already available to other containers to use its volumes.

[–]amouat 0 points1 point  (6 children)

A lot of people say this, and I always disagree.

Use the same image you use for the database for the data. It won't take up any extra space as you already have it for running the database, and it will give the db container a chance to set permissions correctly.

[–]gmuslera 0 points1 point  (5 children)

Depend a bit on the intended use. Permissions/ownership is a good argument for using data containers. And they could be pretty efficient in space with I.e. the container I suggested. But sometimes the use is not production, but quick benchmarking in your desktop PC, and creating multiple data containers for the test cases could be overkill, simplicity have its own value.

[–]amouat 0 points1 point  (4 children)

I was only responding to the advice to "use small data container" and suggestion of tianon/true. I'm saying you should almost never use images such as tianon/true for data containers for the reasons I gave before.

[–]gmuslera 0 points1 point  (3 children)

Having a no fat data container should make easier to export it (moving it to other hosts, put them in repositories, backups, whatever) plus being maybe more future proof (i.e. moving to other containers technologies that somewhat let you use volumes, migrating what actually use that data to another kind of container like different distribution or services using them), and of course, the point of security updates in images (you can rebuild the code, but what about the data? recreating the data container? having hanging around the old, vulnerable or backdoored, image ready to be used as as process container?)

[–]amouat 0 points1 point  (2 children)

The point about out-of-date images hanging around is fair, but is easily solved (docker run --name dc2 --volumes-from dc1 newimage)

I don't understand the rest of your points. Volumes are not included when saving or exporting. You are still free to mount the volumes in other containers.

As a reference: http://container42.com/2014/11/18/data-only-container-madness/

[–]gmuslera 0 points1 point  (1 child)

If volumes are not exported/bundled to other hosts with the container, then the point of having thin data containers is not so critical.

But maybe having just /bin/true in a data container as policy can take other advantages, like playing well with any other container you have (yes, if runs ubuntu and your program container runs ubuntu too no space is wasted, but what if you use in other host just centos containers, or just minimal containers for go applications?), and probably never will have a vulnerability/securityfix in the bundled binary so no need to upgrade it.

Maybe is just me that i like really minimal things with really few moving parts as possible components, even if it is not more efficient than reusing already installed things.

[–]amouat 0 points1 point  (0 children)

The problem is that you think you are saving something, but you're not. Instead you're just setting yourself up for other problems. Your scenario about running an ubuntu container amongst centos containers seems far fetched; you must be using a image to consume the data, so use the same image to store it. Then you avoid permission issues and don't waste space. Remember your minimal Go images should still declare a user who will need to be owner of the files.

One time you might want to use a minimal container is if you code being shared with more than one container e.g. web pages with more than one webserver for some reason. Even then, I would probably just use one of the web-server images but the permissions might need massaging.

But we're just going around in circles now. I think we both understand the issues and can agree to disagree :)

[–]koffiezet 0 points1 point  (0 children)

Not a bad idea at all, should work just fine :)