Integrate service mesh and API gateway
Consul service mesh is a feature that provides secure service-to-service communication with Transport Layer Security (TLS). In a service mesh, sidecar proxies run alongside each service instance, allowing the service to send requests to localhost
instead of a defined upstream service address. All traffic sent to each application service travels through an outbound and inbound sidecar proxy. As a result, each service has encrypted communication and Consul enforces application routing rules with service intentions.
The next step of this monolith migration integrates Consul service mesh to allow secure TLS connections between each service. It also sets up an API gateway for external public access.
In this tutorial, you deploy a version of HashiCups that uses Consul service mesh while running on private client nodes. Then you deploy an API gateway that allows external public access the services running on the private client node.
Infrastructure overview
At the beginning of the tutorial you have a Nomad and Consul cluster with three server nodes, three private client nodes, and one publicly accessible client node. Each node runs a Consul agent and a Nomad agent.
This infrastructure matches the end state of the previous tutorial.
Prerequisites
This tutorial uses the infrastructure set up in a previous tutorial in this collection, Set up the cluster. Complete that tutorial to set up the infrastructure if you have not done so.
Review configuration files
In your terminal, navigate to the directory that contains the code from the learn-consul-nomad-vm
code repository.
Navigate to the jobs
directory.
Additional files for configuring the API gateway and service intentions are located in the shared/jobs
directory. These files include 04.api-gateway.config.sh
, 04.api-gateway.nomad.hcl
, and 04.intentions.consul.sh
.
Review scripts for API gateway configuration
The Consul API gateway allows external traffic to the internal nginx
service.
The repository provides a script, 04.api-gateway.config.sh
, that automates the initial configuration required for Nomad and Consul.
The set up script starts by cleaning up previous Consul configurations, binding rules, auth methods, and the ingress
namespace in Nomad.
Then the script configures the Consul and Nomad ACL integration, which includes setting up the auth method, creating a binding rule, and creating the ingress
namespace in Nomad.
Finally, the script generates TLS certificates, creates a listener and route for the API gateway, and then writes them to Consul configurations.
Review the API gateway jobspec
The API gateway job is constrained to a node with the ingress
meta role that also runs in the ingress
namespace. It has four tasks: two are for job set up and clean up, one registers the gateway with Consul, and one starts the gateway. The set up, clean up, and service registration tasks each define a lifecycle
block that enforces the order in which they run.
Review the Consul intentions configuration
In a secure configuration, Consul uses intentions to specify allowed communications across services.
The repository provides a script, 04.intentions.consul.sh
, that automates the creation of intentions.
The Consul intentions script cleans up any previous configurations and then creates intentions for the HashiCups services. Intentions are how Consul enforces routes of communication between services.
Review the HashiCups jobspec
Open the 04.hashicups.nomad.hcl
jobspec file and review the contents.
This version uses the same constraint
as previous versions to run all of the HashiCups services on private client nodes. It integrates Consul service mesh with upstream configurations and configures services to use mTLS through the Envoy sidecar proxy. These configuration attributes are located in the connect
block.
Deploy Consul API gateway
Set up and deploy the Consul API gateway before you submit the updated jobspec to Nomad. Set up and deploy the Consul API gateway before you submit the updated jobspec to Nomad.
Run the API setup script and jobspec
Set up the API gateway configurations in Consul.
Submit the API gateway job to Nomad.
Run the Consul intentions setup script
Set up the service intentions in Consul.
Verify API gateway deployment
Verify that the API gateway deployed successfully.
Use the nomad job
command to retrieve information about the hashicups
job.
Use the consul catalog
command to verify that the services are correctly registered inside Consul's catalog.
Deploy HashiCups with service mesh
After you deploy the Consul API gateway, deploy the new version of the HashiCups job.
Run the HashiCups jobspec
Submit the HashiCups job to Nomad.
Verify the HashiCups deployment
Use the nomad job
command to retrieve information about the hashicups
job.
Use the consul catalog
command to verify that the services are correctly registered inside Consul's catalog.
To view the Hashicups application, navigate to the public IP address of the API gateway.
In the following command, note the --namespace
flag. The API gateway runs in a namespace that is separate from the application. You will need to trust the certificate in your browser.
Output from the above command.
Visit the address in your web browser to view the application.
Before you proceed, interact with the HashiCups application and then observe the changes in the Nomad and Consul UIs.
Cleanup
Stop the HashiCups deployment when you are ready to move on.
Warning
Do not stop the API gateway job. You will use it in the next tutorial.
Next steps
In this tutorial, you deployed the Consul API gateway to secure access to your application. Then you deployed a version of HashiCups that uses Consul service mesh to fully secure services running on private client nodes.
For more information about to Consul API gateway integration with Nomad, refer to Consul ACL with Nomad Workload Identities and Deploy a Consul API Gateway on Nomad.
In the next tutorial, you will deploy the Nomad Autoscaler and use it to scale up the frontend
service of HashiCups.