Tag Archives: Terraform

Configure your private clouds using the Google Cloud VMware Engine IaC Foundations repository

Introduction

Google Cloud VMware Engine is a Google-managed VMware platform that customers can use to run their VMware workloads on Google Cloud. VMware Engine private clouds consist of VMware ESXi clusters that are managed by Google. Customers manage the virtual infrastructure of private clouds using VMware vCenter and VMware NSX-T for software-defined networking. The GCVE IaC Foundations code guides customers to automate the configuration of several layers of the infrastructure and virtualization stack, using infrastructure as code. This includes the integration of platform logging and monitoring with the Google Cloud Operations Suite, configurations such as VM folders, permissions and VM deployments in vCenter and network configurations in NSX-T, including subnets, firewalls, and load balancers.

The use of infrastructure as code for a VMware Engine Private Cloud offers multiple benefits, including:

  1. Providing consistent and repeatable deployment templates which can be reused across SDLC environments to reduce human error and shorten configuration times.
  2. Enabling continuous integration using GitOps workflows to improve collaboration between engineers and increase reliability in the release process.
  3. Offering version control of configuration templates to track changes in the infrastructure and a simple method to revert changes to a previous configuration.

Technical Details

The Google Cloud VMware Engine IaC Foundations Github repository contains Terraform modules and sample code for maintaining VMware Engine, vCenter and NSX-T configurations using infrastructure as code. The repository is structured as follows:

├── examples
│ ├── nsxt-gateway-firewall
│ ├── nsxt-load-balancer-pool
│ ├── nsxt-load-balancer-service
│ ├── ...
├── modules
│ ├── nsxt-gateway-firewall
│ ├── nsxt-load-balancer-pool
│ ├── nsxt-load-balancer-service
│ ├── ...
└── stages
├── 01-privatecloud
├── 02a-nsxt
├── 02b-vcenter
├── 03-vms
└── 04-load-balancing

The modules directory contains the Terraform IaC modules for GCVE (vCenter & NSX-T) resource types. Each module has a corresponding example in the examples directory. Modules and examples are meant to be discrete and function as the building blocks for managing GCVE at scale.

The stages directory contains sample deployments composed from modules for each of the different stages of the foundational deployment. These stages should be executed in the order they are listed. Stages may also be delegated to different teams within an organization depending on organizational roles and responsibilities. As an example, there may be a team that manages vCenter, while a Networking team manages NSX-T and each team has their own code repository for configuration management.

The individual stages deploy the following components:

Stage

Deployed sample Component(s)

01-privatecloud

  • Google Cloud Monitoring & Logging integration for GCVE

02a-nsxt

  • Virtual machine network segment

  • North / south firewall (gateway firewall)

  • East / west firewall (distributed firewall)

02b-vcenter

  • vCenter resource pools & folders

  • vCenter role assignments

03-vms

  • Virtual machines

04-load-balancing

  • NSX-T Load balancing

Deployment Walkthrough

To deploy the sample stages you will need to clone the gcve-iac-foundations repository and have Terraform 1.3.x or later installed.

To deploy the stages proceed in order in the stages directory from 01-privatecloud until 04-load-balancing. In each directory perform the following:

  • Copy terraform.tfvars.example to terraform.tfvars and customize any values as necessary
  • Run `terraform init`, `terraform plan` and `terraform apply`

Each of the stages and examples contain reference terraform.tfvars files which can be used in the initial stages to test deployment and later customized to meet specific requirements.

As an example, the following Terraform configuration can be used to configure the NSX-T distributed firewall:

dfw_policies = [
{
display_name = "dfw_allow_policy"
sequence_number = 1
rules = [
{
action = "ALLOW"
destination_groups = ["10.123.1.0/24"]
source_groups = []
direction = "IN_OUT"
display_name = "dfw-allow-ssh"
logged = false
services = ["SSH"]
},
{
action = "ALLOW"
destination_groups = ["10.123.2.0/23"]
source_groups = ["10.200.1.0-10.200.1.128"]
direction = "IN_OUT"
display_name = "dfw-allow-dns"
logged = false
services = ["DNS"]
},
]
},
<…snip…>
]

Apply the Terraform configuration from a terminal using

terraform init // initialize the provider and modules
terraform plan // validate the expected Terraform configuration on the console
terraform apply // deploy the configuration in NSX-T

Try it yourself

Whether you consider using VMware Engine for your VMware workloads or you actively use the service already, give it a try and clone the repository into your environment and go through the provided deployment examples and stages of the repository. Review if you can automate any processes that you perform manually today using infrastructure-as-code and improve your VMware operations using the content from the foundations repository.

We would like to get your feedback! If you encounter any issues or you have any feedback or suggestions for improvement, create an issue directly on the repository on Github. We would also like to encourage you to create pull requests to the main branch if you like to become an active contributor. To get started, review how to contribute on Github.

By Konrad Schieban and Jason Steenblik – Google Cloud

Acknowledgments:

Thank you to the following team members who made this solution possible: Kumari Renuka, Ashwin Naik, Leandro Carracedo, Eric Danan, and Umesh Kumhar from Google Cloud.

Four areas of open source contributions from Cloud Databases

Open Cloud enables you to develop software faster, innovate more easily, and scale more efficiently—while also reducing technology risk. Google has a long history of leadership in open source, and today, I want to look back at our activities around open source projects, for databases, over the past year.

Give developers the best tools to be efficient

Developers choose to build applications with managed database services on Google Cloud to benefit from velocity, scalability, security, and performance. To enable you to be most efficient and deliver your best possible work, we deliver tools and frameworks that work with your preferred development environments, no matter if you develop in the cloud or on premises. To make local testing, building and continuous integration easier for our cloud-native databases, we released emulators for Cloud Spanner, Firestore, and Cloud Bigtable so that you can test your code wherever you develop it - without the need to create or re-create cloud infrastructure with every test run.

Another area where we are helping developers is with instrumentation of Cloud SQL for easier debugging and performance tuning. With Cloud SQL Insights it is easier than ever to pinpoint underperforming SQL statements. That said, without additional instrumentation, it can be cumbersome to identify the source code or microservice that issued that SQL - let alone tying a SQL statement to a client session and its context. So we released Sqlcommenter as an open source library that will automatically add this instrumentation as SQL comments in queries that are generated by popular ORMs like Hibernate, Django, Sqlalchemy, and others (repo blog). We didn’t stop there, but merged Sqlcommenter with OpenTelemetry (blog) to add SQL insights from instrumented queries back to OpenTelemetry traces.

Lastly, we want to broaden access to our differentiated offerings, like Spanner. The recently announced Spanner PostgreSQL interface allows organizations to access Spanner’s industry-leading consistency and availability at scale using tools and skills from the popular PostgreSQL ecosystem. This new way of working with Spanner provides familiarity for developers and portability for administrators. (blog) Learn more in the documentation or sign up for the preview today.

Provide connectivity that is simple and secure

Connecting to APIs and databases from an application running in the cloud should be simple and secure. That’s why we recommend using IAM and Application Default Credentials when authenticating to other services. The Cloud SQL Proxy (repo) has been doing this and also setting up firewalls for you for a while. It works by running a local client either inside your VM or a GKE cluster. This year, we added libraries for Java (repo) and Python (repo) that can provide similar functionality without the overhead of running an extra client such as the proxy.

Cloud Spanner also offers an open source adapter for its new PostgreSQL interface (repo). This local proxy allows tools, starting with psql, to connect to a Spanner database using the PostgreSQL wire protocol.

Image 1: White pipes in datacenter

Manage cloud infrastructure with the tools of your choice

When it comes to provisioning, monitoring, and managing your cloud database services, flexibility and choice are important. We provide you with our cloud console, gcloud cli, and APIs as well as our own Deployment Manager. That said, you may prefer different ways to manage cloud infrastructure - whether through interactive tools or scripts or embedded into CI/CD pipelines that support GitOps or other controls, checks, and balances. Terraform is one of those open tools that is very popular - and we ensure that our cloud databases can be managed from it as documented in this blog about creating Spanner instances with Terraform.

If you manage the majority of your resources with Kubernetes either directly or through package managers like Helm, then our Kubernetes Config Connector (KCC) might be for you. In a nutshell, KCC exposes Google Cloud services such as Cloud SQL, Spanner, and others as Custom Resources in Kubernetes. This allows you to create and reconcile cloud resources outside of Kubernetes just like K8s native objects.

Once you are managing cloud infrastructure with CI/CD, the next step is to extend that same mechanism to manage objects within your databases such as tables, indexes, and views. To that extent we have released a Liquibase extension for Cloud Spanner.

Help you to move data with confidence

Cloud journeys often involve moving data either in a lift and shift process or sometimes replatforming to a different database. Whatever your journey, we want to simplify the process and give you the confidence that your migration is successful.

For enterprise users with Oracle databases, we have several open source projects. First, we have the Optimus Prime database assessment tool (repo) that queries your database and collects information about schemas and historic performance to be analyzed for migration complexity and consolidation potential. Our own professional services teams have been using this toolset to plan migrations to Bare Metal Solution for Oracle.

Some Oracle users are looking for opportunities to transform their workloads to fit with their bigger strategy of modernizing applications with Kubernetes. For this group we developed and open sourced the El Carro Kubernetes operator for Oracle. This not only automates database lifecycle tasks for systems running on Kubernetes, but also exposes declarative APIs for these operations.

If your application supports replatforming from Oracle to PostgreSQL, then we have a toolset for schema conversion along with dataflow pipelines that will read the output of a change data capture job and load it into a PostgreSQL database. What a great use-case for Datastream - our new serverless change data capture service.

Another case of heterogeneous database migration is to move MySQL or PostgreSQL databases to Cloud Spanner. HarbourBridge helps with the evaluation and data migration, and our latest contribution was adding support for DynamoDB as a source database. Part of every heterogeneous migration should be to validate that the source and target data are matching - we have released the Data Validation Toolkit for that use-case. DVT can connect to a number of source and target databases and compare the data on each side - giving you the confidence that your migration did not miss or change any records.

Conclusion

Whether you are migrating existing databases or you are building your next application in the cloud - we want to make your journey as comfortable and seamless as possible. Open source projects play a big role in meeting you where you are and providing you with the connectivity options, language support, and tools you want for management and migrations.

By Bjoern Rost, Product Manager, Google Cloud Databases