Cloud Run is a managed computing platform that enables you to run stateless containers that are invocable via HTTP requests. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.

It also natively interfaces with many other parts of the Google Cloud ecosystem, including Cloud SQL for managed databases, Cloud Storage for unified object storage, and Secret Manager for managing secrets.

Setup and requirements

1- Sign in to Cloud Console and create a new project or reuse an existing one. (If you don't already have a Gmail or G Suite account, you must create one.)

2- Next, you'll need to enable billing in Cloud Console in order to use Google Cloud resources. New users of Google Cloud are eligible for the $300USD Free Trial program.

3- While Google Cloud can be operated remotely from your laptop, in this post we will be using Google Cloud Shell, a command-line environment running in the Cloud.

This virtual machine is loaded with all the development tools you'll need. It offers a persistent 5GB home directory and runs in Google Cloud, greatly enhancing network performance and authentication.

Once connected to Cloud Shell, you should see that you are already authenticated and that the project is already set to your project ID.

4- Run the following command in Cloud Shell to confirm that you are authenticated:

gcloud auth list

Command output

 Credentialed Accounts
ACTIVE  ACCOUNT
*       <my_account>@<my_domain.com>

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

Enable the Cloud APIs

From Cloud Shell, enable the Cloud APIs for the components that will be used:

gcloud services enable \
  run.googleapis.com \
  sql-component.googleapis.com \
  sqladmin.googleapis.com \
  compute.googleapis.com \
  cloudbuild.googleapis.com \
  secretmanager.googleapis.com

This operation may take a few moments to complete.

Once completed, a success message similar to this one should appear:

Operation "operations/acf.cc11852d-40af-47ad-9d59-477a12847c9e" finished successfully.

Create a template project

You'll use the default Django project template as your sample Django project.

To create this template project, use Cloud Shell to create a new directory named django-cloudrun and navigate to it:

mkdir ~/django-cloudrun
cd ~/django-cloudrun

Then, install Django into a temporary virtual environment:

virtualenv venv
source venv/bin/activate
pip install Django

Save the list of packages installed to requirements.txt

pip freeze > requirements.txt

Then, create a new template project:

django-admin startproject myproject .

You'll get a new file called manage.py, and a new folder called myproject which will contain a number of files, including a settings.py.

Confirm the contents of your top level folder is as expected:

ls -F
manage.py myproject/ requirements.txt venv/

Confirm the contents of myproject folder is as expected:

ls -F myproject/
asgi.py  __init__.py settings.py  urls.py  wsgi.py

You can now exit and remove your temporary virtual environment:

deactivate
rm venv/ -rf

From here, Django will be called within the container.

Create the backing services

You'll now create your backing services: a Cloud SQL database, a Cloud Storage bucket, and a number of Secret Manager values.

Securing the values of the passwords used in deployment is important to the security of any project, and ensures that no one accidentally puts passwords where they don't belong (for example, directly in settings files, or typed directly into your terminal where they could be retrieved from history.)

First, set two base environment variables, one for the project ID:

PROJECT_ID=$(gcloud config get-value core/project)

And one for the region:

REGION=us-central1

When working with infrastructure, it's useful to have all your components in the same location, so they can talk to each other more efficiently. While some components are globally available, not all components are available in all regions.

For this blogpost, we recommend using us-central1, europe-north1, or asia-northeast1; or any region Cloud Run (fully managed) is supported.

Create the database

Now, create a Cloud SQL instance: ``` gcloud sql instances create myinstance --project $PROJECT_ID \ --database-version POSTGRES_11 --tier db-f1-micro --region $REGION ``` This operation may take a few minutes to complete. Then in that instance, create a database: ``` gcloud sql databases create mydatabase --instance myinstance ``` Then in that same instance, create a user: ``` DJPASS="$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 30 | head -n 1)" gcloud sql users create djuser --instance myinstance --password $DJPASS ``` Create the storage bucket Finally, create a Cloud Storage bucket (noting the name must be globally unique): ``` GS_BUCKET_NAME=${PROJECT_ID}-media gsutil mb -l ${REGION} gs://${GS_BUCKET_NAME} ```

Store configuration as secret

Having set up the backing services, you'll now store these values in a file protected using Secret Manager.

Secret Manager allows you to store, manage, and access secrets as binary blobs or text strings. It works well for storing configuration information such as database passwords, API keys, or TLS certificates needed by an application at runtime.

First, create a file with the values for the database connection string, media bucket, a secret key for Django (used for cryptographic signing of sessions and tokens), and to enable debugging:

echo DATABASE_URL=\"postgres://djuser:${DJPASS}@//cloudsql/${PROJECT_ID}:${REGION}:myinstance/mydatabase\" > .env

echo GS_BUCKET_NAME=\"${GS_BUCKET_NAME}\" >> .env

echo SECRET_KEY=\"$(cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 50 | head -n 1)\" >> .env

echo DEBUG=\"True\" >> .env

Then, create a secret called application_settings, using that file as the secret:

gcloud secrets create application_settings --replication-policy automatic

gcloud secrets versions add application_settings --data-file .env

Allow Cloud Run access to access this secret:

export PROJECTNUM=$(gcloud projects describe ${PROJECT_ID} --format 'value(projectNumber)')
export CLOUDRUN=${PROJECTNUM}-compute@developer.gserviceaccount.com

gcloud secrets add-iam-policy-binding application_settings \
  --member serviceAccount:${CLOUDRUN} --role roles/secretmanager.secretAccessor

Confirm the secret has been created by listing the secrets:

gcloud secrets versions list application_settings

After confirming the secret has been created, remove the local file:

rm .env

Until here the first part about Django in Cloud Run, I hope you enjoyed a lot... Please, go to the second part.