So we got our application up and running
on our cluster here.
Now, let's move on, and let's dig into volumes.
We covered volumes in an earlier module,
and there I also talked about these types of volumes.
And we use the emptyDir type and the hostPath type.
And I mentioned that this CSI type
would also become important later.
Well now is later.
Now the application we are working on at the moment,
actually has no code that would really write a file
to the hard drive.
We're interacting with a real database instead.
Nonetheless, we could assume that we have some code
which does write to a file,
even though it's not the case here.
We could assume that we have some code,
which actually writes to let's say,
a user's folder in our main project folder.
Maybe storing extra data about users and text files there.
Again, it's just an assumption,
it's not something our application does,
but if we would have this behavior,
if we would have a feature like this,
then we might wanna use a volume to persist the data
in that fictional users folder in our project folder.
So what would we do normally?
Well, in docker-compose world, there, we would add a volume.
I'm not going to do this here,
but you'll learn how to add volume
stare over the course sections in this course.
Here, I wanna focus on Kubernetes.
And there we have two main ways of adding volume,
we can directly add it here in our container setup
in our pod template in the end,
or we set up such a persistent volume resource
and create a persistent volume claim.
And here, I will go for this persistent volume approach,
because it is probably the one you'll use more often
in reality, and in addition, the specific type of volume
I wanna set up here, at least at the moment
only works with persistent volumes.
But let's first of all come back to volumes in general.
Now, in local development, emptyDir was useful
because it's a new empty directory,
but it's created for each pot,
and therefore it's not great
if we have multiple pods up and running.
Or if our pod would restart, the data would also be lost,
because it always is recreated as an empty directory.
hostPath was very useful locally with mini-cube
because that created a path on our node
and use that as a volume.
And since the node is not shut down
just because a pod is removed,
that also survived pod restarts
and multiple pods were able to share one of the same volume.
But this is not an option here,
because actually here we got more than one node.
In this case, I got two nodes.
And in most clusters, most Kubernetes clusters,
you will have more than one node.
That means that a hostPath would only be created
on one node but not the other.
But you don't know where your pods will be created.
Kubernetes automatically manages this pod creation
and tries to create them on the node,
which doesn't have too much work at the moment.
So therefore, the node on which a pod is created
might not have the hostPath
to which you wanna bind your volume.
And even if it would,
multiple nodes would have different data
on their hard drives.
So hostPath is really only useful
if you have a single node setup mostly during development.
The CSI type is useful here though,
because this stands for a Container Storage Interface.
And as I explained earlier in the course,
that's a very flexible volume type
where third party developers can add their own integrations
and their own volume types with ease.
And here I wanna use AWSEFS de elastic file
system service to manage my data.
That's the same service we used earlier in the course
already when we deployed our containers with ECS.
And there exists such a CSI package for AWSEFS,
and there also is an official documentation here,
I'm just going to go to this GitHub page
to learn more about this integration.
And this is a very useful integration which is easy to add
to our cluster and which then allows us to use EFS
as a volume driver, as a volume type.