Qual é o comportamento esperado de várias entradas de nome de host com endereços IP diferentes em / etc / hosts?

Question

Sei que isto foi discutido vários places , mas parece não haver uma resposta definitiva ainda - pelo menos não para RHEL 6. Só espero que alguém possa apontar para como está funcionando para que eu possa cavar um pouco.

Versão resumida: Eu tenho um nó de host OpenVZ com um endereço IP público que está atuando como um proxy reverso para um monte de contêineres OpenVZ com endereços IP privados. Eu criei 2 containers com o mesmo nome (se você quer saber o porquê, pule para a versão longa abaixo), e o HN também tem essas entradas (entre outras) em seu /etc/hosts :

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

Eu posso usar o OpenVZ para suspender / retomar qualquer um desses hosts por ID, e o proxy reverso parece encaminhar magicamente solicitações para qualquer host que esteja sendo executado (por exemplo, para o endereço IP 10.0.0.130 ou 10.0.0.131 . Mas eu posso Pela minha vida, descubra qual parte do software está fazendo isso. É Apache? É algo no sistema de rede da HN? Outra coisa? Parece funcionar, mas eu gostaria de saber mais sobre o porquê. / como, como também parecem existir grandes diferenças de opinião sobre se ele deve funcionar . Para ser claro, eu não estou procurando por round-robin ou balanceamento de carga aqui. troca manual de um container OpenVZ para outro.

Versão do Lomg: Ao configurar alguns scripts para criar e gerenciar uma série de contêineres do OpenVZ, criei um script chamado make_clone.sh , que usa um modelo e cria um novo contêiner. O script usa 2 parâmetros - o ID do contêiner e o nome do host desejado. Uma das coisas que ele faz é alocar um novo endereço IP 10.0.0.* para o contêiner e configurar algumas redes, das quais um elemento está colocando uma entrada no arquivo /etc/hosts do Nó Host.

Ao testar alguns scripts de backup / restauração para esses contêineres, eu queria 'fingir' que um determinado contêiner havia morrido, criar outro com o mesmo nome e restaurar o backup. Em vez de excluir o contêiner original, usei vzctl stop 130 para colocá-lo off-line. Em seguida, criei um novo contêiner com o ID 131, mas com o mesmo nome. Uma vez que foi, eu restaurei o banco de dados MySQL e verifiquei (através de um navegador) que eu poderia acessá-lo - ele está executando o Joomla com algumas personalizações - e tudo estava bem.

Mas notei que no /etc/hosts do nó do host, eu tinha essas duas entradas (entre outras):

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

O Host Node também está atuando como um proxy reverso. Apenas o nó host tem um endereço IP externo e sua configuração do Apache mapeia subdomínios para contêineres. Então, assim como as entradas acima em / etc / hosts, ele também tem seções como esta na configuração do httpd:

        ServerName testbackup.xxx.yy

    ProxyRequests Off
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyPass /server-status !
    ProxyPass / http://testbackup.xxx.yy/
    ProxyPassReverse / http://testbackup.xxx.yy/

    <Location />
            Order allow,deny
            Allow from all
    </Location>

'

No cenário que estou descrevendo, ele acabaria com 2 dessas seções devido aos scripts, mas eles seriam idênticos - refere-se ao Container por hostname não IP, o que me faz pensar que não é o Apache por que está escolhendo o contêiner 'working'. Agora posso navegar para http://testbackup.xxx.yy/ (usando o nome de domínio real, obviamente) e o Apache parece feliz em direcionar as solicitações para qualquer um dos 10.0.0.130 ou 10.0.0.131 . Posso alternar entre eles simplesmente suspendendo / retomando os contêineres do OpenVZ.

Eu não esperava que isso funcionasse - mas é bom que sim. Minha pergunta é, deveria? Pode ser invocado? Ou é apenas um acaso que vai parar de funcionar quando qualquer pedaço de penugem que entra em algum outro arquivo de configuração em algum lugar seja arrumado?

    

Answer 1

Como um host pode ter vários endereços IP, o que você está vendo é o comportamento esperado. É como ter vários apelidos, como: bossman, haus, jungle-jim, etc ... Todo mundo que me conhece sabe que esses são meus apelidos (na verdade, eles não são meus apelidos).

A menos que você esteja tentando acessar o recurso por meio do endereço IP, seus sistemas devem funcionar como se nada tivesse acontecido. (Tecnicamente falando, gerar um novo endereço IP em um contêiner não deve afetar seus serviços, desde que esses serviços não estejam vinculados ao endereço IP. No seu caso, você pode ter tido a sorte de ter seus aplicativos sendo executados sem problemas. )

Exemplo: eu poderia atribuir 4 endereços IP a um host:

10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
10.0.0.132 testbackup.xxx.yy
10.0.0.133 testbackup.xxx.yy

TodosessesendereçosIPapontamparatestbackup.xxx.yy,oquesignificaque,seeutentaracessartestbackup.xxx.yy,acessareiqualquerumdeles,dependendodequalendereçoIPestáativo/responsivonomomentodaminhasolicitação.Novamente,issosófunciona,desdequeoserviçoquevocêestátentandoacessarnãoestejavinculadoespecificamenteaesseendereçoIP.

Noentanto,sevocêdesativou10.0.0.133etentouacessarorecursoespecificamenteapartirde10.0.0.133(ouseja,http://10.0.0.133/),vocêreceberiaumerro.

ATUALIZAÇÃO:

SevocêestiverusandooApacheVirtualHosts:

<VirtualHost*:80>DocumentRoot/www/example1ServerNamewww.example.com#Otherdirectiveshere</VirtualHost><VirtualHost*:80>DocumentRoot/www/example2ServerNamewww.example.org#Otherdirectiveshere</VirtualHost>

EstaconfiguraçãopermitiráquedoissitesusemomesmoendereçoIPeporta.SeéassimquevocêconfiguraoVirtualHosts,oVirtualHostsestámanipulandoseuroteamentoautomático(sevocêlistouosdoiscamposServerNamecomoomesmohost,teoricamente).

VocêindicouqueestavausandooOpenVZ.OOpenVZpodepermitirqueseussitessejamexecutadosdeformaindependente,masfisicamente,elesestãotodosnomesmohost.AmenosquevocêatribuaacadaVEoseupróprionomedehostetenteacessaronomedohostespecificamenteenquantoeleestiverinativo,vocêobteráocomportamentoesperadodosite.

Porexemplo,sevocêatribuiuumhostnamediferenteaumdosendereçosdoOpenVZ/IP:

10.0.0.133mybackup.xxx.yy

Sevocêtirasseo10.0.0.133,nãoconseguiriamaisacessá-loapartirdemybackup.xxx.yy,masseriapossívelacessá-loapartirdetestbackup.xxx.yy(porqueelepassapelosoutrosendereçosIPqueaindaestãoeassociadoatestbackup.xxx.yy).