I covered the basic introduction of TMC Self-Managed, the general architecture, and the requirements your environment needs to meet before installing TMC Self-Managed in the first post of this series. Before getting your hands dirty with the installation, I’ll cover configuring DNS Zones and records in this post.
To enable correct traffic flow and access to various TMC endpoints, TMC Self-Managed needs a DNS zone to hold the DNS records. To ensure name resolution between the objects that are deployed during TMC Self-Managed installation, create the following A records in your DNS domain. You can create a new DNS zone or can leverage an existing zone.
- alertmanager.<my-tmc-dns-zone>
- auth.<my-tmc-dns-zone>
- blob.<my-tmc-dns-zone>
- console.s3.<my-tmc-dns-zone>
- gts-rest.<my-tmc-dns-zone>
- gts.<my-tmc-dns-zone>
- landing.<my-tmc-dns-zone>
- pinniped-supervisor.<my-tmc-dns-zone>
- prometheus.<my-tmc-dns-zone>
- s3.<my-tmc-dns-zone>
- tmc-local.s3.<my-tmc-dns-zone>
- tmc.<my-tmc-dns-zone>
To simplify the installation procedure, you can also use a wildcard DNS entry as shown below (for POCs only).
Record Type | Record Name | Value |
A | *.<my-tmc-dns-zone> |
load balancer IP |
A | <my-tmc-dns-zone> |
load balancer IP |
The IP address for the above records must point to the external IP of the contour-envoy service that is deployed during the installation.
Important Note: You can enforce contour-envoy to be provisioned with a preferred IP address by using an annotation ako.vmware.com/load-balancer-ip: “<preffered-ip” in the TMC Self-Managed configuration file. This allows you to know in advance which IP address your DNS records should point to.
In my lab, I have configured an AD-integrated DNS in Windows Server 2019 and I have created a subdomain ‘tmc.vstellar.lab’ under my main domain ‘vstellar.lab’.
I am using a wildcard record instead of creating individual A records.
After that, I created a record ‘tmc.vstellar.lab’ in my main DNS zone, pointing to the same IP address to which my wild card A record is pointing to.
That’s it for this post. In the next post of this series, I will demonstrate the configuration of IDP (Okta). Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.
Pingback: Tanzu Mission Control Self-Managed – Part 1: Introduction & Architecture
Pingback: Tanzu Mission Control Self-Managed – Part 5: Prepare Harbor Registry
Pingback: Install Tanzu Mission Control Self-Managed on vSphere with Tanzu on vSphere 7
Pingback: Tanzu Mission Control Self-Managed – Part 4: Install Cert-Manager and Cluster Issuer for TLS certificates
Pingback: Install Tanzu Mission Control Self-Managed on TKGm
Pingback: Tanzu Mission Control Self-Managed – Part 3: Configure Identity Provider