A computação sem servidor é uma das tendências mais visíveis na computação em nuvem. O princípio básico do trabalho é que a infraestrutura não é uma preocupação do DevOps, mas do provedor de serviços. A escala de recursos se adapta automaticamente à carga e tem uma alta taxa de alteração.
Outro recurso comum é a tendência de minimizar e focar o código; portanto, a computação sem servidor às vezes é chamada de "função como serviço" (FaaS).
Historicamente, o primeiro provedor de serviços em nuvem a oferecer FaaS com o AWS Lambda foi a Amazon, de onde vem o nome. Outros provedores de serviços em nuvem também oferecem análogos:
- Funções do Google Cloud
- Funções do Azure da Microsoft
Todas essas empresas fornecem computação sem servidor, escala automática e pagam apenas pelos recursos realmente usados, mas, ao mesmo tempo, vinculam os clientes ao seu produto proprietário. No entanto, existem alternativas gratuitas de código aberto para computação sem servidor. Vale a pena notar:
Todos eles são completamente independentes das nuvens, ou seja, são instalados em qualquer nuvem, incluindo a sua, pública ou privada e, é claro, na Exoscale.
Como o projeto Fn funciona
O Fn é completamente baseado no Docker, consiste em dois componentes principais:
- Programa CLI projetado para gerenciar todos os aspectos da infraestrutura Fn e interagir com o servidor Fn,
- Na verdade, o servidor Fn, o aplicativo usual empacotado em um contêiner para o Docker.
As funções implantadas no Fn também são executadas em contêineres separados, o que permite suportar muitas linguagens de programação, por exemplo ... Clojure!
Os argumentos das funções são transferidos para a entrada padrão (STDIN), os resultados são gravados na saída padrão (STDOUT). Se os argumentos ou valores de retorno não forem valores simples (por exemplo, um objeto JSON), eles poderão ser convertidos usando a camada de abstração fornecida pelo próprio Fn como um kit de desenvolvimento de funções (FDK).
Por conveniência, estão disponíveis modelos internos para facilitar a implantação do FaaS em uma extensa lista de idiomas diferentes e suas versões (Go, versões diferentes de Java, Python, etc.).
Criar o FaaS é fácil seguindo este padrão:
- Implementamos a função usando a CLI Fn: um arquivo de configuração de aplicativo para Fn é criado, com base no modelo selecionado.
- Implementamos nossa própria função, novamente usando a CLI Fn: a imagem do contêiner é colocada em um determinado repositório, após o qual o servidor é notificado da existência e do posicionamento dessa imagem.
Função Princípio de Entrega em Fn
Instalação local e teste de funções sem servidor
Prosseguimos com a instalação do Fn na máquina local. O Docker é instalado primeiro, conforme exigido pelo Fn. Nós devemos estar no Debian / Ubuntu:
$ sudo apt-get update $ sudo apt-get install docker.io
Bem, ou use o gerenciador de pacotes / construção do Docker de acordo com o seu sistema. Então você pode ir diretamente para a instalação da CLI do Fn. Por exemplo, usando curl:
$ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
Se você estiver executando o OSX com o Homebrew instalado, poderá seguir o outro caminho:
$ brew install fn ==> Downloading https://homebrew.bintray.com/bottles/fn-0.5.8.high_sierra.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/b1/b1767fb00e2e69fd9da73427d0926b1d1d0003622f7ddc0dd3a899b2894781ff?__gda__=exp=1538038849~hmac=c702c9335e7785fcbacad1f29afa61244d02f2eebb ######################################################################## 100.0% ==> Pouring fn-0.5.8.high_sierra.bottle.tar.gz /usr/local/Cellar/fn/0.5.8: 5 files, 16.7MB
Agora tudo está pronto para a implantação inicial de nossa função usando a CLI. Para simplificar, usaremos o ambiente interno para executar, por exemplo, Nó:
$ fn init --runtime node --trigger http hellonode Creating function at: /hellonode Function boilerplate generated. func.yaml created.
Um novo diretório hellonode será criado para desenvolver ainda mais nossa função Fn com alguns arquivos de configuração básicos. Dentro do diretório recém-criado, você pode criar seu aplicativo que segue os padrões do idioma ou tempo de execução escolhido:
# node : hellonode ├── func.js ├── func.yaml └── package.json # Java11 : hellojava11 ├── func.yaml ├── pom.xml └── src ├── main │ └── java │ └── com │ └── example │ └── fn │ └── HelloFunction.java └── test └── java └── com └── example └── fn └── HelloFunctionTest.java
Fn cria a estrutura inicial do projeto, cria um arquivo func.yaml contendo as configurações necessárias para Fn e instala um modelo para o código no idioma selecionado.
No caso do tempo de execução do Nó, isso significa:
$ cat hellonode/func.js const fdk=require('@fnproject/fdk'); fdk.handle(function(input){ let name = 'World'; if (input.name) { name = input.name; } return {'message': 'Hello ' + name} })
Agora vamos verificar rapidamente nossa função localmente para ver como tudo funciona.
Primeiro, iniciaremos o servidor Fn. Como já mencionado, o servidor Fn é um contêiner do Docker; portanto, após a inicialização, ele retirará a imagem do registro do Docker.
$ fn start -d # Unable to find image 'fnproject/fnserver:latest' locally latest: Pulling from fnproject/fnserver ff3a5c916c92: Pull complete 1a649ea86bca: Pull complete ce35f4d5f86a: Pull complete ... Status: Downloaded newer image for fnproject/fnserver:latest 668ce9ac0ed8d7cd59da49228bda62464e01bff2c0c60079542d24ac6070f8e5
Para executar nossa função, você precisa implementá-la. Isso requer um
A CLI Fn procurará o arquivo func.yaml no diretório atual, que será usado para configurar a função. Então, primeiro você precisa ir ao nosso diretório hellonode .
$ cd hellonode $ fn deploy --app fnexo --local # , - fnexo. # local , # Deploying hellonode to app: fnexo Bumped to version 0.0.2 Building image nfrankel/hellonode:0.0.3 . Updating function hellonode using image nfrankel/hellonode:0.0.3... Successfully created app: fnexo Successfully created function: hellonode with nfrankel/hellonode:0.0.3 Successfully created trigger: hellonode-trigger
Como você pode ver na saída do comando, é criada uma nova imagem de contêiner para o Docker que contém nossa função. A função está pronta para ser chamada e temos duas maneiras de fazer isso:
- usando o comando fn
invoke - chamando diretamente via
http
A chamada de chamada através de Fn simplesmente emula o trabalho HTTP para testes, o que é conveniente para verificação rápida:
$ fn invoke fnexo hellonode # hellonode fnexo {"message":"Hello World"}
Para chamar a função diretamente, você precisa conhecer o URL completo:
$ curl http://localhost:8080/t/fnexo/hellonode-trigger {"message":"Hello World"}
O servidor Fn fornece suas funções através da porta 8080 e parece que a URL da função corresponde ao esquema t/app/function , mas não completamente. Através do HTTP, a função não é chamada diretamente, mas através do chamado gatilho, que, de acordo com seu nome, "inicia" a chamada da função. Os gatilhos são definidos no projeto `func.yml :
schema_version: 20180708 name: hellonode version: 0.0.3 runtime: node entrypoint: node func.js format: json triggers: - name: hellonode-trigger type: http source: /hellonode-trigger # URL
Podemos mudar o nome do gatilho para que ele corresponda ao nome da função, isso simplificará tudo:
triggers: - name: hellonode-trigger type: http source: /hellonode #
Então começamos a entrega da função novamente e a chamamos do novo gatilho:
$ fn deploy --app fnexo hellonode --local $ curl http://localhost:8080/t/fnexo/hellonode {"message":"Hello World"}
Tudo funciona! É hora de fazer experimentos em grande escala e publicar nosso FaaS no servidor!
Instalando serviços de função sem servidor em sua própria infraestrutura
Vamos instalar rapidamente uma máquina virtual usando a CLI Exoscale. Se você ainda não o configurou, pode usar nosso guia para iniciá-lo rapidamente . Esta é uma ferramenta interessante que aumentará ainda mais sua produtividade. Não esqueça que você precisa configurar uma regra para abrir a porta 8080 no grupo de segurança! Os seguintes comandos iniciarão uma máquina virtual limpa, pronta para hospedar nossos recursos:
$ exo firewall create fn-securitygroup $ exo firewall add fn-securitygroup ssh --my-ip $ exo firewall add fn-securitygroup -p tcp -P 8080-8080 -c 0.0.0.0/0 $ exo vm create fn-server -s fn-securitygroup
Em seguida, você pode ssh na máquina virtual e instalar o servidor Fn remoto:
$ exo ssh fn-server The authenticity of host '185.19.30.175 (185.19.30.175)' can't be established. ECDSA key fingerprint is SHA256:uaCKRYeX4cvim+Gr8StdPvIQ7eQgPuOKdnj5WI3gI9Q. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '185.19.30.175' (ECDSA) to the list of known hosts. Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-20-generic x86_64)
Em seguida, instale o Docker e o servidor Fn da mesma maneira que fizemos na máquina local, inicie o servidor:
$ sudo apt-get update $ sudo apt-get install docker.io $ sudo systemctl start docker $ curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh $ sudo fn start ... ______ / ____/___ / /_ / __ \ / __/ / / / / /_/ /_/ /_/ v0.3.643
Fn está pronto para os recursos! Para a transferência direcionada de funções para um servidor remoto, usaremos o comando deploy do computador local, omitindo o sinalizador --local .
Além disso, o Fn exige que você especifique o local do servidor Fn e do registro do Docker. Esses parâmetros podem ser definidos por meio das variáveis de ambiente FN_API_URL e FN_REGISTRY respectivamente, mas é oferecida uma maneira mais conveniente para controlar facilmente a criação e o gerenciamento de configurações para implantação.
Em termos de Fn, a configuração para implantação é chamada de context . O seguinte comando criará o contexto:
$ fn create context exoscale --provider default --api-url http://185.19.30.175:8080 --registry nfrankel
Você pode visualizar os contextos disponíveis assim:
$ fn list contexts CURRENT NAME PROVIDER API URL REGISTRY default default http://localhost:8080/ exoscale default http://185.19.30.175:8080 nfrankel
E mude para o contexto que acabou de ser criado, assim:
$ fn use context exoscale Now using context: exoscale
A partir deste momento, o fornecimento de funções Fn fará o upload de imagens do Docker usando a conta selecionada no DockerHub (no meu caso, nfrankel ) e notificará o servidor remoto (neste exemplo, http://185.19.30.175:8080 ) sobre o local e a versão A última imagem que contém sua função.
$ fn deploy --app fnexo . # hellonode Deploying function at: /. Deploying hellonode to app: fnexo Bumped to version 0.0.5 Building image nfrankel/hellonode:0.0.5 .
Finalmente:
$ curl http://185.19.30.175:8080/t/fnexo/hellonode {"message":"Hello World"}
Ciclo de vida das funções na computação sem servidor baseada em Fn
As vantagens da computação sem servidor em suas instalações
A computação sem servidor é uma solução conveniente para implementar rapidamente partes de aplicativos independentes que interagem com aplicativos ou microsserviços mais complexos.
Muitas vezes, isso se deve ao custo oculto da ligação ao fornecedor selecionado, que, dependendo do caso de uso e do volume específicos, pode levar a custos mais altos e flexibilidade reduzida no futuro.
As arquiteturas de nuvem múltipla e nuvem híbrida também sofrem nesse caso, porque você pode se encontrar facilmente em uma situação em que gostaria de usar a computação sem servidor, mas, devido à política corporativa, isso pode não ser possível.
O Fn é bastante simples de trabalhar, pode oferecer quase a mesma interface FaaS, com baixos custos. Ele elimina qualquer ligação ao provedor; você pode instalá-lo localmente ou em qualquer provedor de soluções em nuvem conveniente de sua escolha. Também há liberdade na escolha de uma linguagem de programação.
Apenas o básico do Fn é apresentado no artigo, mas a criação de seu próprio ambiente de tempo de execução é bastante simples, e a arquitetura geral pode ser expandida mais amplamente usando o balanceador de carga do Fn ou colocando o Fn atrás de um proxy para proteção.