Cloud Native应用交付

  • 首页
  • 关于本站
  • 个人介绍
  • Downloads
  • Repo
    • Github
    • Container
  • F5
    • F5 Python SDK
    • F5-container
    • F5-LBaaS
  • 社交
    • 联系我
    • 微信/微博
    • 公众号
    • 打赏赞助
行至水穷处 坐看云起时
Cloud Native Application Services: cnadn.net
  1. 首页
  2. F5技术
  3. 正文

[转]Consul服务自动化发现及F5动态配置更新

2017年10月9日 6540点热度 0人点赞 0条评论

Last update from July 20th, 2015 - I gave a tech talk at Airbnb office related to this topic. you may find the presentation here at my github

In these days where microservices are becoming big, a compulsory modification of traditional architectural approaches are becoming evident. A more automatic distribution of application-afine services, such as load balancing, is required, as demands increase for agile software feature deployments. Traditional, manual configurations of load balancing services are becoming less of a viable option, as it becomes a major road block for organizations to deploy new application services or get new features to today’s rapidly changing software market.

In my quest to develop a solution for automate Virtual IPs deployment for F5 BIG-IP platforms, I’ve been abusing a lot of the iControl REST API available since 11.5.1 code, and I am really happy and pleased. It is powerful and allows safe and almost full interaction with the chassis config – tested for LTM and AFM modules, with a Ruby Sinatra API user interface.

In other hand, the approach with Hashicorp tools allows easily auto-scaling configuration management more close to DevOps world, extending all the good benefits from this hardware based load balancer, in the same way they would do with ha-proxy or keepalived software solutions. BIG-IP solutions has been proven stable and robust, with a good support, nice features with ASIC based routing, which performs awesome with FastL4 type profiles (no TCP proxying).

One of the things I love in BIG-IP platforms is not only they are based on Linux, but also they do not do stupid things to lock the system shell for the admin. Other nice feature is the concept of Partition, which allows you to create namespaces with different objects, roles, and last but not least, configuration files!

But the real BIG WEAPON we are using today is consul-template, which basically query a Consul instance and update a local fs config file based on Go templates, as well can execute arbitrary commands when template updates occurs.

Consul is used for service discovery, health check, and k/v registry for datacenter nodes, allowing query via REST API or DNS.  There is a good tutorial at Hashicorp Consul website about how to install a Vagrant Consul cluster if you’re not familiar with it and want to poke around.

Enough chit chat, lets get hacking!

First, create a different partition at BIG-IP – I am calling my new partition consul at my BIG-IP lab. In my case, the load balancer config file will be stored at /config/partitions/consul/bigip.conf.

Considering a simple scenario where you have at your datacenter a Consul server and a pool of application servers running consul agents publishing a web app at tcp/port 80, as well the app health check URL.

{
"service": {
"name": "web",
"id": "web",
"tags": [
"production"
],
"port": 80,
"check": {
"id": "api",
"name": "HTTP API on port 80",
"http": "http://localhost:80/health",
"interval": "10s",
"timeout": "1s"
}
}
view rawservice_web.json hosted with ❤ by GitHub

At this point Consul can provide reliable information about our app pool health. If a node fail or the health check times out, Consul will remove the service from the healthy pool. Here is an example of a raw query for my consul server:
curl http://localhost:8500/v1/catalog/service/web

[
{
"Node": "n1.nethero.org",
"Address": "172.20.20.10",
"ServiceID": "web",
"ServiceName": "web",
"ServiceTags": [
"production"
],
"ServiceAddress": "",
"ServicePort": 80
},
{
"Node": "n2.nethero.org",
"Address": "172.20.20.11",
"ServiceID": "web",
"ServiceName": "web",
"ServiceTags": [
"production"
],
"ServiceAddress": "",
"ServicePort": 80
}
]
view rawquery-web.json hosted with ❤ by GitHub

This output provides all the information we need for generating BIG-IP nodes and pool objects, so we are ready to setup consul-template for updating and reloading our BIG-IP consul partition config at every Consul detected event, like node down, service failure, as well include new servers (or containers) brought in rotation to consul service pool.

Now we download consul agent and consul-template binaries for Linux AMD64 platform, and place both at our F5 BIG-IP /sbin folder. Make sure you setup your F5 BIG-IP /etc/consul.conf.json to join to the consul cluster, like following example:

{
"datacenter": "netheroDC",
"data_dir": "/var/lib/consul",
"statsd_addr": "127.0.0.1",
"bind_addr": "0.0.0.0",
"disable_remote_exec": true,
"dns_config": {
"enable_truncate": false
}
}
view rawconsul.conf.json hosted with ❤ by GitHub

As well create /etc/consul.d and /etc/consul-templates directories, placing the following template file at /etc/consul-template/bigip.ctmpl

{{range service "web"}}
ltm node /consul/{{.Node}} {
address {{.Address}}
}
{{end}}
ltm pool /consul/dynamic-test {
description "Last change by consul-template => {{timestamp}}"
members {
{{range service "web"}}
/consul/{{.Node}}:{{.Port}} {
address {{.Address}}
}
{{end}}
}
monitor /Common/tcp
}
view rawbigip.ctmpl.go hosted with ❤ by GitHub

Now create a /sbin/reload-consul.sh file with this content:

#!/bin/bash
echo "$(date) - config sync started"
tmsh load sys config partitions { consul }
echo "$(date) - config sync completed"
view rawreload-consul.sh hosted with ❤ by GitHub

Finally, add these lines to your /config/startup:

#Consul agent
echo "Starting consul-agent..."
/sbin/consul agent -config-file=/etc/consul.conf.json -config-dir=/etc/consul.d -pid-file=/var/run/consul.pid -retry-join=consul1.nethero.org -retry-join=consul2.nethero.org -retry-max=0 >>/var/log/consul-agent.log &
sleep 5
#Consul template
echo "Starting consul-template..." ;
/sbin/consul-template -consul 127.0.0.1:8500 -template "/etc/consul-templates/bigip.ctmpl:/config/partitions/consul/bigip.conf:/sbin/reload-consul.sh" 2>&1 >>/var/log/consul-template.log &
view rawstartup.sh hosted with ❤ by GitHub

And the magic happens when consul template starts:

consul-template

Yay! Our F5 BIG-IP is being auto configured based on consul service catalog. As soon as you bring up more app servers and spin up their consul agent publishing their services, it’ll be automatically added to our load balancer pool. Beautiful isn’t it ?

The good news is that BIG-IP parses the config before applying it, so if you break your template after a change, BIG-IP wont overwrite the running-config with the faulty new one, until you provide a valid config. Safe is priceless!BIG-IP config file generated by consul-template:

ltm node /consul/n1.nethero.org {
address 172.20.20.10
}
ltm node /consul/n2.nethero.org {
address 172.20.20.11
}
ltm pool /consul/dynamic-test {
description "Last change by consul-template => 2015-05-02T21:11:57Z"
members {
/consul/n1.nethero.org:80 {
address 172.20.20.10
}
/consul/n2.nethero.org:80 {
address 172.20.20.11
}
}
monitor /Common/tcp
}
原文 http://www.nethero.org/

相关文章

  • F5 CES 用融合的思想保护k8s出向流量安全
  • Container Egress Services 容器出向流量策略管控
  • F5 BIG-IP链接Istio 增强入口服务能力
  • How to build Nginx Plus as k8s Ingress controller and run with F5 CIS together
  • F5-k8s解决方案(2)-基于Calico BGP网络的F5 k8s容器平台方案实践
本作品采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可
标签: consul 服务发现 自动化配置
最后更新:2017年10月9日

纳米

linjing.io

打赏 点赞
< 上一篇
下一篇 >

文章评论

取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。

纳米

linjing.io

☁️迈向Cloud Native ADC ☁️

认证获得:
TOGAF: ID 152743
Kubernetes: CKA #664
Microsoft: MCSE MCDBA
Cisco: CCNP
Juniper: JNCIS
F5:
F5 Certified Solution Expert, Security
F5 Certified Technology Specialist, LTM/GTM/APM/ASM
F5 Certified BIG-IP Administrator
  • 点击查看本博技术要素列表
  • 归档
    分类
    • Automation
    • Avi Networks
    • Cisco ACI
    • CISCO资源
    • F5 with ELK
    • F5-Tech tips
    • F5技术
    • Juniper
    • Linux
    • NGINX
    • SDN
    • ServiceMesh
    • WEB编程
    • WINDOWS相关
    • 业界文章
    • 交换机技术
    • 化云为雨/Openstack
    • 协议原理
    • 容器/k8s
    • 我的工作
    • 我的生活
    • 网站技术
    • 路由器技术
    • 项目案例
    标签聚合
    bigip network nginx docker openstack flannel neutron k8s envoy F5 irule istio api gtm DNS
    最近评论
    厚嘴唇 发布于 6 个月前(02月08日) ces部署之前要提前安装kube-ovn吧?
    厚嘴唇 发布于 6 个月前(02月08日) ces部署必须是在kube-ovn网络安装好之后才可以吗
    平谷无颜祖 发布于 8 个月前(12月15日) 逐步加入dns及egress,不错不错
    minw9545 发布于 9 个月前(11月18日) 2021-11-18 23:36 现在是下午时间。
    minw9545 发布于 9 个月前(11月18日) 我放了奖励。 2021-11-18 11:36 请提供您的密码。
    浏览次数
    • Downloads - 76,651 views
    • Github - 74,375 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 61,142 views
    • F5常见log日志解释 - 59,079 views
    • 联系我 - 55,417 views
    • Sniffer Pro 4 70 530抓包软件 中文版+视频教程 - 47,174 views
    • 这篇文档您是否感兴趣 - 38,697 views
    • 迄今为止最全最深入的BIGIP-DNS/GTM原理及培训资料 - 32,365 views
    • F5利用Elastic stack(ELK)进行应用数据挖掘系列(2)-DNS - 29,659 views
    • F5利用Elastic stack(ELK)进行应用数据挖掘系列(1)-HTTP - 28,748 views
    链接表
    • Jimmy Song‘s Blog
    • SDNap
    • SDNlab
    • SDN论坛
    • Service Mesh社区
    • 三斗室
    • 个人profile

    COPYRIGHT © 2022 Cloud Native应用交付. ALL RIGHTS RESERVED.

    Theme Kratos Made By Seaton Jiang

    京ICP备14048088号-1

    京公网安备 11010502041506号