One place for hosting & domains

      Como Configurar MTA-STS e TLS Reporting para o seu Domínio Usando o Apache no Ubuntu 18.04


      O autor escolheu a Electronic Frontier Foundation Inc para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Mail Transport Agent Strict Transport Security (MTA-STS) é um novo padrão da Internet que lhe permite ativar o force-TLS estrito para emails enviados entre provedores de e-mail suportados. Ele é similar ao HTTP Strict Transport Security (HSTS), onde uma política force-TLS é definida e armazenada em cache por um período especificado, reduzindo o risco de ataques do tipo man-in-the-middle ou de downgrade.

      O MTA-STS é complementado pelo SMTP TLS Reporting (TLSRPT), que fornece informações sobre quais e-mails são entregues com sucesso por TLS e quais não. O TLSRPT é semelhante ao DMARC reporting, mas para TLS.

      O principal motivo para implementar o MTA-STS para o seu domínio é garantir que o e-mail confidencial enviado a você seja transmitido com segurança pelo TLS. Outros métodos para incentivar o TLS para comunicações por e-mail, como o STARTTLS, ainda são suscetíveis a ataques do tipo man-in-the-middle, pois a conexão inicial não é criptografada. O MTA-STS ajuda a garantir que, uma vez estabelecida pelo menos uma conexão segura, o TLS será usado por padrão a partir de então, o que reduz bastante o risco desses ataques.

      Um exemplo de caso de uso para o MTA-STS e o TLS Reporting é ajudar a criar um sistema seguro de atendimento ao cliente para o seu negócio. Os clientes podem enviar tíquetes de suporte por e-mail que contêm informações pessoais confidenciais, que precisam de uma conexão TLS segura. O MTA-STS ajuda a garantir a segurança da conexão, e o TLSRPT fornece relatórios diários identificando todos os e-mails que não foram enviados com segurança — fornecendo informações cruciais sobre quaisquer ataques em andamento ou anteriores ao seu sistema de e-mail.

      Neste tutorial, você aprenderá como configurar o MTA-STS e o TLSRPT para o seu nome de domínio e depois interpretar o seu primeiro relatório TLS. Embora este tutorial cubra as etapas para o uso do Apache no Ubuntu 18.04 com um certificado Let’s Encrypt, a configuração do MTA-STS/TLSRPT também funcionará em alternativas, como o Nginx no Debian.

      Pré-requisitos

      Antes de começar este guia, você precisará de:

      Depois de estar com tudo isso pronto, efetue login no servidor como usuário não-root para começar.

      Nota: Depois de concluir as etapas de implementação do MTA-STS e do TLSRPT, talvez você precise esperar até 24 horas para receber seu primeiro relatório TLS. Isso ocorre porque a maioria dos provedores de e-mail envia relatórios uma vez por dia. Você pode retomar o tutorial a partir do Passo 5 depois de receber seu primeiro relatório.

      Passo 1 — Criando um Arquivo de Política MTA-STS

      O MTA-STS é ativado e configurado usando um arquivo de configuração de texto sem formatação que você hospeda no seu site. Os servidores de e-mail suportados se conectarão automaticamente ao seu site para buscar o arquivo, o que faz com que o MTA-STS seja ativado. Nesta primeira etapa, você entenderá as opções disponíveis para esse arquivo e escolherá as mais adequadas para ele.

      Primeiro, abra um novo arquivo de texto em seu diretório home para que você tenha um lugar para anotar a sua configuração desejada:

      Vamos examinar primeiramente um exemplo e, em seguida, você escreverá seu próprio arquivo de configuração.

      A seguir, é apresentado um exemplo de um arquivo de configuração do MTA-STS:

      Arquivo de Exemplo de Configuração MTA-STS

      version: STSv1
      mode: enforce
      mx: mail1.seu-domínio
      mx: mail2.seu-domínio
      max_age: 604800
      

      Este arquivo de configuração de exemplo especifica que todos os emails entregues a mail1.seu-domínio e mail2.seu-domínio de provedores suportados devem ser entregues por uma conexão TLS válida. Se uma conexão TLS válida não puder ser estabelecida com o seu servidor de correio (por exemplo, se o certificado expirou ou é autoassinado), o email não será entregue.

      Isso tornará muito mais desafiador para um invasor interceptar e bisbilhotar/modificar seu e-mail em uma situação como um ataque man-in-the-middle. Isso ocorre porque o MTA-STS ativado corretamente permite que o e-mail seja transmitido apenas por uma conexão TLS válida, o que requer um certificado TLS válido. Seria difícil para um invasor adquirir esse certificado, pois isso geralmente requer acesso privilegiado ao seu nome de domínio e/ou site.

      Conforme mostrado no exemplo anterior neste passo, o arquivo de configuração consiste em vários pares de chave/valor:

      • version:

        • Propósito: Para especificar a versão da especificação MTA-STS a ser usada.
        • Valores Aceitos: Atualmente, o único valor aceito é STSv1.
        • Exemplo: version: STSv1
      • mode:

        • Propósito: Especificar em qual modo o MTA-STS deve ser ativado.
        • Valores Aceitos:
          • enforce: Forçar todos os emails de fornecedores suportados a usar TLS válido.
          • testing: Modo somente de relatório. O e-mail não será bloqueado, mas os relatórios TLSRPT ainda serão enviados.
          • none: Desativar MTA-STS.
        • Exemplo: mode: enforce
      • mx:

        • Propósito: Para especificar quais servidores de e-mail têm permissão para manipular e-mails do seu domínio. Isso deve corresponder aos servidores especificados em seus registros mx.
        • Valores Aceitos: Nome de domínio totalmente qualificado de um servidor de e-mail ou um host curinga. Vários valores mx: devem ser usados para especificar vários servidores de correio.
        • Exemplo: mx: mail1.seu-domínio, mx: mail2.seu-domínio, mx: *.example.org
      • max_age:

        • Propósito: Para especificar a duração máxima da política MTA-STS, em segundos.
        • Valores Aceitos: Qualquer número inteiro positivo até 31557600.
        • Exemplo: max_age: 604800 (1 semana)

      Você também pode visualizar a especificação oficial para os pares de chave/valor na Seção 3.2 do RFC do MTA-STS.

      Atenção: A ativação do MTA-STS no modo enforce pode inesperadamente causar alguns e-mails a não serem entregues a você. Em vez disso, é recomendável usar o mode: testing e um valor baixo de max_age: no início, para garantir que tudo esteja funcionando corretamente antes de ativar o MTA-STS completamente.

      Usando o arquivo de exemplo anterior, bem como os exemplos anteriores de pares de chave/valor, escreva o arquivo de política MTA-STS desejado e salve-o no arquivo que você criou no início da etapa.

      O arquivo de exemplo a seguir é ideal para testar o MTA-STS, pois não fará com que nenhum e-mail seja bloqueado inesperadamente, e tem um max_age de apenas 1 dia, o que significa que se você decidir desativá-lo, a configuração expirará rapidamente. Observe que alguns provedores de e-mail somente enviarão relatórios TLSRPT se o max_age for maior que 1 dia, razão pela qual 86401 segundos é uma boa opção (1 dia e 1 segundo).

      Example Test MTA-STS Configuration File

      version: STSv1
      mode: testing
      mx: mail1.seu-domínio
      mx: mail2.seu-domínio
      max_age: 86401
      

      Neste passo, você criou o arquivo de configuração MTA-STS desejado e o salvou no seu diretório home. No próximo passo, você configurará um servidor web Apache para servir o arquivo no formato correto.

      Passo 2 — Configurando o Apache para Servir seu Arquivo de Políticas do MTA-STS

      Neste passo, você irá configurar um virtual host no Apache para servir o seu arquivo de configuração do MTA-STS e adicionará um registro DNS para permitir que o site seja acessado a partir de um subdomínio.

      Para que seu arquivo de configuração MTA-STS seja descoberto automaticamente pelos servidores de correio, ele deve ser exibido exatamente no caminho certo: https://mta-sts.seu-domínio/.well-known/mta-sts.txt. Você deve usar o subdomínio mta-sts sobre HTTPS e o caminho /.well-known/mta-sts.txt, caso contrário sua configuração não funcionará.

      Isso pode ser conseguido com a criação de um novo virtual host no Apache para o subdomínio mta-sts, que servirá o arquivo de políticas do MTA-STS. Este passo baseia-se na configuração básica que você definiu no passo de pré-requisito Como Instalar o Servidor Web Apache no Ubuntu 18.04.

      Primeiro, crie um diretório para o seu virtual host:

      • sudo mkdir /var/www/mta-sts

      Se você estiver hospedando vários domínios diferentes no seu servidor web, é recomendável usar um virtual host MTA-STS diferente para cada um, por exemplo, /var/www/mta-sts-site1 and /var/www/mta-sts-site2

      Em seguida, você precisa criar o diretório .well-known, que é onde seu arquivo de configuração do MTA-STS será armazenado. .well-known é um diretório padronizado para arquivos ‘well-known’, como arquivos de validação de certificado TLS, security.txt, entre outros.

      • sudo mkdir /var/www/mta-sts/.well-known

      Agora você pode mover o arquivo de políticas MTA-STS que você criou no Passo 1 para o diretório do servidor web que você acabou de criar:

      • sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

      Você pode verificar se o arquivo foi copiado corretamente, se desejar:

      • cat /var/www/mta-sts/.well-known/mta-sts.txt

      Isso exibirá o conteúdo do arquivo que você criou no Passo 1.

      Para que o Apache sirva o arquivo, você precisará configurar o novo virtual host e ativá-lo. O MTA-STS funciona apenas em HTTPS, portanto você usará a porta 443 (HTTPS) exclusivamente, em vez de usar também a porta 80 (HTTP).

      Primeiro, crie um novo arquivo de configuração para o virtual host:

      • sudo nano /etc/apache2/sites-available/mta-sts.conf

      Como no diretório do virtual host, se você estiver hospedando vários domínios diferentes no mesmo servidor web, é recomendável usar um nome de virtual host diferente para cada um.

      Em seguida, copie a seguinte configuração de exemplo no arquivo e preencha as variáveis onde necessário:

      ~/etc/apache2/sites-available/mta-sts.conf

      <IfModule mod_ssl.c>
      <VirtualHost endereço-ipv4-do-seu-servidor:443 [endereço-ipv6-do-seu-servidor]:443>
          ServerName mta-sts.seu-domínio
          DocumentRoot /var/www/mta-sts
      
          ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href="https://seu-domínio" rel="noopener">https://seu-domínio</a> instead."
      
          RewriteEngine On
          RewriteOptions IgnoreInherit
          RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]
      
          SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
          SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
          Include /etc/letsencrypt/options-ssl-apache.conf
      </VirtualHost>
      </IfModule>
      

      Esta configuração criará o virtual host mta-sts, que será servido em mta-sts.seu-domínio. Ele também redirecionará todas as solicitações, exceto aquelas para o próprio arquivo mta-sts.txt, para uma página de erro 403 Forbidden personalizada, com uma explicação amigável, falando para que serve o site do subdomínio. Isso é para ajudar a garantir que os visitantes que encontrarem acidentalmente seu site MTA-STS não fiquem confusos.

      Atualmente, um certificado TLS autoassinado é utilizado. Isso não é o ideal, pois é necessário um certificado totalmente válido/confiável para o MTA-STS funcionar corretamente. No Passo 3, você adquirirá um certificado TLS usando o Let’s Encrypt.

      Em seguida, verifique se os módulos necessários do Apache estão ativados:

      Depois disso, ative o novo virtual host:

      Em seguida, execute uma verificação de sintaxe dos arquivos de configuração do Apache, para garantir que não haja erros inesperados:

      • sudo apachectl configtest

      Quando o teste passar sem erros, você pode reiniciar o Apache para ativar completamente o novo virtual host:

      • sudo service apache2 restart

      Agora que o virtual host do Apache foi instalado e configurado, é necessário criar o(s) registro(s) de DNS necessário(s) para permitir que ele seja acessado usando o nome de domínio totalmente qualificado mta-sts.seu-domínio.

      A maneira como isso é feito depende do provedor de hospedagem DNS que você usa. No entanto, se você usa a DigitalOcean como seu provedor de DNS, simplesmente navegue até o seu projeto e depois clique em seu domínio.

      Por fim, adicione os registros DNS necessários para o subdomínio mta-sts. Se o seu Droplet usa apenas IPv4, crie um registro A para mta-sts, apontando para endereço-ipv4-do-seu-servidor. Se você usa o IPv6 também, crie um registro AAAA apontando para endereço-ipv6-do-seu-servidor.

      A screenshot of the DigitalOcean DNS control panel, showing an example DNS record for mta-sts pointing to an IPv4 address.

      Neste passo, você criou e configurou um novo virtual host no Apache para o subdomínio MTA-STS e adicionou os registros DNS necessários para permitir que ele seja acessado facilmente. No próximo passo, você adquirirá um certificado Let’s Encrypt confiável para o seu subdomínio MTA-STS.

      Passo 3 — Adquirindo um Certificado Let’s Encrypt para seu Subdomínio MTA-STS

      Neste passo, você adquirirá um certificado TLS da Let’s Encrypt, para permitir que seu site mta-sts.seu-domínio seja publicado corretamente por HTTPS.

      Para fazer isso, você usará o certbot, que você configurou como parte da etapa de pré-requisito Como proteger o Apache com o Let’s Encrypt no Ubuntu 18.04.

      Primeiramente, execute o certbot para emitir um certificado para o subdomínio mta-sts usando o método de verificação de plugin do Apache:

      • sudo certbot --apache -d mta-sts.seu-domínio

      Isso emitirá automaticamente um certificado confiável e o instalará no servidor web Apache. Quando o assistente do Certbot perguntar sobre a configuração de um redirecionamento HTTP -> HTTPS, selecione 'No’, pois isso não é necessário para o MTA-STS.

      Para finalizar, teste seu novo virtual host para garantir que ele esteja funcionando corretamente. Use um navegador para visitar https://mta-sts.seu-domínio/.well-known/mta-sts.txt ou use uma ferramenta de linha de comando como o curl:

      • curl https://mta-sts.seu-domínio/.well-known/mta-sts.txt

      Isso mostrará o arquivo de política MTA-STS que você criou na Etapa 1:

      Output

      version: STSv1 mode: testing mx: mail1.seu-domínio mx: mail2.seu-domínio max_age: 86401

      Se ocorrer um erro, verifique se a configuração do virtual host do Passo 2 está correta e se você adicionou um registro DNS para o subdomínio mta-sts.

      Neste passo, você emitiu um certificado Let’s Encrypt TLS para o subdomínio mta-sts e testou se ele está funcionando. Em seguida, você definirá alguns registros TXT no DNS para ativar completamente o MTA-STS e o TLSRPT.

      Passo 4 — Configurando os Registros DNS Necessários para Ativar o MTA-STS e o TLSRPT

      Neste passo, você configurará dois registros TXT no DNS, que habilitarão totalmente a diretiva MTA-STS que você já criou e também habilitarão o TLS Reporting (TLSRPT).

      Esses registros DNS podem ser configurados usando qualquer provedor de hospedagem DNS, mas neste exemplo, a DigitalOcean é utilizada como provedor.

      Primeiro, faça logon no painel de controle da DigitalOcean e navegue até o seu projeto; depois dê um clique em seu domínio.

      Você precisa então, adicionar os dois registros TXT a seguir:

      _mta-sts.seu-domínio IN TXT "v=STSv1; id=id-value"
      _smtp._tls.seu-domínio IN TXT "v=TLSRPTv1; rua=reporting-address"
      

      id-value é uma string usada para identificar a versão da sua política MTA-STS em vigor. Se você atualizar sua política, precisará também atualizar o valor do id para garantir que a nova versão seja detectada pelos provedores de correio. Recomenda-se usar o carimbo de data atual como o id, por exemplo, 20190811231231 (23:12:31 em 11 de agosto de 2019).

      reporting-address é o endereço para onde seus relatórios TLS serão enviados. Pode ser um endereço de e-mail com o prefixo mailto: ou um URI web, por exemplo, para uma API que coleta relatórios. O endereço para o relatório não precisa ser um endereço no seu-domínio. Você pode usar um domínio completamente diferente, se desejar.

      Por exemplo, os dois registros de exemplo a seguir são válidos:

      _mta-sts.seu-domínio IN TXT "v=STSv1; id=20190811231231"
      _smtp._tls.seu-domínio IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@seu-domínio"
      

      Ajuste as variáveis conforme necessário e defina esses registros TXT de DNS em seu painel de controle da DigitalOcean (ou qualquer provedor de DNS que você esteja usando):

      A screenshot of the DigitalOcean control panel, showing the _mta-sts DNS TXT record being set.

      A screenshot of the DigitalOcean control panel, showing the _smtp._tls DNS TXT record being set.

      Depois que esses registros DNS forem definidos e propagados, o MTA-STS será ativado com a política que você criou no Passo 1 e começará a receber relatórios TLSRPT no endereço que você especificou.

      Neste passo, você configurou os registros DNS necessários para que o MTA-STS seja ativado. Em seguida, você receberá e interpretará seu primeiro relatório TLSRPT.

      Passo 5 — Interpretando seu Primeiro Relatório TLSRPT

      Agora que você ativou o MTA-STS e o TLSRPT (TLS Reporting) para o seu domínio, você começará a receber relatórios de provedores de e-mail suportados. Esses relatórios mostrarão o número de e-mails que foram ou não foram entregues com êxito pelo TLS e os motivos dos erros.

      Diferentes provedores de e-mail enviam seus relatórios em momentos diferentes; por exemplo, o Google Mail envia seus relatórios diariamente por volta das 10:00 UTC.

      Dependendo de como você configurou o registro DNS TLSRPT no Passo 5, você receberá seus relatórios por e-mail ou por uma API web. Este tutorial se concentra no método de e-mail, pois essa é a configuração mais comum.

      Se você acabou de concluir o restante deste tutorial, aguarde até receber seu primeiro relatório e poderá continuar.

      Seu relatório diário do TLSRPT por e-mail geralmente possui uma linha de assunto semelhante à seguinte:

      Report Domain: seu-domínio Submitter: google.com Report-ID: <2019.08.10T00.00.00Z+seu-domínio@google.com>
      

      Este e-mail terá um anexo no formato .gz, que é um arquivo compactado Gzip, com um nome de arquivo semelhante ao seguinte:

      google.com!seu-domínio!1565222400!1565308799!001.json.gz
      

      Para o restante deste tutorial, esse arquivo será chamado de report.json.gz.

      Salve esse arquivo na sua máquina local e extraia-o usando a ferramenta que você preferir.

      Se você estiver usando um sistema Linux baseado no Debian, poderá executar o comando gzip -d para descompactar o arquivo:

      Isso resultará em um arquivo JSON chamado report.json.

      Em seguida, você pode visualizar o relatório diretamente como a sequência JSON bruta ou usar seu formatador JSON favorito para colocá-lo em um formato mais legível. Neste exemplo, o jq será usado, mas você também pode usar o json.tool do Python, se desejar.

      Nota: Se você não possui o jq instalado, você pode instalá-lo utilizando apt install jq. Ou, para outros sistemas operacionais, use as instruções de instalação correspondentes do jq.

      Isso produzirá algo semelhante ao seguinte:

      Prettified report.json

      { "organization-name": "Google Inc.", "date-range": { "start-datetime": "2019-08-10T00:00:00Z", "end-datetime": "2019-08-10T23:59:59Z" }, "contact-info": "[email protected]", "report-id": "2019-08-10T00:00:00Z_seu-domínio", "policies": [ { "policy": { "policy-type": "sts", "policy-string": [ "version: STSv1", "mode: testing", "mx: mail1.seu-domínio", "mx: mail2.seu-domínio", "max_age: 86401" ], "policy-domain": "seu-domínio" }, "summary": { "total-successful-session-count": 230, "total-failure-session-count": 0 } } ] }

      O relatório mostra o provedor que gerou o relatório e o período do relatório, bem como a política MTA-STS que foi aplicada. No entanto, a seção principal em que você estará interessado é a summary, especificamente as contagens de sessões com êxito e com falha.

      Este relatório de exemplo mostra que 230 e-mails foram entregues com êxito por TLS do provedor de e-mail que gerou o relatório e 0 entregas de e-mail falharam ao estabelecer uma conexão TLS adequada.

      Caso haja uma falha — por exemplo, se um certificado TLS expirar ou houver um invasor na rede — o motivo da falha será documentado no relatório. Alguns exemplos de motivos de falha são:

      • starttls-not-supported: Se o servidor de e-mail de recebimento não suportar STARTTLS.
      • certificate-expired: Se um certificado expirou.
      • certificate-not-trusted: Se um certificado autoassinado ou outro certificado não confiável for usado.

      Neste passo final, você recebeu e interpretou seu primeiro relatório TLSRPT.

      Conclusão

      Neste artigo, você definiu e configurou o MTA-STS e o TLS Reporting para o seu domínio e interpretou o seu primeiro relatório TLSRPT.

      Depois que o MTA-STS estiver ativado e funcionando de maneira estável por um tempo, é recomendável ajustar a política, aumentando o valor de max_age e, eventualmente, alternando-a para o modo enforce quando você tiver certeza de que todos os emails de provedores suportados estão sendo entregue com sucesso por TLS.

      Por fim, se você quiser saber mais sobre as especificações MTA-STS e TLSRPT, poderá revisar as RFCs para os dois:



      Source link

      Como Testar Seu Deployment Ansible com InSpec e Kitchen


      O autor escolheu a Diversity in Tech Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O InSpec é um framework open-source de auditoria e teste automatizado usado para descrever e testar preocupações, recomendações ou requisitos regulatórios. Ele foi projetado para ser inteligível e independente de plataforma. Os desenvolvedores podem trabalhar com o InSpec localmente ou usando SSH, WinRM ou Docker para executar testes, portanto, é desnecessário instalar quaisquer pacotes na infraestrutura que está sendo testada.

      Embora com o InSpec você possa executar testes diretamente em seus servidores, existe um potencial de erro humano que poderia causar problemas em sua infraestrutura. Para evitar esse cenário, os desenvolvedores podem usar o Kitchen para criar uma máquina virtual e instalar um sistema operacional de sua escolha nas máquinas em que os testes estão sendo executados. O Kitchen é um executor de testes, ou ferramenta de automação de teste, que permite testar o código de infraestrutura em uma ou mais plataformas isoladas. Ele também suporta muitos frameworks de teste e é flexível com uma arquitetura de plug-in de driver para várias plataformas, como Vagrant, AWS, DigitalOcean, Docker, LXC containers, etc.

      Neste tutorial, você escreverá testes para seus playbooks Ansible em execução em um Droplet Ubuntu 18.04 da DigitalOcean. Você usará o Kitchen como executor de teste e o InSpec para escrever os testes. No final deste tutorial, você poderá testar o deploy do seu playbook Ansible.

      Pré-requisitos

      Antes de começar com este guia, você precisará de uma conta na DigitalOcean além do seguinte:

      Passo 1 — Configurando e Inicializando o Kitchen

      Você instalou o ChefDK como parte dos pré-requisitos que vem empacotados com o kitchen. Neste passo, você configurará o Kitchen para se comunicar com a DigitalOcean.

      Antes de inicializar o Kitchen, você criará e se moverá para um diretório de projeto. Neste tutorial, o chamaremos de ansible_testing_dir.

      Execute o seguinte comando para criar o diretório:

      • mkdir ~/ansible_testing_dir

      E então passe para ele:

      Usando o gem instale o pacote kitchen-digitalocean em sua máquina local. Isso permite que você diga ao kitchen para usar o driver da DigitalOcean ao executar testes:

      • gem install kitchen-digitalocean

      No diretório do projeto, você executará o comando kitchen init especificando ansible_playbook como o provisionador e digitalocean como o driver ao inicializar o Kitchen:

      • kitchen init --provisioner=ansible_playbook --driver=digitalocean

      Você verá a seguinte saída:

      Output

      create kitchen.yml create chefignore create test/integration/default

      Isso criou o seguinte no diretório do projeto:

      • test/integration/default é o diretório no qual você salvará seus arquivos de teste.

      • chefignore é o arquivo que você usaria para garantir que certos arquivos não sejam carregados para o Chef Infra Server, mas você não o usará neste tutorial.

      • kitchen.yml é o arquivo que descreve sua configuração de teste: o que você deseja testar e as plataformas de destino.

      Agora, você precisa exportar suas credenciais da DigitalOcean como variáveis de ambiente para ter acesso para criar Droplets a partir da sua CLI. Primeiro, inicie com seu token de acesso da DigitalOcean executando o seguinte comando:

      • export DIGITALOCEAN_ACCESS_TOKEN="SEU_TOKEN_DE_ACESSO_DIGITALOCEAN"

      Você também precisa obter seu número de ID da chave SSH; note que SEU_ID_DE_CHAVE_SSH_DIGITALOCEAN deve ser o ID numérico da sua chave SSH, não o nome simbólico. Usando a API da DigitalOcean, você pode obter o ID numérico de suas chaves com o seguinte comando:

      • curl -X GET https://api.digitalocean.com/v2/account/keys -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN"

      Após este comando, você verá uma lista de suas chaves SSH e metadados relacionados. Leia a saída para encontrar a chave correta e identificar o número de ID nela:

      Output

      ... {"id":seu-ID-numérico,"fingerprint":"fingerprint","public_key":"ssh-rsa sua-chave-ssh","name":"nome-da-sua-chave-ssh" ...

      Nota: Se você deseja tornar sua saída mais legível para obter seus IDs numéricos, você pode encontrar e baixar o jq com base no seu sistema operacional na página de download do jq. Agora, você pode executar o comando anterior fazendo um pipe para o jq da seguinte maneira:

      • curl -X GET https://api.digitalocean.com/v2/account/keys -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN" | jq

      Você verá as informações da chave SSH formatadas de forma semelhante a:

      Output

      { "ssh_keys": [ { "id": ID_DA_SUA_CHAVE_SSH, "fingerprint": "2f:d0:16:6b", "public_key": "ssh-rsa AAAAB3NzaC1yc2 [email protected]", "name": "sannikay" } ], }

      Depois de identificar seus IDs numéricos de SSH, exporte-os com o seguinte comando:

      • export DIGITALOCEAN_SSH_KEY_IDS="SEU_ID_DE_CHAVE_SSH_DIGITALOCEAN"

      Você inicializou o kitchen e configurou as variáveis de ambiente para suas credenciais da DigitalOcean. Agora você vai criar e executar testes em seus Droplets diretamente da linha de comando.

      Passo 2 — Criando o Playbook Ansible

      Neste passo, você criará um playbook e roles (funções) que configurará o Nginx e o Node.js no Droplet criado pelo kitchen no próximo passo. Seus testes serão executados no playbook para garantir que as condições especificadas no playbook sejam atendidas.

      Para começar, crie um diretório roles para as roles ou funções Nginx e Node.js:

      • mkdir -p roles/{nginx,nodejs}/tasks

      Isso criará uma estrutura de diretórios da seguinte maneira:

      roles
      ├── nginx
      │   └── tasks
      └── nodejs
          └── tasks
      

      Agora, crie um arquivo main.yml no diretório roles/nginx/tasks usando o seu editor preferido:

      • nano roles/nginx/tasks/main.yml

      Neste arquivo, crie uma tarefa ou task que configura e inicia o Nginx adicionando o seguinte conteúdo:

      roles/nginx/tasks/main.yml

      ---
      - name: Update cache repositories and install Nginx
        apt:
          name: nginx
          update_cache: yes
      
      - name: Change nginx directory permission
        file:
          path: /etc/nginx/nginx.conf
          mode: 0750
      
      - name: start nginx
        service:
          name: nginx
          state: started
      

      Depois de adicionar o conteúdo, salve e saia do arquivo.

      Em roles/nginx/tasks/main.yml você define uma tarefa que atualizará o repositório de cache do seu Droplet, o que equivale a executar o comando apt update manualmente em um servidor. Essa tarefa também altera as permissões do arquivo de configuração do Nginx e inicia o serviço Nginx.

      Você também criará um arquivo main.yml em roles/nodejs/tasks para definir uma tarefa que configure o Node.js.

      • nano roles/nodejs/tasks/main.yml

      Adicione as seguintes tarefas a este arquivo:

      roles/nodejs/tasks/main.yml

      ---
      - name: Update caches repository
        apt:
          update_cache: yes
      
      - name: Add gpg key for NodeJS LTS
        apt_key:
          url: "https://deb.nodesource.com/gpgkey/nodesource.gpg.key"
          state: present
      
      - name: Add the NodeJS LTS repo
        apt_repository:
          repo: "deb https://deb.nodesource.com/node_{{ NODEJS_VERSION }}.x {{ ansible_distribution_release }} main"
          state: present
          update_cache: yes
      
      - name: Install Node.js
        apt:
          name: nodejs
          state: present
      
      

      Salve e saia do arquivo quando terminar.

      Em roles/nodejs/tasks/main.yml, você primeiro define uma tarefa que atualizará o repositório de cache do seu Droplet. Em seguida, na próxima tarefa, você adiciona a chave GPG para o Node.js, que serve como um meio de verificar a autenticidade do repositório apt do Node.js. As duas tarefas finais adicionam o repositório apt do Node.js e o instalam.

      Agora você definirá suas configurações do Ansible, como variáveis, a ordem em que você deseja que suas roles sejam executadas e configurações de privilégios de superusuário. Para fazer isso, você criará um arquivo chamado playbook.yml, que serve como um entry point para o Kitchen. Quando você executa seus testes, o Kitchen inicia no seu arquivo playbook.yml e procura as roles a serem executadas, que são seus arquivos roles/nginx/tasks/main.yml e roles/nodejs/tasks/main.yml.

      Execute o seguinte comando para criar o playbook.yml:

      Adicione o seguinte conteúdo ao arquivo:

      ansible_testing_dir/playbook.yml

      ---
       - hosts: all
         become: true
         remote_user: ubuntu
         vars:
          NODEJS_VERSION: 8
      

      Salve e saia do arquivo.

      Você criou as roles do playbook do Ansible com as quais executará seus testes para garantir que as condições especificadas no playbook sejam atendidas.

      Passo 3 — Escrevendo Seus Testes InSpec

      Neste passo, você escreverá testes para verificar se o Node.js está instalado no seu Droplet. Antes de escrever seu teste, vejamos o formato de um exemplo de teste InSpec. Como em muitos frameworks de teste, o código InSpec se assemelha a uma linguagem natural. O InSpec possui dois componentes principais, o assunto a ser examinado e o estado esperado desse assunto:

      block A

      describe '<entity>' do
        it { <expectation> }
      end
      

      Em block A, as palavras-chave do e end definem um bloco ou block. A palavra-chave describe é comumente conhecida como conjuntos ou suites de testes, que contêm casos de teste. A palavra-chave it é usada para definir os casos de teste.

      <entity> é o assunto que você deseja examinar, por exemplo, um nome de pacote, serviço, arquivo ou porta de rede. O <expectation> especifica o resultado desejado ou o estado esperado, por exemplo, o Nginx deve ser instalado ou deve ter uma versão específica. Você pode verificar a documentação da InSpec DSL para aprender mais sobre a linguagem InSpec.

      Outro exemplo de bloco de teste InSpec:

      block B

      control 'Pode ser qualquer coisa única' do  
        impact 0.7                         
        title 'Um título inteligível'     
        desc  'Uma descrição opcional'
        describe '<entity>' do             
          it { <expectation> }
        end
      end
      

      A diferença entre o bloco A e o bloco B é o bloco control. O bloco control é usado como um meio de controle regulatório, recomendação ou requisito. O bloco control tem um nome; geralmente um ID único, metadados como desc, title, impact e, finalmente, agrupam blocos describe relacionados para implementar as verificações.

      desc, title, e impact definem metadados que descrevem completamente a importância do controle, seu objetivo, com uma descrição sucinta e completa. impact define um valor numérico que varia de 0.0 a 1.0 onde 0.0 a <0.01 é classificado como sem impacto, 0.01 a <0.4 é classificado como baixo impacto, 0.4 a <0.7 é classificado como médio impacto, 0,7 a <0,9 é classificado como alto impacto, 0,9 a 1,0 é classificado como controle crítico.

      Agora, vamos implementar um teste. Usando a sintaxe do bloco A, você usará o recurso package do InSpec para testar se o Node.js está instalado no sistema. Você irá criar um arquivo chamado sample.rb em seu diretório test/integration/default para seus testes.

      Crie o sample.rb:

      • nano test/integration/default/sample.rb

      Adicione o seguinte ao seu arquivo:

      test/integration/default/sample.rb

      describe package('nodejs') do
        it { should be_installed }
      end
      

      Aqui seu teste está usando o recurso package para verificar se o node.js está instalado.

      Salve e saia do arquivo quando terminar.

      Para executar este teste, você precisa editar kitchen.yml para especificar o playbook que você criou anteriormente e para adicionar às suas configurações.

      Abra seu arquivo kitchen.yml:

      • nano ansible_testing_dir/kitchen.yml

      Substitua o conteúdo de kitchen.yml com o seguinte:

      ansible_testing_dir/kitchen.yml

      ---
      driver:
        name: digitalocean
      
      provisioner:
        name: ansible_playbook
        hosts: test-kitchen
        playbook: ./playbook.yml
      
      verifier:
        name: inspec
      
      platforms:
        - name: ubuntu-18
          driver_config:
            ssh_key: CAMINHO_PARA_SUA_CHAVE_PRIVADA_SSH
            tags:
              - inspec-testing
            region: fra1
            size: 1gb
            private_networking: false
          verifier:
            inspec_tests:
              - test/integration/default
      suites:
        - name: default
      
      

      As opções de platform incluem o seguinte:

      • name: A imagem que você está usando.
      • driver_config: A configuração do seu Droplet da DigitalOcean. Você está especificando as seguintes opções para driver_config:

        • ssh_key: Caminho para SUA_CHAVE_SSH_PRIVADA. Sua SUA_CHAVE_SSH_PRIVADA está localizada no diretório que você especificou ao criar sua chave ssh.
        • tags: As tags associadas ao seu Droplet.
        • region: A region ou região onde você deseja que seu Droplet seja hospedado.
        • size: A memória que você deseja que seu Droplet tenha.
      • verifier: Isso define que o projeto contém testes InSpec.

        • A parte do inspec_tests especifica que os testes existem no diretório test/integration/default do projeto.

      Observe que name e region usam abreviações. Você pode verificar na documentação do test-kitchen as abreviações que você pode usar.

      Depois de adicionar sua configuração, salve e saia do arquivo.

      Execute o comando kitchen test para executar o teste. Isso verificará se o Node.js está instalado — ele falhará propositalmente, porque você atualmente não possui a role Node.js no seu arquivo playbook.yml:

      Você verá uma saída semelhante à seguinte:

      Output: failing test results

      -----> Starting Kitchen (v1.24.0) -----> Cleaning up any prior instances of <default-ubuntu-18> -----> Destroying <default-ubuntu-18>... DigitalOcean instance <145268853> destroyed. Finished destroying <default-ubuntu-18> (0m2.63s). -----> Testing <default-ubuntu-18> -----> Creating <default-ubuntu-18>... DigitalOcean instance <145273424> created. Waiting for SSH service on 138.68.97.146:22, retrying in 3 seconds [SSH] Established (ssh ready) Finished creating <default-ubuntu-18> (0m51.74s). -----> Converging <default-ubuntu-18>... $$$$$$ Running legacy converge for 'Digitalocean' Driver -----> Installing Chef Omnibus to install busser to run tests PLAY [all] ********************************************************************* TASK [Gathering Facts] ********************************************************* ok: [localhost] PLAY RECAP ********************************************************************* localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Downloading files from <default-ubuntu-18> Finished converging <default-ubuntu-18> (0m55.05s). -----> Setting up <default-ubuntu-18>... $$$$$$ Running legacy setup for 'Digitalocean' Driver Finished setting up <default-ubuntu-18> (0m0.00s). -----> Verifying <default-ubuntu-18>... Loaded tests from {:path=>". ansible_testing_dir.test.integration.default"} Profile: tests from {:path=>"ansible_testing_dir/test/integration/default"} (tests from {:path=>"ansible_testing_dir.test.integration.default"}) Version: (not specified) Target: ssh://[email protected]:22 System Package nodejs × should be installed expected that System Package nodejs is installed Test Summary: 0 successful, 1 failure, 0 skipped >>>>>> ------Exception------- >>>>>> Class: Kitchen::ActionFailed >>>>>> Message: 1 actions failed. >>>>>> Verify failed on instance <default-ubuntu-18>. Please see .kitchen/logs/default-ubuntu-18.log for more details >>>>>> ---------------------- >>>>>> Please see .kitchen/logs/kitchen.log for more details >>>>>> Also try running `kitchen diagnose --all` for configuration 4.54s user 1.77s system 5% cpu 2:02.33 total

      A saída informa que seu teste está falhando porque você não possui o Node.js instalado no Droplet que você provisionou com o kitchen. Você corrigirá seu teste adicionando a role nodejs ao seu arquivo playbook.yml e executará o teste novamente.

      Edite o arquivo playbook.yml para incluir a role nodejs:

      Adicione as seguintes linhas destacadas ao seu arquivo:

      ansible_testing_dir/playbook.yml

      ---
       - hosts: all
         become: true
         remote_user: ubuntu
         vars:
          NODEJS_VERSION: 8
      
         roles:
          - nodejs
      

      Salve e feche o arquivo.

      Agora, você executará novamente o teste usando o comando kitchen test:

      Você verá a seguinte saída:

      Output

      ...... Target: ssh://[email protected]:22 System Package nodejs ✔ should be installed Test Summary: 1 successful, 0 failures, 0 skipped Finished verifying <default-ubuntu-18> (0m4.89s). -----> Destroying <default-ubuntu-18>... DigitalOcean instance <145512952> destroyed. Finished destroying <default-ubuntu-18> (0m2.23s). Finished testing <default-ubuntu-18> (2m49.78s). -----> Kitchen is finished. (2m55.14s) 4.86s user 1.77s system 3% cpu 2:56.58 total

      Seu teste agora passa porque você tem o Node.js instalado usando a role nodejs.

      Aqui está um resumo do que o Kitchen está fazendo em Test Action:

      • Destrói o Droplet se ele existir
      • Cria o Droplet
      • Converge o Droplet
      • Verifica o Droplet com o InSpec
      • Destrói o Droplet

      O Kitchen interromperá a execução em seu Droplet se encontrar algum problema. Isso significa que, se o seu playbook do Ansible falhar, o InSpec não será executado e o seu Droplet não será destruído. Isso permite que você inspecione o estado da instância e corrija quaisquer problemas. O comportamento da ação final de destruição pode ser substituído, se desejado. Verifique a ajuda da CLI para a flag --destroy executando o comando kitchen help test.

      Você escreveu seus primeiros testes e os executou no seu playbook com uma instância falhando antes de corrigir o problema. Em seguida, você estenderá seu arquivo de teste.

      Passo 4 — Adicionando Casos de Teste

      Neste passo, você adicionará mais casos de teste ao seu arquivo de teste para verificar se os módulos do Nginx estão instalados no seu Droplet e se o arquivo de configuração tem as permissões corretas.

      Edite seu arquivo sample.rb para adicionar mais casos de teste:

      • nano test/integration/default/sample.rb

      Adicione os seguintes casos de teste ao final do arquivo:

      test/integration/default/sample.rb

      . . .
      control 'nginx-modules' do
        impact 1.0
        title 'NGINX modules'
        desc 'The required NGINX modules should be installed.'
        describe nginx do
          its('modules') { should include 'http_ssl' }
          its('modules') { should include 'stream_ssl' }
          its('modules') { should include 'mail_ssl' }
        end
      end
      
      control 'nginx-conf' do
        impact 1.0
        title 'NGINX configuration'
        desc 'The NGINX config file should owned by root, be writable only by owner, and not writeable or and readable by others.'
        describe file('/etc/nginx/nginx.conf') do
          it { should be_owned_by 'root' }
          it { should be_grouped_into 'root' }
          it { should_not be_readable.by('others') }
          it { should_not be_writable.by('others') }
          it { should_not be_executable.by('others') }
        end
      end
      

      Esses casos de teste verificam se os módulos nginx-modules no seu Droplet incluem http_ssl, stream_ssl e mail_ssl. Você também está verificando as permissões do arquivo /etc/nginx/nginx.conf.

      Você está usando as palavras-chave it e its para definir seu teste. A palavra-chave its é usada apenas para acessar propriedades de resources. Por exemplo, modules é uma propriedade de nginx.

      Salve e saia do arquivo depois de adicionar os casos de teste.

      Agora execute o comando kitchen test para testar novamente:

      Você verá a seguinte saída:

      Output

      ... Target: ssh://[email protected]:22 ↺ nginx-modules: NGINX modules ↺ The `nginx` binary not found in the path provided. × nginx-conf: NGINX configuration (2 failed) × File /etc/nginx/nginx.conf should be owned by "root" expected `File /etc/nginx/nginx.conf.owned_by?("root")` to return true, got false × File /etc/nginx/nginx.conf should be grouped into "root" expected `File /etc/nginx/nginx.conf.grouped_into?("root")` to return true, got false ✔ File /etc/nginx/nginx.conf should not be readable by others ✔ File /etc/nginx/nginx.conf should not be writable by others ✔ File /etc/nginx/nginx.conf should not be executable by others System Package nodejs ✔ should be installed Profile Summary: 0 successful controls, 1 control failure, 1 control skipped Test Summary: 4 successful, 2 failures, 1 skipped

      Você verá que alguns dos testes estão falhando. Você irá corrigi-los adicionando a role nginx ao seu arquivo playbook e executando novamente o teste. No teste que falhou, você está verificando módulos nginx e permissões de arquivo que não estão presentes atualmente no seu servidor.

      Abra seu arquivo playbook.yml:

      • nano ansible_testing_dir/playbook.yml

      Adicione a seguinte linha destacada às suas roles:

      ansible_testing_dir/playbook.yml

      ---
      - hosts: all
        become: true
        remote_user: ubuntu
        vars:
        NODEJS_VERSION: 8
      
        roles:
        - nodejs
        - nginx
      

      Salve e feche o arquivo quando terminar.

      Em seguida, execute seus testes novamente:

      Você verá a seguinte saída:

      Output

      ... Target: ssh://[email protected]:22 ✔ nginx-modules: NGINX version ✔ Nginx Environment modules should include "http_ssl" ✔ Nginx Environment modules should include "stream_ssl" ✔ Nginx Environment modules should include "mail_ssl" ✔ nginx-conf: NGINX configuration ✔ File /etc/nginx/nginx.conf should be owned by "root" ✔ File /etc/nginx/nginx.conf should be grouped into "root" ✔ File /etc/nginx/nginx.conf should not be readable by others ✔ File /etc/nginx/nginx.conf should not be writable by others ✔ File /etc/nginx/nginx.conf should not be executable by others System Package nodejs ✔ should be installed Profile Summary: 2 successful controls, 0 control failures, 0 controls skipped Test Summary: 9 successful, 0 failures, 0 skipped

      Depois de adicionar a role nginx ao playbook, todos os seus testes agora passam. A saída mostra que os módulos http_ssl, stream_ssl e mail_ssl estão instalados em seu Droplet e as permissões corretas estão definidas para o arquivo de configuração.

      Quando terminar, ou não precisar mais do seu Droplet, você poderá destruí-lo executando o comando kitchen destroy para excluí-lo após executar seus testes:

      Após este comando, você verá uma saída semelhante a:

      Output

      -----> Starting Kitchen (v1.24.0) -----> Destroying <default-ubuntu-18>... Finished destroying <default-ubuntu-18> (0m0.00s). -----> Kitchen is finished. (0m5.07s) 3.79s user 1.50s system 82% cpu 6.432 total

      Você escreveu testes para o seu playbook, executou os testes e corrigiu os testes com falha para garantir que todos os testes sejam aprovados. Agora você está pronto para criar um ambiente virtual, escrever testes para o seu Playbook Ansible e executar seu teste no ambiente virtual usando o Kitchen.

      Conclusão

      Agora você tem uma base flexível para testar seu deployment Ansible, que lhe permite testar seus playbooks antes de executar em um servidor ativo. Você também pode empacotar seu teste em um perfil. Você pode usar perfis para compartilhar seu teste através do Github ou do Chef Supermarket e executá-lo facilmente em um servidor ativo.

      Para detalhes mais abrangentes sobre o InSpec e o Kitchen, consulte a documentação oficial do InSpec e a documentação oficial do Kitchen.



      Source link

      Como Criar e Exibir Imagens WebP para Acelerar Seu Website


      O autor selecionou a Apache Software Foundationpara receber uma doação como parte do programa Write for DOnations.

      Introdução

      WebP é um formato aberto de imagem desenvolvido pelo Google em 2010, baseado no formato de vídeo VP8. Desde então, o número de sites e aplicativos móveis que usam o formato WebP cresceu rapidamente. Tanto o Google Chrome como o Opera suportam o formato WebP de forma nativa e, uma vez que esses navegadores representam cerca de 74% do tráfego da Web, os usuários podem acessar sites mais rapidamente se esses sites usarem imagens WebP. Também existem planos para implementar o WebP no Firefox.

      O formato WebP suporta tanto a compressão de imagens com perda, quanto sem perda de dados, incluindo animação. Sua princpal vantagem em comparação com outros formatos de imagem usados na Web é o tamanho bastante reduzido dos arquivos, o que permite que as páginas Web carreguem mais rapidamente e reduz o uso de largura de banda. Usar imagens WebP pode levar a aumentos consideráveis na velocidade da página. Se o seu aplicativo ou site estiver passando por problemas de desempenho ou aumento de tráfego, converter suas imagens pode ajudar a otimizar o desempenho das páginas.

      Neste tutorial, você usará a ferramenta de linha de comando cwebp para converter imagens para o formato WebP, criando scripts que irão ver e converter imagens em um diretório específico. Finalmente, você irá explorar duas maneiras de exibir imagens WebP aos seus visitantes.

      Pré-requisitos

      Trabalhar com imagens WebP não exige uma distribuição específica, mas vamos demonstrar como trabalhar com os software relevantes no Ubuntu 16.04 e CentOS 7. Para seguir este tutorial você precisará de:

      • Um servidor configurado com um usuário não raiz (non-root) de comando sudo. Para configurar um servidor Ubuntu 16.04, você pode seguir nosso Guia de configuração inicial de servidor Ubuntu 16.04. Se você quiser usar o CentOS, você pode configurar um servidor CentOS 7 com nossa Configuração Inicial de Servidor com tutorial CentOS.

      • O Apache instalado no seu servidor. Se você estiver usando o Ubuntu, você pode seguir o passo um do Como Instalar Linux, Apache, MySQL, pilha PHP (LAMP) no Ubuntu 16.04. Se você estiver usando o CentOS, então você deve seguir o passo um do Como Instalar Linux, Apache, MySQL, pilha PHP (LAMP) no CentOS 7. Certifique-se de ajustar as configurações do seu firewall para permitir o tráfego HTTP e HTTPS.

      • mod_rewrite instalado no seu servidor. Se você estiver usando o Ubuntu, você pode seguir nosso guia Como Manipular URLs com mod_rewrite para o Apache no Ubuntu 16.04. No CentOS 7 o mod_rewrite é instalado e ativado por padrão.

      Passo 1 — Instalando o cwebp e Preparando o Diretório de Imagens

      Nesta seção, instalaremos o software para converter imagens e criaremos um diretório com imagens para a finalidade de teste.

      No Ubuntu 16.04, você pode instalar o cwebp, um utilitário que comprime imagens no formato .webp, digitando:

      • sudo apt-get update
      • sudo apt-get install webp

      No CentOS 7, digite:

      • sudo yum install libwebp-tools

      Para criar um novo diretório de imagens chamado webp no diretório raiz do Apache Web (localizado por padrão em /var/www/html) digite:

      • sudo mkdir /var/www/html/webp

      Altere o proprietário deste diretório para o seu usuário sammy não raiz:

      • sudo chown sammy: /var/www/html/webp

      Para testar comandos, você pode baixar imagens JPEG e PNG gratuitas usando o wget. Esta ferramenta é instalada por padrão no Ubuntu 16.04; se você estiver usando o CentOS 7, você pode instalá-la digitando:

      A seguir, baixe as imagens teste usando os comandos seguintes:

      • wget -c "https://upload.wikimedia.org/wikipedia/commons/2/24/Junonia_orithya-Thekkady-2016-12-03-001.jpg?download" -O /var/www/html/webp/image1.jpg
      • wget -c "https://upload.wikimedia.org/wikipedia/commons/5/54/Mycalesis_junonia-Thekkady.jpg" -O /var/www/html/webp/image2.jpg
      • wget -c "https://cdn.pixabay.com/photo/2017/07/18/15/39/dental-care-2516133_640.png" -O /var/www/html/webp/logo.png

      Nota: estas imagens estão disponíveis para uso e redistribuição sob a licença Creative Commons Attribution-ShareAlike e o Public Domain Dedication.

      A maior parte do seu trabalho no próximo passo estará no diretório /var/www/html/webp, para o qual você pode se mover digitando:

      Com as imagens teste instaladas e o servidor Apache Web, mod_rewrite e cwebp instalados, você está pronto para ir para a conversão de imagens.

      Exibir imagens .webp para visitantes do site exige versões .webp de arquivos de imagem. Neste passo, você irá converter imagens JPEG e PNG para o formato .webp usando o cwebp. A sintaxe geral do comando se parece com essa:

      • cwebp image.jpg -o image.webp

      A opção -o especifica o caminho até o arquivo WebP.

      Uma vez que você ainda está no diretório /var/www/html/webp, você pode executar o comando a seguir para converter a image1.jpg em image1.webp e image2.jpg em image2.webp:

      • cwebp -q 100 image1.jpg -o image1.webp
      • cwebp -q 100 image2.jpg -o image2.webp

      Definir o fator de qualidade -q em 100 retém 100% da qualidade da imagem; se não especificado, o valor padrão é 75.

      A seguir, inspecione o tamanho das imagens JPEG e WebP usando o comando ls. A opção -l irá mostrar o formato de lista longa, que inclui o tamanho do arquivo e a opção -h irá garantir que ls imprima tamanhos legíveis para humanos:

      • ls -lh image1.jpg image1.webp image2.jpg image2.webp

      Output

      -rw-r--r-- 1 sammy sammy 7.4M Oct 28 23:36 image1.jpg -rw-r--r-- 1 sammy sammy 3.9M Feb 18 16:46 image1.webp -rw-r--r-- 1 sammy sammy 16M Dec 18 2016 image2.jpg -rw-r--r-- 1 sammy sammy 7.0M Feb 18 16:59 image2.webp

      O resultado do comando ls mostra que o tamanho da image1.jpg é de 7,4 MB, enquanto o tamanho da image1.webp é 3,9 MB. O mesmo se aplica à image2.jpg (16 MB) e image2.webp (7 MB). Estes arquivos têm quase metade do tamanho original.

      Para salvar os dados das imagens completos e originais durante a compressão, você pode usar a opção -lossless no lugar de -q. Esta é a melhor opção para manter a qualidade de imagens PNG. Para converter a imagem PNG baixada do passo 1, digite:

      • cwebp -lossless logo.png -o https://www.digitalocean.com/logo.webp

      O comando a seguir mostra que o tamanho sem perdas da imagem WebP (60 KB) é aproximadamente metade do tamanho da imagem PNG original (116 KB):

      • ls -lh logo.png https://www.digitalocean.com/logo.webp

      Output

      -rw-r--r-- 1 sammy sammy 116K Jul 18 2017 logo.png -rw-r--r-- 1 sammy sammy 60K Feb 18 16:42 https://www.digitalocean.com/logo.webp

      As imagens convertidas no diretório /var/www/html/webp são cerca de 50% menores do que suas equivalentes em JPEG e PNG. Na prática, as taxas de compressão podem ser diferentes, dependendo de certos fatores: a taxa de compressão da imagem original, o formato do arquivo, o tipo de conversão (com ou sem perdas), a porcentagem de qualidade e o seu sistema operacional. Conforme você for convertendo mais imagens, você poderá ver variações nas taxas de conversão relacionadas a esses fatores.

      Passo 3 — Convertendo Imagens JPEG e PNG em um Diretório

      Escrever um script irá simplificar o processo de conversão, eliminando o trabalho da conversão manual. Agora, vamos escrever um script de conversão que encontre arquivos JPEG e os converta para o formato WebP com 90% da qualidade, enquanto também converte arquivos PNG em imagens WeP sem perdas.

      Usando o nano ou seu editor favorito, crie o script webp-convert.sh no diretório home do seu usuário.

      A primeira linha do script se parecerá com esta:

      ~/webp-convert.sh

      find $1 -type f -and ( -iname "*.jpg" -o -iname "*.jpeg" )
      

      Esta linha tem os seguintes componentes:

      • find: este comando irá procurar por arquivos dentro de um diretório especificado.
      • $1: este parâmetro posicional especifica o caminho do diretório de imagens, tirado da linha de comando. Em última análise, ele torna o local do diretório menos dependente do local do script.
      • -type f: esta opção diz ao find para procurar apenas arquivos regulares.
      • -iname: este teste compara os nomes dos arquivos com um padrão especificado. O teste -iname que não diferencia maiúsculas de minúsculas diz ao find para procurar qualquer nome de arquivo que termine com .jpg (*.jpg) ou .jpeg (*.jpeg).
      • -o: Este operador lógico instrui o comando find para listar arquivos que correspondam ao primeiro teste -iname (-iname ".jpg"**) ou o segundo (-iname "*.jpeg"**).
      • (): parênteses em volta desses testes, junto com o operador -and, garante que o primeiro teste (ou seja -type f) seja sempre executado.

      A segunda linha do script irá converter as imagens para WebP usando o parâmetro -exec. A sintaxe geral deste parâmetro é -exec command {} ;. Cada arquivo substitui uma string {}; o comando faz a iteração através desses arquivos, ao passo que a string ; diz para o find onde o comando termina:

      ~/webp-convert.sh

      find $1 -type f -and ( -iname "*.jpg" -o -iname "*.jpeg" ) 
      -exec bash -c 'commands' {} ;
      

      Neste caso, o parâmetro -exec irá exigir mais de um comando para procurar e converter imagens:

      • bash: este comando irá executar um pequeno script que irá criar a versão .webp do arquivo se ele não existir. Este script será passado para o bash como uma string, graças à opção -c.
      • 'commands': este espaço reservado é o script que irá fazer versões .webp dos seus arquivos.

      O script dentro de 'commands' fará as seguintes coisas:

      • Criar uma variável webp_path.
      • Testar se a versão .webp do arquivo existe ou não.
      • Criar o arquivo se ele não existir.

      O script menor se parece com este:

      ~/webp-convert.sh

      ...
      webp_path=$(sed 's/.[^.]*$/.webp/' <<< "$0");
      if [ ! -f "$webp_path" ]; then 
        cwebp -quiet -q 90 "$0" -o "$webp_path";
      fi;
      

      Os elementos neste script menor incluem:

      • webp_path: esta variável será gerada usando o sed e o nome do arquivo correspondente do comando bash, estipulado pelo pelo parâmetro posicional $0. Uma _string here_ (​​​​​​<<<) passará este nome para o sed.
      • if [ ! -f "$webp_path" ]: este teste irá determinar se um arquivo chamado "$webp_path" já existe, usando o operador lógico not (!).
      • cwebp: este comando irá criar o arquivo se ele não existir, usando a opção -q para não imprimir o resultado.

      Com este script menor no lugar do espaço reservado 'commands', o script completo para converter imagens JPEG se parecerá agora com este:

      ~/webp-convert.sh

      # converting JPEG images
      find $1 -type f -and ( -iname "*.jpg" -o -iname "*.jpeg" ) 
      -exec bash -c '
      webp_path=$(sed 's/.[^.]*$/.webp/' <<< "$0");
      if [ ! -f "$webp_path" ]; then 
        cwebp -quiet -q 90 "$0" -o "$webp_path";
      fi;' {} ;
      

      Para converter imagens PNG para WebP, vamos adotar a mesma abordagem, com duas diferenças: primeiro, o padrão -iname no comando find será "*.png". Segundo, o comando de conversão usará a opção -lossless em vez da opção de qualidade -q.

      O script final se parece com este:

      ~/webp-convert.sh

      #!/bin/bash
      
      # converting JPEG images
      find $1 -type f -and ( -iname "*.jpg" -o -iname "*.jpeg" ) 
      -exec bash -c '
      webp_path=$(sed 's/.[^.]*$/.webp/' <<< "$0");
      if [ ! -f "$webp_path" ]; then 
        cwebp -quiet -q 90 "$0" -o "$webp_path";
      fi;' {} ;
      
      # converting PNG images
      find $1 -type f -and -iname "*.png" 
      -exec bash -c '
      webp_path=$(sed 's/.[^.]*$/.webp/' <<< "$0");
      if [ ! -f "$webp_path" ]; then 
        cwebp -quiet -lossless "$0" -o "$webp_path";
      fi;' {} ;
      

      Salve o arquivo e saia do editor.

      Em seguida, vamos colocar o script webp-convert.sh em prática, usando os arquivos no diretório /var/www/html/webp. Certifique-se de que o arquivo script é executável, executando o comando a seguir:

      • chmod a+x ~/webp-convert.sh

      Execute o script no diretório de imagens:

      • ./webp-convert.sh /var/www/html/webp

      Nada aconteceu! Isso se dá porque já convertemos essas imagens no passo 2. Avançando, o script webp-convert converterá imagens quando adicionarmos novos arquivos ou removermos as versões .webp. Para ver como isso funciona, exclua os arquivos .webp que criamos no passo 2:

      • rm /var/www/html/webp/*.webp

      Após excluir todas as imagens .webp, execute o script novamente para garantir que ele funciona:

      • ./webp-convert.sh /var/www/html/webp

      O comando ls confirmará que o script converteu as imagens com sucesso:

      • ls -lh /var/www/html/webp

      Output

      -rw-r--r-- 1 sammy sammy 7.4M Oct 28 23:36 image1.jpg -rw-r--r-- 1 sammy sammy 3.9M Feb 18 16:46 image1.webp -rw-r--r-- 1 sammy sammy 16M Dec 18 2016 image2.jpg -rw-r--r-- 1 sammy sammy 7.0M Feb 18 16:59 image2.webp -rw-r--r-- 1 sammy sammy 116K Jul 18 2017 logo.png -rw-r--r-- 1 sammy sammy 60K Feb 18 16:42 https://www.digitalocean.com/logo.webp

      O script neste passo é a base para usar imagens WebP no seu site, uma vez que você precisará de uma versão m funcionamento de todas as imagens no formato WebP para exibir aos visitantes. O próximo passo abordará como automatizar a conversão de novas imagens.

      Passo 4 — Monitorando Arquivos de Imagem em um Diretório

      Neste passo, criaremos um novo script para monitorar nosso diretório de imagens quanto a alterações e para converter automaticamente as imagens recém-criadas.

      Criar um script que monitora nosso diretório de imagens pode resolver certos problemas com o script webp-convert.sh da forma como ele está escrito. Por exemplo, este script não identificará se renomeamos uma imagem. Se tivéssemos uma imagem chamada foo.jpg, executássemos o webp-convert.sh, renomeássemos aquele arquivo para bar.jpg e, então, executássemos o webp-convert.sh novamente, teríamos arquivos duplicados de .webp (foo.webp e bar.webp). Para resolver este problema e para evitar executar o script manualmente, adicionaremos observadores a outro script. Os observadores monitoram os arquivos ou diretórios especificados quanto às alterações e executam comandos em resposta a essas alterações.

      O comando inotifywait irá configurar observadores no nosso script. Este comando faz parte do pacote inotify-tools, um conjunto de ferramentas de linha de comando que fornecem uma interface simples ao subsistema do kernel inotify. Para instalá-lo no Ubuntu 16.04 digite:

      • sudo apt-get install inotify-tools

      Com o CentOS 7, o pacote inotify-tools está disponível no repositório EPEL. Instale o repositório EPEL e o pacote inotify-tools usando os comandos a seguir:

      • sudo yum install epel-release
      • sudo yum install inotify-tools

      Em seguida, crie o script webp-watchers.sh no diretório home do seu usuário usando o nano:

      A primeira linha do script se parecerá com esta:

      ~/webp-watchers.sh

      inotifywait -q -m -r --format '%e %w%f' -e close_write -e moved_from -e moved_to -e delete $1
      

      Esta linha inclui os seguintes elementos:

      • inotifywait: este comando monitora quanto às alterações em um certo diretório.
      • -q: esta opção irá dizer ao inotifywait para ficar quieto e não produzir grande quantidade de resultados.
      • -m: esta opção irá dizer ao inotifywait para executar indefinidamente e não sair após receber um único evento.
      • -r: esta opção irá configurar observadores de maneira repetitiva, monitorando um diretório especificado e todos os seus subdiretórios.
      • --format: esta opção diz ao inotifywait para monitorar alterações usando o nome do evento seguido do caminho do arquivo. Os eventos que queremos monitorar são close_write (acionado quando um arquivo é criado e completamente gravado no disco), moved_from e moved_to (acionados quando um arquivo é movido) e delete (acionado quando um arquivo é excluído).
      • $1: este parâmetro posicional retém o caminho dos arquivos alterados.

      Na sequência, vamos adicionar um comando grep para determinar se nossos arquivos são imagens JPEG ou PNG. A opção -i irá dizer ao grep para ignorar a diferença entre maiúsculas e minúsculas; -E irá especificar que o grep deve usar expressões regulares estendidas e a --line-buffered irá dizer ao grep para passar as linhas correspondentes para um loop while:

      ~/webp-watchers.sh

      inotifywait -q -m -r --format '%e %w%f' -e close_write -e moved_from -e moved_to -e delete $1 | grep -i -E '.(jpe?g|png)$' --line-buffered
      

      A seguir, vamos construir um loop while com o comando read. O read irá processar o evento que o inotifywait detectou, atribuindo-o a uma variável chamada $operation e o caminho do arquivo processado para uma variável chamada $path:

      ~/webp-watchers.sh

      ...
      | while read operation path; do
        # commands
      done;
      

      Vamos combinar este loop com o resto do nosso script:

      ~/webp-watchers.sh

      inotifywait -q -m -r --format '%e %w%f' -e close_write -e moved_from -e moved_to -e delete $1 
      | grep -i -E '.(jpe?g|png)$' --line-buffered 
      | while read operation path; do
        # commands
      done;
      

      Após o loop while verificar o evento, os comandos dentro do loop tomarão as seguintes ações, dependendo do resultado:

      • Criar um novo arquivo WebP se um novo arquivo de imagem for criado ou movido para o diretório de destino.
      • Excluir o arquivo WebP se o arquivo de imagem associado for excluído ou movido do diretório de destino.

      Há três seções principais dentro do loop. Uma variável chamada webp_path irá reter o caminho para a versão .webp da imagem em questão:

      ~/webp-watchers.sh

      ...
      webp_path="$(sed 's/.[^.]*$/.webp/' <<< "$path")";
      

      A seguir, o script irá testar qual evento aconteceu:

      ~/webp-watchers.sh

      ...
      if [ $operation = "MOVED_FROM" ] || [ $operation = "DELETE" ]; then
        # commands to be executed if the file is moved or deleted
      elif [ $operation = "CLOSE_WRITE,CLOSE" ] || [ $operation = "MOVED_TO" ]; then
        # commands to be executed if a new file is created
      fi;
      

      Se o arquivo foi movido ou excluído, o script irá verificar se a versão .webp existe. Se ela existe, o script irá removê-la usando o rm:

      ~/webp-watchers.sh

      ...
      if [ -f "$webp_path" ]; then
        $(rm -f "$webp_path");
      fi;
      

      Para arquivos recém-criados, a compressão irá acontecer da seguinte forma:

      • Se o arquivo correspondente for uma imagem PNG, o script irá usar a compressão sem perdas.
      • Se não for, o script usará uma compressão com perdas com a opção -quality.

      Vamos adicionar os comandos cwebp que irão fazer este trabalho no script:

      ~/webp-watchers.sh

      ...
      if [ $(grep -i '.png$' <<< "$path") ]; then
        $(cwebp -quiet -lossless "$path" -o "$webp_path");
      else
        $(cwebp -quiet -q 90 "$path" -o "$webp_path");
      fi;
      

      Na íntegra, o arquivo webp-watchers.sh se parecerá com este:

      ~/webp-watchers.sh

      #!/bin/bash
      echo "Setting up watches.";
      
      # watch for any created, moved, or deleted image files
      inotifywait -q -m -r --format '%e %w%f' -e close_write -e moved_from -e moved_to -e delete $1 
      | grep -i -E '.(jpe?g|png)$' --line-buffered 
      | while read operation path; do
        webp_path="$(sed 's/.[^.]*$/.webp/' <<< "$path")";
        if [ $operation = "MOVED_FROM" ] || [ $operation = "DELETE" ]; then # if the file is moved or deleted
          if [ -f "$webp_path" ]; then
            $(rm -f "$webp_path");
          fi;
        elif [ $operation = "CLOSE_WRITE,CLOSE" ] || [ $operation = "MOVED_TO" ]; then  # if new file is created
           if [ $(grep -i '.png$' <<< "$path") ]; then
             $(cwebp -quiet -lossless "$path" -o "$webp_path");
           else
             $(cwebp -quiet -q 90 "$path" -o "$webp_path");
           fi;
        fi;
      done;
      

      Salve e feche o arquivo. Não se esqueça de torná-lo executável:

      • chmod a+x ~/webp-watchers.sh

      Vamos executar este script no diretório /var/www/html/webp em segundo plano, usando o &. Vamos também redirecionar os resultados padrão e os erros padrão para um ~/output.log, para armazenar os resultados em local prontamente disponível:

      • ./webp-watchers.sh /var/www/html/webp > output.log 2>&1 &

      Neste ponto, você converteu os arquivos JPEG e PNG em /var/www/html/webp para o formato WebP e configurou observadores para fazer esse trabalho, usando o script webp-watchers.sh. Agora é hora de explorar opções para entregar imagens WebP aos visitantes do seu site.

      Passo 5 — Exibindo Imagens WebP para Visitantes Usando Elementos HTML

      Neste passo, vamos explicar como exibir imagens WebP com elementos HTML. Neste ponto, devem haver versões .webp de cada uma das imagens teste JPEG e PNG no diretório /var/www/html/webp. Agora, podemos exibi-las para os navegadores compatíveis, usando ou os elementos HTML5 (<picture>) ou o módulo Apache mod_rewrite. Vamos usar elementos HTML neste passo.

      O elemento <picture> permite que você inclua imagens diretamente nas suas páginas Web e defina mais de uma fonte de imagens. Se seu navegador é compatível com o formato WebP, ele irá baixar a versão .webp do arquivo em vez da versão original, resultando em páginas Web sendo exibidas mais rapidamente. Vale dizer que o elemento <picture> é bem suportado em navegadores modernos compatíveis com o formato WebP.

      O elemento <picture> é um container com elementos <source> que <image> apontam para arquivos específicos. Se usarmos <source> para apontar para uma imagem .webp, o navegador verá se ele pode lidar com ela; caso contrário, ele retrocederá para o arquivo de imagem especificado no atributo src do elemento <source>.

      Vamos usar o arquivo logo.png do nosso diretório /var/www/html/webp, o qual convertemos para https://www.digitalocean.com/logo.webp, como um exemplo com <source>. Podemos usar o seguinte código HTML para exibir o https://www.digitalocean.com/logo.webp em qualquer navegador compatível com o formato WebP e o logo.png com navegadors não compatíveis com o WebP ou o elemento <picture>.

      Crie um arquivo HTML localizado em /var/www/html/webp/picture.html:

      • nano /var/www/html/webp/picture.html

      Adicione o código a seguir à página Web para exibir o https://www.digitalocean.com/logo.webp para navegadores compatíveis, usando o elemento <picture>:

      /var/www/html/webp/picture.html

      <picture>
        <source  type="image/webp">
        <img src="https://www.digitalocean.com/logo.png" alt="Site Logo">
      </picture>
      

      Salve e feche o arquivo.

      Para testar se tudo está funcionando, navegue até a página http://your_server_ip/webp/picture.html. Você deve ver a imagem teste PNG.

      Agora que você sabe como exibir imagens .webp diretamente do código HTML, vamos ver como automatizar este processo usando o módulo mod_rewrite do Apache.

      Passo 6 — Exibindo Imagens WebP Usando o mod_rewrite

      Se queremos otimizar a velocidade do nosso site, mas temos um grande número de páginas ou muito pouco tempo para editar o código HTML, então o módulo mod_rewrite do Apache pode nos ajudar a automatizar o processo de exibição de imagens .webp em navegadores compatíveis.

      Primeiramente, crie um arquivo .htaccess no diretório /var/www/html/webp usando o comando a seguir:

      • nano /var/www/html/webp/.htaccess

      A diretiva ifModule irá testar se o mod_rewrite está disponível; se ele estiver, ele pode ser ativado usando o RewriteEngine On. Adicione essas diretivas ao .htaccess:

      /var/www/html/webp/.htaccess

      <ifModule mod_rewrite.c>
        RewriteEngine On 
        # further directives
      </IfModule>
      

      O servidor Web fará vários testes para estabelecer quando exibir imagens .webp para o usuário. Quando um navegador faz um pedido, ele inclui um cabeçalho que indica ao servidor o que o navegador é capaz de manipular. No caso do WebP, o navegador irá enviar um cabeçalho Accept que contém image/webp. Vamos verificar se o navegador enviou aquele cabeçalho usando o RewriteCond, que especifica os critérios que devem ser correspondidos para executar o RewriteRule:

      /var/www/html/webp/.htaccess

      ...
      RewriteCond %{HTTP_ACCEPT} image/webp
      

      Tudo deve ser filtrado, exceto as imagens JPEG e PNG. Usando o RewriteCond novamente, adicione uma expressão regular (similar ao que usamos nas seções anteriores) para corresponder ao URI solicitado:

      /var/www/html/webp/.htaccess

      ...
      RewriteCond %{REQUEST_URI}  (?i)(.*)(.jpe?g|.png)$ 
      

      O modificador (?i) fará com que a correspondência não diferencie maiúsculas e minúsculas.

      Para verificar se a versão .webp do arquivo existe, use o RewriteCond novamente do seguinte modo:

      /var/www/html/webp/.htaccess

      ...
      RewriteCond %{DOCUMENT_ROOT}%1.webp -f
      

      Finalmente, se todas as condições anteriores forem cumpridas, o RewriteRule irá redirecionar o arquivo JPEG ou PNG solicitado para seu arquivo WebP associado. Observe que isso irá redirecionar usando o sinalizador -R, em vez de reescrever o URI. A diferença entre reescrever e redirecionar é que o servidor irá exibir o URI reescrito sem contar ao navegador. Por exemplo, o URI irá mostrar que a extensão de arquivo é .png, mas ele será na realidade um arquivo .webp. Adicione o RewriteRule ao arquivo:

      /var/www/html/webp/.htaccess

      ...
      RewriteRule (?i)(.*)(.jpe?g|.png)$ %1.webp [L,T=image/webp,R] 
      

      Neste ponto, a seção mod_rewrite no arquivo .htaccess está completa. Mas o que acontecerá se houver um servidor de cache intermediário entre seu servidor e o cliente? Ele pode exibir a versão errada ao usuário final. É por isso que vale a pena verificar se o mod_headers está habilitado, para enviar o cabeçalho Vary: Accept. O cabeçalho Vary indica aos servidores de cache (como servidores proxy) que o tipo de conteúdo do documento varia dependendo das capacidades do navegador que solicita o documento. Além disso, a resposta será gerada com base no cabeçalho Accept no pedido. Um pedido com um cabeçalho Accept diferente pode obter uma resposta diferente. Este cabeçalho é importante porque ele impede que imagens WebP em cache sejam exibidas para navegadores não compatíveis:

      /var/www/html/webp/.htaccess

      ...
      <IfModule mod_headers.c>
        Header append Vary Accept env=REDIRECT_accept
      </IfModule>
      

      Enfim, no final do arquivo .htaccess, configure o tipo MIME das imagens .webp como image/webp usando a diretiva AddType. Isso irá exibir as imagens usando o tipo de MIME correto:

      /var/www/html/webp/.htaccess

      ...
      AddType image/webp .webp
      

      Esta é a versão final do nosso arquivo .htaccess:

      /var/www/html/webp/.htaccess

      <ifModule mod_rewrite.c>
        RewriteEngine On 
        RewriteCond %{HTTP_ACCEPT} image/webp
        RewriteCond %{REQUEST_URI}  (?i)(.*)(.jpe?g|.png)$ 
        RewriteCond %{DOCUMENT_ROOT}%1.webp -f
        RewriteRule (?i)(.*)(.jpe?g|.png)$ %1.webp [L,T=image/webp,R] 
      </IfModule>
      
      <IfModule mod_headers.c>
        Header append Vary Accept env=REDIRECT_accept
      </IfModule>
      
      AddType image/webp .webp
      

      Nota: você pode fundir este .htaccess com outro arquivo .htaccess, se ele existir. Se você está usando o WordPress, por exemplo, você deve copiar este arquivo .htaccess e colá-lo no topo do arquivo existente.

      Vamos colocar o que fizemos neste passo em prática. Se você seguiu as instruções nos passos anteriores, você deve ter as imagens logo.png e https://www.digitalocean.com/logo.webp em /var/www/html/webp. Vamos usar uma tag simples <img> para incluir a logo.png em nossa página Web. Crie um novo arquivo HTML para testar a configuração:

      • nano /var/www/html/webp/img.html

      Digite o código HTML a seguir no arquivo:

      /var/www/html/webp/img.html

      <img src="https://www.digitalocean.com/logo.png" alt="Site Logo">
      

      Salve e feche o arquivo.

      Quando você visitar a página Web usando o Chrome visitando http://your_server_ip/webp/img.html, você irá notar que a imagem exibida é a versão .webp (tente abrir a imagem em uma nova aba). Se você usa o Firefox, você receberá uma imagem .png automaticamente.

      Conclusão

      Neste tutorial, abordamos técnicas básicas para trabalhar com imagens WebP. Explicamos como usar o cwebp para converter arquivos, além de duas opções para exibir essas imagens aos usuários: o elemento <picture> do HTML5 e o mod_rewrite do Apache.

      Para personalizar os scripts deste tutorial, você pode consultar alguns desses recursos:

      • Para aprender mais sobre as características do formato WebP e como usar as ferramentas de conversão, consulte a documentação do WebP.
      • Para ver mais detalhes sobre o uso do elemento <picture>, consulte sua documentação no MDN.
      • Para entender completamente como usar o mod_rewrite, consulte sua documentação.

      Usar o formato WebP para suas imagens irá reduzir os tamanhos dos arquivos de maneira considerável. Isso pode reduzir o uso da largura de banda e fazer as páginas carregarem mais rapidamente, particularmente se seu site usar muitas imagens.



      Source link