- Super Quick Start
- Detailed Quick Start
-
make setup.aws- create the inventory file with global variables. -
vim build/inventory.yaml- edit and update the variables. -
make build- build an image for deploying RPK. -
make deploy- deploy RPK.
This guide will take you through all of the necessary steps to prepare for and to deploy RPK.
A custom inventory will need to be created in order to define which cluster(s) you will be deploying RPK to. This inventory file is a standard Ansible inventory file, in YAML format. The inventory file additionally contains all of the necessary variables that feed into the deployment process.
To create your inventory file, run the following command:
make setup.awsNOTE: The command above will drop your inventory file example at
build/inventory.yaml. If you need the inventory file at another location, you can runINVENTORY=/path/to/my/inventory.yaml make setup.awsfor example. Be sure that theINVENTORYvariable matches this for following build and deploy steps.
After creating your inventory file, you will need to modify required variables that fit your environment needs:
vim build/inventory.yamlCommon variables, regardless of provider type, that will need to be modified are as follows:
| Variable Name | Variable Type | Required | Default Value | Description |
|---|---|---|---|---|
| rpk_profile | string | true | (none) | Name of the RPK profile (collection of cluster components) to deploy . Can be set to platform or advanced. See the contribution guide for more details on profiles here. |
| tanzu_cluster_name | string | true | (none) | The DNS friendly name (e.g. no underscores or special characters) of the cluster |
| tanzu_default_tls_provider | string | true | "ca" | The default method for ingress TLS certificate deployment. Can be set to "ca", "letsencrypt-stage", or "letsencrypt-prod" See Ingress TLS Certificates for expanded information on each setting. |
| tanzu_dns_provider | string | true | route53 | The DNS provider/backend. Currently route53, internal, nip.io, and local are valid options. See Choosing the Appropriate DNS Solution for expanded information on each setting. |
| tanzu_ingress_domain | string | true | (none) | The ingress domain, which will be used to add ingress DNS records to |
| tanzu_kubectl_context | string | true | (none) | The kubectl context (from kubeconfig) which represents the TKG target deployment cluster |
TKG clusters which are hosted on AWS should modify cluster variables (represented in the
inventory as aws_tanzu_cluster1) specific to AWS.
Common variables, specific to the AWS provider type, that will need modified are as follows:
| Variable Name | Variable Type | Required | Default Value | Description |
|---|---|---|---|---|
| tanzu_storage_classes_aws | list of dicts | true (AWS only) | [] |
See documentation at Storage README for examples. |
In most cases you will not need to manipulate any of the preset variables for RPK components. However, you may encounter edge cases where the behavior of a component needs to be tuned or modified to affect how it is deployed into your cluster. This is a rare circumstance, but if you would like to delve into all the possible configuration options for the deployment of RPK, see each of the component specific documentation pages from the table below.
The following components are displayed in the order they will be deployed to a TKG cluster. Additional tuning and behavior can be changed by adding additional variables to your build/inventory.yaml.
| Component Name | Documentation |
|---|---|
| workload-tenancy | README.md |
| networking | README.md |
| security | README.md |
| admission-control | README.md |
| storage | README.md |
| ingress | README.md |
| identity | README.md |
| monitoring | README.md |
| container-registry | README.md |
| logging | README.md |
| autoscaling | README.md |
| secret-management/hashicorp-vault | README.md |
| application-stack | README.md |
| application-pipeline | README.md |
The following components are displayed in the order they will be deployed to a TKG cluster. Additional tuning and behavior can be changed by adding additional variables to your build/inventory.yaml.
| Component Name | Documentation |
|---|---|
| networking | README.md |
| container-registry | README.md |
| tanzu-mission-control | README.md |
| spring-cloud-gateway | README.md |
| spring-cloud-data-flow | README.md |
| tanzu-application-catalog | README.md |
| tanzu-build-service | README.md |
| tanzu-observability | README.md |
| tanzu-sql | README.md |
If your cluster is a TMC-provisioned cluster, the following steps need to be performed:
-
Install the TMC binary. See https://docs.vmware.com/en/VMware-Tanzu-Mission-Control/services/tanzumc-using/GUID-7EEBDAEF-7868-49EC-8069-D278FD100FD9.html.
-
tmc login -
When launching the
make deploycommand in the steps following, ensure that you run it withTMC=true
For example:
TMC=true make deployBuild a Docker image to run the Ansible playbooks. This will relieve you of the need to install the Python dependencies locally. To build the Docker image with the latest state of the project locally, run:
make buildTo build this Docker image with custom image names (default: rpk) and image versions (default: latest), run the following, being sure to substitute in your desired variables appropriately:
IMAGE=rpk-custom VERSION=v1.0.0 make buildNOTE: If using custom names, ensure that these match during the deploy stage.
At this point, you should have completed all the necessary prerequisite work to deploy RPK to your workload cluster. You are now ready to Deploy RPK.
You can deploy using the docker image with the latest state of the project locally. To do so, run:
make deployTo run when using custom image names, image versions, and/or inventory run the following, being sure to substitute your desired variables appropriately:
INVENTORY=/path/to/my/inventory.yaml IMAGE=rpk-test VERSION=v1.0.0 make deployNOTE: If you are deploying RPK to a Tanzu Mission Control provisioned cluster, you must run the following version of the command:
TMC=true make deploy