Maneira fácil de visualizar um site em um IP diferente do associado ao nome do host?

Question

Alguma experiência - o WordPress é realmente irritante em termos de qual nome de host você acessa, o que dificulta a criação de ambientes de teste (ou seja, eu poderia criar um subdomínio para preparação, y.x.com , mas o WordPress definiria todos os links no banco de dados como sendo de lá e não x.com , que é onde eles estarão assim que eu fizer a mudança de DNS). Para contornar isso, eu configurei um alias no meu arquivo / etc / hosts, então eu não tenho que continuar mudando o nome do domínio nas configurações do WP.

Em outras palavras: agora eu tenho um site ao vivo rodando em% IP x e hostname x.com . Quero deixar o site ativo em execução e ter configurado uma máquina de teste no IP y , acessada pelo nome do host x.com , usando uma entrada no /etc/hosts mencionado anteriormente.

Minha pergunta: Como mostro a máquina de teste para o cliente sem que ele edite o arquivo / etc / hosts? Existe um serviço on-line que configura um iframe e mostra um IP específico como um nome de host específico?

Obrigado!

Editar: Não estou perguntando como configurar meus registros DNS; eles são bons no momento. Eu posso navegar para a máquina de teste apenas digitando seu IP na barra de endereços, e o WordPress carrega e tudo está ótimo, exceto que todos os links são para x.com , e clicar neles me leva ao site de produção / ao vivo. Posso corrigir isso colocando uma entrada no arquivo hosts de minha máquina local (por exemplo, /etc/hosts ), que substitui os registros DNS públicos para o site ativo e, em vez disso, mostra a máquina de teste. Eu estou essencialmente querendo uma maneira de fazer isso facilmente para o meu cliente, isto é, sem ele ter que editar seu arquivo hosts .

    

Answer 1

Mapeie x.com/staging para outro servidor

Supondo que você esteja executando no Apache, o proxy pode fazer o truque. A execução de um proxy reverso no Apache sugere que o seguinte pode funcionar, mas eu não testei:

ProxyPreserveHost on
ProxyPass /staging/ http://y.y.y.y/
ProxyHTMLURLMap http://y.y.y.y /staging

<Location /staging/>
    ProxyPassReverse /
    ProxyHTMLEnable On
    ProxyHTMLURLMap / /staging/
    # We need to peek into the HTML, so ensure we don't get gzip'd content:
    RequestHeader unset Accept-Encoding
</Location>

Acima, uma pasta virtual /staging mapeia tudo de http://x.com/staging/ para / no outro endereço IP. Para continuar usando x.com como host, adicionei ProxyPreserveHost .

Tudo isso precisará da barra final; alguma reescrita padrão poderia acrescentar isso quando necessário:

# Add trailing slash if omitted
RewriteRule ^staging$ /staging/ [R=302,L]

Evite compartilhar cookies: use um domínio dedicado

No entanto, para evitar problemas muito desagradáveis com cookies de sessão, eu preferiria um domínio dedicado (de preferência nem mesmo algum subdomínio de x.com ). Para isso, remova todas as referências a staging acima. E para ainda enviar o nome de domínio esperado, suponho que se poderia adicionar um adicional:

RequestHeader set Host x.com

Ao usar esse domínio dedicado, o Apache também não precisará reescrever nenhuma URL relativa, como /some/page em /staging/some/page . No entanto, isso pode implicar que você não notará falhas ao reescrever URLs absolutos (especialmente possíveis quando o JavaScript está envolvido). Como uma falha ao reescrever http://x.com/some/page de volta para http://client.mycompany.com/some/page , pode passar despercebido se a mesma URL existir no servidor de produção e o navegador buscar isso diretamente. Isso pode ser um benefício ou pode ser um desastre quando você ainda está conectado ao servidor de produção e acha que está alterando o conteúdo no servidor de teste ...

Usando o .htaccess

Apenas para a posteridade, imaginei que também era possível usar algo como o seguinte em um arquivo .htaccess :

# Does NOT work (for me). On the target server, this gets me:
#   HTTP_HOST = y.y.y.y            - from the proxy request? Expected x.com
#   HTTP_X_FORWARDED_HOST = x.com  - from Host
#   HTTP_X_MY_DUMMY = x.com        - from X-My-Dummy, as expected

RewriteEngine On
RequestHeader set Host x.com 
RequestHeader set X-My-Dummy x.com
RewriteRule ^(.*) http://y.y.y.y/$1 [L,P] 
ProxyPassReverse / http://y.y.y.y/

No entanto, ProxyPassReverse parece não ser permitido em .htaccess . E alguns testes básicos parecem revelar que o [P] proxy também sempre adiciona seu próprio Host header, e traduz meu Host em X-Forwarded-Host . Isso pode muito bem estar relacionado à hospedagem virtual compartilhada que eu usei para algum teste rápido. Mas ProxyPreserveHost não pode ser usado em .htaccess .

Veja o mod_proxy do Apache, mod_headers e mod_rewrite documentação.

    

Answer 2

você não pode vincular um mesmo nome de host a diferentes ip's. Você precisa editar seus registros de DNS para apontar o domínio para a máquina temporária ou você precisa fazer alterações de resolução de host local via arquivo de hosts.

Além disso, você pode adicionar uma variável de verificação / condição via PHP ou outro idioma com o qual seu site está sendo executado, se houver, o site será aberto na máquina de teste por exemplo http://examplesite.com/?staging=true

    

Answer 3

Outra forma é um servidor proxy normal (como Squid ) e um /etc/hosts editado no servidor proxy.

Quando você usa um proxy HTTP, o navegador do cliente não faz nenhuma pesquisa de DNS para o x.com, mas se conecta ao servidor proxy e informa para ele se conectar ao x.com. Como você curvou x.com para outro IP no servidor proxy, você obtém os resultados do servidor intermediário.