One place for hosting & domains

      Started

      How To Get Started With the Requests Library in Python


      Introduction

      In many web apps, it’s normal to connect to various third-party services by using APIs. When you use these APIs you can get access to data like weather information, sports scores, movie listings, tweets, search engine results, and pictures. You can also use APIs to add functionality to your app. Examples of these are payments, scheduling, emails, translations, maps, and file transfers. If you were to create any of those on your own it would take a ton of time, but with APIs, it can take only minutes to connect to one and access its features and data.

      In this article, we’ll learn about the Python Requests library, which allows you to send HTTP requests in Python.

      And since using an API is sending HTTP requests and receiving responses, Requests allows you to use APIs in Python. We’ll demonstrate the use of a language translation API here so you can see an example of how it works.

      Quick Overview of HTTP Requests

      HTTP requests are how the web works. Every time you navigate to a web page, your browser makes multiple requests to the web page’s server. The server then responds with all the data necessary to render the page, and your browser then actually renders the page so you can see it.

      The generic process is this: a client (like a browser or Python script using Requests) will send some data to a URL, and then the server located at the URL will read the data, decide what to do with it, and return a response to the client. Finally, the client can decide what to do with the data in the response.

      Part of the data the client sends in a request is the request method. Some common request methods are GET, POST, and PUT. GET requests are normally for reading data only without making a change to something, while POST and PUT requests generally are for modifying data on the server. So for example, the Stripe API allows you to use POST requests to create a new charge so a user can purchase something from your app.

      Note: This article will cover GET requests, because we won’t be modifying any data on a server.

      When sending a request from a Python script or inside a web app, you, the developer, gets to decide what gets sent in each request and what to do with the response. So let’s explore that by first sending a request to Scotch.io and then by using a language translation API.

      Install Python Requests

      Before we can do anything, we need to install the library. So let’s go ahead and install requests using pip. It’s a good idea to create a virtual environment first if you don’t already have one.

      Our First Request

      To start, let’s use Requests for requesting the Scotch.io site. Create a file called script.py and add the following code to it. In this article, we won’t have much code to work with, so when something changes you can just update the existing code instead of adding new lines.

      script.py

      import requests
      
      res = requests.get('https://scotch.io')
      
      print(res)
      

      So all this code is doing is sending a GET request to Scotch.io. This is the same type of request your browser sent to view this page, but the only difference is that Requests can’t actually render the HTML, so instead you will just get the raw HTML and the other response information.

      We’re using the .get() function here, but Requests allows you to use other functions like .post() and .put() to send those requests as well.

      You can run it by executing the script.py file.

      And here’s what you get in return:
      script run with output of `Response 200`

      Status Codes

      The first thing we can do is check the status code. HTTP codes range from the 1XX to 5XX. Common status codes that you have probably seen are 200, 404, and 500.

      Here’s a quick overview of what each status code means:

      • 1XX - Information
      • 2XX - Success
      • 3XX - Redirect
      • 4XX - Client Error (you made an error)
      • 5XX - Server Error (they made an error)

      Generally, what you’re looking for when you perform your own requests are status codes in the 200s.

      Requests recognizes that 4XX and 5XX status codes are errors, so if those status codes get returned, the response object from the request evaluates to False.

      You can test if a request responded successfully by checking the response for truth. For example:

      script.py

      if res:
          print('Response OK')
      else:
          print('Response Failed')
      

      The Response 200 output with a follow up of Response OK

      The message “Response Failed” will only appear if a 400 or 500 status code returns. Try changing the URL to some nonsense to see the response fail with a 404.

      You can take a look at the status code directly by adding:

      script.py

      print(res.status_code)
      

      This will show you the status code directly so you can check the number yourself.

      Failure output with 404

      Another thing you can get from the response are the headers. You can take a look at them by using the headers dictionary on the response object.

      script.py

      print(res.headers)
      

      output with headers printed in standard out

      Headers are sent along with the request and returned in the response. Headers are used so both the client and the server know how to interpret the data that is being sent and received in the response/response.

      We see the various headers that are returned. A lot of times you won’t need to use the header information directly, but it’s there if you need it.

      The content type is usually the one you may need because it reveals the format of the data, for example HTML, JSON, PDF, text, etc. But the content type is normally handled by Requests so you can access the data that gets returned.

      Response Text

      And finally, if we take a look at res.text (this works for textual data, like a HTML page like we are viewing) we can see all the HTML needed to build the home page of Scotch. It won’t be rendered, but we see that it looks like it belongs to Scotch. If you saved this to a file and opened it, you would see something that resembled the Scotch site. In a real situation, multiple requests are made for a single web page to load things like images, scripts, and stylesheets, so if you save only the HTML to a file, it won’t look anything like what the Scotch.io page looks like in your browser because only a single request was performed to get the HTML data.

      script.py

      print(res.text)
      

      Printed HTML data on the command line

      Using the Translate API

      So now let’s move on to something more interesting. We’ll use the Yandex Translate API to perform a request to translate some text to a different language.

      To use the API, first you need to sign up. After you sign up, go to the Translate API and create an API key. Once you have the API key, add it to your file as a constant. Here’s the link where you can do all those things: https://tech.yandex.com/translate/

      script.py

      API_KEY = 'your yandex api key'
      

      The reason why we need an API key is so Yandex can authenticate us every time we want to use their API. The API key is a lightweight form of authentication, because it’s added on to the end of the request URL when being sent.

      To know which URL we need to send to use the API, we can look at the documentation for Yandex.

      If we look there, we’ll see all the information needed to use their Translate API to translate text.

      Request syntax for using the API

      When we see a URL with ampersands (&), question marks (?), and equals signs (=), you can be sure that the URL is for GET requests. Those symbols specify the parameters that go along with the URL.

      Normally things in square brackets ([]) will be optional. In this case, format, options, and callback are optional, while the key, text, and lang are required for the request.

      So let’s add some code to send to that URL. You can replace the first request we created with this:

      script.py

      url = 'https://translate.yandex.net/api/v1.5/tr.json/translate'
      res = requests.get(url)
      

      There are two ways we can add the parameters. We can either append it to the end of the URL directly, or we can have Requests do it for us. To do the latter, we can create a dictionary for our parameters. The three items we need are the key, the text, and the language. Let’s create the dictionary using the API key, 'Hello' for the text, and 'en-es' as the lang, which means we want to translate from English to Spanish.

      If you need to know any other language codes, you can look here. You are looking for the 639-1 column.

      We create a params dictionary by using the dict() function and passing in the keys and values we want in our dictionary.

      script.py

      params = dict(key=API_KEY, text='Hello', lang='en-es')
      

      Now we take the parameters dictionary and pass it to the .get() function.

      script.py

      res = requests.get(url, params=params)
      

      When we pass the parameters this way, Requests will go ahead and add the parameters to the URL for us.

      Now let’s add a print statement for the response text and view what gets returned in the response.

      script.py

      print(res.text)
      

      output dictionary with the values inputted

      We see three things. We see the status code, which is exactly the same status code of the response itself, we see the language that we specified, and we see the translated text inside of the list. So you should see 'Hola' for the translated text.

      Try again with en-fr as the language code, and you should see 'Bonjour' in the response now.

      script.py

      params = dict(key=API_KEY, text='Hello', lang='en-fr')
      

      French translated text

      Let’s take a look at the headers for this particular response.

      script.py

      print(res.headers)
      

      Headers printed in output

      Obviously the headers should be different because we’re communicating with a different server, but in this case the content type is application/json instead of text/html. What this means that the data can be interpreted as JSON.

      When application/json is the content type of the response, we are able to have Requests convert the response to a dictionary and list so we can access the data easier.

      To have the data parsed as JSON, we use the .json() method on the response object.

      If you print it, you’ll see that the data looks the same, but the format is slightly different.

      script.py

      json = res.json()
      print(json)
      


      The reason why it’s different is because it’s no longer plain text that you get from res.text. This time it’s a printed version of a dictionary.

      Let’s say we want to access the text. Since this is now a dictionary, we can use the text key.

      script.py

      print(json['text'])
      


      And now we only see the data for that one key. In this case we are looking at a list of one item, so if we wanted to get that text in the list directly, we can access it by the index.

      script.py

      print(json['text'][0])
      

      "Bonjour" without the square brackets

      And now the only thing we see is the translated word.

      So of course if we change things in our parameters, we’ll get different results. Let’s change the text to be translated from Hello to Goodbye, change the target language back to Spanish, and send the request again.

      script.py

      params = dict(key=API_KEY, text='Goodbye', lang='en-es')
      

      "Adios" printed to output
      Try translating longer text in different languages and see what responses the API gives you.

      Translate API Error Cases

      Finally, we’ll take a look at an error case. Everything doesn’t always work, so we need to know when that happens.

      Try changing your API key by removing one character. When you do this your API key will no longer be valid. Then try sending a request.

      If you take a look at the status code, this is what you get:

      script.py

      print(res.status_code)
      

      403 error
      So when you are using the API, you’ll want to check if things are successful or not so you can handle the error cases according to the needs of your app.

      Conclusion

      Here’s what we learned:

      • How HTTP requests work
      • The various status codes possible in a response
      • How to send requests and receive responses using the Python Requests library
      • How to use a language translation API to translate text
      • How to convert application/JSON content responses to dictionaries

      If you want to do more, check out this list to see different APIs that are available, and try to use them with Python Requests.



      Source link

      Getting Started with Software-Defined Networking and Creating a VPN with ZeroTier One


      Introdução

      Atualmente, cada vez mais os projetos de software são construídos por equipes cujos membros trabalham em conjunto em localidades geográficas diferentes. Embora este fluxo de trabalho tenha muitas vantagens claras, existem casos onde tais equipes podem querer vincular seus computadores na internet e tratá-los como se estivessem na mesma sala. Por exemplo, você pode estar testando sistemas distribuídos como o Kubernetes ou construindo um aplicativo multisserviço complexo. Às vezes, tratar as máquinas como se elas estivessem uma ao lado da outra ajuda na produtividade, já que não seria necessário arriscar expor seus serviços inacabados na internet. Este paradigma pode ser alcançado através da Rede Definida por Software (SDN), uma tecnologia relativamente nova que fornece uma estrutura de rede dinâmica cuja existência é totalmente composta por software.

      O ZeroTier One é um aplicativo de código aberto que usa alguns dos últimos desenvolvimentos em SDN para permitir que os usuários criem redes seguras, gerenciáveis e tratem dispositivos conectados como se estivessem no mesmo local físico. O ZeroTier fornece um console Web para o gerenciamento de rede e o software de terminal para os clientes. Trata-se de uma tecnologia criptografada ponto a ponto, o que significa que ao contrário de soluções tradicionais VPN, as comunicações não precisam passar por um servidor central ou roteador — as mensagens são enviadas diretamente de host para host. Como resultado, ela é muito eficiente e garante latência mínima. Outros benefícios incluem a implantação e o processo de configuração simples do ZeroTier, manutenção sem complicações, que permite o registro e gerenciamento centralizados de nós autorizados pelo Console Web.

      Ao seguir este tutorial, você irá conectar um cliente e servidor juntos em uma rede simples ponto a ponto. Como a Rede Definida por Software não utiliza o design tradicional cliente/servidor, não há servidor VPN central para instalar e configurar; isso simplifica a implantação da ferramenta e a adição de qualquer nó complementar. Assim que a conectividade for estabelecida, será possível usar a capacidade VPN do ZeroTier usando algumas funcionalidades inteligentes do Linux. Isso permite que o tráfego deixe sua rede do ZeroTier do seu servidor e instrua um cliente para enviar o tráfego naquela direção.

      Pré-requisitos

      Antes de trabalhar neste tutorial, você precisará dos seguintes recursos:

      • Um servidor executando o Ubuntu 16.04. Neste servidor, será necessário um usuário não raiz com privilégios sudo que pode ser configurado usando nosso guia de configuração inicial de servidor para o Ubuntu 16.04.

      • Uma conta com o ZeroTier One, que você pode configurar indo para o My ZeroTier. Para os fins deste tutorial, é possível usar a versão gratuita deste serviço que não tem custos ou compromissos.

      • Um computador local para se juntar ao seu SDN como um cliente. Nos exemplos neste tutorial, tanto o servidor como o computador local estão executando o Linux Ubuntu, mas qualquer sistema operacional listado na página de download do ZeroTier funcionará no cliente.

      Com esses pré-requisitos no lugar, você está pronto para configurar a rede definida por software para seu servidor e máquina local.

      Passo 1 — Criando uma rede definida por software usando o ZeroTier One

      A plataforma ZeroTier fornece o ponto central de controle para sua rede definida por software. Lá, você pode autorizar e desautorizar clientes, escolher um esquema de endereço e criar um ID de rede ao qual você pode dirigir seus clientes ao configurá-los.

      Logue na sua conta do ZeroTier, clique em Networks no topo da tela e, em seguida, clique em Create. Um nome de rede gerado automaticamente aparecerá. Clique nele para ver a tela de configuração da sua rede. Anote o Network ID mostrado em amarelo, já que você precisará usá-lo mais tarde.

      Se preferir alterar o nome da rede para algo mais descritivo, edite o nome no lado esquerdo da tela; você também pode adicionar uma descrição, caso queira. Qualquer alteração que você fizer será salva e aplicada automaticamente.

      Em seguida, escolha em qual intervalo de endereços IPv4 o SDN irá operar. No lado direito da tela, na área intitulada IPv4 Auto-Assign, selecione um intervalo de endereços em que seus nós irão se enquadrar. Para os fins deste tutorial, qualquer intervalo pode ser usado, mas é importante deixar a caixa Auto-Assign from Range marcada.

      Certifique-se de que o Access Control à esquerda permaneça definido como Certificate (Private Network). Isso garante que apenas máquinas aprovadas possam se conectar à sua rede, e não qualquer uma que saiba seu ID de rede!

      Assim que terminar, suas configurações devem ser semelhantes a estas:

      ZeroTier settings configuration

      Neste ponto, você instalou a fundação de uma Rede Definida por Software do ZeroTier com sucesso. Em seguida, você instalará o software ZeroTier no seu servidor e máquinas de cliente para permitir que eles se conectem ao seu SDN.

      Passo 2 — Instalando o cliente ZeroTier One no seu servidor e computador local

      Como o ZeroTier One é um software relativamente novo, ele ainda não foi incluído nos repositórios de software principais do Ubuntu. Por esse motivo, o ZeroTier fornece um script de instalação que vamos usar para instalar o software. Este comando é um script assinado por GPG, o que significa que o código que você baixa será verificado como publicado pelo ZeroTier. Este script tem quatro partes principais, e esta é uma explicação detalhada de cada uma delas:

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' – importa a chave pública do ZeroTier do MIT.
      • gpg --import – esta seção do comando adiciona a chave pública do ZeroTier ao seu conjunto de chaves local de autoridades para confiar em pacotes que tentar instalar. A próxima parte do comando será executada apenas se a importação GPG for concluída com sucesso.
      • if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" – existem algumas coisas acontecendo nesta seção, mas é essencialmente: “Se o script de instalação assinado criptografadamente baixado do ZeroTier.com passar pelo GPG e não for rejeitado como não assinado pelo ZeroTier, colar essa informação na tela.”
      • sudo bash; fi – esta seção recebe o script de instalação recentemente validado e executa-o antes de finalizar a rotina.

      Aviso: você nunca deve baixar algo da internet e canalizar em outro programa a menos que tenha certeza de que ele vem de uma fonte confiável. Se quiser, você pode inspecionar o software do ZeroTier revisando o código fonte na página oficial do projeto no GitHub.

      Use um Console SSH para se conectar ao seu servidor recém-criado e execute o seguinte comando como seu usuário normal (uma explicação do comando é fornecida abaixo). Certifique-se de que você não execute ele como raiz, já que o script solicita automaticamente sua senha para aumentar seu nível de privilégios e lembre-se de manter o console do ZeroTier aberto no seu navegador para que possa interagir com ele quando necessário.

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' | gpg --import && if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi

      Assim que o script terminar, você verá duas linhas de resultado semelhantes às mostradas abaixo. Anote seu endereço ZeroTier (sem os colchetes) e o nome do sistema que gerou aquele endereço, ambos os quais serão necessários mais tarde:

      Output

      *** Waiting for identity generation... *** Success! You are ZeroTier address [ 916af8664d ].

      Repita este passo no seu computador local se usar o Ubuntu, ou siga os passos relevantes para seu sistema operacional na página de download do site do ZeroTier. Novamente, certifique-se de anotar o endereço do ZeroTier e a máquina que gerou aquele endereço. Você precisará dessas informações no próximo passo deste tutorial quando você ingressar seu servidor e cliente à rede.

      Passo 3 — Ingressando sua rede ZeroTier

      Agora que tanto o servidor como o cliente têm o software do ZeroTier em execução neles, você está pronto para conectá-los à rede que você criou no Web console do ZeroTier.

      Use o comando a seguir para instruir seu cliente a solicitar acesso à rede do ZeroTier através da sua plataforma. O pedido inicial do cliente será rejeitado e suspenso, mas vamos corrigir isso em breve. Certifique-se de substituir o NetworkID pelo ID da rede que você anotou mais cedo da janela de configuração da sua rede.

      • sudo zerotier-cli join NetworkID

      Output

      200 join OK

      Você receberá uma mensagem 200 join OK, confirmando que o serviço do ZeroTier no seu servidor entendeu o comando. Caso contrário, verifique novamente o ID da rede do ZeroTier que você digitou.

      Como não criou uma rede pública que qualquer um no mundo possa ingressar, você precisa agora autorizar seus clientes. Vá até o Console Web do ZeroTier e role para baixo até o fim, onde a seção Members está. Você deve ver duas entradas marcadas como Online, com os mesmos endereços que você mais cedo.

      Na primeira coluna marcada Auth?, marque as caixas para autorizá-los a participar da rede. O Controlador do Zerotier irá atribuir um endereço IP ao servidor e ao cliente do intervalo que você escolheu mais cedo na próxima vez que eles chamarem o SDN.

      A atribuição de endereços IP pode levar tempo. Enquanto espera, você pode fornecer um Short Name e Description para seus nós na seção Members.

      Com isso, você terá conectado dois sistemas à sua rede definida por software.

      Até agora, você ganhou uma familiarização básica com o painel de controle do ZeroTier, usou a interface da linha de comando para baixar e instalar o ZeroTier e, em seguida, anexou tanto o servidor quanto o cliente a essa rede. Em seguida, você irá verificar se tudo foi aplicado corretamente executando um teste de conectividade.

      Passo 4 — Verificando a conectividade

      Nesta fase, é importante validar que os dois hosts possam realmente conversar entre si. Há uma chance de que mesmo que os hosts aleguem ter ingressado na rede, eles não consigam se comunicar. Ao verificar a conectividade neste momento, você não terá que se preocupar com problemas básicos de interconectividade que poderiam causar problemas mais tarde.

      Uma maneira fácil de encontrar o endereço IP do ZeroTier de cada host é olhando na seção Members do Console Web do ZeroTier. Você pode precisar recarregá-lo após autorizar o servidor e cliente antes que seus endereços IP apareçam. De forma alternativa, você pode usar a linha de comando do Linux para encontrar esses endereços. Use o comando a seguir em ambas as máquinas — o primeiro endereço IP mostrado na lista é aquele a ser usado. No exemplo mostrado abaixo, esse endereço é 203.0.113.0.

      • ip addr sh zt0 | grep 'inet'

      Output

      inet 203.0.113.0/24 brd 203.0.255.255 scope global zt0 inet6 fc63:b4a9:3507:6649:9d52::1/40 scope global inet6 fe80::28e4:7eff:fe38:8318/64 scope link

      Para testar a conectividade entre os hosts, execute o comando ping de um host seguido do endereço IP do outro. Por exemplo, no cliente:

      E no servidor:

      Se as respostas estiverem sendo devolvidas do host oposto (como mostrado no resultado abaixo), então os dois nós estão se comunicando com sucesso pelo SDN.

      Output

      PING 203.0.113.0 (203.0.113.0) 56(84) bytes of data. 64 bytes from 203.0.113.0: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from 203.0.113.0: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from 203.0.113.0: icmp_seq=3 ttl=64 time=0.043 ms

      Você pode adicionar quantas máquinas quiser nesta configuração repetindo a instalação do ZeroTier e os processos de ingressão evidenciados acima. Lembre-se, essas máquinas não precisam de forma alguma estar próximas.

      Agora que você confirmou que seu servidor e cliente podem se comunicar entre si, continue lendo para aprender como ajustar a rede para fornecer um gateway de saída e construir seu próprio VPN.

      Passo 5 — Habilitando a capacidade VPN do ZeroTier

      Como mencionado na introdução, é possível usar o ZeroTier como uma ferramenta VPN. Se você não planeja usar o usuário ZeroTier como uma solução VPN, não será necessário que siga esse passo, podendo pular para o Passo 6.

      Ao usar um VPN, a fonte de suas comunicações com websites na internet fica escondida. Ele permite que você ignore os filtros e restrições que podem existir na rede que está usando. Para a internet como um todo, irá parecer que você está navegando a partir do endereço IP público do seu servidor. Para usar o ZeroTier como uma ferramenta VPN, será necessário fazer mais algumas alterações nas configurações do seu servidor e cliente.

      Como habilitar a Network Address Translation e o encaminhamento de IP

      O Network Address Translation, mais comumente conhecido como “NAT”, é um método pelo qual um roteador aceita pacotes em uma interface marcada com o endereço IP do remetente e, em seguida, troca aquele endereço pelo do roteador. Um registro desta troca é mantido na memória do roteador para que quando o tráfego de retorno volte na direção oposta, o roteador possa traduzir o IP de volta para seu endereço original. O NAT é normalmente usado para permitir que vários computadores operem por trás de um endereço IP exposto publicamente, o que acaba sendo útil para um serviço VPN. Um exemplo do NAT na prática é o roteador doméstico que seu provedor de serviço de internet deu a você para conectar todos os dispositivos em seu lar à Internet. Seu notebook, telefone, tablets e qualquer outro dispositivo que consiga se conectar à Internet. Todos parecem compartilhar o mesmo endereço IP público para a Internet, porque seu roteador está executando o NAT.

      Embora o NAT seja normalmente conduzido por um roteador, ele também pode ser executado por um servidor. Ao longo deste passo, você irá potencializar essa funcionalidade no seu servidor do ZeroTier para habilitar suas capacidades VPN.

      O encaminhamento de IP é uma função realizada por um roteador ou servidor na qual ele encaminha o tráfego de uma interface para outra como se esses endereços IP estivessem em diferentes zonas. Se um roteador estiver conectado a duas redes, o encaminhamento de IP permite que ele encaminhe o tráfego entre elas. Isso pode parecer simples, mas implementar isso com sucesso pode ser surpreendentemente complicado. No entanto, no caso deste tutorial, é apenas uma questão de editar alguns arquivos de configuração.

      Ao habilitar o encaminhamento de IP, o tráfego VPN do seu cliente na rede do ZeroTier chegará na interface do ZeroTier do servidor. Sem essas configurações, o Kernel Linux irá (por padrão) jogar fora qualquer pacote que não seja destinado para a interface em que eles chegam. Esse comportamento é normal para o Kernel Linux,já que normalmente qualquer pacote que esteja chegando em uma interface que tenha um endereço de destino para outra rede pode ter como causa um erro de configuração do roteamento em outro lugar na rede.

      É útil encaminhar o IP de forma a informar o Kernel Linux de que é aceitável encaminhar pacotes entre as interfaces. A configuração padrão é 0 — equivalente a “Desligado”. Você irá alterar isso para 1 — equivalente a “Ligado”.

      Para ver a configuração atual, execute o seguinte comando:

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 0

      Para habilitar o encaminhamento de IP, modifique o arquivo /etc/sysctl.conf no seu servidor e adicione a linha necessária. Este arquivo de configuração permite que um administrador substitua as configurações padrão do kernel, e ele sempre será aplicado após as reinicializações, então não será necessário se preocupar em configurá-lo novamente. Use o nano ou seu editor de texto favorito para adicionar a seguinte linha ao final do arquivo.

      • sudo nano /etc/sysctl.conf

      /etc/sysctl.conf

      . . .
      net.ipv4.ip_forward = 1
      

      Salve, feche o arquivo e depois execute o próximo comando para fazer com que o kernel adote suas novas configurações.

      O servidor adotará quaisquer novas diretrizes de configuração dentro do arquivo e irá aplicá-las imediatamente, sem a necessidade de uma reinicialização. Execute o mesmo comando que você fez anteriormente e verá que o encaminhamento de IP está ativo.

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 1

      Agora que o encaminhamento de IP está ativo, faça bom uso dele fornecendo algumas regras básicas de roteamento do servidor. Como o Kernel Linux já tem uma capacidade de roteamento de rede incorporada dentro dele, tudo o que terá que fazer é adicionar algumas regras para informar o firewall integrado e o roteador que o novo tráfego que estarão vendo é aceitável e para onde enviá-lo.

      Para adicionar essas regras da linha de comando, será necessário primeiro conhecer os nomes que o Ubuntu atribuiu tanto para sua interface Zerotier como sua interface ethernet comum de acesso a Internet. Normalmente, eles são zt0 e eth0 respectivamente, embora nem sempre esse seja o caso.

      Para encontrar os nomes dessas interfaces, utilize o comando ip link show. Este utilitário de linha de comando faz parte do iproute2, uma coleção de utilitários de userspace que vem instalada no Ubuntu por padrão:

      No resultado deste comando, os nomes das interfaces estão diretamente ao lado dos números que identificam uma interface única na lista. Estes nomes de interface estão destacados no seguinte exemplo de resultado. Se os seus nomes diferem dos nomes mostrados no exemplo, substitua seu nome de interface apropriadamente durante este guia.

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 72:2d:7e:6f:5e:08 brd ff:ff:ff:ff:ff:ff 3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether be:82:8f:f3:b4:cd brd ff:ff:ff:ff:ff:ff

      Com essas informações em mãos, utilize o iptables para habilitar o Network-Address-Translation e o mascaramento de IP:

      • sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

      Permita o encaminhamento de tráfego e rastreie conexões ativas:

      • sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

      Em seguida, autorize o encaminhamento de tráfego do zt0 para o eth0. Uma regra reversa não é necessária, já que neste tutorial supõe-se que o cliente sempre faça chamadas pelo servidor, e não o contrário:

      • sudo iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT

      É importante lembrar que as regras do iptables que você definiu para o servidor não persistem automaticamente entre as reinicializações. Você precisará salvar essas regras para garantir que elas sejam trazidas de volta, caso o servidor seja alguma vez reinicializado. No seu servidor, execute os comandos abaixo, seguindo as breves instruções na tela para salvar as regras atuais do IPv4. O mesmo não é necessário para o IPv6.

      • sudo apt-get install iptables-persistent
      • sudo netfilter-persistent save

      Após executar o sudo netfilter-persistent save, pode ser vantajoso reiniciar seu servidor para validar o salvamento correto das regras do iptables. Uma maneira fácil de verificar é executando o sudo iptables-save, que irá transferir as configurações atuais carregadas em memória para o seu terminal. Se você ver regras semelhantes às que estão abaixo em relação ao mascaramento, encaminhamento e a interface zt0, então elas foram salvas corretamente.

      Output

      # Generated by iptables-save v1.6.0 on Tue Apr 17 21:43:08 2018 . . . -A POSTROUTING -o eth0 -j MASQUERADE COMMIT . . . -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i zt0 -o eth0 -j ACCEPT COMMIT . . .

      Agora que essas regras foram aplicadas no seu servidor, ele está pronto para manipular o tráfego entre a rede do ZeroTier e a internet pública. No entanto, o VPN não funcionará a menos que a rede do ZeroTier seja informada de que o servidor está pronto para ser usado como um gateway.

      Como habilitar seu servidor para gerenciar a rota global

      Para que seu servidor possa processar o tráfego de qualquer cliente, é preciso garantir que outros clientes na rede do ZeroTier saibam e enviem seus tráfegos à ele. Pode-se fazer isso configurando uma rota global no Console do ZeroTier. As pessoas que estão familiares com redes de computadores também podem descrever isso como uma Default Route. É onde qualquer cliente envia seu tráfego padrão, ou seja, qualquer tráfego que não deva ir para qualquer outro local específico.

      Vá até o lado direito superior da sua página da rede do ZeroTier e adicione uma nova rota com os seguintes parâmetros. Você pode encontrar o IP do ZeroTier para seu servidor na seção Members da sua página de configuração da rede do ZeroTier. No campo network/bits, digite 0.0.0.0/0, no campo (LAN), digite o endereço IP do seu servidor ZeroTier.

      Quando os detalhes estiverem no lugar, clique no símbolo “+” e você verá uma nova regra aparecer abaixo da existente. Haverá um globo laranja nela para informar que ela é, de fato, uma rota global:

      Global Route Rule

      Com sua rede do ZeroTier pronta para funcionar, há apenas uma configuração a ser feita para que o VPN funcione: a dos clientes.

      Configurando clientes Linux

      Nota: os comandos nesta seção são aplicáveis apenas aos clientes Linux. As instruções para configurar os clientes Windows ou macOS são fornecidas na próxima seção.

      Se seu cliente estiver executando o Linux, será necessário fazer uma alteração manual no seu arquivo /etc/sysctl.conf. Esta mudança de configuração é necessária para alterar a visualização do kernel sobre o qual é um caminho de volta aceitável para o tráfego do seu cliente. Devido ao modo como o VPN do ZeroTier é configurado, o tráfego que volta do seu servidor para seu cliente pode, por vezes, parecer vir de um endereço de rede diferente daquele para o qual foi enviado. Por padrão, o Kernel Linux as vê como inválidas e as elimina, tornando necessário sobrepor esse comportamento.

      Abra o /etc/sysctl.conf na sua máquina do cliente:

      • sudo nano /etc/sysctl.conf

      Então, adicione a seguinte linha:

      Output

      . . . net.ipv4.conf.all.rp_filter=2

      Salve, feche o arquivo e depois execute o sudo sysctl -p para adotar as alterações.

      Em seguida, diga ao software de cliente do ZeroTier que sua rede tem permissão para transportar o tráfego da rota padrão. Isso altera o roteamento do cliente e, portanto, é considerado uma função privilegiada, razão pela qual deve ser habilitada manualmente. O comando imprimirá uma estrutura de configuração na saída. Verifique-a para confirmar que mostra o allowDefault=1 no topo:

      • sudo zerotier-cli set NetworkID allowDefault=1

      Se em qualquer momento você quiser parar de usar o ZeroTier como um VPN com todo seu roteamento de tráfego passando por ele, defina allowDefault de volta para 0:

      • sudo zerotier-cli set NetworkID allowDefault=0

      Cada vez que o serviço do ZeroTier no cliente for reiniciado, o valor allowDefault=1 retorna para 0, portanto lembre-se de executá-lo novamente para ativar a funcionalidade VPN.

      Por padrão, o serviço do ZeroTier é definido para iniciar automaticamente na inicialização para tanto o cliente Linux quanto o servidor. Se você não quiser que isso aconteça, desative a rotina de inicialização com o seguinte comando.

      • sudo systemctl disable zerotier-one

      Se quiser usar outros sistemas operacionais na sua rede do ZeroTier, continue lendo na próxima seção. Caso contrário, pule para a seção Como gerenciar fluxos.

      Como configurar clientes não Linux

      O software de cliente do ZeroTier está disponível para muitos sistemas e não apenas para o SO do Linux — até os smartphones são suportados. Os clientes existem para sistemas Windows, macOS, Android, iOS e até mesmo sistemas operacionais especializados como o QNAP, Synology e sistemas NAS da WesternDigital.

      Para ingressar clientes baseados em macOS e Windows na rede, inicie a ferramenta do ZeroTier (que você instalou no Passo 1) e digite sua NetworkID no campo fornecido antes de clicar em Join. Lembre-se de voltar no console do ZeroTier para marcar o botão Allow para autorizar um novo host na sua rede.

      Certifique-se de marcar a caixa rotulada Route all traffic through ZeroTier. Se não o fizer, seu cliente estará anexado à sua rede do ZeroTier, mas não tentará enviar seu tráfego de internet através dela.

      Use uma ferramenta de verificação de IP como a ICanHazIP para verificar se seu tráfego está aparecendo na internet a partir do IP do seu servidor. Para verificar isso, cole o seguinte URL na barra de endereço do seu navegador. Este site mostrará o endereço IP que seu servidor (e o resto da Internet) vê você usando para acessar o site:

      http://icanhazip.com
      

      Com esses passos concluídos, você pode começar a utilizar seu VPN como quiser. A próxima seção opcional aborda uma tecnologia integrada ao SDN do ZeroTier conhecida como “regras de fluxo”, mas não são de forma alguma necessárias para que a funcionalidade VPN funcione.

      Passo 6 — Gerenciando fluxos (Opcional)

      Um dos benefícios de uma rede definida por software é o controle centralizado. No que diz respeito ao ZeroTier, o controle centralizado é a interface do usuário Web que fica no topo do serviço geral SDN do ZeroTier. A partir dessa interface, é possível escrever regras conhecidas como flow rules, que especificam o tráfego que uma rede pode ou não pode fazer. Por exemplo, você pode especificar uma proibição geral em certas portas de rede que transportam tráfego na rede, limitar os hosts que podem conversar uns com os outros e até mesmo redirecionar o tráfego.

      Esta é uma capacidade extremamente poderosa que entra em vigor quase instantaneamente, já que quaisquer alterações feitas na tabela de fluxo são enviadas aos membros da rede e produzem efeitos após alguns instantes. Para editar as regras de fluxo, volte para a Interface do usuário Web do ZeroTier, clique na aba Networking e role para baixo até ver uma caixa chamada Flow Rules (pode estar recolhida e precisar ser expandida) Isso abre um campo de texto onde você pode digitar as regras que quiser. Um manual completo está disponível dentro do console do ZeroTier em uma caixa abaixo da caixa de entrada Flow Rules, intitulado Rules Engine Help.

      Aqui estão algumas regras para servir de exemplo para ajudar você a explorar essa funcionalidade.

      Para bloquear qualquer tráfego que seja ligado ao servidor DNS do Google 8.8.8.8, adicione essa regra:

      drop
          ipdest 8.8.8.8/32
      ;
      

      Para redirecionar qualquer tráfego que seja ligado ao servidor DNS público do Google para um dos seus nós do ZeroTier, adicione a seguinte regra. Isso pode ser um excelente ponto de captura para substituir pesquisas de DNS:

      redirect NetworkID
          ipdest 8.8.8.8/32
      ;
      

      Se sua rede tiver requisitos especiais de segurança, você pode remover quaisquer atividades nas portas FTP, Telnet e HTTP não criptografada, adicionando essa regra:

      drop
          dport 80,23,21,20
      ;
      

      Quando terminar de adicionar as regras de fluxo, clique no botão Save Changes e o ZeroTier irá gravar suas alterações.

      Conclusão

      Neste tutorial, você deu um primeiro passo no mundo das Redes Definidas por Software. Trabalhar com o ZeroTier fornece alguns insights sobre os benefícios dessa tecnologia. Se seguiu o exemplo VPN, e embora a configuração inicial possa contrastar de outras ferramentas que você possa ter usado no passado, a facilidade em adicionar clientes adicionais pode ser uma razão convincente para usar a tecnologia em outro lugar.

      Para resumir, você aprendeu como usar o ZeroTier como um provedor SDN, além de configurar e anexar nós a essa rede. O elemento VPN fará você compreender mais profundamente como o roteamento dentro de uma rede dessas funciona e ambos os caminhos neste tutorial permitirão que utilize a poderosa tecnologias das regras de fluxo.

      Agora que uma rede ponto a ponto existe, é possível combiná-la com outra funcionalidade, como o Compartilhamento de arquivos. Se você tiver um NAS ou servidor de arquivos em casa, você pode vinculá-lo ao ZeroTier e acessá-lo fora de casa. Se quiser compartilhá-lo com seus amigos, mostre a eles como ingressar na sua rede do ZeroTier. Os funcionários que estão distribuídos em uma grande área poderiam até mesmo vincular-se ao mesmo espaço de armazenamento central. Para começar a construir o compartilhamento de arquivos para qualquer um desses exemplos, consulte Como configurar uma Samba Share para uma organização pequena no Ubuntu 16.04.



      Source link

      Getting Started with Containers and Kubernetes: A DigitalOcean Workshop Kit


      Getting Started with Containers and Kubernetes Workshop Kit Materials

      This meetup kit is designed to help a technical audience become familiar with core Kubernetes concepts and practices.

      The aim is to provide a complete set of resources for a speaker to host an event and deliver an introductory talk on containers and Kubernetes. It includes:

      This tutorial is intended to supplement the talk demo with additional detail and elucidation. It also serves as a reference for readers seeking to get a minimal containerized Flask app up and running on DigitalOcean Kubernetes.

      Introduction

      In the past decade, containerized applications and container clusters have rapidly replaced the old paradigm of scaling applications using virtual machines. Containers offer the same process isolation, but are generally more lightweight, portable, and performant than full virtualization. Container clusters, which can be used to manage thousands of running containers across a set of physical machines, abstract away much of the work of rolling out new versions of applications, scaling them, and efficiently scheduling workloads. Out of these, Kubernetes has emerged as a mature, production-ready system. It provides a rich set of features like rolling deployments, health checking, self-monitoring, workload autoscaling, and much, much more.

      This tutorial, designed to accompany the Slides and speaker notes for the Getting Started with Kubernetes Meetup Kit, will show you how to harness these technologies and deploy the “Hello World” Flask app onto a DigitalOcean Kubernetes cluster.

      Prerequisites

      To follow this tutorial, you will need:

      • A Kubernetes 1.10+ cluster with role-based access control (RBAC) enabled. This setup will use a DigitalOcean Kubernetes cluster
      • The kubectl command-line tool installed on your local machine or development server and configured to connect to your cluster. You can read more about installing kubectl in the official documentation.
      • Docker installed on your local machine or development server. If you are working with Ubuntu 18.04, follow Steps 1 and 2 of How To Install and Use Docker on Ubuntu 18.04; otherwise, follow the official documentation for information about installing on other operating systems. Be sure to add your non-root user to the docker group, as described in Step 2 of the linked tutorial.
      • A Docker Hub account (optional). For an overview of how to set this up, refer to this introduction to Docker Hub. You’ll only need a Docker Hub account if you plan on modifying the Flask Docker image described in this tutorial.

      Step 1 — Cloning the App Repository and Building the Flask Image

      To begin, clone the demo Flask app repo onto your machine, navigate into the directory, and list the directory contents:

      • git clone https://github.com/do-community/k8s-intro-meetup-kit.git
      • cd k8s-intro-meetup-kit
      • ls

      Output

      LICENSE README.md app k8s

      The app directory contains the Flask demo app code, as well as the Dockerfile for building its container image. The k8s directory contains Kubernetes manifest files for a Pod, Deployment, and Service. To learn more about these Kubernetes objects, consult the slide deck or An Introduction to Kubernetes.

      Navigate into the app directory and print out the contents of the app.py file:

      Output

      from flask import Flask app = Flask(__name__) @app.route('/') def hello_world(): return 'Hello, World!' if __name__ == "__main__": app.run(debug=True, host='0.0.0.0')

      This code defines a single default route that will print “Hello World.” Additionally, the apps runs in debug mode to enable verbose output.

      In a similar fashion, cat out the contents of the app’s Dockerfile:

      Output

      FROM python:3-alpine WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . EXPOSE 5000 CMD ["python", "app.py"]

      This Dockerfile first sources a lightweight Alpine Linux Python parent image. It then copies in the Python requirements file, installs Flask, copies the app code into the container image, defines port 5000 as the container port, and finally sets the default command to python app.py.

      Next, build the app image:

      • cd app
      • docker build -t flask_demo:v0 .

      We give the image a name, flask_demo, and tag, v0 using the -t option.

      After Docker finishes the build, run the container using run:

      • docker run -p 5000:5000 flask_demo:v0

      This command runs a container using the flask:v0 image, and forwards local port 5000 to container port 5000.

      If you’re running Docker on your local machine, navigate to http://localhost:5000 in your web browser. You should see “Hello World,” generated by the dockerized Flask app.

      If you’re running Docker on a dev server, navigate instead to http://dev_server_external_IP:5000. If you’re running a firewall like UFW, be sure to allow external access on port 5000. To learn more about doing this with UFW, consult UFW Essentials: Common Firewall Rules and Commands.

      At this point you can experiment with Docker commands like docker ps, docker top, and docker images to practice working with images and containers on your system.

      In the next step, we’ll deploy this demo app to your Kubernetes cluster. We’ll use a prebuilt image shared publicly on Docker Hub. If you’d like to customize the Flask app and use your own image, you should create a Docker Hub account and follow the steps in this introduction to push your image to a public repository. From there, Kubernetes will be able to pull and deploy the container image into your cluster.

      Step 2 — Deploying the Flask App on Kubernetes

      The app and Docker image described in the previous step have already been built and made publicly available in the flask-helloworld Docker Hub repository. You can optionally create your own repository for the app and substitute it for flask-helloworld throughout this step.

      We’ll first deploy this demo “Hello World” app into our cluster as a standalone Pod, then as a multi-pod Deployment, which we’ll finally expose as a LoadBalancer Service. At the end of this tutorial, the “Hello World” app will be publicly accessible from outside of the Kubernetes cluster.

      Before we launch any workloads into the cluster, we’ll create a Namespace in which the objects will run. Namespaces allow you to segment your cluster and limit scope for running workloads.

      Create a Namespace called flask:

      • kubectl create namespace flask

      Now, list all the Namespaces in your cluster:

      You should see your new Namespace as well as some default Namespaces like kube-system and default. In this tutorial, we are going to exclusively work within the flask Namespace.

      Navigate back out to the k8s directory in the demo repo:

      In this directory, you’ll see three Kubernetes manifest files:

      • flask-pod.yaml: The app Pod manifest
      • flask-deployment.yaml: The app Deployment manifest
      • flask-service.yaml: The app LoadBalancer Service manifest

      Let’s take a look at the Pod manifest:

      Output

      apiVersion: v1 kind: Pod metadata: name: flask-pod labels: app: flask-helloworld spec: containers: - name: flask image: hjdo/flask-helloworld:latest ports: - containerPort: 5000

      Here, we define a minimal Pod called flask-pod and label it with the app: flask-helloworld key-value pair.

      We then name the single container flask and set the image to flask-helloworld:latest from the hjdo/flask-helloworld Docker Hub repository. If you’re using an image stored in a different Docker Hub repo, you can reference it using the image field here. Finally, we open up port 5000 to accept incoming connections.

      Deploy this Pod into the flask Namespace using kubectl apply -f and the -n Namespace flag:

      • kubectl apply -f flask-pod.yaml -n flask

      After ten or so seconds, the Pod should be up and running in your cluster:

      Output

      NAME READY STATUS RESTARTS AGE flask-pod 1/1 Running 0 4s

      Since this Pod is running inside of the Kubernetes cluster, we need to forward a local port to the Pod’s containerPort to access the running app locally:

      • kubectl port-forward pods/flask-pod -n flask 5000:5000

      Here we use port-forward to forward local port 5000 to the Pod’s containerPort 5000.

      Navigate to http://localhost:5000, where you should once again see the “Hello World” text generated by the Flask app. If you’re running kubectl on a remote dev server, replace localhost with your dev server’s external IP address.

      Feel free to play around with kubectl commands like kubectl describe to explore the Pod resource. When you’re done, delete the Pod using delete:

      • kubectl delete pod flask-pod -n flask

      Next, we’ll roll out this Pod in a scalable fashion using the Deployment resource. Print out the contents of the flask-deployment.yaml manifest file:

      • cat flask-deployment.yaml

      Output

      apiVersion: apps/v1 kind: Deployment metadata: name: flask-dep labels: app: flask-helloworld spec: replicas: 2 selector: matchLabels: app: flask-helloworld template: metadata: labels: app: flask-helloworld spec: containers: - name: flask image: hjdo/flask-helloworld:latest ports: - containerPort: 5000

      Here, we define a Deployment called flask-dep with an app: flask-helloworld Label. Next, we request 2 replicas of a Pod template identical to the template we previously used to deploy the Flask app Pod. The selector field matches the app: flask-helloworld Pod template to the Deployment.

      Roll out the Deployment using kubectl apply -f:

      • kubectl apply -f flask-deployment.yaml -n flask

      After a brief moment, the Deployment should be up and running in your cluster:

      • kubectl get deploy -n flask

      Output

      NAME READY UP-TO-DATE AVAILABLE AGE flask-dep 2/2 2 2 5s

      You can also pull up the individual Pods that are managed by the Deployment controller:

      Output

      NAME READY STATUS RESTARTS AGE flask-dep-876bd7677-bl4lg 1/1 Running 0 76s flask-dep-876bd7677-jbfpb 1/1 Running 0 76s

      To access the app, we have to forward a port inside of the cluster:

      • kubectl port-forward deployment/flask-dep -n flask 5000:5000

      This will forward local port 5000 to containerPort 5000 on one of the running Pods.

      You should be able to access the app at http://localhost:5000. If you’re running kubectl on a remote dev server, replace localhost with your dev server’s external IP address.

      At this point you can play around with commands like kubectl rollout and kubectl scale to experiment with rolling back Deployments and scaling them. To learn more about these and other kubectl commands, consult a kubectl Cheat Sheet.

      In the final step, we’ll expose this app to outside users using the LoadBalancer Service type, which will automatically provision a DigitalOcean cloud Load Balancer for the Flask app Service.

      Step 3 — Creating the App Service

      A Kubernetes Deployment allows the operator to flexibly scale a Pod template up or down, as well as manage rollouts and template updates. To create a stable network endpoint for this set of running Pod replicas, you can create a Kubernetes Service, which we’ll do here.

      Begin by inspecting the Service manifest file:

      Output

      apiVersion: v1 kind: Service metadata: name: flask-svc labels: app: flask-helloworld spec: type: LoadBalancer ports: - port: 80 targetPort: 5000 protocol: TCP selector: app: flask-helloworld

      This manifest defines a Service called flask-svc. We set the type to LoadBalancer to provision a DigitalOcean cloud Load Balancer that will route traffic to the Deployment Pods. To select the already running Deployment, the selector field is set to the Deployment’s app: flask-helloworld Label. Finally, we open up port 80 on the Load Balancer and instruct it to route traffic to the Pods’ containerPort 5000.

      To create the Service, use kubectl apply -f:

      • kubectl apply -f flask-service.yaml -n flask

      It may take a bit of time for Kubernetes to provision the cloud Load Balancer. You can track progress using the -w watch flag:

      Once you see an external IP for the flask-svc Service, navigate to it using your web browser. You should see the “Hello World” Flask app page.

      Conclusion

      This brief tutorial demonstrates how to containerize a minimal Flask app and deploy it to a Kubernetes cluster. It accompanies the meetup kit’s slides and speaker notes and GitHub repository.



      Source link