fonte da Imagem: Infográfico vetor criado por pikisuperstar — www.freepik.com

Redes de Entrega de Conteúdo (CDN) são geralmente usadas por sites e aplicativos para acelerar o carregamento de elementos estáticos. Isso é feito armazenando arquivos em cache em servidores CDN localizados em várias regiões do mundo. Tendo solicitado dados via CDN, o usuário o recebe do servidor mais próximo.

os princípios subjacentes por trás das CDNs e sua funcionalidade são aproximadamente os mesmos para todos eles. Tendo recebido uma solicitação de um arquivo, um servidor CDN o retira uma vez do servidor de origem e o transfere para o Usuário e armazena em cache uma cópia dele por um período de tempo. Outras solicitações para os dados são tratadas usando o cache. Todos os CDNs têm opções para pré-carregamento de arquivos, limpeza de cache, tempos de retenção de cache e muito mais.

às vezes, por várias razões, pode-se encontrar-se na necessidade de construir o próprio CDN, e assim, apresentamos o seguinte guia sobre como realizá-lo.

quando você precisa de seu próprio CDN?Vamos dar uma olhada em situações em que você pode precisar criar seu próprio CDN:

• quando você está tentando economizar dinheiro e até mesmo soluções acessíveis como BunnyCDN acabar por custar-lhe centenas de dólares por mês
• quando você deseja obter permanente de cache ou necessidade de largura de banda garantida e recursos
• existente CDNs não tem PoPs em sua região de destino
• você requerem especial de entrega de conteúdo de definições
• você quer acelerar a entrega de conteúdo dinâmico, servindo-la mais próxima dos usuários
• você está preocupado terceiros CDNs pode ilegalmente coletar e usar dados do usuário (ei lá, servidores que não são Compatível com GDPR) ou se envolver em outras atividades ilícitas

na maioria dos outros casos, é mais viável usar soluções prontas existentes.

Vamos criar o próprio CDN

Para construir até mesmo uma simples rede de entrega de conteúdo você precisa dos seguintes:

• nome de domínio ou um subdomínio
• um mínimo de dois servidores em diferentes regiões. Os servidores podem ser dedicados ou virtuais
• ferramenta geoDNS. Com ele, um usuário que envia uma solicitação para o domínio será direcionado para o servidor mais próximo

registrar servidores de domínio e pedidos

registrar um nome de domínio é fácil — basta registrá-lo em qualquer zona de domínio que você preferir. Para CDN, você também pode usar um subdomínio, como cdn.domainname.com. este é o caso do seguinte exemplo.

quando se trata de Servidores, você deve alugar aqueles em regiões e países onde seu público-alvo está localizado. Se o seu projeto é intercontinental, é conveniente seleccionar, de entre os provedores de hospedagem que oferecem servidores de todo o mundo, tais como OVH, Leaseweb e 100Tb (para servidores dedicados), ou Vultr e DigitalOcean (virtuais e cloud servers).

para o nosso CDN privado, vamos encomendar três servidores virtuais em diferentes continentes. A Vultr oferece espaço SSD de 25 GB e 1 TB de tráfego por US $5/mês. Durante a instalação, selecione o Debian mais recente. Aqui estão os nossos servidores:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121.123

• Singapura, ip: 157.230.240.216

Configurando geoDNS

Para garantir que os clientes são direcionados para o adequado (mais próximo) servidores mediante o envio de pedidos para o nosso domínio ou subdomínio, vamos precisar de um servidor de DNS com geoDNS funcionalidade.

veja como funciona o geoDNS:

1. obtém o IP do cliente (Se enviou o pedido DNS) ou o IP do servidor DNS recursivo que é usado processando o pedido. De um modo geral, esses servidores recursivos são geralmente o DNSs dos provedores de Internet.
2. pelo IP do cliente, ele identifica seu país ou região. Esta operação requer o uso de banco de dados do GeoIP, que estão disponíveis em nenhuma falta. Há até decente opções gratuitas.
3. Dependendo do cliente local, geoDNS lhe devolve o endereço IP do próximo CDN servidor.

UM servidor de DNS com geoDNS funcionalidade é algo que você pode construir a si mesmo, mas é melhor usar soluções prontas que tem servidores espalhados pelo mundo e um fora-da-caixa Anycast opção:

• ClouDNS, a partir de us $9.95 / mês, Pacote GeoDNS, um Failover DNS é fornecido por padrão
• Zilore, de US $25/mês, inclui Failover DNS
• Amazon Route 53, de US $35/mês para 50 milhões de solicitações geográficas. O DNS Failover é avaliado separadamente
• DNS Fácil, de r $125/mês, com 10 Activações pós-falha de DNS
• Cloudflare, Geo funcionalidade é fornecida na Empresa pacotes

Quando o pedido geoDNS você precisa prestar atenção para o número de solicitações incluído no pacote e tenha em mente que o real pedidos de número pode exceder em muito suas expectativas. Existem milhões de rastreadores da web, scanners, spammers e outros devilry no trabalho a qualquer momento.

quase todos os Serviços DNS incluem um recurso útil para CDN building – DNS Failover. Com ele, você pode configurar o monitoramento de atividades para que, se um servidor descer, o sistema redirecione automaticamente os clientes para servidores em funcionamento.

para o nosso CDN, vamos usar ClouDNS e seu pacote GeoDNS.

no perfil, adicione uma nova zona DNS e especifique seu nome de domínio. Se você estiver usando subdomínio e o domínio principal estiver em uso, não se esqueça de adicionar os registros DNS existentes imediatamente após adicionar a zona. O próximo passo é criar vários registros A para o domínio/subdomínio CDN, cada um dos quais será usado para a região especificada. Você pode designar continentes ou países como regiões, e opções de sub-região estão disponíveis para os EUA e Canadá.

em nosso exemplo, o CDN operará no cdn.sayt.in subdomínio. Tendo adicionado o sayt.in zona, criar o primeiro um registro para o subdomínio e direcionar todos os clientes NA para o servidor de Chicago:

repita esta etapa para as outras regiões e não se esqueça de criar um registro para regiões padrão. Aqui está como é o resultado final:

o último registro padrão significa solicitações de todas as regiões não especificadas (Europa, África, usuários de internet via satélite, etc.) devem ser direcionados para o servidor de Frankfurt.

isso conclui a configuração básica do DNS. Tudo o que resta é ir ao site do registrador e substituir os servidores de nomes atuais pelos fornecidos pelo ClouDNS. Enquanto eles estão sendo atualizados, vamos definir os servidores.

instalando certificados SSL

nosso CDN funcionará usando HTTPS, portanto, se você já tiver certificados SSL para o domínio ou o subdomínio, envie-os para todos os servidores, por exemplo, para o diretório /etc/ssl/yourdomain/.

se você não tiver nenhum certificado, poderá obtê-lo gratuitamente no Let’s Encrypt. O script Acme Shell é uma ótima opção. Ele tem um cliente amigável e, mais importante, permite realizar a validação do domínio/subdomínio via DNS usando API por ClouDNS.

vamos instalar acme.sh em apenas um servidor — o Europeu (199.247.18.199), e a partir dele, os certificados serão copiados para todos os outros. Para instalá-lo, execute o seguinte comando:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

durante a instalação, será criada uma tarefa CRON para atualização automática dos certificados.

a verificação do domínio após a emissão do certificado será realizada via DNS usando API, portanto, no perfil do ClouDNS, em Reseller API, crie um novo usuário da API e especifique uma senha para ele. Digite o resultante auth-identificação juntamente com a senha para o seguinte arquivo: ~/.acme.sh/dnsapi/dns_cloudns.sh (para não ser confundido com dns_clouddns.sh). Aqui estão as linhas que você precisa para descomente e edite:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

Agora, vamos solicitar a emissão do certificado SSL para o cdn.sayt.em

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

para uso futuro, em parâmetros, deixamos um comando para Reinicialização automática de configuração após cada renovação do certificado.

o processo de aquisição do certificado pode levar até dois minutos, portanto, não o interrompa. Caso ocorra um erro de validação de domínio, tente executar o comando novamente. No final, veremos onde os certificados foram baixados.

lembre-se desses caminhos, precisaremos especificá-los ao copiar os certificados para outros servidores e precisaremos especificá-los nas configurações do servidor. Ignore o erro nginx Config reloading, — ele não ocorrerá em um servidor totalmente configurado durante a renovação do certificado.

quanto ao certificado SSL, tudo o que resta a fazer é copiá-lo para os outros dois servidores salvando os caminhos do certificado. Crie diretórios idênticos em cada servidor e copie arquivos de certificado:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

para automatizar a renovação do certificado, você precisa criar uma tarefa CRON diária em ambos os servidores. Abaixo está o comando que você deve adicionar ao CRON jobs:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload</pre>

lembre-se de que a conexão com o servidor de origem remota requer um acesso por chave sem inserir uma senha. Não se esqueça de criá-lo.

Instalando e configurando o Nginx

para entrega de conteúdo estático, usaremos o Nginx, configurado como um servidor proxy de cache. Atualizar a lista de pacotes e instale-o em todos os três servidores:

root@cdn:~# apt updateroot@cdn:~# apt install nginx

em Vez do padrão de configuração, use o abaixo:

nginx.conf

user www-data;worker_processes auto;pid /run/nginx.pid;events { worker_connections 4096; multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_proxied any; gzip_vary on; gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml; gunzip on; proxy_temp_path /var/cache/tmp; proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d; proxy_cache_bypass $http_x_update;server { listen 443 ssl; server_name cdn.sayt.in; ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer; ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key; location / { proxy_cache cdn; proxy_cache_key $uri$is_args$args; proxy_cache_valid 90d; proxy_pass https://sayt.in; } }}

na configuração, vamos editar:

• max_size tamanho do cache de que não ultrapasse o espaço em disco disponível
• inativos — tempo de retenção para não solicitadas em cache de dados
• ssl_certificate e ssl_certificate_key — caminhos para SSL certificado e a chave
• proxy_cache_valid — tempo de retenção de dados em cache
• proxy_pass — endereço do servidor de origem a partir do qual o CDN vai solicitação de dados para armazenamento em cache. Para o nosso exemplo, é sayt.in

como você pode ver, não é ciência de foguetes. A única dificuldade é configurar o tempo de retenção, dadas as semelhanças entre os parâmetros inativos e proxy_cache_valid. Vamos dar uma olhada mais de perto. Aqui está o que acontece com inativos=7d e proxy_cache_valid=90d:

• se o pedido não for repetido dentro de 7 dias, os dados são excluídos do cache
• se o pedido é repetido até uma vez durante 7 dias, o cache será considerado fora-de-data após 90 dias, e o próximo pedido vai fazer Nginx atualizá-lo a partir do servidor de origem

Com nginx.conf manipulado, recarregar a configuração:

root@cdn:~# service nginx reload

então, nosso CDN está pronto para uso! Por US $15 / mês, temos PoPs em três continentes e 3 TB de tráfego: 1 TB para cada região.

verificando nosso CDN

vamos dar uma olhada no ping em nosso CDN de diferentes locais. Qualquer serviço de ping fará neste caso.

Os resultados são bons. Agora vamos colocar uma imagem de teste intitulada teste.jpg no servidor principal e verifique a rapidez com que ele carrega via CDN. Dito e feito. O carregamento é rápido.

vamos fazer um pequeno script no caso de precisarmos limpar o cache em um ponto CDN.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

Para apagar toda a cache no servidor, basta executar o script. Se você precisar de algum arquivo purgado, basta especificar seu caminho:

root@cdn:~# ./purge.sh /test.jpg 

Para limpar o cache em todos os lugares, o script deve ser executado em todos os servidores CDN.

Em vez de conclusões

Finalmente, eu gostaria de dar algumas dicas úteis para que você pode evitar cair nas armadilhas que eu já limpo:

• Considerar a viabilidade e os custos de manutenção de seu futuro CDN. Na maioria dos casos, é muito eficiente e mais fácil comprar um CDN barato, que provavelmente será mais estável e de melhor qualidade.
• para melhorar a tolerância a falhas do CDN, é recomendável configurar um Failover DNS, o que permitiria alternar rapidamente o registro A no caso de um servidor quebrar. Você pode fazer isso no painel de controle de registros do DNS.
• sites com ampla cobertura exigem um grande número de PoPs, mas não ficam excessivamente zelosos. Muito provavelmente, um usuário não notará a diferença entre seu CDN e um Pago, Se você tiver servidores em 6-7 locais (Europa, América do Norte (Leste), América do Norte (Oeste), Cingapura, Austrália, Hong Kong ou Japão).
• às vezes, os provedores de hospedagem não permitem o uso de servidores alugados para CDNs. Portanto, se você deseja criar um serviço CDN, leia os Termos e Condições do provedor de hospedagem.
• estude o mapa de cabos submarinos para entender como os continentes estão conectados e use esse conhecimento ao construir seu CDN.
• tente fazer ping em seus servidores de diferentes locais. Dessa forma, você pode identificar as regiões mais próximas de seus PoPs e isso o ajudará a configurar GeoDNS.