WARNING: the script is currently under development. Some configurations might not work as expected. Do not test on production environments.
./config.sh consul_server_config --interface=eno1 --consul-datacenter=dc1 --consul-retry-join=[172.16.8.3,172.16.8.2]
Using the pre-configured environments you can spin-up scenarios to be used in tutorials or as test environments.
The environments are defined inside the ./self-managed/infrastructure/aws/conf
folder:
tree ./self-managed/infrastructure/aws/conf
./self-managed/infrastructure/aws/conf
├── 00_hashicups.tfvars
├── 01_consul.tfvars
├── 02_service_discovery.tfvars
├── 03_service_mesh.tfvars
├── 04_service_mesh_access.tfvars
└── 05_service_mesh_monitoring.tfvars
0 directories, 6 files
Info: only AWS cloud provider scenarios are available ATM.
Use one of the configurations available as parameter for terraform
:
cd ./infrastructure/aws
First, initialize the Terraform project.
terraform init
Optionally, reset your environment.
terraform destroy --auto-approve && \
terraform apply --auto-approve -var-file=./conf/00_hashicups.tfvars
Info: the tool is currently under active development, the info in this section might be outdated. Refer to the actual output of your
terraform apply
command.
terraform output
connection_string = "ssh -i certs/id_rsa.pem admin@`terraform output -raw ip_bastion`"
ip_bastion = "35.161.114.102"
remote_ops = "export BASTION_HOST=35.161.114.102"
retry_join = "provider=aws tag_key=ConsulJoinTag tag_value=auto-join-j26f"
ui_consul = "https://35.87.2.143:8443"
ui_grafana = "http://35.161.114.102:3000"
ui_hashicups = "http://34.216.72.145"
-
connection_string
: is the command you can use to connect via SSH to the Bastion Host. By changing theip_bastion
to one of theip_*
output names you can connect to the respective host. -
ip_bastion
: Public IP of the Bastion Host. This is a VM containing all necessary tools to interact with the environment. The tool uses this host as a entrypoint into the environment and as a centralized scenario orchestrator. Read more on Bastion Host. -
ip_*
: Public IP of the*
host. Used for UI and SSH connections. -
ui_consul
: UI for Consul Control Plane. Some scenario do not start Consul servers or do not deploy an HCP Consul cluster. In those scenarios the URL will not work or might be empty. This is expected for those scenarios that test the Consul daemon lifecycle. -
ui_hashicups
: UI for the Grafana monitoring tool. The tool is running from the Bastion Host VM. -
ui_hashicups
: UI for the test application, HashiCups, deployed in all scenarios. For most scenarios the UI corresponds to thenginx
host.
All the scenarios include a demo application, HashiCups, used to demonstrate Consul features in a setting that can mimic real-life deployments.
Read more in the HashiCups Demo Application page.
Here a brief description of the available scenarios.
Deploy:
terraform apply --auto-approve -var-file=./conf/00_hashicups.tfvars
- HashiCups application installed on 4 VMs
- One empty VM ready to host Consul server
- One Bastion Host VM with all tools pre-installed to interact with the environment.
Deploy:
terraform apply --auto-approve -var-file=./conf/01_consul.tfvars
- All steps of scenario
00_hashicups
. - Consul server configured for TLS and Gossip encryption and with restrictive ACL defaults.
- Consul server running.
- Consul ACL system initialized.
- Restricted token applied to the Consul server agent.
Deploy:
terraform apply --auto-approve -var-file=./conf/02_service_discovery.tfvars
- All steps of scenario
01_consul
. for each service
- Consul client configured for TLS and Gossip encryption and with restrictive ACL defaults.
- Consul client tokens generated and added to the Consul configuration.
- Service discovery configuration files created and added the the Consul configuration.
- Consul client running
Deploy:
terraform apply --auto-approve -var-file=./conf/03_service_mesh.tfvars
- All steps of scenario
02_service_discovery
. for each service
- Consul service mesh configuration files created for the service and added to the Consul configuration replacing the service discovery configuration.
- Consul client agent restarted to apply the configuration change
- Envoy sidecar proxy running
- Service process configuration change to use only
localhost
references. - Service process restarted to listen on
localhost
interface only.
- Permissive
* > *
intention configured,to allow traffic.
Deploy:
terraform apply --auto-approve -var-file=./conf/04_service_mesh_access.tfvars
- All steps of scenario
03_service_mesh
. - Consul server configuration changed for service mesh access (API Gateway).
Deploy:
terraform apply --auto-approve -var-file=./conf/05_service_mesh_monitoring.tfvars
- All steps of scenario
04_service_mesh_access
. - Consul server configuration changed for monitoring.
- Consul server agent restarted to apply the configuration change
for each service
- Grafana agent configuration generated
- Grafana agent process started
During the environment setup, some steps of the UX are performed using external scripts. Those steps are usually the operations more dependent on your specific deployment.
We detached those steps into supporting scripts to:
- provide easier reference for those steps
- avoid code drift for the core parts of the workflow
The scripts are located under the ./ops/scenarios/99_supporting_scripts/
folder:
tree ./ops/scenarios/99_supporting_scripts/
./ops/scenarios/99_supporting_scripts/
├── generate_consul_client_config.sh
├── generate_consul_server_config.sh
├── generate_consul_server_tokens.sh
└── generate_consul_service_config.sh
0 directories, 4 files
You can use the scripts in this folder as a source of inspiration for writing your custom configuration scripts.
Read more on the different scripts on the Separate Scripts page.