T E R M I N A L $ dig llama.node.consul ; <<>> DiG 9.10.3-P4-Ubuntu <<>> testing-llama.node.consul ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64443 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;testing-llama.node.consul.IN A ;; ANSWER SECTION: testing-llama.node.consul. 0 IN A 10.1.1.148
Exercise: Query Service Query for consul service information using dig and the DNS interface. HINT: Remember the DNS naming format is {service_name}.service.consul @anubhavm
T E R M I N A L $ dig consul.service.consul ; <<>> DiG 9.10.3-P4-Ubuntu <<>> consul.service.consul ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9334 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;consul.service.consul. IN A ;; ANSWER SECTION: consul.service.consul. 0 IN A 10.1.1.164 consul.service.consul. 0 IN A 10.1.1.73 consul.service.consul. 0 IN A 10.1.2.16 ;; ADDITIONAL SECTION: consul.service.consul. 0 IN TXT "consul-network-segment=" consul.service.consul. 0 IN TXT "consul-network-segment=" consul.service.consul. 0 IN TXT "consul-network-segment=" ;; Query time: 1 msec
T E R M I N A L $ dig +short consul.service.consul 10.1.1.164 10.1.2.16 10.1.1.73
Registering Services Services are registered using JSON definition or via the HTTP API. JSON files are put into a dot-d directory and loaded by Consul. @anubhavm
C O D E E D I T O R { "service": { "name": "my-service", "tags": ["tag-1", "tag-2"], "port": 1234 } }
C O D E E D I T O R { "service": { "name": "my-service" , "tags": ["tag-1", "tag-2"], "port": 1234 } } Exposed via DNS and HTTP APIs Referred to as the "logical service" name dig my-service.service.consul
C O D E E D I T O R { "service": { "name": "my-service", "tags": [ "tag-1" , "tag-2"], "port": 1234 } } Exposed via DNS and HTTP APIs dig tag-1.my-service.service.consul
C O D E E D I T O R { "service": { "name": "my-service", "tags": ["tag-1", "tag-2"], "port": 1234 } } Exposed via DNS and HTTP APIs dig SRV my-service.service.consul
Service Discovery (CLI)
Service Discovery - Consul CLI Consul CLI provides basic interactions with service discovery Do not use the CLI to build tooling (use API instead) Allows easily querying services Currently only supports the catalog @anubhavm
Exercise: Get Help Run consul catalog -h to see the list of available CLI service discovery commands. @anubhavm
T E R M I N A L $ consul catalog -h Usage: consul catalog <subcommand> [options] [args] This command has subcommands for interacting with Consul's catalog. The catalog should not be confused with the agent, although the APIs and responses may be similar. Here are some simple examples, and more detailed examples are available in the subcommands or the documentation. List all datacenters: $ consul catalog datacenters List all nodes: $ consul catalog nodes List all services: $ consul catalog services .....
Exercise: List Services with Tags List all registered services with their tags using the service discovery CLI. @anubhavm
T E R M I N A L $ consul catalog services -tags consul counting velocity counting-proxy dashboard velocity dashboard-proxy fabio http nomad http,rpc,serf nomad-client http
K/V Store
K/V Store Highly-available, globally accessible key-value store Folder-like architecture allows for easy organization K/V Store: Use Cases Optional ACLs can enforce policy and access Accessible via HTTP API (no DNS interface) Can be used via the CLI or via a tool like curl @anubhavm
K/V Store: Use Cases Runtime configuration data Secrets or sensitive application data (eg. Vault’s encrypted data) @anubhavm
K/V Store: Use Cases Runtime configuration data Secrets or sensitive application data (eg. Vault’s encrypted data) @anubhavm
T E R M I N A L $ consul kv put <KEY> <DATA> Success! Data written to: <KEY> $ curl -X PUT -d <DATA> http://localhost:8500/v1/kv/<KEY> true
T E R M I N A L $ consul kv get <KEY> <DATA> $ curl http://localhost:8500/v1/kv/<KEY>
Exercise: Create KV Data Create two new key-value pairs in the store. Keep in mind that everyone is using the same Consul servers, so choose a unique name that won't conflict with another user. Read those values back out. @anubhavm
T E R M I N A L $ consul kv put anubhavmishra/velocity hello Success! Data written to: anubhavmishra/velocity $ consul kv get anubhavmishra/velocity hello
Consul Template
Consul Template: A Helper tool for Consul Consul Template handles the HTTP API flow with Consul Retrieves keys and services from Consul and renders them into a template Optionally integration with HashiCorp Vault as well @anubhavm
Consul Template: Architecture 2 {{ key “hello/world“ }} CONSUL 1 CONSUL TEMPLATE 3 value FILE @anubhavm
Exercise: Validate Consul Template Validate Consul Template is installed and configured. @anubhavm
T E R M I N A L $ consul-template -h Usage: consul-template [options] Watches a series of templates on the file system, writing new changes when Consul is updated. It runs until an interrupt is received unless the -once flag is specified. Options: -config=<path> Sets the path to a configuration file or folder on disk. This can be specified multiple times to load multiple files or folders. If multiple values are given, they are merged left-to-right, and CLI arguments take the top-most precedence. -consul-addr=<address> Sets the address of the Consul instance
Exercise: Create Template Create and execute a Consul Template template that iterates over all the healthy services named "consul" and prints out the IP address. HINT: Consul Template's documentation is very verbose and probably has examples that you can follow. @anubhavm
C O D E E D I T O R {{ range service “consul" }} {{ .Address }} {{ end }}
T E R M I N A L $ consul-template -dry —template=in.tpl > 10.1.1.13 10.1.2.250 10.1.1.36
“Smart Proxy” with NGINX and Consul Similar to AirBnB’s “Smart Stack” Configure NGINX dynamically using Consul’s service catalog Make the simplest form of a “Smart Proxy” Use Consul Template as the helper tool to achieve this @anubhavm
“Smart Nginx” server { listen 5051; server { listen 5050; ..... NGINX @anubhavm
“Smart NGINX” server { server { listen 5051; listen 5051; server { server { listen 5050; listen 5050; SERVICE A SERVICE B ..... ..... :8080 NGINX NGINX 10.0.0.1 10.0.0.2 @anubhavm
“Smart NGINX” server { server { listen 5051; listen 5051; server { server { listen 5050; listen 5050; SERVICE A SERVICE B ..... ..... :8080 https://10.0.0.2:5051/service/service-b/hello NGINX NGINX 10.0.0.1 10.0.0.2 @anubhavm
“Smart NGINX” server { server { listen 5051; listen 5051; server { server { listen 5050; listen 5050; SERVICE A SERVICE B ..... ..... :8080 https://10.0.0.2:5051/service/service-b/hello NGINX NGINX 10.0.0.1 10.0.0.2 @anubhavm
Exercise: Validate NGINX Validate NGINX is installed and configured. @anubhavm
Recommend
More recommend
