cloud-foundation-fabric/blueprints/third-party-solutions/wordpress/cloudrun
Julio Castillo dfed7cc5bd
Rename `modules/cloudsql-instance` deletion protection variables (#2135)
* Rename Cloud SQL deletion protection variables

* Fix tests
2024-03-06 10:44:54 +00:00
..
images Align documentation, move glb blueprint (#921) 2022-10-26 14:31:04 +02:00
README.md Make deletion protection consistent across all modules (#1735) 2023-10-05 17:31:07 +02:00
cloudsql.tf Rename `modules/cloudsql-instance` deletion protection variables (#2135) 2024-03-06 10:44:54 +00:00
main.tf IAM interface refactor (#1595) 2023-08-20 09:44:20 +02:00
outputs.tf Enforce nonempty descriptions ending in a colon 2022-11-24 18:56:01 +01:00
terraform.tfvars.sample Merge branch 'example-wordpress' of https://github.com/skalolazka/cloud-foundation-fabric into example-wordpress 2022-09-15 13:03:33 +00:00
variables.tf Make deletion protection consistent across all modules (#1735) 2023-10-05 17:31:07 +02:00

README.md

Wordpress deployment on Cloud Run

43% of the Web is built on Wordpress. Because of its simplicity and versatility, Wordpress can be used for internal websites as well as customer facing e-commerce platforms in small to large businesses, while still offering security.

This repository contains the necessary Terraform files to deploy a functioning new Wordpress website exposed to the public internet with minimal technical overhead.

This architecture can be used for the following use cases and more:

  • Blog
  • Intranet / internal Wiki
  • E-commerce platform

TODO

  • refactor variables merging WP configuration in a single variable
  • optional creation of a remote artifact registry repository
  • optional serverless connector

Architecture

Wordpress on Cloud Run

The main components that are deployed in this architecture are the following (you can learn about them by following the hyperlinks):

  • Cloud Run: serverless PaaS offering to host containers for web-oriented applications, while offering security, scalability and easy versioning
  • Cloud SQL: Managed solution for SQL databases
  • VPC Serverless Connector: Solution to access the CloudSQL VPC from Cloud Run, using only internal IP addresses

Setup and deployment

Setting up the project for the deployment

This example will deploy all its resources into the project defined by the project_id variable. Please note that we assume this project already exists. However, if you provide the appropriate values to the project_create variable, the project will be created as part of the deployment.

If project_create is left to null, the identity performing the deployment needs the owner role on the project defined by the project_id variable. Otherwise, the identity performing the deployment needs resourcemanager.projectCreator on the resource hierarchy node specified by project_create.parent and billing.user on the billing account specified by project_create.billing_account_id.

Step 0: Cloning the repository

If you want to deploy from your Cloud Shell, click on the image below, sign in if required and when the prompt appears, click on “confirm”.

Open Cloudshell

Otherwise, in your console of choice:

git clone https://github.com/GoogleCloudPlatform/cloud-foundation-fabric

Before you deploy the architecture, you will need at least the following information (for more precise configuration see the Variables section):

  • The project ID.
  • A Google Cloud Registry path to a Wordpress container image.

Step 1: Add Wordpress image

In order to deploy the Wordpress service to Cloud Run, you need to store the Wordpress image in Google Cloud Registry (GCR).

Make sure that the Google Container Registry API is enabled and run the following commands in your Cloud Shell environment with your project_id in place of the MY_PROJECT placeholder:

docker pull bitnami/wordpress:6.0.2
docker tag bitnami/wordpress:6.0.2 gcr.io/MY_PROJECT/wordpress
docker push gcr.io/MY_PROJECT/wordpress

Note: This example has been built for this particular Docker image. If you decide to use another one, this example might not work (or you can edit the variables in the Terraform files).

Step 2: Prepare the variables

Once you have the required information, head back to your cloned repository. Make sure youre in the directory of this tutorial (where this README is in).

Configure the Terraform variables in your terraform.tfvars file. See terraform.tfvars.sample as starting point - just copy it to terraform.tfvars and edit the latter. See the variables documentation below.

Notes:

  1. If you will want to change your admin password later on, please note that it will only work in the admin interface of Wordpress, but not with redeploying with Terraform, since Wordpress writes that password into the database upon installation and ignores the environment variables (that you can change with Terraform) after that.
  2. If you have the domain restriction org. policy on your organization, you have to edit the cloud_run_invoker variable and give it a value that will be accepted in accordance to your policy.

Step 3: Deploy resources

Initialize your Terraform environment and deploy the resources:

terraform init
terraform apply

The resource creation will take a few minutes.

Note: you might get the following error (or a similar one):

│ Error: resource is in failed state "Ready:False", message: Revision '...' is not ready and cannot serve traffic.│

You might try to reapply at this point, the Cloud Run service just needs several minutes.

Step 4: Use the created resources

Upon completion, you will see the output with the values for the Cloud Run service and the user and password to access the /admin part of the website. You can also view it later with:

terraform output
# or for the concrete variable:
terraform output cloud_run_service
  1. Open your browser at the URL that you get with that last command, and you will see your Wordpress installation.
  2. Add "/admin" in the end of the URL and log in to the admin interface, using the outputs "wp_user" and "wp_password".

Cleaning up your environment

The easiest way to remove all the deployed resources is to run the following command in Cloud Shell:

terraform destroy

The above command will delete the associated resources so there will be no billable charges made afterwards.

Variables

name description type required default
prefix Prefix used for resource names. string
project_id Project id, references existing project if project_create is null. string
wordpress_image Image to run with Cloud Run, starts with "gcr.io". string
admin_principal User or group that is assigned roles, in IAM format (group:foo@example.com). string null
cloud_run_invoker IAM member authorized to access the end-point (for example, 'user:YOUR_IAM_USER' for only you or 'allUsers' for everyone). string "allUsers"
cloudsql_password CloudSQL password (will be randomly generated by default). string null
connector Existing VPC serverless connector to use if not creating a new one. string null
create_connector Should a VPC serverless connector be created or not. bool true
deletion_protection Prevent Terraform from destroying data storage resources (storage buckets, GKE clusters, CloudSQL instances) in this blueprint. When this field is set in Terraform state, a terraform destroy or terraform apply that would delete data storage resources will fail. bool false
ip_ranges CIDR blocks: VPC serverless connector, Private Service Access(PSA) for CloudSQL, CloudSQL VPC. object({…}) {…}
project_create Provide values if project creation is needed, uses existing project if null. Parent is in 'folders/nnn' or 'organizations/nnn' format. object({…}) null
region Region for the created resources. string "europe-west4"
wordpress_password Password for the Wordpress user (will be randomly generated by default). string null
wordpress_port Port for the Wordpress image. number 8080

Outputs

name description sensitive
cloud_run_service CloudRun service URL.
cloudsql_password CloudSQL password.
wp_password Wordpress user password.
wp_user Wordpress username.

Test

module "test" {
  source          = "./fabric/blueprints/third-party-solutions/wordpress/cloudrun"
  admin_principal = "group:foo@example.com"
  prefix          = "wp-cr-test"
  project_create = {
    billing_account_id = "1234-ABCD-1234"
    parent             = "folders/1234563"
  }
  project_id      = "test-prj"
  wordpress_image = "gcr.io/myprj/wordpress"
}
# tftest modules=5 resources=33