MARTIN OMANDER: Hi, Dina.
DINA GRAVES PORTMAN: Hi, Martin.
What's up?
MARTIN OMANDER: In a previous episode,
you showed me your checklist for reporting containerized web
apps to Cloud Run.
And by running them serverlessly on Cloud Run,
I got autoscaling.
I only pay when my code is running.
And I don't have to do server maintenance.
DINA GRAVES PORTMAN: Actually, I believe
I showed you two checklists.
MARTIN OMANDER: Oh, right.
The first checklist was for finding out
if my containerized app can be ported to Cloud Run.
And it said that the container should be stateless.
DINA GRAVES PORTMAN: That's right.
MARTIN OMANDER: And then in the comments,
you were asked how to port containerized web apps that
store and use sessions--
in other words, apps that are stateful on the server.
DINA GRAVES PORTMAN: OK, well, those containers can still
be ported to Cloud Run.
But it does require a few more steps.
Let me show you how.
[MUSIC PLAYING]
MARTIN OMANDER: All right, I have this e-commerce web app
that keeps track of the user's shopping cart contents
between requests.
And it does so with server side sessions.
For example, if I reload the page like this,
the session is still active, so the shopping cart content
is still there.
DINA GRAVES PORTMAN: I see, yeah.
That does make the container stateful.
Any time your application reads and writes data locally,
for instance, to a database or a key value store,
this means that your application is stateful.
And that's just a way of saying that you're
saving the state locally.
But let's focus on the user sessions right now.
MARTIN OMANDER: Yeah, why do we even
need to think about statefulness, Dina?
DINA GRAVES PORTMAN: Well, OK, here's the deal.
If your server side code stores user session data and memory,
it's easy to lose it.
MARTIN OMANDER: Why is that?
DINA GRAVES PORTMAN: Well, for instance,
your server may crash, which wipes out its memory.
Also, if you're running your app on a serverless platform,
like Cloud Run, each user request
is sent to the next available instance,
which may not be the instance that
has the user session in memory.
MARTIN OMANDER: Oh, that sounds like a huge problem.
DINA GRAVES PORTMAN: Yeah, exactly.
So try not to store sessions in the server's memory.
MARTIN OMANDER: OK, but I've got to store the session data
between requests somewhere.
DINA GRAVES PORTMAN: Yes, store it outside the server.
For instance, Redis is an open source
distributed key value store.
And it is a great alternative to saving locally
because it's fast and it can still
be reached by your application servers.
MARTIN OMANDER: OK, but my app uses the Express framework
with the Express session package.
And that package stores session data in memory on the server.
DINA GRAVES PORTMAN: You're right.
It does by default. But you can edit it.
You can add a Redis connector to it.
Many frameworks, like Express, Django, Flask, Laravel, Spring
Boot, Koa, Gin, and Ruby on Rails,
can be configured to use Redis for session storage.
MARTIN OMANDER: OK.
Let me go and read the docs for Express session
and see if I can connect it to Redis.
Let's meet back here for a little bit?
DINA GRAVES PORTMAN: Sounds good.
I will grab a cup of tea.
MARTIN OMANDER: All right, I'm back, Dina.
I added the Redis connector to my app.
It requires the address of a Redis server
and a port it listens to.
So my code now reads those values
from environment variables.
DINA GRAVES PORTMAN: Well done.
So let's set up your Redis server.
Go to the Cloud Console, open the hamburger menu,
and click Memory Store.
Memory Store is Google's hosted solution for Redis,
which automates many important features like high availability
and patching.
MARTIN OMANDER: OK.
I will pick Redis for now.
And I'm enabling Memory Store in this project.
DINA GRAVES PORTMAN: Good.
Now click Create Instance.
Give it a name and a display name.
For the rest of the fields, the defaults are fine.
Now click Create.
Now your Redis server is being initialized.
This server sits in a virtual private cloud,
so it's not accessible from the public internet.
So next, we need to set up a connector so
that your Cloud Run service can connect
to your virtual private cloud.
To do that, first pick VPC network
in the navigation sidebar.
Then click serverless VPC access.
Click Create Connector and give it the name My VPC Connector.
Under network, pick Default. Under subnet,
pick custom IP Range.
And go ahead and enter that suggested 10.8.0.0 in the IP
text box and click Create.
Now head back over to the Memory Store
and copy the IP address of the Redis instance
that you just created.
In your deployment shell script, add Redis host, Redis port,
and VPC connector as environment variables.
MARTIN OMANDER: OK.
Now that is done, I will build and deploy the container.
DINA GRAVES PORTMAN: Is it working?
MARTIN OMANDER: Let's see.
Let me reload the page here.
Refresh.
Yeah, it's working.
DINA GRAVES PORTMAN: OK, awesome.
Let's recap what you have achieved.
By moving your container to Cloud Run,
you no longer need to maintain a server.
And your service auto scales as load increases.
And we have Cloud Run to thank for this.
Now, Cloud Run is able to offer these features by not
storing the data in memory.
So by putting the session data in Redis via memory store,
you won't lose it if the user's second request hits
a different server than their first request
or if an app server crashes.
MARTIN OMANDER: I like that.
Have we earned another tea break, Dina?
DINA GRAVES PORTMAN: I think so.
MARTIN OMANDER: Thank you all for watching.
If you have any questions for Dina or me,
enter them in the comments below,
and we'll try to answer them.
Also let us know what other serverless topics we should
bring up in this video series.
Bye for now.
[MUSIC PLAYING]