Por que minha instância está falhando nas verificações de integridade do ELB ao adicioná-lo ao balanceador de carga via Ansible?

4

Estou tentando adicionar uma instância do EC2 a um Balanceador de Carga Elasitic usando um playbook Ansible, com o módulo ec2_elb . Esta é a tarefa que deve fazer isso:

- 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 }}"

No entanto, rotineiramente falha, com essa saída (verbosidade aumentada):

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

Eu tenho minha configuração de ELB definida assim (também via 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

Quando eu acesso o recurso de status do meu laptop ou do próprio servidor (como localhost) recebo uma resposta 200 conforme o esperado. Eu também adicionei uma tarefa command ao playbook Ansible, antes de adicionar a instância ao ELB, para confirmar que o aplicativo foi inicializado e atender aos pedidos corretamente (e é):

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

Não vejo nenhuma resposta não-200 para o recurso de verificação de status nos logs do meu aplicativo (mas, é claro, se as solicitações nunca chegarem até o meu aplicativo, elas não serão registradas).

A outra coisa estranha é que a instância é adicionada ao ELB e parece funcionar corretamente. Portanto, sei que, em algum momento, pelo menos, o balanceador de carga pode acessar o aplicativo adequadamente (para o recurso de verificação de status e outros recursos). O console da AWS mostra que a instância está íntegra e os gráficos do Cloudwatch não mostram nenhuma verificação de integridade.

Alguma idéia?

    
por pkaeding 27.08.2014 / 18:53

2 respostas

4

Adaptado do meu comentário anterior:

A julgar pelos documentos Ansible, há um parâmetro wait_timeout que você deverá definir para algo maior que 300 para isso funcionar. (330 estaria seguro).

Ou você pode reduzir seu interval ou healthy_threshold ou ambos para que você tenha que esperar menos de 300 segundos.

Seu unhealthy_threshold é igual ao healthy_threshold , portanto, quando um servidor da web começar a gerar 500 respostas, ele permanecerá no pool por cinco minutos antes que o ELB o derrube.

    
por 27.08.2014 / 21:11
3

Você pode usar a opção ec2_elb wait: no .

    
por 23.09.2015 / 20:26