Docker storage is beyond confusing. There is more jargon and nonsense technical terms than a football locker room. I’m not sure if that makes sense but lets just go with it. I’ve been reading articles all week and I think I sort of understand this “persistent memory” thing. Most of the videos are related to actually spinning up containers for use by developers. And lets be honest, who wants to be a developer? I mean typing shit out all day because you think its fun and then seeing it run in production and being like ‘I made that’ and having no one know that bit of code was you or care. Sounds fucking awful. Any way lets get into some stuff.
Ok, so first of all I keep hearing this thing about persistance and I have no idea what this is. So I watched a bunch of YouTube videos, none of which where helpful, so I’m going to link some articles that I found helpful in understanding that all of this documentation surrounding pulling a fucking file from an HD and writing to ram when using containers is full of so much nonsense jargon its almost insufferable. Like ok, i can write shit to ram in Linux but not windows. Right.
The other thing about this, a lot of what i’m finding that’s useful for conceptualizing is marketing material that’s requiring to read through product specific jargon.
Persistent Storage Strategies for Containers
This is basically marketing material as its for a coporate blog. As I read it I realize that I should probably spin up docker and build a bullshit website to spin up however, to be quite frank, obviously writing two lines of HTML and using different color backgrounds is way outside my scope. I go into server manager and click around until it does what I need it to lol. Ok, I could do this but im not sure it would be work the time for me. I mean, this isn’t a super cool CTF so why would I learn anything about it. It too me 6 months to figure out how to exit VIM. Build several containers that host a local site and use clustering with source code stored for each? That sounds like its outside of my wheelhouse. I guess I should also mention that this has nothing to do with the question I posted above. No worries…we will get to not finding an answer for that and discussing the hella meta ideas presented about Docker storage that seem like they are clearly designed to put the ball in devs court and confuse the ever loving hell out of management. Honestly, I’m absolutely ‘pro’ this concept. Like lets take every thing you know about computing and pretend is all absolutely false because we have just reinvented the wheel by figuring out a way to have services run in containers (that somehow have OS kernels but are not VMs) and use a shared source for serving up applications or use info contained in the container. I realize that contained in the container sounds absurd and to be honest, there are a lot of things that sound real dumb boiled down which plausibly led to over complicated lingo. That said, the spaghetti monster is alive and well in containers. So, here is my favorite thing from this article, this all makes sense:
as always, the devil is in the details. In the case of containers and persistent storage:
- The practical need for some kind of storage for use by the container. Many common software tasks use temporary storage. While it may be possible to design programs that perform those tasks without the need for persistent storage, doing so introduces unnecessary complications.
- Prolonged use of individual containers. In practice, some containers remain in use for hours, or even longer. The longer a container remains in use, the greater the likelihood that it will need storage (as a scratchpad, to save state information, or for more complex purposes).
- The need for containers to share data. This is a big one. Containers frequently need to work together, and working together generally means sharing data. The easiest and best way to share data is often by means of shared storage. Lack of such storage makes data sharing difficult.
So here is thing about this, what are each of these states of storage called? I’m not sure. At this point it seems like ‘persistant storage’ means avalible data. Like, wtf. Every application needs
this. Why are you confusing me with this new word. I’m still not clear on what it means and I think they made it up so that ‘kind ol’ southern folks’ such as myself would be confused. I’m pretty sure thats
true because devs are going to look at it and go lol you mean applications need to have access to data to serve things up? Wow, I did not know that. So then comes in this whole bit of what the hell they are
talking about at any given moment.
Docker storage types
- Docker Data Volumes
- For storage by individual containers, Docker offers data volumes. These allow a container to use a kind of virtualized persistent storage abstracted from the host system’s storage. This virtualized storage is integrated into the standard container file structure, which makes access easy. Data volumes are, however, limited to an individual instance of a single container. The data can’t be shared with other containers, and it can’t be accessed by later instances of the same container.
- Using the Host File System
- There are other methods of persistent storage which make much more direct use of the host file system, setting aside some of the host system’s storage for use by the container without the layers of abstraction imposed by data volumes. This can, depending on the method used, allow data to be shared with other containers, or with later instances of the same container. If file and storage management are not fully coordinated between the container and the host system, however, data may be overwritten or corrupted
This information is immensely helpful. Unlike the 4-5 hours of YouTube videos I watched while trying to figure out what they where talking about. It seems really obvious and I’m not sure why this isn’t present in the articles linked from MeasureUp. This is why I pay you MeasureUp. I could have bought these sick shoes, mostly
Thats neither here nor there. But those shoes are sooo sick. So you should pay me so much money so I can be your offices Server High Roller. I’m sure this is extremely convincing as well as appealing. Jody has quality tastes. If your not familiar already, there isnt much point in this exercise in absurdity and modern art. Yes, I legit think he is a walking bit of modern art and commentary on peoples responses to things they are unclear on.
Ok, so now that ive informed you that the linked Docker documentation is garbage, that YouTube videos are for starter devs or execs pretending to be learning, and that (holy shit) applications require back-end data to be able to do anything, what the hell is going on in the linked question.
Glad you asked, Lets find out!
ok so i said this was useless but really its just confusing as fuck with no baseline. Like what the fuck, no where in this does it mention Linux and I have to be running a linux kernel in the container to use this. That’s crazy but ok. the best part is its insisting that its writing to ram and not a HD. Like ok, so I can write to ram in Linux but not in windows. You guys are fucking with me aren’t you. Yep. Ok, that’s fine, that’s how it works. There are a lot of cmds here to use with docker around thing but we don’t really care. I want to be able to answer the question and know the why. At this point the how is outside my scope. Wait, but it says ‘not persisted’ what the fuck, it seems like all this is persisted. Ignore that, its a red herring. That’s my thought at least. I could be wrong here but we shall see haha. Any way the next part about being removed when its stopped, that’s important. This is a unique identifier to tmpfs mounts as its written to ram.
This is literal normal application storage on a hard disk that can be accessed by multiple docker containers or to put in other words, instances of your app server. The host core functionality bit is slightly confusing but again, I think this is red herring. The important part is its managed on the host. Obviously the services are going to be isolated from the host. That’s literally the entire point of containers. So the important part of this question is “in a directory on the host” and basically ignore any thing else. However, this bit is the difference between the last two answers “While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker” I know what your thinking, why would they be so cruel? Welcome to server tests. Honestly, I enjoy the logic torture.
Basically this somehow calls on OS local APIs to be able to serve the data into the application and a volume mount does not otherwise its the same thing. Well, that’s my understanding.
So all that is clear as mud right? I don’t know what to say, its kind of a lot to wrap your brain around but its good stuff. Just read, stop obsessing over terminology your not familiar with and realize that maybe you understand a few things about computes. Perhaps the terms are tools more for communication than practical things.
Leave a Reply