Se você quer validar um proxy reverso, hospedar diversas aplicações no IIS para testar, enfim, estou compartilhando com vocês 10 domínios que apontam para 127.0.0.1.

NOTA

Esses endereços foram descontinuados, por favor utilize o nip.io

https://nip.io/

A ideia original

Respectivamente:

• localhost1.gago.io
• localhost2.gago.io
• localhost3.gago.io
• localhost4.gago.io
• localhost5.gago.io
• localhost6.gago.io
• localhost7.gago.io
• localhost8.gago.io
• localhost9.gago.io
• localhost10.gago.io

Ao realizar uma requisição para localhost6.gago.io, o primeiro passo do browser é buscar o IP desse endereço, o DNS retornará 127.0.0.1, seu ip de loopback.

Logo em seguida seu browser usará a porta especificada na URL ou a padrão do protocolo definido no schema da URL (443 para https ou 80 para http).

De posse do IP e da PORTA, uma conexão TCP será enviada para esse endereço (IP e PORTA), aqui, nome não é mais relevante, embora ele vá em um cabeçalho chamado host.

É com esse cabeçalho que seu proxy reverso consegue diferenciar localhost6.gago.io de localhost7.gago.io, por exemplo.

Qual o sentido disso?

1° porque é util sempre que você está testando um proxy reverso, api gateway ou algum cenário multi-tenant na própria máquina.

2° porque ilustra o papel de um DNS, inclusive para service discovery.

3° porque desmistifica e remove a ideia de que DNS recebe a requisição HTTP (isso é papel de um proxy reverso) e por consequência, DNS não diz respeito à portas.

Exemplo

# docker-compose.override.yml
version: '3.4'

services:
  identity_mock:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:12080;https://+:12443
    ports:
      - "12080:12080"
      - "12443:12443"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
    networks:
     app:
        aliases:
          - localhost10.gago.io

  example:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:13080;https://+:13443
      - bearer__Authority=https://localhost10.gago.io:12443
      - oidc__Authority=https://localhost10.gago.io:12443
    ports:
      - "13080:13080"
      - "13443:13443"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
    networks:
     app:
        aliases:
          - localhost1.gago.io


networks:
  app:
    driver: bridge  

Esse exemplo é bem curioso, pois enquanto teu browser é enganado pelo meu DNS, que entrega o IP 127.0.0.1 como resposta para o nome localhost10.gago.io, o docker engana o container de aplicação fazendo com que localhost10.gago.io aponte para o container que é meu identity server. Com isso tudo funciona perfeitamente.

Conclusão

Esses 10 nomes são coringas na hora de criar demonstrações. Como o endereço aponta para 127.0.0.1, seja eu daqui ou você daí da sua casa sempre veremos respectivamente nosso próprio ambiente ao usarmos esses nomes. Como há um DNS de verdade entregando esses IP’s, não precisamos ficar manipulando arquivos hosts.

No docker, se passar por esses endereços é super fácil e por isso é uma mão na roda na hora de fazer demonstrações como a que mostrei acima, uma aplicação web e seu identity server.

Esses nomes vão me ajudar no conteúdo gratuito e no conteúdo das turmas de todos os cursos. No curso de RabbitMQ vamos abordar Event Driven, e preciso de algumas aplicações lado-a-lado com nomes diferentes que ao mesmo tempo sejam fáceis de ser usáveis pelos alunos.

Já no Docker Definitivo temos demandas novas com Kong e NGINX que usarão esses nomes, mas também multi-tenant maturity models.

Amanhã eu vou mostrar o nosso mock de servidor de identidade, já estou finalizando a documentação.