One place for hosting & domains

      Gateway

      Hreflang Tags: Your Gateway to International SEO


      Continually working to optimize your website for search engine visibility will ensure that new users can find your website on the web. There are a range of techniques you can use to improve your website’s SEO rankings for a national audience, however when trying to target audiences in multiple countries or visitors who speak more than one language, you’ll need to follow a few additional rules — one of which involves adding hreflang tags to your website.

      Search engines read hreflang tags to ensure that your pages are indexed correctly for a defined international audience, and that those users are directed to the correct versions of your site. Fortunately, there are a handful of relatively simple, easy methods you can use to insert and leverage these attributes on your website.

      In this post, we’ll introduce you to hreflang tags and explain why they’re important. Then we’ll walk you through how you can implement them on your website. Let’s jump in!

      An Introduction to Hreflang Tags

      First introduced by Google in 2011, the hreflang attribute specifies the language of the content on a page.

      You can use hreflang tags to target specific countries. They are handy for websites offering content in multiple languages.

      Hreflang tags are added to the <head> section of your web pages’ HTML code. Each tag should specify the language and country for a particular page.

      For instance, the tags might look similar to the following:

      <link rel="alternate" hreflang="x-default" href="http://example.com/">
      <link rel="alternate" hreflang="en" href="http://example.com/en/">
      <link rel="alternate" hreflang="de" href="http://example.com/de/">

      In the above example, the first line is the default page for users who don’t speak any of the languages specified. The second and third lines are for English and German speakers, respectively. The hreflang attribute specifies the language, and the href attribute specifies the URL.

      It’s important to note that hreflang tags are only used by search engines — they won’t be visible to users. Furthermore, hreflang tags are just one type of tag that can improve your website’s SEO and User Experience (UX). Other common tags include title tags and meta descriptions.

      Also, keep in mind that hreflang tags and canonical tags are not the same. A canonical tag is an HTML element that tells search engines which version of a page to index.

      A hreflang tag, on the other hand, tells search engines which version of a page to serve to users in different countries. Canonical tags solve duplicate content issues. By contrast, hreflang tags ensure that users who speak different languages are served the correct page versions.

      Why Hreflang Tags Are Important

      Hreflang tags are important for a handful of reasons. They affect both the UX and SEO of your website.

      Benefits of Using Hreflang Tags

      • Ensure that your pages are indexed correctly.
      • Direct users to the correct versions of your site.
      • Lead to higher traffic levels and more conversions.
      • Organize your website.
      • Localize your content for global users.
      • Prevent competition between alternate web pages.

      In addition, hreflang tags can improve your Click-Through Rate (CTR) from Search Engine Result Pages (SERPs). Users who see your site is available in their languages are more likely to click on it. This can lead to higher traffic levels and, ultimately, more conversions.

      How to Use Hreflang Tags (3 Technical Methods)

      There are three main methods for implementing the hreflang attribute on your website. Below, we’ll walk you through each one.

      However, regardless of your chosen method, it’s important to understand three basic elements of hreflang tags. First, the language attribute must be in a two-letter country code known as the ISO 639-1 format. ISO is short for International Organization for Standardization. This value consists of one language, and can be combined with an (optional) region.

      You can use the ISO 3166-1 region codes to specify a region. It’s important not to get the two confused or use them interchangeably. For example, the code for the Greek language is “el”, but the code for the Greece region is “gr”.

      The second rule is that each URL needs to have return links pointing to the canonical versions. For instance, if you have 40 languages, you would have hreflang links for 40 URLs.

      Finally, you need self links for your hreflang tag implementation to work. This means that each language version must also list itself using a self-referential hreflang tag, which the page points back to itself.

      Now, here are three methods for using hreflang tags!

      1. Use HTML Tags in <head> Sections

      As we mentioned earlier, one of the ways to implement hreflang tags on your website is to insert them in HTML tags. This is often the quickest and easiest method.

      However, this process can be time-consuming if you have a long list of languages. You would need to link each variation to every other variation. Additionally, WordPress would have to make multiple database calls to generate these links.

      Ultimately, this could slow down your site. Therefore, if you have a larger website or want to create a long list of languages, you might want to use the sitemap method instead (see Method 3).

      To use this HTML tag method, you must insert your hreflang tags into the <head> section of each of your pages. For instance, if you wanted to add English and Spanish versions for the United States version of your site, you would add the following code:

      <link rel="alternate" hreflang="x-default" href="http://example.com/">
      <link rel="alternate" hreflang="en" href="http://example.com/en/">
      <link rel="alternate" hreflang="es" href="http://example.com/de/">

      In the above example, the first line refers to the default page. The second and third are for English and Spanish speakers.

      2. Insert Hreflang Tags in Your HTTP Headers

      If you want to add hreflang tags in non-HTML pages, such as PDFs, you won’t have HTML code to place the tags in. When this is the case, you can use your HTTP headers instead.

      The code would look something like the following:

      <http://example.pdf>; rel="alternate";hreflang="x-default",
      <http:/example.pdf>; rel="alternate";hreflang="en",
      <http://example.pdf>; rel="alternate";hreflang="es",
      <http://example.pdf>; rel="alternate";hreflang="de"

      In this example, you’re adding variants for English, Spanish, and German. Each of the respective versions must be placed in the headers of each PDF file.

      Get Content Delivered Straight to Your Inbox

      Subscribe to our blog and receive great content just like this delivered straight to your inbox.

      3. Add Hreflang Tags to Your Sitemap

      The third method for implementing hreflang tags is using XML sitemap markup. This approach will let you add the hreflang attributes for all your site’s pages in one place.

      It can also help you avoid slowing down your page loading speed (which might happen if you place the tags in the head section of the pages). Plus, changing a sitemap can be significantly easier than modifying each page’s <head> tag.

      The sitemap method is similar to the HTML <head> tag method, except the xhtml:link attribute adds the hreflang annotations to each URL. Following the xhtml:link attribute at the front of your URL, you would add the alternative page versions, so your markup would look similar to the following:

      <url>
      <loc>https://example.com/link</loc>
      <xhtml:link rel=”alternate” hreflang=”en-us” href=”x-default”
      <xhtml:link rel=”alternate” hreflang=”en” href=”https://example.com/link/” />
      <xhtml:link rel=”alternate” hreflang=”es” href=”https://example.com/enlance/” />

      Here, you’ll see that each URL has a hreflang attribute and return links to the other URLs. A separate <url> element should be created for every URL. Each element must include a <loc> that indicates the page URL. The URLs also need a <xhtml:link rel=”alternate” hreflang=”supported_language-code”> element that lists each alternative version of the page.

      You can add all of the necessary tags to one file. While the order of the elements doesn’t matter, we recommend keeping them uniform, because this layout will make it easier to check for mistakes. You can submit your new sitemap to Google Search Console when you’re done.

      Tools That Generate Hreflang Tags Automatically

      The time it takes to generate and implement your hreflang tags can vary depending on how many versions you want to create and which method you use. However, a handful of tools can simplify and speed up the process. Let’s take a look at some of the most popular ones!

      Weglot Translate Plugin

      Weglot is a popular and reliable translation tool that can add hreflang Google tags and markup to your website:

      The Weglot Translate WordPress plugin

      Weglot can be a helpful solution if you’re a beginner and unfamiliar with working with code. It automatically identifies href tags in your code during translation, and changes the page header links.

      Hreflang Checker

      It’s crucial to always double-check your hreflang tags to ensure that they’re working correctly after you’ve placed them. The Hreflang Checker tool provided by Weglot can help simplify this process:

      The Hreflang Checker tool

      To use it, just copy and paste the URL that you want to check into the text field (make sure to include “http://” or “https://”) and select a search engine bot to emulate. Then click on the Test URL button. It will display a search results page showing your tags’ status.

      XML Sitemap Generator

      If you want to implement hreflang tags using the sitemap method, you can utilize the Hreflang XML Sitemap Generator Tool. It was created by Erudite, a digital marketing agency:

      The Erudite Hreflang Sitemap tool

      After creating an account using your email address, simply tell the tool where to send your sitemap and upload your CSV file, including a column for each language. Then Erudite’s tool will automatically generate an XML sitemap.

      Hreflang Tags Generator

      If you need help generating the link elements for your hreflang tags, you can use the Hreflang Tags Generator:

      the Hreflang Tags Generator tool

      This tool, created by Aleyda Solis, can streamline creating tags for your multi-language or multi-country website. You can generate these tags by either adding the (up to 50) URLs to tag in the given form, or uploading them via a CSV file. Again, you’ll need to make sure that there is one column for the URLs.

      Ahrefs Google Sheets Template

      Another tool that you can use is the Google Sheets template provided by Ahrefs:

      The Hreflang planner Google Sheets template

      Under the Setup tab, select your site’s language-locale (default language), then choose up to four additional variations. For instance, you could pick English as the Default language-locale, followed by Spanish, German, Chinese, and Russian as the alternatives.

      Next, under the URLs tab, you’ll find five columns, each with its own header cells that correspond to the language you chose in the Setup tab. There should also be an X-Default column.

      Now paste the URLs into the respective cells. Then, under the Results tab, you’ll find an auto-generated code for your XML sitemap. You can copy and paste everything in the A column into an XML document and upload it via Google Search Console.

      Tips and Best Practices for Using Hreflang Tags

      Now that you understand the basics of hreflang tags and their implementation, let’s discuss some tips for using them. Below are some key best practices to follow!

      Make Sure the Tags Are Bidirectional

      Hreflang tags operate in pairs, meaning that they are bidirectional. When you add a hreflang tag to an English page pointing to a Spanish version, you also need to ensure that the Spanish variant returns with a hreflang tag pointing to the English version.

      This setup tells search engines the relationship is in agreement, and that you control both pages. If two pages don’t point to each other, Google will ignore the tags.

      Specify the Default Page for Users Who Don’t Speak Any of the Specified Languages

      Specifying the default page for users who don’t speak any of your set languages is important. It will ensure that visitors are directed to the correct version of your site.

      You can do this by adding a tag with the language code “x-default”. It would look something like:

      <link rel=”alternate” hreflang=”x-default” href=”https://example.com/” />

      The default page will be used in situations where Google is unable to extract the language or region for users when it’s not specified or listed. Instead, the x-default page will ask users which language they prefer, then point them to the appropriate alternate version.

      Use Absolute URLs

      Absolute URLs are complete URLs that include the domain name. They are also the preferred type of URL to use with hreflang tags. They are less likely to be affected by changes on your website, and make it easier for search engines to index your pages correctly.

      It’s important to make sure that your hreflang tags contain absolute URLs. In other words, the code should look like “https://example.com/link” rather than “example.com/link”.

      Make Sure Your Hreflang Tags Are Valid and Correctly Formatted

      As we mentioned earlier, the correct ISO language and region codes must be used when creating your hreflang link attributes. Otherwise, you may encounter a message in Google Search Console informing you that your site doesn’t have any hreflang language tags.

      Remember to use the ISO language codes for language attributes and the region codes for geographical locations. For instance, while “kr” is for the region of South Korea, “ko” is the code for the Korean language.

      Keep Your Hreflang Tags Up To Date

      As you continue adding content and pages to your website, keeping up with your hreflang tags becomes more critical.

      Let’s say you add a new domain for a particular country. Then you’ll need to add the appropriate hreflang tags to your existing pages, and check to ensure that they point to the new domain.

      The same applies if you delete any language versions of your website. If you remove a language, you’ll need to delete or replace the hreflang tags pointing to it. Pointing to missing or incorrect URLs can hurt both your UX and SEO.

      Monitor Your Website for Errors

      Just as essential as keeping your hreflang tags updated is consistently monitoring your website for errors. This process includes checking your site’s source code to make sure that all necessary tags are present.

      You can use a tool such as Google Search Console to monitor your website more easily. This platform will help you verify whether your pages are being indexed correctly.

      Optimize Your Website for International Audiences

      Using hreflang tags can improve the SEO and UX of your website for international audiences. These attributes can help your site reach users in different countries, and ensure that the correct content is served in their native or preferred languages.

      As we discussed in this article, there are three methods you can use to implement hreflang tags:

      1. Add the attributes to the <head> section of each page.
      2. Place them in the HTTP headers of non-HTML content pages.
      3. Put the tags in your XML sitemap, so that all the attributes are in one place.

      Do you need help optimizing your multilingual website? Check out our DreamHost Pro Services to learn how we can take your site to the next level!

      International SEO Made Easy

      We take the guesswork (and actual work) out of growing your website traffic with SEO.

      shared hosting



      Source link

      Building an API Gateway to Get Out of the Monoliths


      How to Join

      This Tech Talk is free and open to everyone. Register below to get a link to join the live event.

      Format Date RSVP
      Presentation and Q&A October 15, 2020, 12:00–1:00 p.m. ET

      If you can’t join us live, the video recording will be published here as soon as it’s available.

      About the Talk

      As DigitalOcean grew, we got to a point where we couldn’t force all teams (now dozens of developers) to work on the same monoliths. We needed a solution that wouldn’t throw away all the investment that had already been made, but that would allow teams to get up and running fast with new applications without reinventing everything.

      We’ll discuss why we decided to go the API gateway route, the challenges we had to overcome along the way, the mistakes we’ve made and how you can avoid them when adding an API gateway to your microservices architecture or when you want to start to move away from monoliths.

      What You’ll Learn

      • What is an API gateway and how you can use it.
      • The challenges the Edge team at DigitalOcean had to overcome to make sure the migration into microservices wasn’t as bad as staying in the monolith.
      • The importance of communication and self-service solutions for infrastructure.

      This Talk is Designed For

      Developers that are starting to think about microservices or that are already running on microservices-based architectures and would like to get a better idea on what and how they can use API Gateways.

      Prerequisites

      An understanding of HTTP-based APIs.

      About the Presenter

      Maurício Linhares is a Senior Engineer on the Edge Team at DigitalOcean and was involved in building our API gateway from its beginnings. He’s passionate about distributed and functional programming, DevOps, and building infrastructure.

      To join the live Tech Talk, register here.



      Source link

      Como criar um API Gateway Usando o Ambassador no Kubernetes da DigitalOcean


      O autor escolheu a Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Ambassador é um API Gateway para aplicações nativas em nuvem que roteia o tráfego entre serviços heterogêneos e mantém fluxos de trabalho descentralizados. Ele atua como um único ponto de entrada e suporta tarefas como descoberta de serviço, gerenciamento de configuração, regras de roteamento e limitação de taxas de acesso. Ele também oferece grande flexibilidade e facilidade de configuração para seus serviços.

      O Envoy é um proxy de serviço de código aberto projetado para aplicações nativas em nuvem. No Kubernetes, o Ambassador pode ser usado para instalar e gerenciar a configuração do Envoy. O Ambassador suporta alterações na configuração com tempo zero de inatividade e integração com outros recursos, como autenticação, descoberta de serviços e service meshes.

      Neste tutorial, você configurará um Ambassador API Gateway em um cluster Kubernetes usando o Helm e o configurará para rotear o tráfego de entrada para vários serviços com base nas regras de roteamento. Você configurará essas regras para rotear o tráfego com base no nome do host ou no caminho para os serviços relevantes.

      Pré-requisitos

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

      • Um cluster Kubernetes na DigitalOcean com o kubectl configurado. Para criar um cluster Kubernetes na DigitalOcean, veja nosso guia Kubernetes Quickstart.

      • O gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalado em seu cluster. Complete os passos 1 e 2 do tutorial How To Install Software on Kubernetes Clusters with the Helm Package Manager

      • Um nome de domíno totalmente qualificado com pelo menos dois registros A configurados. Ao longo deste tutorial iremos utilizar svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio. Você pode seguir o guia DNS Quickstart para configurar seus registros na DigitalOcean.

      Passo 1 — Instalando o Ambassador

      Nesta seção, você instalará o Ambassador no seu cluster Kubernetes. O Ambassador pode ser instalado usando um chart do Helm ou passando um arquivo de configuração YAML para o comando kubectl.

      Nota: O Kubernetes na DigitalOcean tem o RBAC ativado por padrão, portanto, ao usar um arquivo de configuração YAML para instalação, é necessário garantir que você use o RBAC ativado. Você pode encontrar mais detalhes sobre o deployment do Ambassador no Kubernetes via YAML na documentação do Ambassador

      Para os propósitos deste tutorial, você usará um chart do Helm para instalar o Ambassador no seu cluster. Após seguir os pré-requisitos, você terá o Helm instalado em seu cluster.

      Para começar, execute o seguinte comando para instalar o Ambassador via Helm:

      • helm upgrade --install --wait ambassador stable/ambassador

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

      Output

      Release "ambassador" does not exist. Installing it now. NAME: ambassador LAST DEPLOYED: Tue Jun 18 02:15:00 2019 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Deployment NAME READY UP-TO-DATE AVAILABLE AGE ambassador 3/3 3 3 2m39s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE ambassador-7d55c468cb-4gpq9 1/1 Running 0 2m38s ambassador-7d55c468cb-jr9zr 1/1 Running 0 2m38s ambassador-7d55c468cb-zhm7l 1/1 Running 0 2m38s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer 10.245.183.114 139.59.52.164 80:30001/TCP,443:31557/TCP 2m40s ambassador-admins ClusterIP 10.245.46.43 <none> 8877/TCP 2m41s ==> v1/ServiceAccount NAME SECRETS AGE ambassador 1 2m43s ==> v1beta1/ClusterRole NAME AGE ambassador 2m41s ==> v1beta1/ClusterRoleBinding NAME AGE ambassador 2m41s ==> v1beta1/CustomResourceDefinition NAME AGE authservices.getambassador.io 2m42s consulresolvers.getambassador.io 2m41s kubernetesendpointresolvers.getambassador.io 2m42s kubernetesserviceresolvers.getambassador.io 2m43s mappings.getambassador.io 2m41s modules.getambassador.io 2m41s ratelimitservices.getambassador.io 2m42s tcpmappings.getambassador.io 2m41s tlscontexts.getambassador.io 2m42s tracingservices.getambassador.io 2m43s . . .

      Isso criará um deployment do Ambassador, um serviço e um balanceador de carga do Ambassador com os seus nodes do cluster Kubernetes conectados. Você precisará do IP do balanceador de carga para mapeá-lo para os registros A do seu domínio

      Para obter o endereço IP do balanceador de carga do seu Ambassador, execute o seguinte:

      • kubectl get svc --namespace default ambassador

      Você verá uma saída semelhante a:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer IP-do-seu-cluster seu-endereço-IP 80:30001/TCP,443:31557/TCP 8m4s

      Observe o IP externo seu-endereço-IP neste passo e mapeie os domínios (através de seu provedor de domínio) svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio para apontar para este endereço IP.

      Você pode ativar o HTTPS com o seu balanceador de carga na DigitalOcean usando os passos fornecidos em Como configurar a terminação SSL. É recomendável configurar a terminação TLS por meio do balanceador de carga. Outra maneira de configurar a terminação TLS é usar o Suporte TLS do Ambassador

      Você instalou o Ambassador no seu cluster Kubernetes usando o Helm, que criou um deployment do Ambassador com três réplicas no namespace padrão. Isso também criou um balanceador de carga com um IP público para rotear todo o tráfego em direção ao API Gateway. Em seguida, você criará deployments do Kubernetes para três serviços diferentes que você usará para testar esse API Gateway.

      Passo 2 — Configurando Deployments de Servidor Web

      Nesta seção, você criará três deployments para executar três containers de servidor web diferentes. Você criará arquivos YAML com definições de deployments do Kubernetes para os três diferentes containers de servidores web e fará o deploy usando o kubectl.

      Abra seu editor de texto preferido para criar seu primeiro deployment para um servidor web Nginx:

      Digite a seguinte configuração yaml no seu arquivo:

      svc1-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc1
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: nginx
            name: svc1
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
              name: svc1
          spec:
            containers:
            - name: nginx
              image: nginx:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container nginx:latest a ser deployada com 1 réplica, chamada svc1. O Deployment é definido para expor o cluster na porta 80.

      Salve e feche o arquivo.

      Em seguida, execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc1-deploy.yaml

      Você verá a saída confirmando a criação:

      Output

      deployment.extensions/svc1 created

      Agora, crie um segundo deployment de servidor web. Abra um arquivo chamado svc2-deploy.yaml com:

      Digite a seguinte configuração YAML no arquivo:

      svc2-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc2
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpd
            name: svc2
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpd
              name: svc2
          spec:
            containers:
            - name: httpd
              image: httpd:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpd a ser deployada com 1 réplica, chamada svc2.

      Salve e feche o arquivo.

      Execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc2-deploy.yaml

      Você verá esta saída:

      Output

      deployment.extensions/svc2 created

      Finalmente, para o terceiro deployment, abra e crie o arquivo svc3-deploy.yaml:

      Adicione as seguintes linhas ao arquivo:

      svc3-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc3
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpbin
            name: svc3
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpbin
              name: svc3
          spec:
            containers:
            - name: httpbin
              image: kennethreitz/httpbin:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpbin a ser deployada com 1 réplica, chamada svc3.

      Salve e feche o arquivo.

      Por fim, execute o seguinte comando para aplicar:

      • kubectl apply -f svc3-deploy.yaml

      E você verá a seguinte saída:

      Output

      deployment.extensions/svc3 created

      Você fez o deploy de três containers de servidor web usando deployments do Kubernetes. No próximo passo, você irá expor esses deployments ao tráfego da Internet.

      Nesta seção, você irá expor suas aplicações web à Internet, criando os Serviços Kubernetes com Anotações do Ambassador para configurar regras para rotear o tráfego para eles. Annotations ou Anotações no Kubernetes são uma maneira de adicionar metadados aos objetos. O Ambassador usa esses valores de anotação dos serviços para configurar suas regras de roteamento.

      Como lembrete, você precisa ter seus domínios (por exemplo: svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio) mapeados para o IP público do balanceador de carga em seus registros DNS.

      Defina um serviço Kubernetes para o deployment do svc1 com anotações do Ambassador, criando e abrindo este arquivo:

      Nota: O nome do mapeamento deve ser exclusivo para cada bloco de anotação do Ambassador. O mapeamento atua como um identificador para cada bloco de anotação e, se repetido, ele irá sobrepor o bloco de anotação mais antigo.

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.seu-domínio
            prefix: /
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Neste código YAML, você definiu um serviço Kubernetes svc1 usando anotações do Ambassador para mapear o nome do host svc1.seu-domínio para este serviço.

      Salve e saia do arquivo svc1-service.yaml e execute o seguinte para aplicar esta configuração:

      • kubectl apply -f svc1-service.yaml

      Você verá esta saída:

      Output

      service/svc1 created

      Crie seu segundo serviço Kubernetes para o deployment do svc2 com anotações do Ambassador. Este é outro exemplo de roteamento baseado em host com o Ambassador:

      Adicione a seguinte configuração ao arquivo:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc2-service.yaml. Aqui, você definiu outro serviço Kubernetes usando anotações do Ambassador para rotear o tráfego para svc2 quando qualquer solicitação é recebida pelo Ambassador com o valor do cabeçalho host como svc2.seu-domínio. Portanto, esse roteamento baseado em host permitirá que você envie uma solicitação ao subdomínio svc2.seu-domínio, que encaminhará o tráfego para o serviço svc2 e servirá sua solicitação a partir do servidor web httpd.

      Para criar este serviço, execute o seguinte:

      • kubectl apply -f svc2-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc2 created

      Crie um terceiro serviço Kubernetes para seu deployment svc3 e sirva-o através do caminho svc2.seu-domínio/bin. Isso configurará o roteamento baseado em caminho para o Ambassador:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc3-service.yaml e execute o seguinte para aplicar a configuração:

      • kubectl apply -f svc3-service.yaml

      Sua saída será:

      Output

      service/svc3 created

      Edite svc2-service.yaml para acrescentar o segundo bloco de anotação do Ambassador para rotear o /bin para o serviço svc3:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc3-service_mapping
            host: svc2.seu-domínio
            prefix: /bin
            service: svc3:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou o segundo bloco de anotação do Ambassador para configurar os caminhos que começam com /bin para mapear para o seu serviço Kubernetes svc3. Para rotear solicitações de svc2.seu-domínio/bin para svc3, você adicionou o segundo bloco de anotação aqui com o valor do host svc2.seu-domínio, que é o mesmo para os dois blocos. Portanto, o roteamento baseado em caminho permitirá que você envie uma solicitação ao svc2.seu-domínio/bin, que será recebido pelo serviço svc3 e servido pela aplicação httpbin neste tutorial.

      Agora execute o seguinte para aplicar as alterações:

      • kubectl apply -f svc2-service.yaml

      Você verá esta saída:

      Output

      service/svc2 configured

      Você criou os Serviços Kubernetes para os três deployments e adicionou regras de roteamento com base no host e no caminho com as anotações do Ambassador. Em seguida, você adicionará configuração avançada a esses serviços para configurar o roteamento, o redirecionamento e cabeçalhos personalizados.

      Passo 4 — Configurações Avançadas do Ambassador para Roteamento

      Nesta seção, você irá configurar os serviços com mais anotações do Ambassador para modificar cabeçalhos e configurar redirecionamento.

      Faça um curl no domínio svc1.seu-domínio e verifique os cabeçalhos de resposta:

      • curl -I svc1.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:41:00 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-envoy-upstream-service-time: 0

      Esta saída mostra os cabeçalhos recebidos do serviço roteado usando o Ambassador. Você adicionará cabeçalhos personalizados à sua resposta de serviço usando as anotações do Ambassador e validará a saída para os novos cabeçalhos adicionados.

      Para adicionar cabeçalhos personalizados à sua resposta de serviço, remova o cabeçalho x-envoy-upstream-service-time da resposta e adicione um novo cabeçalho de resposta x-geo-location: Brazil para o svc1. (Você pode alterar este cabeçalho conforme seus requisitos.)

      Edite o arquivo svc1-service.yaml:

      Atualize a anotação com as seguintes linhas destacadas:

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.example.com
            prefix: /
            remove_response_headers:
            - x-envoy-upstream-service-time
            add_response_headers:
              x-geo-location: Brazil
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Aqui você modificou o serviço svc1 para remover x-envoy-upstream-service-time e adicionou o cabeçalho x-geo-location: Brazil na resposta HTTP.

      Aplique as alterações que você fez:

      • kubectl apply -f svc1-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc1 configured

      Agora execute curl para validar os cabeçalhos atualizados na resposta do serviço:

      • curl -I svc1.seu-domínio

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:45:26 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-geo-location: Brazil

      Agora edite o svc3-service.yaml para redirecionar solicitações para o seu nome de host svc3.seu-domínio para o caminho svc2.seu-domínio/bin:

      Acrescente o bloco de anotação do Ambassador, conforme mostrado no YAML a seguir, e salve-o:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind:  Mapping
            name:  redirect_mapping
            host: svc3.seu-domínio
            prefix: /
            service: svc2.seu-domínio
            host_redirect: true
            path_redirect: /bin
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou host_redirect: true para configurar uma resposta de redirecionamento 301 de svc3 para svc2.seu-domínio/bin para o nome de host svc3.seu-domínio . O parâmetro host_redirect envia uma resposta de redirecionamento 301 para o cliente. Se não estiver definido, as requisições receberão respostas 200 HTTP em vez de respostas 301 HTTP.

      Agora execute o seguinte comando para aplicar essas alterações:

      • kubectl apply -f svc3-service.yaml

      Você verá uma saída semelhante a:

      Output

      service/svc3 configured

      Agora você pode verificar a resposta para svc3.seu-domínio usando curl:

      • curl -I svc3.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 301 Moved Permanently location: http://svc2.seu-domínio/bin date: Mon, 17 Jun 2019 21:52:05 GMT server: envoy transfer-encoding: chunked

      A saída é um cabeçalho HTTP para a resposta da solicitação ao serviço svc3.seu-domínio mostrando que a configuração de host_redirect: true na anotação do serviço forneceu corretamente o código de status HTTP: 301 Moved Permanently.

      Você configurou o serviço com anotações do Ambassador para modificar cabeçalhos HTTP e configurar redirecionamentos. Em seguida, você adicionará a configuração global ao serviço Ambassador API Gateway.

      Passo 5 — Definindo Configurações Globais do Ambassador

      Nesta seção, você editará o serviço Ambassador para adicionar a configuração global de compactação GZIP. A compactação GZIP compactará o tamanho dos assets HTTP e reduzirá os requisitos de largura de banda da rede, levando a tempos de resposta mais rápidos para os clientes web. Essa configuração afeta todo o tráfego que está sendo roteado pelo Ambassador API Gateway. Da mesma forma, você pode configurar outros módulos globais com o Ambassador, que permitem ativar comportamentos especiais para o serviço em nível global. Essas configurações globais podem ser aplicadas usando anotações do serviço Ambassador. Você pode consultar a documentação da Configuração Global do Ambassador para obter mais informações.

      O seguinte comando kubectl edit abrirá o editor padrão, que é o vim. Para usar o nano, por exemplo, você pode definir a variável de ambiente KUBE_EDITOR como nano:

      • export KUBE_EDITOR="nano"

      Edite o serviço Ambassador:

      • kubectl edit service ambassador

      Agora adicione as linhas destacadas a um novo bloco de anotação para compactação GZIP:

      Editing Ambassador Service

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Module
            name: ambassador
            config:
              service_port: 8080
            ---
            apiVersion: ambassador/v0
            kind:  Module
            name:  ambassador
            config:
              gzip:
                memory_level: 5
                min_content_length: 256
                compression_level: BEST
                compression_strategy: DEFAULT
                content_type:
                - application/javascript
                - application/json
                - text/html
                - text/plain
                disable_on_etag_header: false
                remove_accept_encoding_header: false
        creationTimestamp: "2019-06-17T20:45:04Z"
        labels:
          app.kubernetes.io/instance: ambassador
          app.kubernetes.io/managed-by: Tiller
          app.kubernetes.io/name: ambassador
          helm.sh/chart: ambassador-2.8.2
        name: ambassador
        namespace: default
        resourceVersion: "2153"
        . . .
      

      Você adicionou o bloco de anotação do Ambassador ao seu serviço Ambassador e configurou o GZIP globalmente para o API Gateway. Aqui você incluiu a configuração para controlar a quantidade de memória interna usada com memory_level, que pode ser um valor de 1 a 9. O compression_level configurado como BEST garante uma taxa de compactação mais alta, com o custo de uma latência mais alta. Com o min_content_length, você configurou o comprimento mínimo de resposta para 256 bytes. Para o content_type, você incluiu especificamente um conjunto de tipos de mídia (anteriormente MIME-types) que produz compactação. Finalmente, você adicionou as duas configurações finais como false para permitir a compactação.

      Você pode ler mais sobre a compactação GZIP na página sobre GZIP do Envoy.

      Quaisquer alterações neste serviço se aplicam como configurações globais para o API Gateway.

      Depois de sair do editor, você verá uma saída semelhante à seguinte:

      Output

      service/ambassador edited

      Verifique o svc1.seu-domínio usando o curl para ver o cabeçalho content-encoding tendo o valor gzip:

      • curl --compressed -i http://svc1.example.com

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 22:25:35 GMT content-type: text/html last-modified: Tue, 21 May 2019 14:23:57 GMT accept-ranges: bytes x-geo-location: Brazil vary: Accept-Encoding content-encoding: gzip transfer-encoding: chunked <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>

      Aqui você pode ver a página HTML padrão do Nginx com seu cabeçalho de resposta, mostrando que o content-encoding da resposta recebida é compactação gzip.

      Você adicionou a configuração global ao Ambassador para habilitar a configuração GZIP para respostas de tipos de conteúdo selecionados no API Gateway.

      Conclusão

      Você configurou com êxito um API Gateway para seu cluster Kubernetes usando o Ambassador. Agora você pode expor suas aplicações usando roteamento baseado em host e caminho, com cabeçalhos personalizados e a compactação GZIP global.

      Para obter mais informações sobre as anotações do Ambassador e parâmetros de configuração, leia a documentação oficial do Ambassador.



      Source link