Infrastructure: local setup

Hi, how are you?

I’m creating some Terraform and Crossplane modules, and I’d like to know how to set up a local lab to test the creation of org, environment, and envgroups.

Is there a similar “ministack” for GCP that supports Apigee?

How do you mock the GCP/Apigee API?

Hi @kelvingl — welcome to the Apigee community! We have seen your question regarding local testing and mocking options for Apigee infrastructure setup, we encourage our community to chime in and share their insights.

In the meantime, we invite you to join our upcoming Community TechTalks! We host a live community session each Thursday. It’s a great place to come learn directly from Googlers and ask your questions live :right_arrow: Register for the Community TechTalks.

Thanks for reaching out, and we’re glad to have you here!

1. Is there a “LocalStack” / “MiniStack” for GCP that supports Apigee?

No, there is currently no official or community drop-in local emulator for the Apigee Control Plane.

It helps to differentiate the two layers of Apigee:

  • Control Plane (apigee.googleapis.com): Handles resource management (Orgs, Environments, Envgroups, Instances, Attachments). There is no local emulator for these administrative REST APIs.
  • Data Plane / Runtime: Google provides the Apigee Emulator (via Docker: gcr.io/apigee-release/hybrid/apigee-emulator), but this is strictly built for developing and testing API proxies locally (e.g., via VS Code / Cloud Code), not for provisioning infrastructure with Terraform or Crossplane.

2. How to test and mock Apigee infrastructure modules

Because control-plane operations (especially Orgs and Instances) involve asynchronous Long-Running Operations (LROs) and complex backend dependencies, full local emulation is rarely practical. Instead, the standard approach is a multi-tier testing strategy:

Tier 1: Local Static & Schema Validation (Fast & 100% Offline)

  • Terraform:
    • Use terraform validate and tflint for syntax and linting.

    • Use terraform test with command = plan to assert module outputs, resource attributes, and naming conventions without touching cloud infrastructure:

      HCL# tests/unit.tftest.hcl
      run "validate_envgroup_attachment" {
        command = plan
      
        assert {
          condition     = google_apigee_envgroup_attachment.env_attachment.environment == "dev"
          error_message = "Environment attachment did not point to expected 'dev' environment"
        }
      }
      
      
  • Crossplane:
    • Validate Composition logic, patch/transform rules, and Composed Resources offline using the Crossplane CLI:

      BASHcrossplane beta render xr.yaml composition.yaml functions.yaml
      crossplane beta validate
      
      

Tier 2: Mocking the Apigee API (Custom HTTP Endpoints)

If you want to run terraform apply or test a custom provider client against a local mock server, you can override the API endpoint in the Google Terraform provider:

HCLprovider "google" {
  project                = "mock-project"
  apigee_custom_endpoint = "http://localhost:8080/v1/"
  access_token           = "mock-token"
}

You can then run an HTTP mock server (e.g., WireMock, Prism, or Smocker) to simulate responses for endpoints like:

  • POST /v1/organizations/{org}/environments
  • POST /v1/organizations/{org}/envgroups
  • GET /v1/organizations/{org}/operations/{operationId} (polling LROs)

Note: While feasible for simple unit testing of resource creation, maintaining mock states for async LRO polling and state reconciliation can become cumbersome for complex setups.


Tier 3: Automated Ephemeral Sandboxes (Recommended for E2E / Integration)

For reliable end-to-end testing of Terraform and Crossplane modules:

  1. Apigee Evaluation (Eval) Org / Pay-as-you-go: Spin up an evaluation or pay-as-you-go project in GCP.
  2. Integration Test Automation: Use Terratest (Go) or Kuttl (for Crossplane) in your CI pipeline to provision real resources in an isolated sandbox and destroy them immediately after validation.