Configurando dominio personalizado no blogger.com

INTRODUÇÃO

Ao criar um site no blogger.com, podemos usar o dominio que ele mesmo sugere como por exemplo: meusite.blogspot.com. Mas para usar o nosso próprio domínio registrado como por exemplo: www.meusite.com, nesse artigo vamos mostrar como realizar essas configurações.

CONFIGURAÇÃO

1. Blogger.com

Acessar o blogger.com, no painel lateral esquerdo superior, selecionar o blog. Depois disso, clique em configurações. Procure a seção "Publicação" e clique em "Domínio personalizado". Nesse momento, vai abrir um pop-up para o preenchimento, coloque o seu domínio como "www.meusite.com", precisa colocar o "www" para não dar erros. Ao clicar em salvar, vai aparecer uma mensagem de erros e informando os códigos chave-valor do CNAME que deverão ser usado no item 2 desse artigo.

Serão mostrados dois CNAMEs:

• CNAME 
• Nome: www
• Valor: ghs.google.com

• CNAME
• Nome: código_seu_blog
• Valor: url_gerada_seu_blog

Onde o primeiro CNAME quase sempre deve-se usar esse conjunto de dados (chave-valor). Mas no segundo CNAME, será gerado um código exclusivo do seu blog e o valor será como fosse uma url, também um código gerado para o seu blog.

Além disso, entre também na mesma seção "Publicação", ative o redirecionamento do dominio algo como meusite.com para www.meusite.com.

Por último, entre na seção "HTTPS" e ative todas essas configurações para aumentar a segurança do seu blog.

Observação: Anotar os códigos gerados assim que aparecer no pop-up porque depois não conseguimos mais obter nesse site. Pois deve seguir uma regra de segurança que quando um código alfanumérico é gerado, só mostra na primeira vez e depois não mostra mais.

2. Site de registro do dominio

Nesse momento, precisa entrar no site onde você fez o registro do domínio e entrar na seção de configuração do DNS. Basta adicionar as seguintes configurações:

Tipo: A

Nome: @

Valores: 216.239.32.21, 216.239.34.21, 216.239.36.21 e 216.239.38.21

Tipo: CNAME

Nome: www

Valor: ghs.google.com

Tipo: CNAME

Nome: código_seu_blog

Valor: url_gerada_seu_blog

Os valores CNAMEs foram obtidos no item 1 no painel dentro do blogger.com, usar os valores aqui.

Observações:

Excluir ou fazer backup de outras configurações do tipo A ou CNAME que podem conflitar com as configurações acima e acabar não funcionando, deixando o site fora do ar.

Sobre tempo de vida, pode deixar os valores padrão atribuídos automaticamente. Além disso, remover encaminhamento do domínio para outro domínio se caso essa configuração foi realizada pelo usuário ou o site de registro criou-a automaticamente. Caso contrário, vai dar erros no acesso ao site. Por último, depois disso, essas configurações podem levar horas ou até 48 horas para serem aplicadas. O ideal é realiza-la hoje e no outro dia ou depois de uma ou duas horas, realizarem os testes.

Apache Web Server Httpd - Configurações com e sem Proxy Reverso

INTRODUÇÃO

Na configuração do proxy reverso do apache Web Server, podemos ter situações onde queremos mapear paths com ou sem o proxy reverso. Isso tudo dentro do mesmo servidor Apache, sem precisar criar outro servidor Apache (isto é, criar outro container para subir outro Apache para resolver o problema sem proxy reverso).

CONFIGURAÇÃO

Para fazer isso, nos arquivos de configurações do apache, com a extensão .conf, por exemplo[1], devemos informar a diretiva "!" para o proxy reverso não estar ativo para um determinado path, por exemplo.

Conforme documentação[2], temos o seguinte exemplo de configuração:

ProxyPass            /site/recursos/docs !

ProxyPassReverse     /site/recursos/docs !

ProxyPass            /site/recursos "http://backend.exemplo.com"

ProxyPassReverse     /site/recursos "http://backend.exemplo.com"

Nesse caso, ao acessar o path "/site/recursos/docs" não funcionará o proxy reverso. Mas o que estiver configurado no Apache além disso (como acesso a diretório ou outras configurações) pode funcionar, sem conflitar com a configuração do Proxy Reverso.

Observação: A ordem dos paths é importante, colocando primeiro o path mais detalhado possível para o mais geral. Pois na execução do proxy reverso, verá se o path "/site/recursos" tem proxy reverso, nesse caso, a primeira configuração é "/site/recursos/docs" o que não "bate" (match), e indo para a configuração seguinte que dará "match" e será executada (indo para a URL http://backend.exemplo.com).

Se fosse o contrário (configurações invertidas, onde temos o path "/site/recursos" primeiro), ao chamar a URL "/site/recursos/docs" fará um match com a configuração "/site/recursos" apenas no começo (porque esse path é mais geral) e será válido o match, sendo executado o proxy reverso da configuração "/site/recursos" que chamará a URL http://backend.exemplo.com o que estará errado, segundo as nossas configurações.

A seguir, temos o restante da configuração para mapear o path "/site/recursos/docs" para o sistema de arquivos (File System) do servidor:

DocumentRoot "/var/local/docs"

Alias /site/recursos/docs "/var/local/docs"

<Directory "/var/local/docs">

    Options Indexes FollowSymLinks MultiViews

    AllowOverride None

    Require all granted

</Directory>

A configuração do proxy reverso e depois a configuração do diretório (nesse ordem) devem estar dentro da tag "VirtualHost" do arquivo de configuração do Apache Httpd.

CONCLUSÃO

Com essa configuração conseguimos desativar o proxy reverso somente para um determinado path e evitando o conflito com outras configurações de proxy reverso para outros paths. Sem isso, precisaríamos criar outros servidores/containers para isolar isso, o que sempre pode não ser possível.

REFERÊNCIAS

[1] Dependendo da versão do Apache e até do sistema operacional subjacente, pode ter mudanças na organização dos arquivos de configuração. Uma vez entendido essas mudanças, a essência das configurações descritas nesse artigo, permanece a mesma, somente variando a sintaxe e localização desses arquivos de configuração.

[2] https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

Docker - Acessando outra aplicação localmente no mesmo host

INTRODUÇÃO 

Ao usar o docker para criar containers para a sua solução, pode haver a necessidade de uma aplicação A dentro de um container A acessar outra aplicação B em outro container B ou no próprio host hospedeiro. Se chamar pela URL localhost:X (onde X é a porta), a sua aplicação A que está dentro do container A, procurará por esse serviço no próprio container A e que não existirá! Pois não tem nenhuma aplicação registrada na porta X no container A. Pois essa aplicação estará no container B!

EXEMPLO

Container A

Aplicação: Web (Pode ser uma aplicação frontend React/Vue/Angular)

Porta: 3000

Container B

Aplicação: Banco de dados PostgreSQL

Porta: 5432

Observação:

Nesse exemplo, estamos simplificando a comunicação para explicar os conceitos desse artigo. Logicamente numa aplicação real, teremos mais containers e camadas de aplicações, como por exemplo o frontend num container X chamando o backend no container Y e depois chamando o banco de dados num container Z.

OBJETIVO

A aplicação Web A acessar o banco de dados no container B.

PROBLEMA

A aplicação Web A deseja acessar o banco de dados que está em outro container, mas se acessar chamando a URL localhost e na porta 5432, dará erros, de conexão recusada, pois no container A não possui nenhuma aplicação registrada na porta 5432.

SOLUÇÃO

Usar a URL: host.docker.internal nas suas configurações locais para o docker entender que é para buscar fora do próprio container que está efetuando a chamada. No exemplo acima, usariamos a URL com porta, como host.docker.internal:5432.