One place for hosting & domains

      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

      Como Criar uma Imagem do Seu Ambiente Linux e Lançá-la na DigitalOcean


      Introdução

      O recurso Custom Images ou Imagens Personalizadas da DigitalOcean lhe permite trazer seu disco virtual personalizado de Linux e Unix-like de um ambiente local ou de outra plataforma de nuvem para a DigitalOcean e utilizá-lo para iniciar Droplets na DigitalOcean.

      Como descrito na documentação do Custom Images, os seguintes tipos de imagens são suportados nativamente pela ferramenta de upload do Custom Images:

      Embora imagens com formato ISO não sejam oficialmente suportadas, você pode aprender como criar e carregar uma imagem compatível usando o VirtualBox seguindo o tutorial How to Create a DigitalOcean Droplet from an Ubuntu ISO Format Image.

      Se você ainda não tem uma imagem compatível para carregar na DigitalOcean, você pode criar e comprimir uma imagem de disco do seu sistema Unix-like ou Linux, desde que ela tenha o software e os drivers de pré-requisitos instalados.

      Vamos começar assegurando que sua imagem atende ao requisitos do Custom Images. Para fazer isso, vamos configurar o sistema e instalar alguns pré-requisitos de software. Depois, vamos criar a imagem utilizando o utilitário de linha de comando dd e comprimí-la usando o gzip. Na sequência, vamos fazer o upload desse arquivo de imagem compactado para o DigitalOcean Spaces, de onde podemos importá-lo como uma Imagem Personalizada. Finalmente, vamos inicializar um droplet usando a imagem enviada

      Pré-requisitos

      Se possível, você deve usar uma das imagens fornecidas pela DigitalOcean como base, ou uma imagem de nuvem oficial fornecida pela distribuição como o Ubuntu Cloud. Então você pode instalar softwares e aplicaçoes em cima dessa imagem de base para fazer uma nova imagem usando ferramentas como o Packer e o VirtualBox. Muitos provedores de nuvem e ambientes de virtualização também fornecem ferramentas para exportar discos virtuais para um dos formatos compatíveis listados acima, assim, se possível, você deve usá-las para simplificar o processo de importação. Nos casos em que você precisa criar manualmente uma imagem de disco do seu sistema você pode seguir as instruções nesse guia. Observe que essas instruções só foram testadas com um sistema Ubuntu 18.04 e as etapas podem variar dependendo do sistema operacional e da configuração do seu servidor.

      Antes de começar com este tutorial, você deve ter o seguinte disponível para você:

      • Um sistema Linux ou Unix-like que atenda a todos os requisitos listados na documentação de produto do Custom Images. Por exemplo, seu disco de boot deve ter:

        • Um tamanho máximo de 100GB
        • Um tabela de partição MBR ou GPT com um gerenciador de boot grub
        • Drivers do VirtIO instalados
      • Um usuário não-root com privilégios administrativos disponível para você no sistema que você está fazendo imagem. Para criar um novo usuário e conceder a ele privilégios administrativos no Ubuntu 18.04, siga nosso tutorial de Configuração Inicial de Servidor com Ubuntu 18.04. Para aprender como fazer isto no Debian 9, consulte Configuração Inicial de Servidor com Debian 9.

      • Um dispositivo de armazenamento adicional usado para armazenar a imagem de disco criada neste guia, preferivelmente tão grande quanto o disco que está sendo copiado. Isso pode ser um volume de armazenamento em blocos anexado, um drive externo USB, um espaço em disco adicional, etc.

      • Um Space na DigitalOcean e o utilitário de transferência de arquivos s3cmd configurado para uso com o seu Space. Para aprender como criar um Space, consulte o Guia Rápido do Spaces. Para aprender como configurar o s3cmd para uso com o seu Space, consulte o Guia de Configuração do s3cmd 2.x.

      Passo 1 — Instalando o Cloud-Init e ativando o SSH

      Para começar, vamos instalar o pacote de inicialização do cloud-Init. O cloud-init é um conjunto de scripts que executam no boot para configurar certas propriedades da instância de nuvem como a localidade padrão, hostname, chaves SSH e dispositivos de rede.

      Os passos para a instalação do cloud-init vão variar dependendo do sistema operacional que você instalou. Em geral, o pacote cloud-init deve estar disponível no gerenciador de pacotes do seu SO, assim se você não estiver utilizando uma distribuição baseada no Debian, você deve substituir o apt nos seguintes passos pelo seu comando do gerenciador de pacotes específico da distribuição.

      Instalando o cloud-init

      Neste guia, vamos utilizar um servidor Ubuntu 18.04 e então usaremos o apt para baixar e instalar o pacote cloud-init. Observe que o cloud-init pode já estar instalado em seu sistema (algumas distribuições Linux instalam o cloud-initpor padrão). Para verificar, efetue o login em seu servidor e execute o seguinte comando:

      Se você vir a seguinte saída, o cloud-init já foi instalado no seu servidor e você pode continuar configurando-o para uso com a DigitalOcean:

      Output

      usage: /usr/bin/cloud-init [-h] [--version] [--file FILES] [--debug] [--force] {init,modules,single,query,dhclient-hook,features,analyze,devel,collect-logs,clean,status} ... /usr/bin/cloud-init: error: the following arguments are required: subcommand

      Se, em vez disso, você vir o seguinte, você precisa instalar o cloud-init:

      Output

      cloud-init: command not found

      Para instalar o cloud-init, atualize o índice de pacotes e em seguida instale o pacote usando o apt:

      • sudo apt update
      • sudo apt install cloud-init

      Agora que instalamos o cloud-init, vamos configurá-lo para uso com a DigitalOcean, assegurando que ele utilize o datasource ConfigDrive. O datasource do cloud-init determina como o cloud-init procurará e atualizará a configuração e os metadados da instância. Os Droplets da DigitalOcean usam o datasource ConfigDrive, por isso, vamos verificar se ele vem em primeiro lugar na lista de datasources que o cloud-init pesquisa sempre que o Droplet inicializa.

      Reconfigurando o cloud-init

      Por padrão, no Ubuntu 18.04, o cloud-init configura a si mesmo para utilizar o datasource NoCloud primeiro. Isso irá causar problemas ao executar a imagem na DigitalOcean, por isso precisamos reconfigurar o cloud-init para utilizar o datasource ConfigDdrive e garantir que o cloud-init execute novamente quando a imagem é lançada na DigitalOcean.

      A partir da linha de comando, navegue até o diretório /etc/cloud/cloud.cfg.d:

      • cd /etc/cloud/cloud.cfg.d

      Use o comando ls para listar os arquivos de configuração do cloud-init presentes dentro do diretório:

      Output

      05_logging.cfg 50-curtin-networking.cfg 90_dpkg.cfg curtin-preserve-sources.cfg README

      Dependendo da sua instalação, alguns desses arquivos podem não estar presentes. Se presente, exclua o arquivo 50-curtin-networking.cfg, que configura as interfaces de rede para seu servidor Ubuntu. Quando a imagem é lançada na DigitalOcean, o cloud-init irá executar e reconfigurar estas interfaces automaticamente, portanto esse arquivo não é necessário. Se esse arquivo não for excluído, o Droplet da DigitalOcean criado a partir dessa imagem Ubuntu terá suas interfaces configuradas incorretamente e não serão acessíveis pela internet:

      • sudo rm 50-curtin-networking.cfg

      Em seguida, vamos executar dpkg-reconfigure cloud-init para remover o datasource NoCloud, garantindo que o cloud-init procure e localize o datasource ConfigDrive usado na DigitalOcean:

      • sudo dpkg-reconfigure cloud-init

      Você deve ver o seguinte menu gráfico:

      O datasource NoCloud está inicialmente destacado. Pressione ESPAÇO para desmarcá-lo e, em seguida, pressione ENTER.

      Finalmente, navegue até /etc/netplan:

      Remova o arquivo 50-cloud-init.yaml, que foi gerado a partir do arquivo de rede cloud-init que removemos anteriormente:

      • sudo rm 50-cloud-init.yaml

      A etapa final é garantir que limpemos a configuração da execução inicial do cloud-init para que ela seja executada novamente quando a imagem for lançada na DigitalOcean.

      Para fazer isso, execute cloud-init clean:

      Neste ponto você instalou e configurou o cloud-init para uso com a DigitalOcean. Agora você pode seguir para ativar o acesso SSH ao seu droplet.

      Ativar o Acesso SSH

      Depois que você instalou e configurou o cloud-init, o próximo passo é assegurar que você tenha um usuário e senha de administrador não-root disponível para você em sua máquina, conforme descrito nos pré-requisitos. Este passo é essencial para diagnosticar quaisquer erros que possam surgir após o upload da sua imagem e o lançamento do seu droplet. Se uma configuração de rede preexistente ou uma configuração incorreta do cloud-init tornar o seu Droplet inacessível na rede, você pode utilizar esse usuário em combinação ao Console do Droplet da DigitalOcean para acessar seu sistema e diagnosticar quaisquer problemas que possam ter surgido.

      Depois que você tiver configurado seu usuário administrativo não-root, a etapa final é garantir que você tenha um servidor SSH instalado e executando. O SSH geralmente vem pré-instalado em muitas distribuições populares do Linux. O procedimento para verificar se um processo está executando irá variar dependendo do sistema operacional do seu servidor. Se você não tiver certeza de como fazer isso, consulte a documentação do seu sistema operacional sobre o gerenciamento de serviços. No Ubuntu, você pode verificar que o SSH está funcionando utilizando este comando:

      Você deve ver a seguinte saída:

      Output

      ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2018-10-22 19:59:38 UTC; 8 days 1h ago Docs: man:sshd(8) man:sshd_config(5) Process: 1092 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 1115 (sshd) Tasks: 1 (limit: 4915) Memory: 9.7M CGroup: /system.slice/ssh.service └─1115 /usr/sbin/sshd -D

      Se o SSH não estiver em execução, você pode instalá-lo usando o apt (nas distribuições baseadas em Debian):

      • sudo apt install openssh-server

      Por padrão, o servidor SSH vai iniciar no boot a menos que esteja configurado de outra forma. Isso é desejável ao executar o sistema na nuvem, já que a DigitalOcean pode copiar automaticamente sua chave pública e conceder acesso SSH imediato ao seu Droplet após a criação.

      Depois que você criou um usuário administrativo não-root, ativou o SSH, e instalou o cloud-init, você está pronto para continuar criando uma imagem do seu disco de boot.

      Passo 2 — Criando uma Imagem de Disco

      Neste passo, vamos criar uma imagem de disco de formato RAW usando o utilitário de linha de comando dd, e compactá-lo usando o gzip. Vamos então carregar a imagem para o Spaces da DigitalOcean usando o s3cmd.

      Para começar, efetue login em seu servidor, e inspecione o arranjo de dispositivos de bloco para o seu sistema usando lsblk:

      Você deverá ver algo como o seguinte:

      Output

      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 12.7M 1 loop /snap/amazon-ssm-agent/495 loop1 7:1 0 87.9M 1 loop /snap/core/5328 vda 252:0 0 25G 0 disk └─vda1 252:1 0 25G 0 part / vdb 252:16 0 420K 1 disk

      Nesse caso, observamos que nosso disco principal de boot é o /dev/vda, um disco de 25GB, e a partição primária, montada no /, é a /dev/vda1. Na maioria dos casos o disco contendo a partição montada no / será o disco de origem para a imagem. Vamos usar o dd para criar uma imagem do /dev/vda.

      Neste ponto, você deve decidir onde você quer armazenar a imagem de disco. Uma opção é anexar outro dispositivo de armazenamento em bloco, de preferência tão grande quanto o disco que você está fazendo a imagem. Em seguida, você pode salvar a imagem neste disco temporário anexado e enviá-la para o Spaces da DigitalOcean.

      Se você tem acesso físico ao servidor, você pode adicionar um drive adicional à máquina ou anexar outro dispositivo de armazenamento, como um disco USB externo.

      Outra opção, que iremos demonstrar nesse guia, é copiar a imagem por SSH para uma máquina local, a partir da qual você pode enviá-la para o Spaces.

      Independentemente do método escolhido, verifique se o dispositivo de armazenamento no qual você salvou a imagem compactada tem espaço livre suficiente. Se o disco que você está fazendo imagem está quase vazio, você pode esperar que o arquivo de imagem compactado seja significativamente menor que o disco original.

      Atenção: Antes de rodar o seguinte comando dd, certifique-se de que todos os aplicativos críticos tenham sido parados e seu sistema esteja o mais folgado possível. Copiar um disco sendo usado ativamente pode resultar em alguns arquivos corrompidos, portanto, certifique-se de interromper qualquer operação que use muitos dados e encerre o máximo possível de aplicativos em execução.

      Opção 1: Criando a Imagem Localmente

      A sintaxe para o comando dd que vamos executar é a seguinte:

      • dd if=/dev/vda bs=4M conv=sparse | pv -s 25G | gzip > /mnt/tmp_disk/ubuntu.gz

      Neste caso, estamos selecionando /dev/vda como o disco de entrada para se fazer imagem, e definindo o tamanho dos blocos de entrada/saída para 4MB (sendo que o padrão é 512 bytes). Isso geralmente acelera um pouco as coisas. Além disso, estamos usando a flag conv=sparse para minimizar o tamanho do arquivo de saída pulando o espaço vazio. Para aprender mais sobre parâmetros do dd, consulte a sua manpage.

      Em seguida, fazemos um pipe da saída para o utilitário de visualização de pipe pv para que possamos acompanhar o progresso da transferência visualmente (esse pipe é opcional e requer a instalação do pv usando o gerenciador de pacotes). Se você sabe o tamanho do disco inicial (nesse caso é 25GB), você pode adicionar -s 25G ao pipe do pv para ter uma estimativa de quando a transferência será concluída.

      Fazemos então um pipe de tudo isso para o gzip e salvamos em um arquivo chamado ubuntu.gz no volume de armazenamento de bloco temporário que anexamos ao servidor. Substitua /mnt/tmp_disk com o caminho para o dispositivo de armazenamento externo que você anexou ao seu servidor.

      Opção 2: Criando a Imagem via SSH

      Em vez de provisionar armazenamento adicional para sua máquina remota, você também pode executar a cópia via SSH se tiver espaço em disco suficiente disponível na sua máquina local. Observe que, dependendo da largura de banda disponível para você, isso pode ser lento e você pode incorrer em custos adicionais para a transferência de dados pela rede.

      Para copiar e compactar o disco via SSH, execute o seguinte comando em sua máquina local:

      • ssh usuário_remoto@ip_do_seu_servidor "sudo dd if=/dev/vda bs=4M conv=sparse | gzip -1 -" | dd of=ubuntu.gz

      Neste caso, estamos fazendo SSH para o nosso servidor remoto executando o comando dd lá, e fazendo um pipe da saída para o gzip. Em seguida, transferimos a saída do gzip pela rede e a salvamos localmente como ubuntu.gz. Certifique-se de que você tenha o utilitário dd disponível em sua máquina local antes de executar esse comando:

      Output

      /bin/dd

      Crie o arquivo de imagem compactado usando qualquer um dos métodos acima. Isso pode levar várias horas, dependendo do tamanho do disco que você está criando e do método que você está usando para criar a imagem.

      Depois de criar o arquivo de imagem compactado, você pode passar a enviá-lo para seus Spaces da DigitalOcean usando o s3cmd.

      Passo 3 — Fazendo Upload da Imagem para Spaces e Custom Images

      Conforme descrito nos pré-requisitos, você deve ter o s3cmd instalado e configurado para uso com seu Space da DigitalOcean na máquina que contém sua imagem compactada.

      Localize o arquivo de imagem compactado e faça o upload dele para seu Space usando o s3cmd:

      Nota: Você deve substituir your_space_name pelo nome do seu Space e não a sua URL. Por exemplo, se a URL do seu Space é https://example-space-name.nyc3.digitaloceanspaces.com, então o nome do seu Space é example-space-name.

      • s3cmd put /caminho_da_imagem/ubuntu.gz s3://your_space_name

      Quando o upload estiver concluído, navegue até seu Space usando o Painel de Controle da DigitalOcean, e localize a imagem na lista de arquivos. Tornaremos a imagem publicamente acessível temporariamente para que o Custom Images possa acessá-la e salvar uma cópia.

      À direita da lista de imagens, clique no menu suspenso More e, em seguida, clique em Manage Permissions:

      Em seguida, clique no botão de opção ao lado de Public e clique em Update para tornar a imagem publicamente acessível.

      Atenção: Sua imagem estará temporariamente acessível publicamente para qualquer pessoa com o caminho do seu Space durante este processo. Se você gostaria de evitar tornar sua imagem temporariamente pública, você pode criar sua Imagem Personalizada usando a API da DigitalOcean. Certifique-se de definir sua imagem como Private usando o procedimento acima depois que sua imagem for transferida com sucesso para o Custom Images.

      Busque a URL do Spaces para sua imagem passando o mouse sobre o nome da imagem no Painel de controle, e clique em Copy URL na janela que aparece.

      Agora, navegue para Images na barra de navegação à esquerda, e depois para Custom Images.

      A partir daqui, envie sua imagem usando esta URL, conforme detalhado na Documentação de Produto do Custom Images.

      Você pode então criar um Droplet a partir desta imagem. Observe que você precisa adicionar uma chave SSH ao Droplet na criação. Para aprender como fazer isso, consulte How to Add SSH Keys to Droplets.

      Uma vez que o seu Droplet inicializa, se você puder fazer SSH nele, você lançou com sucesso a sua Imagem Personalizada como um Droplet da DigitalOcean.

      Fazendo Debug

      Se você tentar fazer SSH no seu Droplet e não conseguir conectar, certifique-se de que sua imagem atenda aos requisitos listados e tenha o cloud-init e o SSH instalados e configurados corretamente. Se você ainda não conseguir acessar o Droplet, você pode tentar utilizar o Console do Droplet da DigitalOcean e o usuário não-root que você criou anteriormente para explorar o sistema e fazer o debug das configurações de sua rede, do cloud-init e do SSH. Outra maneira de fazer o debug de sua imagem é usar uma ferramenta de virtualização como o Virtualbox para inicializar sua imagem de disco dentro de uma máquina virtual, e fazer o debug da configuração do seu sistema a partir da VM.

      Conclusão

      Neste guia, você aprendeu como criar uma imagem de disco de um sistema Ubuntu 18.04 usando o utilitário de linha de comando dd e fazer o upload dela para a DigitalOcean como uma Custom Image ou Imagem Personalizada a partir da qual você pode lançar Droplets.

      As etapas neste guia podem variar dependendo do seu sistema operacional, do hardware existente e da configuração do kernel, mas, em geral, as imagens criadas a partir de distribuições populares do Linux devem funcionar usando esse método. Certifique-se de seguir cuidadosamente as etapas de instalação e configuração do cloud-init e de garantir que o sistema atenda a todos os requisitos listados na seção pré-requisitos acima.

      Para aprender mais sobre Custom Images, consulte a documentação de produto do Custom Images.

      Por Hanif Jetha



      Source link

      Como Criar um Pull Request no GitHub


      Introdução

      Livre e open-source, o Git é um sistema de controle de versão distribuído que torna os projetos de software colaborativo mais gerenciáveis. Muitos projetos mantém seus arquivos em um repositório Git, e sites como o Github tornaram o compartilhamento e a contribuição para o código simples e efetiva.

      Projetos open-source que são hospedados em repositórios públicos beneficiam-se de contribuições feitas pela ampla comunidade de desenvolvedores através de pull requests, que solicitam que um projeto aceite as alterações feitas em seu repositório de código.

      Este tutorial vai guiá-lo no processo de realizar um pull request para um repositório Git através da linha de comando para que você possa contibuir com projetos de software open-source.

      Pré-requisitos

      Você deve ter o Git instalado em sua máquina local. Você pode verificar se o Git está instalado em seu computador e passar pelo processo de instalação para o seu sistema operacional, seguindo este guia.

      Você também precisará ter ou criar uma conta no GitHub. Você pode fazer isso através do website do GitHub, github.com, e pode ou efetuar login ou criar sua conta.

      Finalmente, você deve identificar um projeto de software open-source para contribuir. Você pode se familiarizar mais com os projetos open-source lendo essa introdução.

      Crie uma Cópia do Repositório

      Um repositório, ou repo para abreviar, é essencialmente a pasta principal do projeto. O repositório contém todos os arquivos relevantes do projeto, incluindo documentação, e também armazena o histórico de revisão para cada arquivo. No GitHub, os repositórios podem ter vários colaboradores e podem ser públicos ou privados.

      Para trabalhar em um projeto open-source, primeiro você precisará criar sua própria cópia do repositório. Para fazer isso, você deve fazer um fork do repositório e então fazer a clonagem dele para que você tenha uma cópia de trabalho local.

      Faça o Fork do Repositório

      Você pode fazer um fork de um repositório navegando até a URL GitHub do projeto open-source que você gostaria de contribuir.

      As URLs de repositórios GitHub irão referenciar o nome do usuário associado com o proprietário do repositório, bem como o nome do repositório. Por exemplo, DigitalOcean Community é o proprietário do repositório do projeto cloud_haiku, assim a URL GitHub para esse projeto é:

      https://github.com/do-community/cloud_haiku
      

      No exemplo acima, do-community é o nome do usuário e cloud_haiku é o nome do repositório.

      Um vez que você identificou o projeto que você gostaria de contribuir, você pode navegar até a URL, que estará formatada da seguinte forma:

      https://github.com/nome-do-usuário/repositório
      

      Ou você pode procurar o projeto usando a barra de pesquisa do GitHub.

      Quando você estiver na página principal do repositório, você verá um botão “Fork” no seu lado superior direito da página, abaixo do seu ícone de usuário:

      Clique no botão fork para iniciar o processo de fork. Dentro da janela do seu navegador, você receberá um feedback assim:

      Quando o processo estiver concluído, o seu navegador irá para uma tela semelhante à imagem do repositório acima, exceto que no topo você verá seu nome de usuário antes do nome do repositório, e na URL ela também mostrará seu nome de usuário antes do nome do repositório.

      Então, no exemplo acima, em vez de do-community / cloud_haiku na parte superior da página, você verá seu-nome-de-usuário / cloud_haiku, e a nova URL será parecida com isto:

      https://github.com/seu-nome-de-usuário/cloud_haiku
      

      Com o fork do repositório realizado, você está pronto para cloná-lo para que você tenha uma cópia de trabalho local da base de código.

      Clone o Repositório

      Para criar sua própria cópia local do repositório com o qual você gostaria de contribuir, primeiro vamos abrir uma janela de terminal.

      Vamos utilizar o comando git clone juntamente com a URL que aponta para o seu fork do repositório.

      Esta URL será semelhante à URL acima, exceto que agora ela irá terminar com .git. No exemplo do cloud_haiku acima, a URL ficará assim:

      https://github.com/seu-nome-de-usuário/cloud_haiku.git
      

      Você pode, alternativamente, copiar a URL usando o botão verde “Clone or download” da página do seu repositório que você acabou de fazer fork. Depois de clicar no botão, você poderá copiar a URL clicando no botão do fichário ao lado da URL:

      Uma vez que tenhamos a URL, estamos prontos para clonar o repositório. Para fazer isto, vamos combinar o comando git clone com a URL do repositório a partir da linha de comando em uma janela de terminal:

      • git clone https://github.com/seu-nome-de-usuário/repositório.git

      Agora que você tem uma cópia local do código, podemos passar para a criação de uma nova branch ou ramificação na qual iremos trabalhar com o código.

      Crie uma Nova Branch

      Sempre que você trabalha em um projeto colaborativo, você e outros programadores que contribuem para o repositório terão ideias diferentes para novos recursos ou correções de uma só vez. Alguns desses novos recursos não levarão tempo significativo para serem implementados, mas alguns deles estarão em andamento. Por isso, é importante ramificar o repositório para que você possa gerenciar o fluxo de trabalho, isolar seu código e controlar quais recursos serão retornados à branch principal do repositório do projeto.

      A branch principal padrão de um repositório de projeto é geralmente chamada de master branch. Uma prática comum recomendada é considerar qualquer coisa na branch master como sendo passível de se fazer o deploy para outras pessoas usarem a qualquer momento.

      Ao criar uma nova branch, é muito importante que você a crie fora da branch master. Você também deve se certificar de que o nome da sua branch é descritivo. Em vez de chamá-la de minha-branch, você deve usar frontend-hook-migration ou Corrigir erros de digitação na documentação.

      Para criar nossa branch, na nossa janela de terminal, vamos mudar nosso diretório para que estejamos trabalhando no diretório do repositório. Certifique-se de usar o nome real do repositório (como cloud_haiku) para mudar para esse diretório.

      Agora, vamos criar nossa nova branch com o comando git branch. Certifique-se de nomeá-la de maneira descritiva para que outras pessoas trabalhando no projeto entendam no que você está trabalhando.

      Agora que nossa nova branch está criada, podemos mudar para nos certificar de que estamos trabalhando nessa branch usando o comando git checkout:

      Depois de inserir o comando git checkout, você receberá a seguinte saída:

      Output

      Switched to branch nova-branch

      Alternativamente, você pode condensar os dois comandos acima, criando e mudando para a nova branch, com o seguinte comando e com a flag -b:

      • git checkout -b nova-branch

      Se você quiser mudar de volta para o master, você irá usar o comando checkout com o nome da branch master:

      O comando checkout vai lhe permitir alternar entre várias branches, para que você possa trabalhar em vários recursos de uma só vez.

      Neste ponto, agora você pode modificar arquivos existentes ou adicionar novos arquivos ao projeto em sua própria branch.

      Faça Alterações Localmente

      Depois de modificar os arquivos existentes ou adicionar novos arquivos ao projeto, você pode adicioná-los ao seu repositório local, o que podemos fazer com o comando git add. Vamos adicionar a flag -A para adicionar todas as alterações que fizemos:

      Em seguida, queremos registrar as alterações que fizemos no repositório com o comando git commit.

      A mensagem de commit é um aspecto importante da sua contribuição de código; ela ajuda os outros contribuidores a entenderem completamente a mudança que você fez, por que você fez e o quanto é importante. Adicionalmente, as mensagens de commit fornecem um registro histórico das mudanças para o projeto em geral, ajudando os futuros contribuidores ao longo do caminho.

      Se tivermos uma mensagem muito curta, podemos gravar isso com a flag -m e a mensagem entre aspas:

      • git commit -m "Corrigidos erros de digitação na documentação"

      Mas, a menos que seja uma mudança muito pequena, é bem provável que incluiremos uma mensagem de confirmação mais longa para que nossos colaboradores estejam totalmente atualizados com nossa contribuição. Para gravar esta mensagem maior, vamos executar o comando git commit que abrirá o editor de texto padrão:

      Se você gostaria de configurar seu editor de texto padrão, você pode fazê-lo com o comando git config e definir o nano como editor padrão, por exemplo:

      git config --global core.editor "nano"
      

      Ou o vim:

      • git config --global core.editor "vim"

      Depois de executar o comando git commit, dependendo do editor de texto padrão que você está usando, sua janela de terminal deve exibir um documento pronto para edição que será semelhante a este:

      GNU nano 2.0.6 File: …username/repository/.git/COMMIT_EDITMSG

      
      # Please enter the commit message for your changes. Lines starting
      # with '#' will be ignored, and an empty message aborts the commit.
      # On branch nova-branch
      # Your branch is up-to-date with 'origin/new-branch'.
      #
      # Changes to be committed:
      #       modified:   novo-recurso.py
      #
      

      Abaixo dos comentários introdutórios, você deve adicionar a mensagem de commit ao arquivo de texto.

      Para escrever uma mensagem útil no commit, você deve incluir um sumário na primeira linha com cerca de 50 caracteres. Abaixo disso, e dividido em seções de fácil entendimento, você deve incluir uma descrição que indique o motivo pelo qual você fez essa alteração, como o código funciona, e informações adicionais que irão contextualizar e esclarecer o código para que outras pessoas revisem o trabalho ao mesclá-lo. Tente ser o mais útil e proativo possível para garantir que os responsáveis pela manutenção do projeto possam entender totalmente sua contribuição.

      Depois de salvar e sair do arquivo de texto da mensagem de commit, você poderá verificar o commit que o git estará fazendo com o seguinte comando:

      Dependendo das alterações que você fez, você receberá uma saída parecida com esta:

      Output

      On branch nova-branch Your branch is ahead of 'origin/nova-branch' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working directory clean

      Nesse ponto você pode usar o comando git push para fazer o push das alterações para a branch atual do repositório que você fez o fork:

      • git push --set-upstream origin nova-branch

      O comando irá lhe fornecer uma saída para que você saiba do progresso e será semelhante ao seguinte:

      Output

      Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/seu-nome-de-usuário /repositório .git a1f29a6..79c0e80 nova-branch -> <^>nova-branch< Branch nova-branch set up to track remote branch nova-branch from origin.

      Agora você pode navegar até o repositório que você fez o fork na sua página web do GitHub e alternar para a branch que você acabou de fazer push para ver as alterações que você fez diretamente no navegador.

      Nesse ponto, é possível fazer um pull request para o repositório original, mas se ainda não o fez, certifique-se de que seu repositório local esteja atualizado com o repositório upstream.

      Atualize o Repositório Local

      Enquanto você estiver trabalhando em um projeto ao lado de outros colaboradores, é importante que você mantenha seu repositório local atualizado com o projeto, pois você não deseja fazer um pull request de um código que cause conflitos. Para manter sua cópia local da base de código atualizada, você precisará sincronizar as alterações.

      Primeiro vamos passar pela configuração de um repositório remoto para o fork, e então, sincronizar o fork.

      Configure um Repositório Remoto para o Fork

      Repositórios remotos permitem que você colabore com outras pessoas em um projeto Git. Cada repositório remoto é uma versão do projeto que está hospedada na Internet ou em uma rede à qual você tem acesso. Cada repositório remoto deve ser acessível a você como somente leitura ou como leitura-gravação, dependendo dos seus privilégios de usuário.

      Para poder sincronizar as alterações feitas em um fork com o repositório original com o qual você está trabalhando, você precisa configurar um repositório remoto que faça referência ao repositório upstream. Você deve configurar o repositório remoto para o repositório upstream apenas uma vez.

      Primeiro, vamos verificar quais servidores remotos você configurou. O comando git remote listará qualquer repositório remoto que você já tenha especificado, então se você clonou seu repositório como fizemos acima, você verá pelo menos o repositório origin, que é o nome padrão fornecido pelo Git para o diretório clonado.

      A partir do diretório do repositório em nossa janela de terminal, vamos usar o comando git remote juntamente com a flag -v para exibir as URLs que o Git armazenou junto com os nomes curtos dos repositórios remotos relevantes (como em "origin"):

      Como clonamos um repositório, nossa saída deve ser semelhante a isso:

      Output

      origin https://github.com/seu-nome-de-usuário/repositório-forked.git (fetch) origin https://github.com/seu-nome-de-usuário/repositório-forked.git (push)

      Se você configurou anteriormente mais de um repositório remoto, o comando git remote -v fornecerá uma lista de todos eles.

      Em seguida, vamos especificar um novo repositório remoto upstream para sincronizarmos com o fork. Este será o repositório original do qual fizemos o fork. Faremos isso com o comando git remote add.

      • git remote add upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git

      Nesse exemplo, upstream é o nome abreviado que fornecemos para o repositório remoto, já que em termos do Git, “Upstream” refere-se ao repositório do qual nós clonamos. Se quisermos adicionar um ponteiro remoto ao repositório de um colaborador, podemos fornecer o nome de usuário desse colaborador ou um apelido abreviado para o nome abreviado.

      Podemos verificar que nosso ponteiro remoto para o repositório upstream foi adicionado corretamente usando o comando git remote -v novamente a partir do diretório do repositório:

      Output

      origin https://github.com/seu-nome-de-usuário/repositório-forked.git (fetch) origin https://github.com/seu-nome-de-usuário/repositório-forked.git (push) upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git (fetch) upstream https://github.com/nome-de-usuário-do-proprietário-original/repositório-original.git (push)

      Agora você pode se referir ao upstream na linha de comando em vez de escrever a URL inteira, e você está pronto para sincronizar seu fork com o repositório original.

      Sincronizando o Fork

      Depois de configurarmos um repositório remoto que faça referência ao upstream e ao repositório original no GitHub, estamos prontos para sincronizar nosso fork do repositório para mantê-lo atualizado.

      Para sincronizar nosso fork, a partir do diretório do nosso repositório local em uma janela de terminal, vamos utilizar o comando git fetch para buscar as branches juntamente com seus respectivos commits do repositório upstream. Como usamos o nome abreviado "upstream" para nos referirmos ao repositório upstream, passaremos o mesmo para o comando:

      Dependendo de quantas alterações foram feitas desde que fizemos o fork do repositório, sua saída pode ser diferente, e pode incluir algumas linhas de contagem, compactação e descompactação de objetos. Sua saída terminará de forma semelhante às seguintes linhas, mas pode variar dependendo de quantas branches fazem parte do projeto:

      Output

      From https://github.com/nome-de-usuário-do-proprietário-original/repositório-original * [new branch] master -> upstream/master

      Agora, os commits para o branch master serão armazenados em uma branch local chamada upstream/master.

      Vamos mudar para a branch master local do nosso repositório:

      Output

      Switched to branch 'master'

      Agora mesclaremos todas as alterações feitas na branch master do repositório original, que vamos acessar através de nossa branch upstream/master local, com a nossa branch master local:

      • git merge upstream/master

      A saída aqui vai variar, mas começará com Updating se tiverem sido feitas alterações, ou Already up-to-date, se nenhuma alteração foi feita desde que você fez o fork do repositório.

      A branch master do seu fork agora está em sincronia com o repositório upstream, e as alterações locais que você fez não foram perdidas.

      Dependendo do seu fluxo de trabalho e da quantidade de tempo que você gasta para fazer alterações, você pode sincronizar seu fork com o código upstream do repositório original quantas vezes isso fizer sentido para você. No entanto, você certamente deve sincronizar seu fork antes de fazer um pull request para garantir que não contribuirá com código conflitante.

      Crie um Pull Request

      Neste ponto, você está pronto para fazer um pull request para o repositório original.

      Você deve navegar até o seu repositório onde você fez o fork e pressionar o botão "New pull request" no lado esquerdo da página.

      Você pode modificar a branch na próxima tela. Em qualquer site, você pode selecionar o repositório apropriado no menu suspenso e a branch apropriada.

      Depois de ter escolhido, por exemplo, a branch master do repositório original no lado esquerdo, e a nova-branch do seu fork do lado direito, você deve ver uma tela assim:

      O GitHub vai lhe alertar de que é possível mesclar as duas branches porque não há código concorrente. Você deve adicionar um título, um comentário e, em seguida, pressionar o botão "Create pull request".

      Neste ponto, os mantenedores do repositório original decidirão se aceitam ou não o seu pull request. Eles podem solicitar que você edite ou revise seu código antes de aceitar o pull request.

      Conclusão

      Neste ponto, você enviou com êxito um pull request para um repositório de software open-source. Depois disso, você deve se certificar de atualizar e fazer um rebase do seu código enquanto espera que ele seja revisado. Os mantenedores do projeto podem pedir que você refaça seu código, então você deve estar preparado para isso.

      Contribuir para projetos de open-source - e se tornar um desenvolvedor ativo de open-source - pode ser uma experiência gratificante. Fazer contribuições regulares para o software que você usa com frequência lhe permite certificar-se de que esse software seja tão valioso para outros usuários finais quanto possível.

      Se você estiver interessado em aprender mais sobre o Git e colaborar com open-source, leia nossa série de tutoriais intitulada An Introduction to Open Source. Se você já conhece o Git e gostaria de um guia de consulta rápida, consulte “Como Usar o Git: Um Guia de Consulta Rápida.”

      Por Lisa Tagliaferri



      Source link