Okay, so now with everything being set up
with the EFS file system created on AWS
and the volume configured and set up here
in our configuration, I did change the code a little bit
so that we actually do write
to that users folder and read from it.
And therefore attached you find a new user-actions.js,
and a new user-routes.js file.
And you should just replace your files with my files,
because in there I changed the code a little bit.
I added this new getLogs function,
where I try to read a file.
And I'm trying to read a file
which is written whenever a new user is created.
When a new user is created,
I save log entries here with the date, the user ID
and the email address of the user.
I save that all to a users-log.txt file
in the users folder in the app folder
and that's the file which then gets read here with getLogs.
And this getLogs function triggers
whenever a get request is sent to the users API /logs.
So with that, make sure you use these two files
instead of the files you had originally there.
And then once you updated your code,
you of course needs to push
that updated code to Docker Hub again.
So let's go into that users API folder
and build the image again,
with that tag we use before as well, like this.
And once the image is built, of course,
also push the updated image to Docker Hub,
so that this latest code is reflected there
and so that our Kubernetes deployment
is able to use that code.
Now once that was pushed,
let's cd into the Kubernetes folder
and there I will first of all
run cube control delete deployment users-deployment
to completely remove and recreate it.
So now that this is deleted,
I'll apply the users.yaml file again,
so that the latest image is pulled again
and all these changes, also regarding the volumes,
which we made to users.yaml are reflected.
Deleting the old deployment, of course,
wasn't really necessary,
since I'd changed the volume configuration
for this deployment anyways.
But yeah, here I did it nonetheless.
So now this new deployment is eventually starting up.
And therefore once this did start up,
we can again test this.
And I will start by saving a new user
with an email address of test3@test.com.
So sending this to the signup route.
Now if we do this, it should work as it did before,
and now this user was created.
But now, we also should have an entry
in a text file being stored.
So let's try this by sending a request to that same URL,
but this time a get request
and let's send it to /logs at the end,
which is this new route which was added here
with one of the two files I provided.
Click send and what you should get back
is a list of log entries.
Now you probably only see one entry,
the test3@test.com entry.
I have two here, because I tested this off screen
before I started recording.
You will only have one, but actually,
this already proves that it works by the way,
because I did create my first entry
before I started recording,
and therefore before I deleted the deployment.
Since it's still there, it means that it was saved on EFS.
But we can test this together.
First of all, let's go back to EFS,
and there, click into that file system
and go to the monitoring area.
And what you should see there
is that once these metrics load up,
we do have some right access here.
It's very hard to see because
the majority of access types are metadata access.
But you see there are some rights here
if you hover across some of these points here,
some of these bullets you have in these charts.
And you see that you also got
a couple of client connections at the moment three,
which makes sense since we got three replicas for this pod.
Here three replicas for this pod which uses this volume.
So having three connections makes a lot of sense.
So that all seems to work
and on metered size you also eventually,
maybe after you add more and more entries,
you should see that file size increase.
So the data is definitely getting stored on EFS.
Now let's also see if it survives
if all our pods would be shut down.
And we can test this
by shrinking the number of replicas to zero,
which will close all pods.
If I now run apply-f=users.yaml,
all the pods will be stopped.
So if I run get pods now,
you will see that they're all terminating.
And once they are stopped, if we then recreate them,
if we then change that number of replicas again,
brand new pods will be created
and traditionally, that would mean that all the data
in the containers would be lost.
Now if our volume works, the data should still be there.
And since it's a persistent volume,
as you learned earlier in the course,
it's also independent of this specific pod
to which it was attached.
So launching new pods should still give us access
to the same data we saved before
with different pod instances.
So let's wait until this is all terminated.
And then let's maybe set replicas to two
and apply the updated users.yaml file
so that these new pods are launched.
And once they are up and running,
we can try sending our requests again
and we should then be able
to still see that data which we saved before.
So they are up and running now.
So for now, I send this get requests to /logs,
I still get that data from before.
So using that volume works,
and therefore this is now
how you could add a volume when using EKS.
Again, you applied just what you learned before
with the persistent volume and so on,
but then in this case,
you can for example, use this EFS specific driver
to use this as a volume for this deployed application.
And now to just clarify this again
and make this really clear,
you could of course use other volume types as well.
You could use any of the volume types supported here,
for example, all the built-in specific types
like the awsElasticBlockStore,
which is a different storage than EFS
which we are using.
But with the CSI implementation here,
you can also use any third party kind of volume,
which supports this interface.
The AWS EFS driver is just one example
since it makes a lot of sense as we're using AWS anyways,
but you could use any third party CSI driver,
which works in this application.
And that's therefore it.
That's how we can add a volume, how we can use it.
And the most important takeaway of course is
that it just works as shown for the last sections,
but here with the special twist
of being deployed on a real EKS cluster.