GoodData.CN POC

Spin up a GoodData.CN deployment in the cloud in just a few minutes.

This deployment is for evaluation only – not production. It can be used as a source of inspiration for a production-level setup, but this project is not versioned and is not officially supported by GoodData in production.

How It Works

Terraform provisions:

Cloud network with public & private subnets across multiple zones
Managed PostgreSQL for GoodData metadata
Object storage for cache, data sources, and exports
Managed Kubernetes cluster
- GoodData.CN
- Apache Pulsar (for messaging)
- Ingress controller
- Other cloud-specific prerequisites

Quickstart

Setup

Install the following CLI utilities:
- Terraform
- Cloud provider CLI (AWS, Azure)
- For Azure deployments: kubelogin
- kubectl
- helm
- For local deployments:
  - Docker
  - k3d
- tinkey
- Standard utilities like curl, openssl, and base64
Have your GoodData.CN license key handy (your GoodData contact can help you with this)

Note: If you want to skip the installation of all of the CLI utilities, a VS Code Dev Containers configuration is provided in this repo. Just install the extension into any compatible IDE and the repo will reopen with all utilities installed.

(optional, AWS only) Use an existing VPC

By default Terraform creates a new VPC. If your IT team has already provisioned a VPC for the PoC, you can deploy into it instead by setting three variables in aws/settings.tfvars:

existing_vpc_id             = "vpc-0123456789abcdef0"
existing_private_subnet_ids = ["subnet-aaa", "subnet-bbb"]
existing_public_subnet_ids  = ["subnet-ccc", "subnet-ddd"]

Requirements:

The VPC must have DNS hostnames and DNS support enabled.
Provide at least 2 private and 2 public subnet IDs, spanning at least 2 availability zones.
Private subnets are used for EKS nodes and RDS; public subnets are used for load balancers.
Subnets must carry the following tags for the AWS Load Balancer Controller and EKS to discover them:
- Public subnets: kubernetes.io/role/elb = 1 and kubernetes.io/cluster/<deployment_name> = shared
- Private subnets: kubernetes.io/role/internal-elb = 1 and kubernetes.io/cluster/<deployment_name> = shared

Deploy

Clone the repo: git clone https://github.com/gooddata/gooddata-cn-terraform.git

Copy the sample variables file for your provider and customize it:

cp aws/settings.tfvars.example aws/settings.tfvars
# or (for azure)
cp azure/settings.tfvars.example azure/settings.tfvars
# or (for local)
cp local/settings.tfvars.example local/settings.tfvars

The example file has good defaults but you may want to modify it based on your needs.

Choose your provider and cd into its directory: cd aws, cd azure, or cd local
Authenticate to your cloud provider's CLI:
- For AWS: authenticate the profile named by aws_profile_name in settings.tfvars, since Terraform uses it regardless of your default profile. For an IAM Identity Center (SSO) profile that is aws sso login --profile <aws_profile_name>; for access keys it is aws configure --profile <aws_profile_name>.
- For Azure: az login
- Azure note: Terraform's Kubernetes authentication uses kubelogin with your Azure CLI session.
Initialize Terraform: terraform init
Review what Terraform will deploy: terraform plan -var-file=settings.tfvars
Run Terraform:
- For cloud deployments: terraform apply -var-file=settings.tfvars
- For local deployments, first create the cluster, then apply everything else:
```
terraform apply -target=null_resource.k3d_cluster -var-file=settings.tfvars
terraform apply -var-file=settings.tfvars
```
Once everything has been deployed, configure kubectl: ../scripts/configure-kubectl.sh
If you set gdcn_orgs, Terraform already created the organizations. Otherwise, you can create those manually now.
Configure authentication according to your needs:
- To use an external OIDC provider (recommended for anything beyond local testing), follow the Set Up Authentication guide.
- For quick testing with the default IdP (Dex), create one or more users by staying in the provider directory (aws, azure, or local) and running ../scripts/create-user.sh. If Terraform created the organization, the script will automatically read the admin credentials from the Secret gooddata-cn/gdcn-org-admin-<org_id>.
(Optional) If you enabled the observability stack (enable_observability = true), create Grafana users by running ../scripts/create-grafana-user.sh from your provider directory. The script creates a Grafana user and optionally promotes them to admin. It automatically reads the Grafana admin credentials from the Kubernetes secret.
Finally, open your GoodData.CN URL and log in.
- For cloud deployments: open https://<gdcn_org_hostname> (exact address in Terraform output).
- For local deployments: open https://gooddata.localhost (you will see a browser warning because the certificate is self-signed).

Upgrading GoodData.CN

To upgrade GoodData.CN to the latest version, follow these steps:

Check for any updates to this repo and pull them.
Open settings.tfvars and change the helm_gdcn_version variable to the latest value.
Run Terraform: terraform apply -var-file=settings.tfvars

Tearing down

To delete all resources associated with the GoodData POC, follow these steps:

Run Terraform: terraform destroy -var-file=settings.tfvars

Observability

Set enable_observability = true and observability_hostname in your settings.tfvars to deploy the observability stack (Prometheus, Loki, Tempo, and Grafana).

After terraform apply, Grafana is available at https://<observability_hostname>. A GoodData-CN health dashboard is automatically provisioned and can be found under the GoodData-CN folder in Grafana.

To import the dashboard into a standalone Grafana instance, upload modules/k8s-common/dashboards/gooddata-cn-overall-health.json via Dashboards → Import and replace the datasource UIDs (prometheus → your Prometheus UID, loki → your Loki UID).

LLM observability

Set enable_llm_observability = true, llm_observability_hostname and langfuse_admin_email in your settings.tfvars to deploy Langfuse and send traces from the gen-ai services to it. This also requires enable_ai_features = true, since those services are what produce the traces. Langfuse brings its own ClickHouse, Keeper, and Valkey pods, so expect it to add a few GB of memory to the cluster.

After terraform apply, Langfuse is available at https://<llm_observability_hostname>. Traces appear within a few seconds of using any AI feature, tagged with langfuse_tracing_environment (dev unless you change it).

An admin user is created on the first apply, and self-registration is disabled, so this is the only account. Read its credentials from the Terraform output in your provider directory:

terraform output langfuse_admin_email
terraform output -raw langfuse_admin_password

Invitations are not wired up (Langfuse blocks sign-up before it checks them), so treat this output as a shared deployment secret and keep it within the team that already has cluster access.

Installing an internal build (GoodData employees)

Internal only — the registry is unreachable outside GoodData. Leave these unset to install the released chart. <registry> is in the internal deployment docs.

Run the adhoc: Build pipeline. You can set deploy_to_adhoc=false since we'll deploy here instead.
Copy the chart version from its Generate version used by chart/images step. The <sha> in it is also the image tag.

Add to settings.tfvars in any environment:

internal_chart_repository     = "oci://<registry>/helm/gooddata/adhoc"
helm_gdcn_version             = "0.1.<timestamp>+<sha>"
internal_registry_server      = "<registry>"
internal_registry_aws_profile = "<profile>"

# The chart pins image tags but not the registry, and ships no UI tags at all.
# Without both of these, components resolve to Docker Hub (no branch builds are
# published there) and the UI to an empty tag.
gdcn_helm_extra_values = <<-EOT
  image:
    repositoryPrefix: <registry>/nas-testing
  analyticalDesigner: { image: { repositoryPrefix: gooddata, tag: "<released-version>" } }
  dashboards:         { image: { repositoryPrefix: gooddata, tag: "<released-version>" } }
  homeUi:             { image: { repositoryPrefix: gooddata, tag: "<released-version>" } }
  hostApplication:    { image: { repositoryPrefix: gooddata, tag: "<released-version>" } }
  webComponents:      { image: { repositoryPrefix: gooddata, tag: "<released-version>" } }
EOT

Run terraform apply -var-file=settings.tfvars

Need help?

Reach out to your GoodData contact and they'll point you in the right direction!

Name		Name	Last commit message	Last commit date
.claude/skills/sync-settings-tfvars		.claude/skills/sync-settings-tfvars
.devcontainer		.devcontainer
aws		aws
azure		azure
local		local
modules		modules
scripts		scripts
.gitignore		.gitignore
AGENTS.md		AGENTS.md
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
NOTICE.txt		NOTICE.txt
README.md		README.md
renovate.json		renovate.json

Navigation Menu

Repository files navigation

GoodData.CN POC

How It Works

Quickstart

Setup

(optional, AWS only) Use an existing VPC

Deploy

Upgrading GoodData.CN

Tearing down

Observability

LLM observability

Installing an internal build (GoodData employees)

Need help?

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

GoodData.CN POC

How It Works

Quickstart

Setup

(optional, AWS only) Use an existing VPC

Deploy

Upgrading GoodData.CN

Tearing down

Observability

LLM observability

Installing an internal build (GoodData employees)

Need help?

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages