One place for hosting & domains

      Uma Introdução ao Serviço de DNS do Kubernetes


      Introdução

      O Domain Name System ou Sistema de Nomes de Domínio (DNS) é um sistema para associar vários tipos de informação – como endereços IP – com nomes fáceis de lembrar. Por padrão, a maioria dos clusters de Kubernetes configura automaticamente um serviço de DNS interno para fornecer um mecanismo leve para a descoberta de serviços. O serviço de descoberta integrado torna fácil para as aplicações encontrar e se comunicar umas com as outras nos clusters de Kubernetes, mesmo quando os pods e serviços estão sendo criados, excluídos, e deslocados entre os nodes.

      Os detalhes de implementação do serviço de DNS do Kubernetes mudaram nas versões recentes do Kubernetes. Neste artigo vamos dar uma olhada nas versões kube-dns e CoreDNS do serviço de DNS do Kubernetes. Vamos rever como eles operam e os registros DNS que o Kubernetes gera.

      Para obter uma compreensão mais completa do DNS antes de começar, por favor leia Uma Introdução à Terminologia, Componentes e Conceitos do DNS. Para qualquer tópico do Kubernetes com o qual você não esteja familiarizado, leia Uma Introdução ao Kubernetes.

      O que o serviço DNS do Kubernetes fornece?

      Antes da versão 1.11 do Kubernetes, o serviço de DNS do Kubernetes era baseado no kube-dns. A versão 1.11 introduziu o CoreDNS para resolver algumas preocupações de segurança e estabilidade com o kube-dns.

      Independentemente do software que manipula os registros de DNS reais, as duas implementações funcionam de maneira semelhante:

      • Um serviço chamado kube-dns e um ou mais pods são criados.

      • O serviço kube-dns escuta por eventos service e endpoint da API do Kubernetes e atualiza seus registros DNS quando necessário. Esses eventos são disparados quando você cria, atualiza ou exclui serviços do Kubernetes e seus pods associados.

      • O kubelet define a opção nameserver do /etc/resolv.conf de cada novo pod para o IP do cluster do serviço kube-dns, com opções apropriadas de search para permitir que nomes de host mais curtos sejam usados:

      resolv.conf

      
      nameserver 10.32.0.10
      search namespace.svc.cluster.local svc.cluster.local cluster.local
      options ndots:5
      
      • Aplicações executando em containers podem então resolver nomes de hosts como example-service.namespace nos endereços IP corretos do cluster.

      Exemplo de registros DNS do Kubernetes

      O registro de DNS A completo de um serviço do Kubernetes será semelhante ao seguinte exemplo:

      service.namespace.svc.cluster.local
      

      Um pod teria um registro nesse formato, refletindo o endereço IP real do pod:

      10.32.0.125.namespace.pod.cluster.local
      

      Além disso, os registros SRV são criados para as portas nomeadas do serviço Kubernetes:

      _port-name._protocol.service.namespace.svc.cluster.local
      

      O resultado de tudo isso é um mecanismo de descoberta de serviço interno baseado em DNS, onde seu aplicativo ou microsserviço pode referenciar um nome de host simples e consistente para acessar outros serviços ou pods no cluster.

      Pesquisar Domínios e Resolver Nomes de Host Mais Curtos

      Por causa dos sufixos de busca de domínio listados no arquivo resolv.conf, muitas vezes você não precisará usar o nome do host completo para entrar em contato com outro serviço. Se você estiver referenciando um serviço no mesmo namespace, poderá usar apenas o nome do serviço para contatá-lo:

      outro-service
      

      Se o serviço estiver em um namespace diferente, adicione-o à consulta:

      outro-service.outro-namespace
      

      Se você estiver referenciando um pod, precisará usar pelo menos o seguinte:

      pod-ip.outro-namespace.pod
      

      Como vimos no arquivo resolv.conf padrão, apenas os sufixos .svc são automaticamente completados, então certifique-se de que você especificou tudo até o .pod.

      Agora que sabemos os usos práticos do serviço DNS do Kubernetes, vamos analisar alguns detalhes sobre as duas diferentes implementações.

      Detalhes de implementação do DNS do Kubernetes

      Como observado na seção anterior, a versão 1.11 do Kubernetes introduziu um novo software para lidar com o serviço kube-dns. A motivação para a mudança era aumentar o desempenho e a segurança do serviço. Vamos dar uma olhada na implementação original do kube-dns primeiro.

      kube-dns

      O serviço kube-dns antes do Kubernetes 1.11 é composto de três containers executando em um pod kube-dns no namespace kube-system. Os três containers são:

      • kube-dns: um container que executa o SkyDNS, que realiza a resolução de consultas DNS

      • dnsmasq: um resolvedor e cache de DNS leve e popular que armazena em cache as respostas do SkyDNS

      • sidecar: um container sidecar que lida com relatórios de métricas e responde a verificações de integridade do serviço

      As vulnerabilidades de segurança no Dnsmasq, e os problemas com desempenho ao escalar com o SkyDNS levaram à criação de um sistema substituto, o CoreDNS.

      CoreDNS

      A partir do Kubernetes 1.11, um novo serviço de DNS do Kubernetes, o CoreDNS foi promovido à Disponibilidade Geral. Isso significa que ele está pronto para uso em produção e será o serviço DNS de cluster padrão para muitas ferramentas de instalação e provedores gerenciados do Kubernetes.

      O CoreDNS é um processo único, escrito em Go, que cobre todas as funcionalidades do sistema anterior. Um único container resolve e armazena em cache as consultas DNS, responde a verificações de integridade e fornece métricas.

      Além de abordar problemas relacionados a desempenho e segurança, o CoreDNS corrige alguns outros pequenos bugs e adiciona alguns novos recursos:

      • Alguns problemas com incompatibilidades entre o uso de stubDomains e serviços externos foram corrigidos

      • O CoreDNS pode melhorar o balanceamento de carga round-robin baseado em DNS ao randomizar a ordem na qual ele retorna determinados registros

      • Um recurso chamado autopath pode melhorar os tempos de resposta do DNS ao resolver nomes de host externos, sendo mais inteligente ao iterar através de cada um dos sufixos de domínio de busca listados em resolv.conf

      • Com o kube-dns 10.32.0.125.namespace.pod.cluster.local sempre resolveria para 10.32.0.125, mesmo que o pod não existisse realmente. O CoreDNS tem um modo “pods verificados” que somente resolverá com sucesso se o pod existir com o IP correto e no namespace correto.

      Para mais informações sobre o CoreDNS e com ele se diferencia do kube-dns, você pode ler o anúncio do Kubernetes CoreDNS GA.

      Opções de Configuração Adicionais

      Os operadores do Kubernetes geralmente desejam personalizar como seus pods e containers resolvem determinados domínios personalizados, ou precisam ajustar os servidores de nomes upstream ou os sufixos de domínio de busca configurados em resolv.conf. Você pode fazer isso com a opção dnsConfig na especificação do seu pod:

      example_pod.yaml

      
      apiVersion: v1
      kind: Pod
      metadata:
        namespace: example
        name: custom-dns
      spec:
        containers:
          - name: example
            image: nginx
        dnsPolicy: "None"
        dnsConfig:
          nameservers:
            - 203.0.113.44
          searches:
            - custom.dns.local
      

      A atualização dessa configuração irá reescrever o resolv.conf do pod para ativar as alterações. A configuração mapeia diretamente para as opções padrão do resolv.conf, assim a configuração acima criaria um arquivo com as linhas nameserver 203.0.113.44 e search custom.dns.local

      Conclusão

      Neste artigo, cobrimos as noções básicas sobre o que o serviço de DNS do Kubernetes fornece aos desenvolvedores, mostramos alguns exemplos de registros DNS para serviços e pods, discutimos como o sistema é implementado em diferentes versões do Kubernetes, e destacamos algumas opções de configuração adicionais disponíveis para personalizar como seus pods resolvem as consultas DNS.

      Para mais informações sobre o serviço e DNS do Kubernetes, por favor, consulte a documentação oficial do DNS do Kubernetes para Serviços e Pods.

      Por Brian Boucheron



      Source link

      Como Usar o Git: Um Guia de Consulta Rápida


      Introdução

      Equipes de desenvolvedores e mantenedores de software open-source geralmente gerenciam seus projetos através do Git, um sistema distribuído de controle de versão que suporta colaboração.

      Este artigo no estilo de Guia de Consulta Rápida fornece uma referência de comandos que são úteis para o trabalho e colaboração em um repositório Git. Para instalar e configurar o Git, certifique-se de ler “How To Contribute to Open Source: Getting Started with Git.”

      Como utilizar esse guia:

      • Este guia está no formato de Guia de Consulta Rápida com fragmentos de linha de comando autocontidos.

      • Pule para qualquer seção que seja relevante para a tarefa que você está tentando completar.

      • Quando você vir texto destacado nos comandos deste guia, tenha em mente que este texto deve se referir aos commits e arquivos em seu próprio repositório.

      Configuração e Inicialização

      Verifique a versão do Git com o seguinte comando, que irá também confirmar que o git está instalado.

      Você pode inicializar seu diretório de trabalho atual como um repositório Git com o init.

      Para copiar um repositório Git existente hospedado remotamente, você irá utilizar git clone com a URL do repositório ou a localização do servidor (no último caso você irá usar ssh).

      • git clone https://www.github.com/username/nome-do-repositório

      Mostrar o repositório remoto do seu diretório Git atual.

      Para uma saída mais detalhada, use a flag -v.

      Adicionar o Git upstream, que pode ser uma URL ou pode estar hospedado em um servidor (no último caso, conecte com ssh).

      • git remote add upstream https://www.github.com/username/nome-do-repositório

      Staging

      Quando você modificou um arquivo e o marcou para ir no próximo commit, ele é considerado um arquivo preparado ou staged.

      Verifique o status do seu repositório Git, incluindo arquivos adicionados que não estão como staged, e arquivos que estão como staged.

      Para colocar como staged os arquivos modificados, utilize o comando add, que você pode executar diversas vezes antes de fazer um commit. Se você fizer alterações subsequentes que queira ver incluídas no próximo commit, você deve exwcutar add novamente.

      Você pode especificar o arquivo exato com o add.

      Com o . você pode adicionar todos os arquivos no diretório atual incluindo arquivos que começam com um ..

      Você pode remover um arquivo da área de staging enquanto mantém as alterações no seu diretório de trabalho com reset.

      Fazendo Commit

      Um vez que você tenha colocado no stage a suas atualizações, você está pronto para fazer o commit delas, que irá gravar as alterações que você fez no repositório.

      Para fazer commit dos arquivos em stage, você irá executar o comando commit com sua mensagem de confirmação significativa para que você possa rastrear os commits.

      • git commit -m "Mensagem de commit"

      Você pode condensar o staging de todos os arquivos rastreados fazendo o commit deles em uma única etapa.

      • git commit -am "Mensagem de commit"

      Se você precisar modificar a sua mensagem de commit, você pode fazer isto com a flag --amend.

      • git commit --amend -m "Nova Mensagem de commit"

      Branches ou Ramificações

      Uma branch ou ramificação é um ponteiro móvel para um dos commits no repositório. Ele lhe permite isolar o trabalho e gerenciar o desenvolvimento de recursos e integrações. Você pode aprender mais sobre branches através da leitura da documentação do Git.

      Listar todas as branches atuais com o comando branch. Um aterisco (*) irá aparecer próximo à sua branch ativa atualmente.

      Criar uma nova branch. Você permanecerá na sua branch ativa até mudar para a nova.

      Alternar para qualquer branch existente e fazer checkout em seu diretório de trabalho atual.

      • git checkout outra-branch

      Você pode consolidar a criação e o checkout de uma nova branch utilizando a flag -b.

      • git checkout -b nova-branch

      Renomear a sua branch.

      • git branch -m nome-da-branch-atual novo-nome-da-branch

      Mesclar o histórico da branch especificada àquela em que você está trabalhando atualmente.

      Abortar a mesclagem, no caso de existirem conflitos.

      Você também pode selecionar um commit particular para mesclar com cherry-pick e com a string que referencia o commit específico.

      Quando você tiver mesclado uma branch e não precisar mais dela, poderá excluí-la.

      • git branch -d nome-da-branch

      Se você não tiver mesclado uma branch com o master, mas tiver certeza de que deseja excluí-la, poderá forçar a exclusão da branch.

      • git branch -D nome-da-branch

      Colaborar e Atualizar

      Para baixar alterações de outro repositório, tal como o upstream remoto, você irá usar o fetch.

      Mesclar os commits baixados.

      • git merge upstream/master

      Envie ou transmita seus commits na branch local para a branch do repositório remoto.

      Busque e mescle quaisquer commits da branch remota de rastreamento.

      Inspecionando

      Mostrar o histórico de commits para a branch ativa atualmente.

      Mostrar os commits que alteraram um arquivo particular. Isso segue o arquivo, independentemente da renomeação do mesmo.

      • git log --follow meu_script.py

      Mostrar os commits que estão em uma branch e não estão em outra. Isto irá mostrar os commits em a-branch que não estão em b-branch.

      • git log a-branch..b-branch

      Observe os logs de referência (reflog) para ver quando as dicas de branches e outras referências foram atualizadas pela última vez dentro do repositório.

      Mostrar qualquer objeto no Git através da sua string de commit ou hash em um formato mais legível.

      Mostrar Alterações

      O comando git diff mostra as alterações entre commits, branches, entre outras. Você pode ler mais detalhadamente sobre isso através da Documentação do Git.

      Comparar arquivos modificados que estão na área de staging.

      Exibe o diff do que está em a-branch mas não está em b-branch.

      • git diff a-branch..b-branch

      Mostrar o diff entre dois commits específicos.

      • git diff 61ce3e6..e221d9c

      Stashing

      Às vezes, você descobrirá que fez alterações em algum código, mas, antes de terminar, precisa começar a trabalhar em outra coisa. Você ainda não está pronto para fazer o commit das alterações que você fez até agora, mas não quer perder seu trabalho. O comando git stash lhe permitirá salvar suas modificações locais e reverter para o diretório de trabalho que está alinhado com o commit mais recente do HEAD.

      Guarde (stash) seu trabalho atual.

      Veja o que você tem guardado atualmente.

      Seus rascunhos serão nomeados stash@{0}, stash@{1}, e assim por diante.

      Mostrar informações sobre um rascunho em particular.

      Para trazer os arquivos de um rascunho atual enquanto mantém o rascunho guardado, utilize apply.

      • git stash apply stash@{0}

      Se você quer trazer os arquivos de uma rascunho e não precisa mais do rascunho, utilize pop.

      Se você não precisar mais dos arquivos salvos em um determinado rascunho ou stash, você pode descartar o rascunho com drop.

      Se você tiver muitos rascunhos salvos e não precisar mais de nenhum deles, você pode utilizar clear para removê-los.

      Ignorando Arquivos

      Se você quiser manter arquivos em seu diretório local do Git, mas não quer fazer o commit deles no projeto, você pode adicionar esses arquivos ao seu arquvo .gitignore para que não causem conflitos.

      Utilize um editor de textos como o nano para adicionar arquivos ao arquivo .gitignore.

      Para ver exemplos de arquivos .gitignore, você pode olhar o repositório de modelos .gitignore do GitHub.

      Rebasing

      Um rebase nos permite mover as branches alterando o commit no qual elas são baseadas. Como o rebasing, você pode reescrever ou reformular os commits.

      Você pode iniciar um rebase chamando o número de commits que você fez e que você quer fazer rebase (5 no caso abaixo).

      Como alternativa, você pode fazer o rebase com base em uma determinada string de commit ou hash.

      Depois de ter reescrito ou reformulado os commits, você pode concluir o rebase da sua branch em cima da versão mais recente do código upstream do projeto.

      • git rebase upstream/master

      Para aprender mais sobre rabase e atualização, você pode ler How To Rebase and Update a Pull Request, que também é aplicável a qualquer tipo de commit.

      Resetando

      Às vezes, inclusive após um rebase, você precisa redefinir sua árvore de trabalho. Você pode redefinir ou resetar para um commit específico e excluir todas as alterações com o seguinte comando.

      Para forçar a enviar seu último commit conhecido e não conflitante para o repositório de origem, você precisará usar o --force.

      Atenção: Forçar o envio ou pushing para o master não é muito aprovado a menos que haja uma razão realmente importante para fazê-lo. Use isso com moderação ao trabalhar em seus próprios repositórios e evite fazer isso quando estiver colaborando.

      • git push --force origin master

      Para remover arquivos e subdiretórios locais não rastreados do diretório Git para uma branch de trabalho limpa, você pode usar git clean.

      Se você precisar modificar seu repositório local para que ele pareça com o upstream master atual (isto é, quando há muitos conflitos), você pode executar um hard reset.

      Nota: Executar este comando fará com que seu repositório local fique exatamente igual ao upstream. Todos os commits que você fez, mas que não foram enviados para o upstream, serão destruídos.

      • git reset --hard upstream/master

      Conclusão

      Este guia aborda alguns dos comandos mais comuns do Git que você pode usar ao gerenciar repositórios e colaborar em software.

      Você pode aprender mais sobre software open-source e colaboração em nossa série de tutoriais Introduction to Open Source:

      Existem muitos outros comandos e variações que você pode achar úteis como parte do seu trabalho com o Git. Para saber mais sobre todas as opções disponíveis, você pode executar o comando abaixo receber informações úteis:

      Você também pode ler mais sobre o Git e ver a documentação dele no website oficial do Git.

      Por Lisa Tagliaferri



      Source link

      Usando uma CDN para Acelerar a Entrega de Conteúdo Estático


      Introdução

      Websites e aplicações modernas geralmente entregam uma quantidade significativa de conteúdo estático para os usuários finais. Este conteúdo inclui imagens, folhas de estilo, JavaScript, e vídeo. À medida que esses recursos estáticos aumentam em número e tamanho, o uso da largura de banda aumenta e o tempo de carregamento da página aumenta, deteriorando a experiência de navegação dos usuários e reduzindo a capacidade disponível dos servidores.

      Para reduzir drasticamente o tempo de carregamento de página, aumentar a performance e reduzir seus custos com largura de banda e infraestrutura, você pode implementar uma CDN, ou rede de entrega de conteúdo para armazenar em cache esses recursos em um conjunto de servidores distribuídos geograficamente.

      Neste tutorial, vamos fornecer uma visão geral de alto nível de CDNs e como elas funcionam, bem como os benefícios que elas podem trazer para suas aplicações web.

      O que é uma CDN?

      Content delivery network ou rede de entrega de conteúdo é um grupo de servidores geograficamente distribuídos otimizados para entregar conteúdo estático aos usuários finais. Esse conteúdo estático pode ser praticamente qualquer tipo de dados, mas as CDNs são mais comumente usadas para entregar páginas web e seus arquivos relacionados, streaming de vídeo e áudio e grandes pacotes de software.

      Uma CDN consiste em múltiplos pontos de presença (PoPs) em várias localidades, cada qual consistindo de vários servidores de borda que armazenam em cache recursos de sua origem, ou servidor de hospedagem. Quando um usuário visita seu website e solicita recursos estáticos como iamgens ou arquivos de JavaScript, suas solicitações são encaminhadas pela CDN para o servidor de borda mais próximo, a partir do qual o conteúdo é servido. Se o servidor de borda não tem os recursos em cache ou o cache de recursos expirou, a CDN irá buscar e armazenar em cache a versão mais recente de outro servidor de borda da CDN mais próximo ou de seus servidores de origem. Se a borda da CDN tiver uma entrada de cache para seus recursos (o que ocorre na maior parte do tempo se seu site receber uma quantidade moderada de tráfego), ela retornará a cópia em cache para o usuário final.

      Isso permite que usuários geograficamente dispersos minimizem o número de saltos necessários para receber o conteúdo estático, buscando o conteúdo diretamente do cache de uma borda próxima. O resultado é latência e perda de pacotes significativamente reduzidos, tempos de carregamento de página mais rápidos e uma carga drasticamente reduzida na sua infraestrutura de origem.

      Os provedores de CDN oferecem recursos adicionais como mitigação de DDoS e limitação de taxa, análise de usuários e otimizações para casos de uso móvel ou de streaming com custo adicional.

      Como uma CDN funciona?

      Quando um usuário visita seu website, ele primeiro recebe uma resposta de um servidor de DNS contendo o endereço IP do host do seu servidor web. Seu navegador então solicita o conteúdo da página web, que geralmente consite de uma variedade de arquivos estáticos, como páginas HTML, folhas de estilo CSS, código JavaScript e imagens.

      Uma vez lançada a CDN e descarregados esses recursos estáticos em sevidores da CDN, “empurrando-os” manualmente ou fazendo com que a CDN “puxe” os recursos automaticamente (ambos os mecanismos são cobertos na próxima seção), você então instrui seu webserver a reescrever os links para conteúdo estático, de modo que esses links agora apontem para arquivos hospedados pela CDN. Se você estiver usando um CMS como o WordPress, essa reescrita de link pode ser implementada usando um plugin de terceiros como o CDN Enabler.

      Muitas CDNs fornecem suporte para domínios personalizados, permitindo que você crie um registro CNAME em seu domínio apontando para um endpoint da CDN. Depois que a CDN recebe uma solicitação do usuário nesse endpoint (localizado na borda, muito mais perto do usuário do que seus servidores de back-end), ela então encaminha a solicitação para o Ponto de Presença (PoP) localizado mais próximo do usuário. Este PoP geralmente consiste de um ou mais servidores de borda da CDN colocados em um ponto de troca de Internet (IxP), essencialmente um datacenter que os Provedores de Serviço de Internet (ISPs) utilizam para interconectar suas redes. O balanceador de carga interno da CDN então encaminha a solicitação para um servidor de borda localizado neste PoP, que então serve o conteúdo para o usuário.

      Os mecanismos de cache variam entre os provedores de CDN, mas geralmente funcionam da seguinte maneira:

      1. Quando a CDN recebe uma primeira solicitação para um recurso estático, como uma imagem PNG, ele não tem o recurso em cache e deve buscar uma cópia do recurso de um servidor de borda de CDN próximo ou do próprio servidor de origem. Isso é conhecido como cache “miss” e geralmente pode ser detectado inspecionando o cabeçalho de resposta HTTP, contendo X-Cache: MISS. Essa solicitação inicial será mais lenta que as solicitações futuras porque, depois de concluir essa solicitação, o recurso terá sido armazenado em cache na borda.

      2. As solicitações futuras para esse recurso (“hits” do cache), encaminhadas para esse local de borda, agora serão atendidas a partir do cache, até a expiração (normalmente definida através de cabeçalhos HTTP). Essas respostas serão significativamente mais rápidas do que a solicitação inicial, reduzindo drasticamente as latências para os usuários e transferindo o tráfego web para a rede da CDN. Você pode verificar se a resposta foi atendida a partir de um cache CDN, inspecionando o cabeçalho de resposta HTTP, que agora deve conter X-Cache: HIT.

      Para saber mais sobre como uma CDN específica funciona e como foi implementada, consulte a documentação do seu provedor de CDN.

      Na próxima seção, vamos introduzir os dois tipos populares de CDNs: As CDNs push e pull

      Zonas Push versus Zonas Pull

      A maioria dos provedores de CDN oferecem duas maneiras de armazenar seus dados em cache: zonas pull e zonas push.

      Zonas Pull envolvem a entrada do endereço do seu servidor de origem, e deixar a CDN buscar e armazenar em cache automaticamente todos os recursos estáticos disponíveis em seu site. Zonas Pull são comumente usadas para fornecer recursos web de pequeno a médio porte frequentemente atualizados, como arquivos HTML, CSS e arquivos JavaScript. Depois de fornecer à CDN o endereço do servidor de origem, a próxima etapa é geralmente reconfigurar links para recursos estáticos, de forma que eles agora apontem para o URL fornecido pela CDN. A partir desse ponto, o CDN manipulará as solicitações de recursos de entrada dos usuários e fornecerá conteúdo de seus caches geograficamente distribuídos e sua origem, conforme apropriado.

      Para utilizar uma Zona Push, você faz o upload de seus dados para um bucket ou local de armazenamento designado, que a CDN então envia para caches em sua frota distribuída de servidores de borda. As zonas Push são normalmente usadas para arquivos maiores, atualizados com pouca frequência, como arquivamentos, pacotes de software, PDFs, vídeo e arquivos de áudio.

      Benefícios do Uso de uma CDN

      Quase qualquer site pode colher os benefícios fornecidos pela implementação de uma CDN, mas geralmente as principais razões para implementá-la são descarregar a largura de banda de seus servidores de origem nos servidores CDN e reduzir a latência para usuários distribuídos geograficamente.

      Vamos passar por estas e várias outras grandes vantagens oferecidas pelo uso de uma CDN logo abaixo.

      Descarregamento da Origem

      Se você estiver se aproximando da capacidade de largura de banda em seus servidores, o descarregamento de recursos estáticos como imagens, vídeos, arquivos CSS e JavaScript reduzirá drasticamente o uso da largura de banda dos servidores. Redes de entrega de conteúdo são projetadas e otimizadas para servir conteúdo estático, e as solicitações de clientes para esse conteúdo serão encaminhadas e servidas por servidores CDN de borda. Isso traz o benefício adicional de reduzir a carga em seus servidores de origem, pois eles servem esses dados com uma frequência muito menor.

      Latência Mais Baixa para uma Melhor Experiência do Usuário

      Se sua base de usuários estiver geograficamente dispersa e uma parte não trivial de seu tráfego vier de uma área geográfica distante, uma CDN poderá diminuir a latência ao colocar em cache os recursos estáticos em servidores de borda mais próximos dos seus usuários. Ao reduzir a distância entre os usuários e o conteúdo estático, você pode fornecer conteúdo para seus usuários com mais rapidez e melhorar a experiência aumentando as velocidades de carregamento de páginas.

      Esses benefícios são compostos para websites que atendem principalmente a conteúdo de vídeo com uso intensivo de largura de banda, em que altas latências e lentidão no tempo de carregamento afetam diretamente a experiência do usuário e o engajamento de conteúdo.

      Gerenciar Picos de Tráfego e Evitar Tempo de Inatividade

      As CDNs permitem lidar com grandes picos e rajadas de tráfego através do balanceamento da carga de solicitações em uma grande rede distribuída de servidores de borda. Ao descarregar e armazenar em cache o conteúdo estático em uma rede de entrega, você pode acomodar um número maior de usuários simultâneos com sua infraestrutura atual.

      Para sites que usam um único servidor de origem, esses grandes picos de tráfego podem sobrecarregar o sistema, causando interrupções e tempo de inatividade não planejados. A transferência do tráfego para uma infraestrutura de CDN altamente disponível e redundante, projetada para lidar com níveis variáveis de tráfego web, pode aumentar a disponibilidade de seus recursos e do seu conteúdo.

      Reduzir Custos

      Como a veiculação de conteúdo estático geralmente ocupa a maior parte do uso da largura de banda, o descarregamento desses recursos em uma rede de distribuição de conteúdo pode reduzir drasticamente os gastos mensais com infraestrutura. Além de reduzir os custos de largura de banda, uma CDN pode reduzir os custos de servidor através da redução da carga nos servidores de origem, permitindo escalar a infraestrutura existente. Por fim, alguns provedores de CDN oferecem faturamento mensal com preço fixo, permitindo que você transforme seu uso de largura de banda mensal variável em um gasto recorrente estável e previsível.

      Aumentar a Segurança

      Outro caso de uso comum para CDNs é a mitigação de ataques de DDoS. Muitos provedores de CDN incluem recursos para monitorar e filtrar solicitações para servidores de borda. Esses serviços analisam o tráfego web em busca de padrões suspeitos, bloqueando o tráfego de ataque mal-intencionado e, ao mesmo tempo, permitindo o tráfego de usuários confiáveis. Os provedores de CDN geralmente oferecem uma variedade de serviços de mitigação de DDoS, desde proteção contra ataques comuns no nível de infra-estrutura (camadas OSI 3 e 4), até serviços de mitigação mais avançados e limitação de taxa.

      Além disso, a maioria das CDNs permite configurar o SSL completo, para que você possa criptografar o tráfego entre a CDN e o usuário final, bem como o tráfego entre a CDN e seus servidores de origem, usando certificados SSL personalizados ou fornecidos pela própria CDN.

      Escolhendo a Melhor Solução

      Se o seu gargalo for a carga da CPU no servidor de origem e não a largura de banda, uma CDN pode não ser a solução mais apropriada. Nesse caso, o cache local usando caches populares, como NGINX ou Varnish, pode reduzir significativamente a carga servindo os recursos a partir da memória do sistema.

      Antes de lançar uma CDN, etapas adicionais de otimização — como minimizar e compactar arquivos JavaScript e CSS e ativar a compactação de solicitação HTTP do servidor Web — podem também ter um impacto significativo em tempos de carregamento de páginas e uso de largura de banda.

      Uma ferramenta útil para avaliar a velocidade de carregamento de página e melhorá-la é o PageSpeed Insights do Google. Outra ferramenta útil que fornece um detalhamento em cascata de solicitações e tempos de resposta, bem como otimizações sugeridas é o Pingdom.

      Conclusão

      Uma rede de entrega de conteúdo pode ser uma solução rápida e eficaz para melhorar a escalabilidade e disponibilidade de seus websites. Ao armazenar em cache os recursos estáticos em uma rede geograficamente distribuída de servidores otimizados, você pode reduzir muito os tempos de carregamento de página e as latências para os usuários finais. Além disso, as CDNs permitem que você reduza significativamente o uso de largura de banda, absorvendo as solicitações dos usuários e respondendo a partir do cache na borda, reduzindo assim seus custos de largura de banda e infra-estrutura.

      Com plugins e suporte de terceiros para os principais frameworks como WordPress, Drupal, Django e Ruby on Rails, além de recursos adicionais como mitigação de DDoS, SSL completo, monitoramento de usuários e compactação de recursos, as CDNs podem ser uma ferramenta de impacto para proteger e otimizar websites de alto tráfego.

      Por Hanif Jetha



      Source link