As portas Docker da instância EC2 não são acessíveis após a alteração do tipo de instância

1

Quando altera o tipo de instância do EC2 , me deparo com um problema. A máquina tinha 3 contêineres Docker que precisavam ser reiniciados e após o reinício suas portas ficaram inacessíveis.

Qual poderia ser o problema e como devo proceder para obter outras informações de depuração necessárias?

  • Nenhuma alteração foi feita na configuração dos Grupos de segurança na AWS, todas as portas necessárias ainda estão ativadas.

  • Ainda estou habilitado para SSH na instância do EC2, mas as portas usadas por O Docker (80, 8181) não está acessível (tempo limite de conexão).

  • Em um navegador da web, não importa se estou tentando acessar uma porta que está sendo usada ou o comportamento do navegador é sempre o mesmo (o indicador de carregamento é interrompido no início, seguido de tempo limite, nada é registrado, por ex. Access.log ou error.log do Apache ).

  • Dentro de um navegador da Web, nenhum endereço da instância por seu DNS público (IPv4), IPv4 Público IP ou seu nome de domínio original funciona.

  • Reiniciar a instância ou alterar seu tipo novamente não ajuda

Eu consigo fazer ping / telnet / wget nas portas usadas pelos contêineres do Docker    dentro da instância:

$ docker exec f227cf8d9481 wget 127.0.0.1:8181
converted 'http://127.0.0.1:8181' (ANSI_X3.4-1968) -> 'http://127.0.0.1:8181' (UTF-8)
--2018-01-15 23:49:10--  http://127.0.0.1:8181/
Connecting to 127.0.0.1:8181... connected.
HTTP request sent, awaiting response... 401 Unauthorized

Mas não de fora (o endereço IP ainda é resolvido):

$ wget <aws-ip>.<aws-zone>.<instance>.amazonaws.com:8181
--2018-01-16 00:53:32--  http://<aws-ip>.<aws-zone>.<instance>.amazonaws.com:8181/
Resolving <aws-ip>.<aws-zone>.<instance>.amazonaws.com... xxx.xxx.xxx.xxx
Connecting to <aws-ip>.<aws-zone>.<instance>.amazonaws.com|xxx.xxx.xxx.xxx|:8181... failed: Operation timed out.
Retrying.

Os contêineres docker estão em execução e o mapeamento entre as portas do Docker é    feito corretamente:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                                    NAMES
f227cf8d9481        cloud9              "forever /cloud9/s..."   3 seconds ago       Up 2 seconds        0.0.0.0:8080-8081->8080-8081/tcp, 80/tcp, 0.0.0.0:8181->8181/tcp, 0.0.0.0:81->3000/tcp   my-cloud9
fa0d2bbce863        wordpress           "docker-entrypoint..."   59 minutes ago      Up 59 minutes       0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp                                                 goofy_torvalds
6ada961a5ea0        mysql               "docker-entrypoint..."   About an hour ago   Up About an hour    0.0.0.0:3306->3306/tcp  

A configuração Iptables parece ter as portas do Docker ativadas:

$ sudo iptables --table nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !loopback/8           ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  <aws-ip>.<aws-zone>.<instance>.internal/16  anywhere            
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:mysql
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:https
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:http
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:8181
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:tproxy
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.<instance>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:webcache
MASQUERADE  tcp  --  <aws-ip>.<aws-zone>.internal  <aws-ip>.<aws-zone>.<instance>.internal  tcp dpt:hbci

Chain DOCKER (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            
DNAT       tcp  --  anywhere             anywhere             tcp dpt:mysql to:<docker-ip>:3306
DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:<docker-ip>:443
DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:<docker-ip>:80
DNAT       tcp  --  anywhere             anywhere             tcp dpt:8181 to:<docker-ip>:8181
DNAT       tcp  --  anywhere             anywhere             tcp dpt:tproxy to:<docker-ip>:8081
DNAT       tcp  --  anywhere             anywhere             tcp dpt:webcache to:<docker-ip>:8080
DNAT       tcp  --  anywhere             anywhere             tcp dpt:81 to:<docker-ip>:3000

Não, não parece haver nenhuma atividade de rede perceptível (cerca de 2 KB a cada 5 minutos) usando a ferramenta de monitoramento da instância do EC2. Exceto pelos picos dos tempos em que usei o SSH para fazer o login:

    
por Peter Gerhat 16.01.2018 / 01:20

1 resposta

0

O problema estava na configuração do certificado DNS e SSL, porque a instância foi configurada para usar apenas HTTPS.

Após a alteração do tipo de instância, a nova instância recebeu automaticamente um novo URL, que precisava ser atualizado com o provedor de DNS e a autoridade de certificação.

    
por 17.01.2018 / 19:29