Free WordPress on Google Cloud – Cloud Run. Part 1

Feb 22, 2024

—

in Google Cloud Platform (GCP), Wordpress

Spread the love

This is one of the series of the articles about hosting WordPress (any) website on Google Cloud completely (or almost) FREE of charge.

What is Google Cloud Run

Cloud Run is a managed compute platform that lets you run containers directly on top of Google’s scalable infrastructure.

You can deploy code written in any programming language on Cloud Run if you can build a container image from it. In fact, building container images is optional. If you’re using Go, Node.js, Python, Java, .NET Core, or Ruby, you can use the source-based deployment option that builds the container for you, using the best practices for the language you’re using.

Google has built Cloud Run to work well together with other services on Google Cloud, so you can build full-featured applications.

In short, Cloud Run allows developers to spend their time writing their code, and very little time operating, configuring, and scaling their Cloud Run service. You don’t have to create a cluster or manage infrastructure in order to be productive with Cloud Run.

Cloud Run integrates with the broader ecosystem of Google Cloud, which enables you to build full-featured applications.
Essential integrations include:
Data storage
Cloud Run integrates with Cloud SQL (managed MySQL, PostgreSQL, and SQL Server), Memorystore (managed Redis and Memcached), Firestore, Spanner, Cloud Storage, and more. Refer to Data storage for a complete list.
Logging and error reporting
Container logs are automatically ingested by Cloud Logging. If there are exceptions in the logs, Error Reporting aggregates them, and then notifies you. The following languages are supported: Go, Java, Node.js, PHP, Python, Ruby, and .NET.
Service identity
Every Cloud Run revision is linked to a service account, and the Google Cloud client libraries transparently use this service account to authenticate with Google Cloud APIs.
Continuous delivery
If you store your source code in GitHub, Bitbucket, or Cloud Source Repositories, you can configure Cloud Run to automatically deploy new commits.
Private networking
Cloud Run instances can reach resources in the Virtual Private Cloud (VPC) network through the serverless VPC access connector. This is how your service can connect with Compute Engine virtual machines or products based on Compute Engine, such as Google Kubernetes Engine or Memorystore.
Google Cloud APIs
Your service’s code transparently authenticates with Google Cloud APIs. Examples include the AI and Machine Learning APIs, such as the Cloud Vision API, Speech-to-Text API, AutoML Natural Language API, Cloud Translation API, and many more.
Background tasks
If you want to schedule code to run later or immediately after returning a web request, Cloud Run works well together with Cloud Tasks to provide scalable and reliable asynchronous execution.

More details, guides and API reference you will find on official google page.

WordPress on Cloud Run, Concerns

WordPress is a blogging tool that uses a relational database to store the blog articles and their related objects and metadata, and the local file system to store assets, such as pictures in a blog post.

In general, a container’s root file system isn’t suitable to store persistent data. The containers you run on Cloud Run are typically disposable or stateless entities. So basically Cloud Run is using the fresh filesystem of the container every time when you hit the website (roughly), and all the file changes or new assets keeps there until the Google kills the instance of the Cloud Run service (usually within a 10 minutes or even less, on idle). When the instance is killed, all data saved to a container’s file system is lost, so next time when you hit the website address it will be a new instance with the fresh filesystem from the container without file changes.

Another issue is a database, Cloud Run can not store or contain SQL databases in its containers, well, it can, but since it is a stateless application it will be always new (empty) database every time Cloud Run creates a new instance of the app container, so external SQL database shall be used. For this you can either use paid version of Cloud SQL, or connect to a Compute Engine with the MariaDB (or MySQL) VM running there. Basically you can use MariaDB as one of the multi container solution in Cloud Run (covered later), but the database itself shall be stored on the external storage (network or persistent disk) and mounted every time when the new instance of your Cloud Run app is launched.

There are other versions of WordPress on Google Cloud Run deployments available on internet where the assets (images, article files) are stored on Cloud Storage using the specific WordPress plugin, but the root filesystem (PHP files) are hardcoded in the app container and will never change until you’ll rebuild the container image.

Cloud Run – Basic Setup

Enable Cloud Run API (make sure the project and the billing account are created and the billing account is linked to your project):

gcloud services enable run.googleapis.com

This will usually enable the following related APIs:

Artifact Registry API
Cloud Logging API
Cloud Pub/Sub API
Cloud Run Admin API
Cloud Storage
Container Registry API
Google Cloud Storage JSON API

Set default region for Cloud Run (use one of the Tier1 price regions, I will use us-east1 in these article series):

gcloud config set run/region us-east1

WordPress

To be able to run a WordPress on Cloud Run you need basically only the containerized image. In this article, as am example, I will be using the official WordPress Docker images, let’s start from the one based on Apache – wordpress:apache, run the following command (wordpress-apache – is the name of your Cloud Run service):

gcloud run deploy wordpress-apache \
  --image docker.io/wordpress:apache \
  --region=us-east1 \
  --port=80 \
  --concurrency=100 \
  --cpu=1 \
  --memory=512Mi \
  --max-instances=1 \
  --allow-unauthenticated \
  --cpu-throttling

You can remove the parameters like –concurrency, –cpu, –memory, –max-instances and –cpu-throttling for now, check this document for more details and understanding.

After it is successfully deployed to Cloud Run you should see a confirmation message in your command line like this:

Deploying container to Cloud Run service [wordpress-apache] in project [wordpress-414215] region [us-east1]
✓ Deploying new service... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [wordpress-apache] revision [wordpress-apache-00001-gr9] has been deployed and is serving 100 percent of traffic.
Service URL: https://wordpress-apache-vfbipc7oqa-ue.a.run.app

By following the link https://wordpress-apache-vfbipc7oqa-ue.a.run.app you should be able to see the initial WordPress setup page:

This revision of your WordPress Cloud Run service won’t be able to save the credentials to your database (or to wp-config.php), to save the uploaded images/assets or installed plugins permanently, only for while the current service revision is running, but don’t worry, we just started, follow the details in this article below and in the end you will have all you need to make your own WordPress features composition (architecture).

SQL Database

As Cloud SQL is paid feature of Google Cloud platform and it does not has any resources available under the Free Tier program I will not consider it as an option and as a solution in these article series, but we still need MySQL or MariaDB database, so what would be the solution?

The one of the possible solutions would be to use Compute Engine virtual machine where we will install Docker and run MariaDB docker container with the database we will be connecting to from our Cloud Run service.

So let’s continue with creating the Compute Engine VM instance (Part 1) in Google Cloud platform.