גילוי שירותים וניהול תצורה עם HashiCorp Consul

# /etc/consul.d/consul-client.hcl
datacenter = "dc1"
data_dir = "/opt/consul/data"
node_name = "app-server-03"
retry_join = ["consul-server-01.company.ru", "consul-server-02.company.ru", "consul-server-03.company.ru"]
bind_addr = "{{ GetInterfaceIP \"eth0\" }}"
client_addr = "127.0.0.1"
encrypt = "BASE64_GOSSIP_KEY"
acl {
  enabled = true
  default_policy = "deny"
  tokens {
    default = "CLIENT_ACL_TOKEN"
  }
}

# /etc/consul.d/service-payments.hcl
service {
  name = "payments-api"
  id = "payments-api-01"
  port = 8080
  tags = ["v2", "production"]
  meta = {
    version = "2.1.0"
    environment = "production"
  }
  check {
    id = "payments-http"
    name = "HTTP health check"
    http = "http://localhost:8080/health"
    interval = "10s"
    timeout = "3s"
  }
}

לאחר טעינה מחדש של הסוכן, השירות מופיע בקטלוג. שירותים אחרים מוצאים אותו דרך DNS (פורט 8600).

dig @127.0.0.1 -p 8600 payments-api.service.consul SRV 

זה מאפשר גילוי שירותים דרך DNS ללא כלים נוספים. לשימוש שקוף ללא ציון פורט, הגדר dnsmasq או systemd-resolved.

חנות KV ו-ACL: תצורה ואבטחה

אנו משתמשים בחנות KV כדי לאחסן פרמטרים של סביבה, דגלי תכונה ונעילות מבוזרות.

consul kv put config/payments-service/db_host "postgres-primary.company.ru"
consul kv put config/payments-service/feature_new_checkout "false"
consul kv get config/payments-service/db_host
consul watch -type=key -key=config/payments-service/feature_new_checkout \
  /usr/local/bin/reload-config.sh

יישומים קוראים KV בעת ההפעלה או נרשמים לשינויים דרך long-polling. עבור Kubernetes, External Secrets Operator מסנכרן KV לתוך Secrets.

ACL עם מדיניות # /etc/consul.d/consul-server.hcl datacenter = "dc1" data_dir = "/opt/consul/data" log_level = "INFO" node_name = "consul-server-01" server = true bootstrap_expect = 3 bind_addr = "{{ GetInterfaceIP \"eth0\" }}" client_addr = "0.0.0.0" ui_config { enabled = true } connect { enabled = true } acl { enabled = true default_policy = "deny" enable_token_persistence = true } encrypt = "BASE64_GOSSIP_KEY" # consul keygen חוסם הכל כברירת מחדל. צור מדיניות עבור payments-service:

# acl-policy-payments.hcl
key_prefix "config/payments-service/" {
  policy = "read"
}

service "payments-api" {
  policy = "write"
}

service_prefix "" {
  policy = "read"
}

הטוקן מועבר לשירות דרך # /etc/consul.d/consul-client.hcl datacenter = "dc1" data_dir = "/opt/consul/data" node_name = "app-server-03" retry_join = ["consul-server-01.company.ru", "consul-server-02.company.ru", "consul-server-03.company.ru"] bind_addr = "{{ GetInterfaceIP \"eth0\" }}" client_addr = "127.0.0.1" encrypt = "BASE64_GOSSIP_KEY" acl { enabled = true default_policy = "deny" tokens { default = "CLIENT_ACL_TOKEN" } } . סוגי בדיקות הבריאות הזמינים ב-Consul:

אנו מגדירים לכל שירות בדיקת בריאות; לדוגמה, בדיקת בריאות של Consul באמצעות HTTP GET.

כיצד Consul משפר סובלנות לתקלות?

בדיקות בריאות מסירות מופעים מתים תוך שניות, ו-ACL מונעים גישה לא מורשית. בפרויקט אחד לאחר אימוץ Consul, MTTR ירד מ-30 דקות ל-2 דקות—ה-runbook ביצע אוטומציה של מעבר לשרתי גיבוי. Consul מעבד בדיקות בריאות פי 3 מהר יותר מחלופות, ומבטיח זמינות שירות של 99.9%.

תהליך היישום

1. ביקורת תשתית: זיהוי שירותים, נקודות תורפה בגילוי, דרישות KV.
2. תכנון: סכמת קלאסטר Consul, מדיניות ACL, תרחישי גיבוי.
3. פריסה: Terraform או Ansible עבור צמתי שרת, סוכנים, הגדרת הצפנת gossip.
4. אינטגרציה: רישום שירותים, חיבור בדיקות בריאות, העברת תצורות.
5. בדיקות: בדיקות chaos (כשל צומת, עיכובי רשת), אימות מעבר.
6. פריסה לייצור: פריסה הדרגתית עם ניטור והתראות.

מהן הטעויות הנפוצות בהגדרת Consul?

הגדרה נכונה של Consul דורשת תכנון קפדני. טעויות אופייניות:

• דילוג על הגדרת ACL—הקלאסטר הופך לפגיע.
• רק צומת שרת אחד—אובדן קוורום במקרה של כשל.
• בדיקות בריאות ללא timeouts—בדיקות תקועות חוסמות גילוי.
• התעלמות מהצפנת gossip—תעבורה בין צמתים פתוחה.

לוח זמנים ועלות

פריסת קלאסטר בסיסי אורכת בין 2 ל-5 ימים בהתאם למורכבות התשתית. השקעה טיפוסית בפרויקט נעה בין $5,000 ל-$15,000, עם עלות ממוצעת של $8,500. לקוחות מדווחים על חיסכון שנתי של $50,000 עד $70,000 בשל הפחתת זמן השבתה ועלויות תפעול. לצוות שלנו ניסיון של 5 שנים ויותר מ-50 פרויקטי DevOps מוצלחים.

מה כלול בעבודה

• תיעוד ארכיטקטורה המותאם לתשתית שלך
• פריסת קלאסטר Consul (צמתי שרת, סוכנים, הצפנה)
• יצירת מדיניות ACL וניהול טוקנים
• אינטגרציה עם שירותים קיימים (רישום, בדיקות בריאות)
• כתיבת סקריפטים מותאמים לבדיקות בריאות אם נדרש
• הגדרת ניטור והתראות (Prometheus, consul_exporter, Grafana)
• תמיכה לאחר פריסה למשך שבועיים

אנו פורסים קלאסטר Consul עם 5 צמתי שרת לסובלנות תקלות. בקש ביקורת על התשתית שלך—נעריך בעיות קיימות ונציע ארכיטקטורת Consul אופטימלית.