DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Node and Capacity Spillover: What Happens When Kubernetes Runs Out of Room
  • One Query, Four GPUs: Tracing a Distributed Training Stall Across Nodes
  • Implementing Budget Policies and Budget Limits on Databricks
  • Can You Run a MariaDB Cluster on a $150 Kubernetes Lab? I Gave It a Shot

Trending

  • Part 4: Multi-Agent Orchestration — Pairing Goose With Quarkus Flow State Machines
  • MQTT, Kafka, NATS, or Zenoh? Choosing Edge-to-Cloud Messaging by Traffic Pattern
  • New York City Taxi Trips: Putting Neo4j and DuckDB to Work
  • Member Spotlight: Shai Almong

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. Bootstrapping a Consul Cluster With Cloud-Init-Buddy

Bootstrapping a Consul Cluster With Cloud-Init-Buddy

A look at the scripting processes necessary to bootstrap and integrate a consul cluster into your virtual machine set up. In this tutorial, we'll use Digital Ocean.

By 
David Karapetyan
·
Apr. 06, 18 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
6.2K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

Bootstrapping a consul cluster is a non-trivial operation mostly because it requires sequencing the startup of the cluster nodes with the starting of the consul agents. You can't form a cluster until you know the IP addresses of the nodes to pass to the consul agent for registration and cluster formation. So you first need to start the nodes and then distribute the IP addresses to all the nodes that need to be in the cluster. This is where cloud-init-buddy comes in. Cloud-init-buddy provides the glue for the cluster nodes to discover each other and not worry about sequencing startup and setup. Everything happens in the cloud-init script with all the sequencing and discovery automatically handled by the cluster nodes themselves.

The first thing we need to do is create a cloud-init-buddy node. I'm going to use the one provided in the Digital Ocean VM, but you can use whatever cloud provider you feel most comfortable with. The only thing you need is for the VM to support cloud-init.

Here's the cloud-init configuration for setting up the cloud-init-buddy node

#!/bin/bash
while ! (git clone https://github.com/cloudbootup/cloud-init-buddy.git); do
  echo "Looks like network is not ready. Sleeping and retrying."
  sleep 2
done
cd cloud-init-buddy
sudo apt update && sudo apt install --yes ruby
rake setup:initialize
rake flyway:check || rake flyway:install
rake postgres:configure
npm install
./node_modules/.bin/tsc
node utils/generate-certificate.js
tmux new-session -d -s cloud-init-buddy 'node app.js' && sleep 1
node utils/users.js add-user admin \
  $(gpg2 --gen-random 0 64 | shasum -b -a 512 | head -c 32 | tee password)

Wait for the VM to come up. Once it is up, log in to find out the password for the admin user because we need the password for the consul nodes to talk to cloud-init-buddy to coordinate the cluster formation. You can get the admin password by running cat /cloud-init-buddy/password <(echo).

At this point, we have all the pieces and can write the cloud-init scripts for the consul cluster. I'm going to use the values that I got and you will need to substitute your own values for the IP address and admin password.

#!/bin/bash
# Initial parameters for interacting with cloud-init-buddy
export CLOUD_INIT_BUDDY="138.197.199.132"
export PASSWORD="4c6f44cd5b5d549731d9ec1e3d7179e9"
export ENDPOINT="https://admin:${PASSWORD}@${CLOUD_INIT_BUDDY}:8443"
export NODE_COUNT=3
# Directory for us to do work
mkdir /consul
cd /consul
while ! (wget https://releases.hashicorp.com/consul/1.0.6/consul_1.0.6_linux_amd64.zip); do
  echo "Waiting for network to be ready."
  sleep 2
done
apt install unzip
unzip -o *.zip
rm -f *.zip
# What is our IP address? We will need this for registration
export SELF_ADDRESS="$(ip route get 8.8.8.8 | awk '{print $NF; exit}')"
# Initialize the metadata for coordination
export CONSUL_ENDPOINT="${ENDPOINT}/metadata/consul"
curl -k -XPOST "${CONSUL_ENDPOINT}" -d '{"hosts":[]}'
# Wait for all nodes to register
while [[ "$(curl -k "${CONSUL_ENDPOINT}/hosts.length")" -lt "${NODE_COUNT}" ]]; do
  # It is possible some other node reset everything so make sure we re-register
  if ! (curl -k "${CONSUL_ENDPOINT}" | grep "${SELF_ADDRESS}"); then
    curl -k -XPOST "${CONSUL_ENDPOINT}/hosts" -d "\"${SELF_ADDRESS}\""
  fi
  echo "Waiting for other nodes to register."
  sleep 1
done
# Whoever registered first will set a key
if [[ "$(curl -k "${CONSUL_ENDPOINT}/hosts/0")" == "\"${SELF_ADDRESS}\"" ]]; then
  key="$(./consul keygen | head -c 24)"
  curl -k -XPOST -d "{\"key\":\"${key}\"}" "${CONSUL_ENDPOINT}"
fi
# Wait for the key to be set
while ! (curl -k "${CONSUL_ENDPOINT}.keys" | grep "key"); do
  echo "Waiting for key to be set"
  sleep 1
done
# Everyone is registered and there is a key so we can form the cluster.
# In a production setting this would be an actual systemd unit file 
# and you would not use public facing IP addresses, i.e. you'd run
# the nodes in a private address space
nohup ./consul agent -ui -syslog -server -bootstrap-expect "${NODE_COUNT}" \
  -data-dir "/consul" \
  -bind "${SELF_ADDRESS}" \
  -advertise "${SELF_ADDRESS}" \
  -encrypt "$(curl -k "${CONSUL_ENDPOINT}/key" | tr -d '"')" \
  -retry-join "$(curl -k "${CONSUL_ENDPOINT}/hosts/0" | tr -d '"')" &

It looks a little ugly but it gets the job done.

Cloud-init-buddy also provides an endpoint for storing and retrieving tar packages but I didn't use that feature here. It comes in handy when you want to include other assets on the consul nodes or if you want to use something other than bash for bootstrapping the node. The package could include a Ruby or Python script and the cloud-init script would just be reduced to downloading the package, unpacking it, and executing the necessary script from the package.

cluster

Published at DZone with permission of David Karapetyan. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Node and Capacity Spillover: What Happens When Kubernetes Runs Out of Room
  • One Query, Four GPUs: Tracing a Distributed Training Stall Across Nodes
  • Implementing Budget Policies and Budget Limits on Databricks
  • Can You Run a MariaDB Cluster on a $150 Kubernetes Lab? I Gave It a Shot

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook