Docker Non-Persistent Storage

Docker containers are famous for their “use and throw” nature. This is where the term “docker non-persistent storage” comes into light. Whenever a container is used for the purpose of “testing“, non-persistent nature of containers help to achieve that.

To learn more about docker storage, follow -> Docker Storage

Today, we are going to learn about the docker’s non-persistent nature with the help of following steps:

Step 1: Now, create a container which the following command, as shown in the picture below.

$ docker run -it --name container1 alpine

docker = command

run = context to the command

it = run the container in interactive mode

container1 = name of the container

alpine = image name, from which the container has to be created

Note, from the picture above, after creating the “container1” we are dropped into the container’s shell. Here, we have listed the current files and directories already present inside the container.

Further, we have also created a new file inside the “container1” with a name of “file1.txt“, for testing purpose.

After that, we have exited the container using the keyboard keys combination as “CTRL + d“.

Note: In case of an alpine container, on “exiting/log-out” it will get stopped by default.

Step 2: Now, “what if we try to create a new with the same name container1“?

From the picture below, the docker daemon has thrown an ERROR to us, stating that “this particular container name is already associated with a container“.

Further, if we still want to create a container with name “container1” in the current system state, we have to delete the previously created container, which is currently in the “Exit state“.

Step 3: Now, let us create a new container with the name of “container2” as shown below.

$ docker run -it --name container2 alpine

Question: Why we have created another container?

Answer: In order to check, that it does not matter whether you are using a base image to any number of containers, the containers by default are going to be created on their own space, sometimes called isolated namespaces. Here we can see, that the file created in the “container1” is not available to “container2“, even if both the containers are created using the same base image.

Step 4: From the photo below, we can see that both the containers “container1” and “container2” are in a stopped state.

Question: Where does our “file.txt” has gone? What was its purpose in this post?

Answer: We are going to start our stopped container “container1” and check whether the “file.txt” is still there or not.

Step 5: Now, start the container “container1” using the command below:

$ docker container start container1

Step 5: As we can see, our container “container1” has been successfully started.

Step 6: Now, in order to login into the container we have to use the “attach” context for the “docker container” command, as shown below.

$ docker container attach container1

From the picture above, we executed the “ls” command, and from the output of it, we can confirm that “file1.txt” still exists and persisted inside the container.

Question: Wait, What? isn’t this post is about “docker non-persistent storage“?

Answer: Yes, but don’t get confused by this nature of docker containers.

Question: What does it even mean then?

Answer: By default, the containers will only get stopped on “log-out” or on “exit“. But in the “testing phases” or sometimes in “production phases” they are configured as, on “exit or log-out” they are also going to be deleted.

Question: Still, what is the meaning of “non-persistent” here for this post (Docker Non-Persistent Storage)?

Answer: Here, it means that on the container deletion, the data inside the container also gets deleted, this is what is being referred to “use and throw” nature of containers.

To understand it more robustly, follow the forthcoming steps.

Step 7: Now, we are going to delete/remove the container “container1” with the help of the following command.

$ docker container rm container1

Step 8: Here, we have created a new container again with the same name as “container1“.

But note, here the “file.txt” does not exist that’s because it got deleted with the deletion of the container holding it. This is docker’s by default nature to hold any data created inside it.