Existem alguns problemas aqui que descreverei. Outros já deram um jeito de explicá-los, mas como desenvolvedor do Django, posso adicionar alguns problemas:
- Não entenda mal a relação entre servidores, navegadores e DNS. O navegador precisa do DNS para procurar um nome e obter um endereço IP para se conectar. O servidor não fornece uma banana voadora cujo nome aponta para seu IP.
Nota: O httpd irá, mas não para fins de conexão - ele o usa para hospedar múltiplos hosts virtuais em um IP.
-
/etc/hosts
pode apontar um nome de domínio para um IP, mas é isso. Eles não podem especificar a porta 8000. Esse é o trabalho do navegador.
- Para hospedar algo na porta 80, você precisa executá-lo como root, redirecionar porta 80 , ou usa
setcap
para permitir que o Python roube a porta 80 . Os dois últimos são muito hacky, mas são infinitamente melhores que rodar um servidor dev do Django como root. Por favor, nunca faça isso.
- A hospedagem de vários servidores do dev do Django na porta 80 de um IP é impossível. Todos tentarão ligar-se avidamente a ele e não permitir mais amarras. Você tem que escalonar as portas ou colocar um httpd / reverse-proxy na frente para dividir os hosts virtuais para os servidores do Django.
Para desenvolvimento, apenas carrego o servidor de desenvolvimento como e quando preciso. Eu só corro um de cada vez e ele é executado no padrão 127.0.0.0:8000
. Se esse modelo combina com você e você só quer hospedar em um nome de domínio personalizado, apenas algo assim para o seu /etc/hosts
:
127.0.0.1 my.domain.ext sub.my.domain.ext
Você pode continuar fazendo o encadeamento, mas lembre-se de que isso substituirá todo o tráfego de saída das solicitações nesses domínios. Aka: não esqueça que você hackeou seu próprio DNS! A partir daí, você apenas carrega http://my.domain.ext:8000
e está vendo seu servidor de desenvolvimento.
Se você quiser http://my.domain.ext
, você terá que hackear as coisas (veja acima) ou mudar para uma infraestrutura mais tradicional (abaixo).
Se você precisar executar vários servidores, posso sugerir apenas executar uma pilha adequada. Eu rodaria nginx + uwsgi + virtualenv stack. Algo parecido com o que você usaria na produção. De fato, quanto mais próximo você puder espelhar seu ambiente de produção, melhor. Se você estiver usando o Apache e o modwsgi, faça isso.
Isso oferece uma plataforma de testes melhor. Se você precisar conectar-se à depuração, acho que configure o uwsgi para registrar (e monitorar o log) um substituto adequado para uma saída do console ao vivo.