In my last post, we learned about push-button automation with the UI provided by the SDDC Manager. We learned that the SDDC Manager allows us to manage the automation of new clusters, add new hosts into existing clusters, and that it can manage infrastructure across multiple vCenters Fleet-wide.
Here, we are going to take a look at the infrastructure as code (IaC) approach and detail how we can leverage the VCF APIs to achieve a more automated way of provisioning and life-cycling VCF infrastructure.
Talking to VMware engineers on the daily, I commonly get the question whether or not we “support Terraform” or if we “support Ansible”.
Those are the wrong questions.
We don’t care what tool you use:
The advantage of using VCF is that we provide a standard and unified REST API endpoint that provides flexibility in automation platform choice.
Here are some more details on that with VCF 9.1.
Since a VCF Fleet allows you to have one single API endpoint to easily manage your entire VMware infrastructure, you won’t need to make multiple calls across multiple vCenters, ESX hosts, etc.
Additionally, with unified policies and guardrails, they are all enforced/accessible through the set of VCF APIs.
We have API reference docs for every VCF component. You can also access the local swagger documentation for all VCF components, like here is how to access that for VCF Operations.
The example I will use here is an API call on the VCF SDDC Manager through Terraform. I want to see some information about my VCF domain and test to see if I need to add more memory or more hosts into my cluster. If I have less than 15% memory capacity, then add a host (possibly); if not, do nothing.
To be fair, Terraform may not be ideal for runtime remediation, but I am using it because it’s super common. My point here, and the larger lesson, is that I am filing the receipt that cloud-native tools like Terraform can be used.
Can you use Ansible, bash, Python, or PowerCLI to do the same thing?
Absolutely!
My example here is just the code for the test. Actions will be up to you, but the main lesson from this is a working example of using an automation tool on our SDDC Manager API.
All of the code I am running is from this repo. I will be referencing files from that repo, but feel free to expand on that repo or make it your own. The README should give you everything you need to run the terraform code.
The first piece is a shell script that will run as part of the terraform apply command. This script is not required, but it’s an easy way to format the output, rather than using the Hashicorp Configuration Language formatting. This is the examples/read-only-api-gate/scripts/sddc_probe.sh file in the directory.
In the main.tf file, I will ensure I am querying for the right information. Most of the parameters there are for connection to the SDDC Manager API and to query for memory usage in the Management Domain.
I also have some accompanying tfvars files and variables files; that’s part of the standard terraform directory setup. There is an example included for you to tweak according to your needs.
Here’s the full terraform output:
terraform init ─╯ Initializing the backend... Initializing provider plugins... - Reusing previous version of hashicorp/external from the dependency lock file - Using previously-installed hashicorp/external v2.3.5 Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary. |
Then the plan:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
terraform plan ─╯ data.external.sddc_probe: Reading... data.external.sddc_probe: Read complete after 2s [id=-] Changes to Outputs: ~ domain_capacity = [ ~ { ~ current_capacity = { ~ cpu = { ~ used = { ~ value = 43.657998765267436 -> 34.97899901072632 # (1 unchanged attribute hidden) } # (2 unchanged attributes hidden) } ~ memory = { ~ used = { ~ value = 281.517578125 -> 281.328125 # (1 unchanged attribute hidden) } # (1 unchanged attribute hidden) } ~ storage = { ~ used = { ~ value = 1.34421987600399 -> 1.3442330625457544 # (1 unchanged attribute hidden) } # (1 unchanged attribute hidden) } } id = "9faa050c-216e-4b54-8e1f-177f1b5e0cac" name = "vcf-m01" }, ] You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure. ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now. |
You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.
And finally, the apply:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
~ domain_capacity = [ ~ { ~ current_capacity = { ~ cpu = { ~ used = { ~ value = 43.657998765267436 -> 34.97899901072632 # (1 unchanged attribute hidden) } # (2 unchanged attributes hidden) } ~ memory = { ~ used = { ~ value = 281.517578125 -> 281.328125 # (1 unchanged attribute hidden) } # (1 unchanged attribute hidden) } ~ storage = { ~ used = { ~ value = 1.34421987600399 -> 1.3442330625457544 # (1 unchanged attribute hidden) } # (1 unchanged attribute hidden) } } id = "9faa050c-216e-4b54-8e1f-177f1b5e0cac" name = "vcf-m01" }, ] |
In these past two posts, I have talked about automating the VMware Fleet infrastructure. In Part 3 we will take a look at automating VM and Kubernetes provisioning using VCF Automation.
Subscribe to get the latest posts sent to your email.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。