Target CLI: The context switcher for HashiCorp tools
Managing multiple clusters of HashiCorp tools can be complicated. Target CLI eases the burden by using context profiles to easily switch between different clusters and environments.
As an engineer, you may be required to interact with multiple HashiCorp Vault, Nomad, Consul, and Boundary clusters, including dev, staging, and production clusters for each tool. Using each product’s respective CLI tools, engineers have to set environment variables to switch between these clusters when running commands. Remembering the connectivity details of each cluster can involve setting multiple environment variables, which is cumbersome, time consuming, and sometimes error prone.
To address these issues, I developed Target CLI to store these details in context profiles, which engineers can easily switch between. Currently, Target CLI supports HashiCorp Vault, Boundary, Consul, Nomad, and Terraform. Support for all the tools except Terraform is based on connecting to and interacting with clusters. Support for Terraform is based on groupings of Terraform configurations that represent a single environment.
» Installing Target CLI
Target CLI can be installed on Mac and Linux. We plan to add Windows support in the near future. Here are the instructions for installing Target CLI on various platforms:
» MacOS Brew
Run this command to install Target CLI using brew.:
brew tap devops-rob/tap && \
brew install target
» MacOS and Linux quick install script
You can also use a shell script to install Target CLI on both Mac and Linux distributions. To execute the script, run this command in your terminal:
curl https://raw.githubusercontent.com/devops-rob/target-cli/main/install.sh | bash
» Testing your installation
No matter which installation method you chose, Target CLI should be installed and available on your PATH
. To test this, type the following command in your terminal:
target
If Target CLI is installed correctly, you should see this output:
target
Target CLI allows users to configure and switch between different context profiles for their Vault, Nomad, Consul, Terraform, and Boundary targets by setting tool-specific environment variables.
A context profile contains connection details for a given target, as shown below.
Example:
A vault-dev context profile could point to:
https://example-dev-vault.com:8200
with a vault token value of s.jidjibndiyuqepjepwo
Usage:
target [command]
Available commands:
boundary
|
Manage Boundary context profiles |
completion
|
Generate the autocompletion script for the specified shell |
config
|
Configure target CLI for shell sessions |
consul
|
Manage Consul context profiles |
help
|
Help for any command |
nomad
|
Manage Nomad context profiles |
terraform
|
Manage Terraform context profiles |
vault
|
Manage Vault context profiles |
version
|
Show current installed version of target-cli |
Flags:
-h , --help
|
help for target |
-v , --version
|
version for target |
Use target [command] --help
for more information about a command.
» Setting up Target CLI
Target CLI supports setting up default context profiles that load all of your default configurations when a shell is spawned. To enable this behavior, Target CLI must place a small helper script in your shell’s startup script. The config
command is a helper utility command to perform this task.
For example, if you are using Zsh as your shell, the helper script goes in the .zshrc
file, which is usually located in the HOME
directory.
The following command configures your Zsh shell for Target CLI defaults:
Target config --path ~/.zshrc
This command adds the following lines to your .zshrc
file:
# Target CLI Defaults
for file in /Users/rbarnes/.target/defaults/*; do
if [ -f "$file" ]; then
source "$file"
fi
done
» Creating context profiles
Creating context profiles for all tools with the exception of Terraform requires an endpoint
config parameter (all other configurations are optional):
target vault create local-dev \
--endpoint “http://localhost:8200” \
--token “root” \
--namespace “droids”
The above example creates a Vault context profile called local-dev
, which points to the http://localhost:8200
endpoint, using the token root
and pointing to the droids
namespace.
The same thing can be done for all of the other tools with the exception of Terraform. Each tool has its own specific configurations available. Here’s a Nomad example:
target nomad create local-cluster \
--endpoint “http://localhost:4646” \
--token “secret-id” \
--namespace “local”\
--region “uk”
To view a complete list of the configuration parameters, use the help
flag for your desired tool as shown here:
target nomad create -h
» Listing context profiles
Once you create context profiles, you can list them for each tool using the list command. Here is an example of this for Vault:
target vault list
Example output:
+----------------------+-------------------------------------------+
| PROFILE NAME | ENDPOINT |
+----------------------+-------------------------------------------+
| local-dev | http://localhost:8200 |
| new-vault | https://some-vault-cluster:8200 |
+----------------------+-------------------------------------------+
» Switching context profiles
The select
subcommand for each tool prints out the export commands to set the context profile configurations in the current shell. For example:
target vault select local-dev
This outputs:
export VAULT_ADDR=http://localhost:8200; export VAULT_TOKEN=root
In order for this to take effect in the current shell session, simply wrap this command in the eval
command, as shown here:
eval $(target vault select local-dev)
Once this is done, any Vault CLI commands will be run against the cluster specified in the local-dev
context profile.
» Setting default context profiles
If you would like a particular context profile to be loaded by default any time a shell is spawned, you can set it as the default with this command:
target vault set-default local-dev
The above example sets the local-dev profile as default and as such, the configured environment variables will be set automatically. This assumes that you have configured Target CLI for your chosen shell as described above in the Setting up Target CLI section.
It’s worth noting that setting a profile as default will not take effect in the current shell session.
» Target CLI for Terraform
As mentioned earlier, support for Terraform differs from the other tools. Instead of managing connections to clusters and servers, Target CLI manages groupings of Terraform configurations, allowing the same Terraform code to be used to deploy multiple environments.
In order for this to work, the configuration parameters within the Terraform code that you want Target CLI to specify must be set up to use variables, as shown here:
resource "digitalocean_droplet" "nomad_client" {
image = "ubuntu-20-04-x64"
name = var.droplet_name
region = var.region
size = var.droplet_size
}
The above example code deploys a droplet for a Nomad server to DigitalOcean cloud. Notice the name
, region
, and size
configuration parameters are all set using variables. This allows Target CLI to set their values according to the context profiles created.
Using this example, you could set up two context profiles: one for New York, called nyc-prod
and another for London, called ldn-dev
. The latter droplet will be used for development purposes as the engineering team is based in London, whereas the first droplet will be used for production, because the clients are in New York. The snippet below shows the Target CLI command that would be run to create the London context profile:
target terraform create ldn-dev \
--var "droplet_name=ldn-dev" \
--var "region=lon1" \
--var "droplet_size=s-2vcpu-4gb"
The above command creates a context profile called ldn-dev
with the specified configuration parameters. Notice the --var
flag can be specified as many times as required:
target terraform create nyc-prod \
--var "droplet_name=nyc-prod" \
--var "region=nyc2" \
--var "droplet_size=s-8vcpu-16gb"
This command example above does the same thing for our New York instance. Selecting a context profile in the current shell and setting a default context profile can be done in the same way, as specified in the Switching context profiles and the Setting default context profiles sections, respectively.
Once a context profile is selected, or the default context profile has been loaded into your shell, run the usual terraform plan
and terraform apply
commands and Terraform will pick up the configuration values from the selected context profile.
» Summary
The primary benefit of Target CLI lies in its ability to simplify the process of switching between different clusters and configurations of HashiCorp tools like Vault, Nomad, Consul, Boundary, and Terraform. By storing connection details in easy-to-switch context profiles, Target CLI eliminates the need for setting and remembering multiple environment variables for each cluster. This not only saves time but also reduces the likelihood of errors that can occur when manually configuring environments. Target CLI’s support for managing Terraform configurations further extends its utility, making it a versatile solution for environment management across various HashiCorp products.
Install Target CLI using the instructions above and simplify your connection and environment settings. If you would like additional HashiCorp tool support added to Target CLI, open a Github issue and share your requirements.
Sign up for the latest HashiCorp news
More blog posts like this one
5 ways to improve DevEx and security for infrastructure provisioning
Still using manual scripting and provisioning processes? Learn how to accelerate provisioning using five best practices for Infrastructure Lifecycle Management.
HCP Vault Dedicated adds secrets sync, cross-region DR, EST PKI, and more
The newest HCP Vault Dedicated 1.18 upgrade includes a range of new features that include expanding DR region coverage, syncing secrets across providers, and adding PKI EST among other key features.
Fix the developers vs. security conflict by shifting further left
Resolve the friction between dev and security teams with platform-led workflows that make cloud security seamless and scalable.