Add terraform tencentcloud support#629
Conversation
adcf226 to
6f058de
Compare
Package a Dockerfile alongside the prebuilt cube-api binary so the one-click release bundle can be turned into a container image directly from an extracted bundle. Assisted-by: Cursor:claude-opus-4.8 Signed-off-by: Like Xu <likexu@tencent.com>
Package a Dockerfile alongside the prebuilt cubemaster binary so the one-click release bundle can be turned into a container image directly from an extracted bundle. Assisted-by: Cursor:claude-opus-4.8 Signed-off-by: Like Xu <likexu@tencent.com>
Provide a multi-stage Dockerfile that builds the dashboard from source and a package Dockerfile that serves the prebuilt dashboard from an extracted one-click release bundle, both served by OpenResty. Assisted-by: Cursor:claude-opus-4.8 Signed-off-by: Like Xu <likexu@tencent.com>
Add a Terraform-based deployer that stands up a clustered CubeSandbox on Tencent Cloud: a managed TKE control plane running cubemaster, cube-api, cube-proxy and cube-webui, backed by cloud MySQL and Redis, with one or more CVM PVM compute nodes inside a private VPC reached through an SSH jumpserver. The deployer is driven by create.sh and destroy.sh and runs directly from an extracted release bundle: it can work offline from the local bundle, builds and pushes the component images, and provisions the network, databases, TCR, TKE addons and compute nodes in a phased, fail-fast and re-runnable flow, tearing everything down on destroy. Wire the deployer into the release-bundle build, add a Terraform validate CI workflow, and document the full workflow in both the English and Chinese one-click READMEs. Assisted-by: Cursor:claude-opus-4.8 Signed-off-by: Like Xu <likexu@tencent.com>
6f058de to
bb56fba
Compare
| Poststop = true | ||
| Prestop = true | ||
| } | ||
| cube_box_req_template = "{\"volumes\":[{\"name\":\"tmp\",\"volume_source\":{\"empty_dir\":{\"medium\":0}}}],\"containers\":[{\"name\":\"cubebox-default\",\"envs\":[{\"key\":\"TZ\",\"value\":\"Asia/Shanghai\"},{\"key\":\"TERM\",\"value\":\"xterm\"}],\"volume_mounts\":[{\"name\":\"tmp\",\"container_path\":\"/\"}],\"security_context\":{\"privileged\":true,\"readonly_rootfs\":false,\"no_new_privs\":false}}],\"network_type\":\"tap\",\"cubevs_context\":{\"allowInternetAccess\":true,\"denyOut\":[\"10.0.0.0/8\",\"100.64.0.0/10\",\"172.16.0.0/12\",\"192.168.0.0/18\"]}}" |
There was a problem hiding this comment.
This template uses cubevs_context, but CubeMaster deserializes the request into cube_network_config / CreateCubeSandboxReq.CubeNetworkConfig. Go's JSON decoder will ignore the unknown field, so the default allowInternetAccess / denyOut policy configured here will not be applied in the TKE deployment. Please switch this to cube_network_config and add a regression test that deserializes this template and asserts the network config is populated.
| cube_proxy_image = "${local.image_registry}/${local.image_namespace}/cubeproxy:${var.image_tag}" | ||
| cube_webui_image = "${local.image_registry}/${local.image_namespace}/cube-webui:${var.image_tag}" | ||
|
|
||
| cube_db = "cube_mvp" |
There was a problem hiding this comment.
create.sh and env.example expose TENCENTCLOUD_CUBE_DB / TENCENTCLOUD_CUBE_USER, but the Terraform addon config still hard-codes cube_mvp / cube. If a user enters non-default values, the saved environment and later checks can drift from what the control plane actually uses. Please either wire these through Terraform as real variables everywhere, or remove the unsupported prompts/env examples so the deployer does not imply customization works.
| ssh_key="${TENCENTCLOUD_SSH_PRIVATE_KEY_PATH:-$SSH_PRI_KEY}" | ||
| if [ -z "$js_pub_ip" ]; then | ||
| echo -e "${YELLOW}⚠ jumpserver unavailable, skipping cube-proxy certificate generation${NC}" | ||
| return 0 |
There was a problem hiding this comment.
This failure path continues even though cube-proxy later requires cube.app+3.pem and cube.app+3-key.pem to be present. In TENCENTCLOUD_BUILD_IMAGES=0, weak-network, or incomplete local-bundle deployments, this can leave Terraform without the cubeproxy-certs ConfigMap or start cube-proxy with missing TLS files, causing apply failures or Pod CrashLoop. Please fail fast before deploying addons unless both required cert files exist, or explicitly support and validate a BYO-certificate path.
| pull_request: | ||
| types: [opened, synchronize, reopened] | ||
| paths: | ||
| - 'deploy/one-click/terraform/**' |
There was a problem hiding this comment.
The Terraform validation workflow only triggers on deploy/one-click/terraform/**, but this PR's deployer also depends on deploy/one-click/build-release-bundle.sh and the component Dockerfile/package contexts. Changes there can break bundle layout or image builds without running this validation. Please extend the path filters and consider adding a lightweight package-layout dry run so quickstart/package deployment regressions are covered.
fslongjin
left a comment
There was a problem hiding this comment.
Additional inline comments from the responsibility/redundancy/correctness review section.
|
|
||
| # ============================================================ | ||
| # Sequential, fail-fast provisioning. Each step below is a synchronous | ||
| # terraform apply (restricted to that step's resources via -target) that must |
There was a problem hiding this comment.
create.sh now owns interaction, Terraform orchestration, state recovery, image build/push, certificate generation, health checks, and compute-node initialization. That is acceptable for an initial deployer, but the script is becoming the deployment state machine. Please consider splitting the high-risk phases into smaller sourced modules, or at least adding scripted coverage for the phase transitions and rerun paths so future changes do not regress one-click deployment recovery.
| idle_timeout = 30 | ||
| max_retry = 2 | ||
| } | ||
| redis_read = { |
There was a problem hiding this comment.
Please verify that CubeMaster actually consumes redis_read / redis_write. I do not see matching fields in the current CubeMaster config structure, so these entries appear to be dead configuration. If they are not supported, removing them would avoid implying read/write Redis separation that the control plane ignores; otherwise the server-side config type should be updated and covered by a config parsing test.
| # TENCENTCLOUD_SSH_PORT SSH port on compute nodes through the jumpserver (22) | ||
| # TENCENTCLOUD_SSH_PRIVATE_KEY_PATH SSH private key (default ./.ssh/id_rsa, auto-generated) | ||
| # TENCENTCLOUD_SSH_PUBLIC_KEY_PATH SSH public key (default ./.ssh/id_rsa.pub) | ||
| # TENCENTCLOUD_CUBE_{MASTER,API,PROXY,WEBUI}_IMAGE per-component image ref overrides |
There was a problem hiding this comment.
This advertises per-component image overrides, but the addon Terraform only composes images from image_registry / image_namespace / image_tag, and create.sh only exports TF_VAR_image_tag. In TENCENTCLOUD_BUILD_IMAGES=0 or bring-your-own-image scenarios, users may set these variables and still get the default composed images. Please either wire per-component image refs through Terraform, or remove this documented override.
| # only connects once the API Server exists — until then create_tke / | ||
| # deploy_tke_addons stay OFF for every base apply. | ||
| # ============================================================ | ||
| export TF_VAR_create_tke=false |
There was a problem hiding this comment.
The phased terraform apply -target flow depends on TF_VAR_create_tke and TF_VAR_deploy_tke_addons being exactly right across first runs and reruns. A stale or wrong phase flag can hide count-gated resources from Terraform or make the Kubernetes provider connect at the wrong time. Please add a lightweight dry-run/integration check for rerun scenarios, especially after partial failure, so this one-click path remains recoverable.
Add a Terraform-based deployer that stands up a clustered CubeSandbox on
Tencent Cloud, complementing the existing single-machine
install.sh.cubemaster/cube-api/cube-proxy/
cube-webui, backed by cloud MySQL + Redis, with one or more CVM PVMcompute nodes inside a private VPC reached through an SSH jumpserver (port 443).
create.shis the single entry point anddestroy.shtears everything down.Both run directly from an extracted release bundle and can work fully offline
from the local bundle (with an online-install fallback).
image build/push → MySQL/Redis → TKE + addons → health checks → compute setup.
A partial failure can be fixed and resumed by simply re-running
create.sh.sandbox-package), wired into the release-bundle build, and documented in boththe English and Chinese one-click READMEs.
terraform-validateGitHub Actions workflow (fmt + validate +shellcheck) for
deploy/one-click/terraform/**.Assisted-by: Cursor:claude-opus-4.8
How to test:
Tested .env demo:
You may try different CVMs in different regions.
I expect to uncover all sorts of defects and issues while testing the cluster version of Cubesandbox.
There’s a lot to explore here when it comes to contributing to open source - let’s get started.