Rancher 服务

Jitao Hou 正在翻译首稿,欢迎之后Review

Rancher implements a distributed health monitoring system by running an HAProxy instance on every host for the sole purpose of providing health checks to containers. When health checks are enabled either on an individual container or a service, each container is then monitored by up to three HAProxy instances running on different hosts. The container is considered healthy if at least one HAProxy instance reports a “passed” health check and it is considered unhealthy when all HAProxy instances report a “unhealthy” health check.

Rancher’s approach handles network partitions and is more efficient than client-based health checks. By using HAProxy to perform health checks, Rancher enables users to specify the same health check policy for DNS service and for load balancers.

Note: Health checks will only work for services that are using the managed network. If you select any other network choice, it will not be monitored.

To enable health checks for services, we add the health check in the rancher-compose.yml file.

  1. wordpress:
  2. scale: 1
  3. health_check:
  4. port: 80
  5. # Interval is measured in milliseconds
  6. interval: 2000
  7. unhealthy_threshold: 3
  8. # For TCP, request_line needs to be ''
  9. # TCP Example:
  10. # request_line: ''
  11. request_line: GET /healthcheck HTTP/1.0
  12. healthy_threshold: 2
  13. # Response timeout is measured in milliseconds
  14. response_timeout: 2000

More details about Health Checks can be read in the concept section.

Note: If a host is down in Rancher (i.e. in reconnecting or inactive state), you will need to implement a health check in order for Rancher to launch the containers on your service on to a different host.

Custom Rancher Services


Custom Rancher services are configured by using a special image name in the compose template. The image name is how rancher-compose knows to set up a Rancher service versus a normal service.

Service Image Name
Load Balancer rancher/load-balancer-service
External Service rancher/external-service
Alias/DNS Service rancher/dns-service

Load Balancer


A load balancer can be scheduled like any other service. Read more about scheduling services and load balancers using rancher-compose.

Rancher supports L4 load balancing by adding ports and linking target services. Any traffic directed to any of source port(s) will be sent to the private port(s) of the linked service(s).

Note: Port 42 cannot be used as a source port for load balancers because it’s internally used for health checks.

When working with services that contains sidekicks, you need to link the primary service, which is the service that contains the sidekick label.

Note: Load balancers will only work for services that are using the managed network. If you select any other network choice for your target services, it will not work with the load balancer.

Load Balancer Example (L4)

Sample configuration docker-compose.yml

  1. lb:
  2. image: rancher/load-balancer-service
  3. ports:
  4. # Assign a random public port and direct traffic to private port 80 of the service.
  5. - 80
  6. # Listen on public port 80 and direct traffic to private port 80 of the service
  7. - 80:80
  8. # Listen on public port 82 and by default forward traffic to private port 81 using HTTP
  9. - 82:81
  10. # Assign a random public port and direct traffic to private port 9999 using TCP and not HTTP
  11. - 9999/tcp
  12. links:
  13. # Target services in the same stack will be listed as a link
  14. - web1:web1
  15. - web2:web2
  16. external_links:
  17. # Target services in a different stack will be listed as an external link
  18. - differentstack/web3:web3

Sample rancher-compose.yml

  1. lb:
  2. # Two load balancer containers
  3. scale: 2
  4. load_balancer_config:
  5. name: lb config
  6. web1:
  7. scale: 1
  8. web2:
  9. scale: 1
  10. web3:
  11. scale: 1

Advanced Load Balancing (L7)

We also support L7 load balancing with advanced routing options, which include using host headers, host paths and specific target ports. We go into more detail on advanced routing options for load balancers in our UI section, but anything that we can create in Rancher can be created using rancher-compose.

Advanced routing options use labels in the docker-compose.yml file. Here’s the basic syntax for applying the label. You would only use this label if you were going to do some advanced routing rules. Advanced routing rules are optional and all of the fields are optional as well. This syntax shows if you were to use all the options.

Label Key Label Value
io.rancher.loadbalancer.target.<SERVICE_NAME> <REQUEST_HOST>:<SOURCE_PORT>/<REQUEST_PATH>=<TARGET_PORT>


Note: If you use a source port with the advanced routing options, the source port must also be listed in ports section of the docker-compose.yml

Linking Services in a Different Stack

In the label for target services, <SERVICE_NAME> is the name of the service. If your service is in another stack, the <SERVICE_NAME> will need to include stack name using the following format <STACK_NAME>/<SERVICE_NAME>. The link to the target service of other stacks will be under external_links.

Syntax of the Combination of all Optional Fields

Since the fields are optional, we support all combinations of the fields. Here is the syntax for all combinations using request host, source port, path and target port.

Request Host Source Port Path Target Port Label Value
example.com 80 /path 81 example.com:80/path=81
example.com 80 /path/a example.com:80/path/a
example.com 80 81 example.com:80=81
example.com 80 example.com:80
example.com /path/b/c 81 example.com/path/b/c=81
example.com /path example.com/path
example.com 81 example.com=81
example.com example.com
80 /path 81 80/path=81
80 /path 80/path
80 81 80=81
/path 81 /path=81
/path /path
81 '81' *See Note


Note: It is assumed that if you have only a port in the label, then the port is for the target port of the service. When using only a target port, it must be surrounded by single quotes.

Wildcards

Rancher supports wildcards when adding host based routing. The following wildcard syntax is supported.

  1. *.domain.com -> hdr_end(host) -i .domain.com
  2. domain.com.* -> hdr_beg(host) -i domain.com.

Multiple Routing Rules for the Same Service

In rancher-compose, you can configure multiple hostname routing rules to the same service by separating each rule with a comma. See the example for service web2.

Priority

When there are multiple hostname routing rules, the order of priority is as follows:

  1. Hostname and URL
  2. Hostname only
  3. URL
  4. Default (no hostname, no URL)

Load Balancer Example (L7)

Sample configuration docker-compose.yml

  1. lb:
  2. image: rancher/load-balancer-service
  3. ports:
  4. # Listen on public port 80 and direct traffic to private port 80 of the service
  5. - 80:80
  6. # Listen on public port 82 and by default forward traffic to private port 81 using HTTP
  7. - 82:81
  8. # Listen on public port 9999 using TCP and not HTTP
  9. - 9999/tcp
  10. links:
  11. # Target services in the same stack will be listed as a link
  12. - web1:web1a
  13. - web2:web2a
  14. external_links:
  15. # Target services in a different stack will be listed as an external link
  16. - differentstack/web3:web3a
  17. labels:
  18. # Put load balancer containers on hosts with label lb=true
  19. io.rancher.scheduler.affinity:host_label: lb=true
  20. # Requests to http://app.example.com/foo:80 should be routed to web1 over port 8000
  21. io.rancher.loadbalancer.target.web1: app.example.com:80/foo=8000
  22. # Requests to http://app.example.com/foo should be routed to web2 over port 8000
  23. # and http://app.example.com/foo/bar over port 8001
  24. io.rancher.loadbalancer.target.web2: app.example.com/foo=8000,app.example.com/foo/bar=8001
  25. # Requests routed to web3 go to port 8000, overriding the default configuration
  26. # of 82:81
  27. io.rancher.loadbalancer.target.differentstack/web3: 82=8000

Sample rancher-compose.yml

  1. lb:
  2. # Two load balancer containers
  3. scale: 2
  4. load_balancer_config:
  5. name: lb config
  6. web1:
  7. scale: 1
  8. web2:
  9. scale: 1
  10. web3:
  11. scale: 1

Internal Load Balancer

To set an internal load balancer, the listening ports are listed under expose instead of ports.

Sample configuration docker-compose.yml

  1. lb:
  2. image: rancher/load-balancer-service
  3. # Instead of using ports, we use expose to define that it will be private ports
  4. expose:
  5. # Listen on private port 80 and direct traffic to private port 80 of the service
  6. - 80:80
  7. # Listen on private port 82 and by default forward traffic to private port 81 using HTTP
  8. - 82:81
  9. links:
  10. # Any service that is a target will be listed as a link
  11. - web1:web1



Sample rancher-compose.yml

  1. lb:
  2. # Two load balancer containers
  3. scale: 2
  4. load_balancer_config:
  5. name: lb config
  6. web1:
  7. scale: 1

Custom haproxy.cfg

For advanced users, you can specify global and defaults configuration to the load balancer in the rancher-compose.yml. Please refer to the HAProxy documentation for details on the available options you can add.

Sample rancher-compose.yml

  1. lb:
  2. scale: 1
  3. load_balancer_config:
  4. haproxy_config:
  5. defaults: <DEFAULTS_INPUTS>
  6. global: <GLOBAL_INPUTS>
  7. health_check:
  8. port: 42
  9. interval: 2000
  10. unhealthy_threshold: 3
  11. healthy_threshold: 2
  12. response_timeout: 2000

External Service


With external services, you can set either external IP(s) OR a domain name. The rancher/external-service is not an actual image, but is required for the docker-compose.yml. There are no containers created for external services.

Sample configuration docker-compose.yml

  1. db:
  2. image: rancher/external-service
  3. redis:
  4. image: redis

Sample rancher-compose.yml using external IPs

  1. db:
  2. external_ips:
  3. - 1.1.1.1
  4. - 2.2.2.2
  5. # Override any service to become an external service
  6. redis:
  7. image: redis
  8. external_ips:
  9. - 1.1.1.1
  10. - 2.2.2.2



Sample rancher-compose.yml using hostname

  1. db:
  2. hostname: example.com

Service Alias/Internal DNS service


A service alias creates a pointer to service(s). In the example below, web[.stack-name.rancher.internal] will resolve to the IPs of the containers of web1 and web2. The rancher/dns-service is not an actual image, but is required for the docker-compose.yml. There are no containers created for alias services.

Sample configuration docker-compose.yml

  1. web:
  2. image: rancher/dns-service
  3. links:
  4. - web1
  5. - web2
  6. web1:
  7. image: nginx
  8. web2:
  9. image: nginx