KATIE MCLAUGHLIN: Hey, Martin, did
you see that Livestream from the nature reserve?
MARTIN OMANDER: Hey, Katie.
Yeah, I'm watching it now.
It looks like a Django pony had wandered
into unicorn territory.
KATIE MCLAUGHLIN: Geez, I hope they get along OK.
MARTIN OMANDER: Here's hoping.
[MUSIC PLAYING]
MARTIN OMANDER: Alex is an engineer
at Vivid, a digital agency that creates websites
for their clients using Django.
Django is a web framework written in Python
that handles serving web pages for you.
You define data models as Python objects,
and Django simplifies communicating these
to a database.
Vivid's client websites, like agate construction,
currently runs on servers in Vivid's office.
But the company is moving to The Cloud.
Alex looked at running their existing client websites
on virtual machines, but that would require
a fair amount of ops work.
Alex wonders, can they serverless?
KATIE MCLAUGHLIN: Yeah, they can.
Cloud Run is a managed serverless platform, where
each server run stateless.
No data is stored on the servers itself.
But Cloud Run can connect to state
for backing services, databases, APIs, and the like.
Web frameworks that rely on databases like Django
can run in a serverless setup with some configuration.
The general steps described in this video
can be used for not only Django, but any other content
management system that uses Django,
such as Wagtail and Django CMS.
We've created code labs that walk you through everything
described in this video.
They're linked in the description below.
Any Django site can be built into a container image.
This image can be deployed as a Cloud Run service,
but that just handles the code part.
Django also needs a database to store
relational data and a place to store media and static assets.
These two backing services need to be
provisioned and accessible by the service.
MARTIN OMANDER: First, let's talk data.
Django supports many relational databases,
including PostgreSOL and MySQL.
Alex can use Cloud SQL, a managed database service,
that supports both PostgreSOL and MySQL, and even MS SQL.
KATIE MCLAUGHLIN: When Alex first deploys their Cloud Run
service, they'll need to set the add SQL instance
parameter, linking their Cloud Run service with their Cloud
SQL database.
This allows the service in the database
to communicate over an automatically
encrypted connection.
Django will also need connection settings.
Not just the instance hostname, but also the database username
and password.
Alex can store these credentials using Secret Manager,
retrieving them at runtime.
From here, everything is set up to run
Django's migrate command.
MARTIN OMANDER: Secondly, media and static assets.
Alex can configure their new Django app
to use a Google Cloud Storage bucket to store these files.
KATIE MCLAUGHLIN: Cloud storage can
be configured as a custom storage backend in Django using
the Django storages package.
Alex just needs to install the package
and edit their settings.py to use this new storage backend
and point to their new Cloud Storage bucket.
From here, everything is set up to run Django's collect
static command.
MARTIN OMANDER: This all seems great.
But about those Django commands.
Where do you actually run those?
KATIE MCLAUGHLIN: Well, this is the question, Martin.
Cloud Run focuses on serving containers,
and doesn't provide a way to run a one-off shell command
against a running service.
What Alex can do is run these commands
as part of their continuous integration process
using Google Cloud Build.
In their Cloud Build config, they
can add a new step called migrate between their built
step and their deploy step.
This migrate step uses the App Engine exec wrapper,
which allows commands to be run against a database
during a Cloud Build job.
Additionally, they can configure this job
to be automatically run anytime the agate code is
updated in source control using Cloud Build triggers.
If an automated process doesn't work for Alex's migration
strategy, they can run their migration commands manually
with help from Cloud SQL proxy.
We've described this method in more detail in our blog post.
MARTIN OMANDER: By connecting these manager's services
together, Alex is able to host their websites in the cloud.
These services automatically scale up and down
as their load changes throughout the day,
without having to pay a fixed price for a virtual server.
KATIE MCLAUGHLIN: Details for everything mentioned
in this video, including the code labs,
are linked in the description.
So how are the herd doing?
MARTIN OMANDER: It looks like they're going along great.
KATIE MCLAUGHLIN: Yay.
[MUSIC PLAYING]