Назад | Перейти на главную страницу

Почему мой экземпляр не проходит проверку работоспособности ELB при добавлении его в балансировщик нагрузки через Ansible?

Я пытаюсь добавить экземпляр EC2 в Elasitic Load Balancer, используя Ansible playbook, с ec2_elb модуль. Это задача, которая должна сделать это:

- name: "Add host to load balancer {{ load_balancer_name }}"
  sudo: false
  local_action:
    module: ec2_elb
    state: present
    wait: true
    region: "{{ region }}"
    ec2_elbs: ['{{ load_balancer_name }}']
    instance_id: "{{ ec2_id }}"

Однако он обычно терпит неудачу с таким выводом (повышена многословность):

TASK: [Add host to load balancer ApiELB-staging] ****************************** 
<127.0.0.1> REMOTE_MODULE ec2_elb region=us-east-1 state=present instance_id=i-eb7e0cc7
<127.0.0.1> EXEC ['/bin/sh', '-c', 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868 && echo $HOME/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868']
<127.0.0.1> PUT /var/folders/d4/17fw96k107d5kbck6fb2__vc0000gn/T/tmpki4HPF TO /Users/pkaeding/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868/ec2_elb
<127.0.0.1> EXEC ['/bin/sh', '-c', u'LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 /usr/bin/python /Users/pkaeding/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868/ec2_elb; rm -rf /Users/pkaeding/.ansible/tmp/ansible-tmp-1409156786.81-113716163813868/ >/dev/null 2>&1']
failed: [10.0.115.149 -> 127.0.0.1] => {"failed": true}
msg: The instance i-eb7e0cc7 could not be put in service on LoadBalancer:ApiELB-staging. Reason: Instance has not passed the configured HealthyThreshold number of health checks consecutively.

FATAL: all hosts have already failed -- aborting

Моя конфигурация ELB определена следующим образом (также через Ansible):

- name: "Ensure load balancer exists: {{ load_balancer_name }}"
  sudo: false
  local_action:
    module: ec2_elb_lb
    name: "{{ load_balancer_name }}"
    state: present
    region: "{{ region }}"
    subnets: "{{ vpc_public_subnet_ids }}"
    listeners:
      - protocol: https
        load_balancer_port: 443
        instance_protocol: http
        instance_port: 8888
        ssl_certificate_id: "{{ ssl_cert }}"
    health_check:
        ping_protocol: http # options are http, https, ssl, tcp
        ping_port: 8888
        ping_path: "/internal/v1/status"
        response_timeout: 5 # seconds
        interval: 30 # seconds
        unhealthy_threshold: 10
        healthy_threshold: 10
  register: apilb

Когда я получаю доступ к ресурсу статуса с моего ноутбука или с самого сервера (как localhost), я получаю 200 ответ, как ожидалось. Я также добавил command прямо перед добавлением экземпляра в ELB, чтобы убедиться, что приложение загружено и правильно обслуживает запросы (и это так):

- command: /usr/bin/curl -v --fail http://localhost:8888/internal/v1/status

Я не вижу никаких ответов, отличных от 200, для ресурса проверки статуса в журналах моего приложения (но, конечно, если запросы никогда не доходили до моего приложения, они не регистрировались).

Другая странность заключается в том, что экземпляр действительно добавляется в ELB, и, похоже, он работает правильно. Итак, я знаю, что, по крайней мере, в какой-то момент балансировщик нагрузки сможет правильно получить доступ к приложению (как для ресурса проверки статуса, так и для других ресурсов). Консоль AWS показывает, что экземпляр исправен, а диаграммы Cloudwatch не показывают неудачных проверок работоспособности.

Любые идеи?

Адаптировано из моего предыдущего комментария:

Судя по документации Ansible, есть wait_timeout параметр, который вам нужно будет установить на значение выше 300, чтобы это работало. (330 было бы безопасно).

Или вы могли бы снизить interval или healthy_threshold или оба, так что вам придется ждать менее 300 секунд.

Ваш unhealthy_threshold такой же, как healthy_threshold, поэтому, как только веб-сервер начнет отправлять 500 ответов, он останется в пуле в течение 5 минут, прежде чем ELB его отбросит.

Вы можете использовать опцию ec2_elb wait: no.