Joseph  Murray

Joseph Murray

1660122780

An Adapter to Build A SvelteKit App into A Lambda

adapter-lambda for SvelteKit

An adapter to build a SvelteKit app into a lambda ready for deployment with lambda proxy via the Serverless framework.

Installation

npm install --save-dev @yarbsemaj/adapter-lambda

Usage

In your svelte.config.js configure the adapter as bellow;

import preprocess from 'svelte-preprocess'; //Optional
import serverless from '@yarbsemaj/adapter-lambda';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  preprocess: preprocess(), //Optional

  kit: {
    adapter: serverless(),
  },

};

export default config;

Copy serverless.yml from the root of this repo to the root of your project, make sure to change the service name.

After building your app run sls deploy to deploy code to AWS using the build tool serverless.

Your app can then be accessed via the CloudFront distribution created as a part of the stack.

Static Assets and precompiled pages

To server static assets and precompiled pages this adapter makes use of S3. In order to route traffic the correct destination a Lambda@edge fuction is used to perfrom a origin rewrite to redirect traffic to the S3 Bucket.

Help! I'm getting an error while building or serving my app.

As SvelteKit is still in early development, there are often breaking changes made to the adapter API and other associated functions. If this is the case, please raise an issue on Github, and I will be happy to issue a fix.

Versions

Adapter VersionSveltekit Version
0.11.x1.0.0-next.401
0.10.x1.0.0-next.380
0.9.x1.0.0-next.348
0.6.x - 0.8.x1.0.0-next.301
0.5.x1.0.0-next.286
0.3.x - 0.4.x1.0.0-next.286
0.2.x1.0.0-next.239
0.1.x1.0.0-next.169

Download details:

Author: yarbsemaj
Source code: https://github.com/yarbsemaj/sveltekit-adapter-lambda
License: MIT license

#svelte #javascript #lambda

An Adapter to Build A SvelteKit App into A Lambda
Nat  Grady

Nat Grady

1659548760

Lambda.r: Functional Programming in R

Description

Provides a syntax for writing functional programs in R. Lambda.r has a clean syntax for defining multi-part functions with optional guard statements. Simple pattern matching is also supported. Types can be easily defined and instantiated using the same functional notation. Type checking is integrated and optional, giving the programmer complete flexibility over their application or package.

Basic Usage

Defining a function

Functions are defined using %as% notation. Any block of code can be in the function definition.

fib(n) %as% { fib(n-1) + fib(n-2) }

Pattern matching

Multi-part function definitions are easily constructed. For simple criteria, pattern matching of literals can be used directly in lambda.r.

fib(0) %as% 1
fib(1) %as% 1

Strings can also be pattern matched within definitions.

Guard statements

Executing different function variants within a multi-part function sometimes requires more detail than simple pattern matching. For these scenarios a guard statement is used to define the condition for execution. Guards are simply an additional clause in the function definition.

fib(n) %when% { n >= 0 } %as% { fib(n-1) + fib(n-2) }

A function variant only executes if the guard statements all evaluate to true. As many guard statements as desired can be added in the block. Just separate them with either a new line or a semi-colon.

fib(n) %when% {
  is.numeric(n)
  n >= 0
} %as% { fib(n-1) + fib(n-2) }

Note that in the above example the type check can be handled using a type declaration, which is discussed below.

For functions defined in multiple parts, each separate function variant is evaluated in the same order as they are defined. Hence a less restrictive variant that evaluates to true defined early in the chain of function definitions will take precedence over variants defined later. (If you are following along in sequence, the pattern matches for fib(0) and fib(1) will never be called since the first definition fib(n) will always evaulate to true).

Types

Lambda.R introduces types as an alternative to classes. Types are data structures with type information attached to it. Like classes, constructors exist for types and one type can inherit from another type. The difference is that types do not have embedded methods. In functional programming, functions are first class so there is no need to embed them within the data structure. Using types provides type safety, which means that a function variant will only execute if the types are correct.

Defining a type

Types are defined by defining their constructor. We define constructors using an uppercase function name. The return value of the constructor is automatically typed. Hence the value x will be of type Integer.

Integer(x) %as% x

Instantiating the type is as simple as calling the function. Check the type using the standard S3 introspection function class. The %isa% operator can also be used to test whether an object is a particular type.

x <- Integer(5)
x %isa% Integer

Type declarations

Type constraints can be added to a function. These constraints specify the type of each input argument in addition to the return type. Using this approach ensures that the arguments can only have compatible types when the function is called. The final type in the constraint is the return type, which is checked after a function is called. If the result does not have the correct return type, then the call will fail.

fib(n) %::% Integer : Integer
fib(0) %as% Integer(1)
fib(1) %as% Integer(1)
fib(n) %as% { fib(n-1) + fib(n-2) }

fib(x)

The call fib(1) will fail because 1 is not of type Integer.

> fib(1)
Error in UseFunction("fib", ...) : No valid function for 'fib(1)'

Properly typing the argument by calling fib(Integer(1)) will give the correct output. Note that pattern matching works even with the custom type.

> fib(Integer(1))
[1] 1
attr(,"class")
[1] "Integer" "numeric"

Type constraints must be declared prior to the function implementation. Once declared, the type declaration will retain scope until another type declaration with the same number of parameters is declared (see tests/types.R for an example).

Legacy types

There are plenty of built-in types that are supported just like custom types defined in lambda.r. Use the same syntax for these types. In the example above we can just as easily declare

fib(n) %::% numeric : numeric

or even

fib(n) %::% Integer : numeric

NOTE: For objects of type function, due to the precedence rules of the parser, you cannot specify 'function' in a type constraint. Instead use 'Function'.

# Do this
make.gen(n) %::% numeric : Function

# Don't do this
make.gen(n) %::% numeric : function

Type Variables

Type constraints are useful, but too specific of a constraint can destroy the polymorphism of a function. To preserve this while still retaining some type safety you can use a type variable. With type variables the actual type is not checked. Instead it is the relationship between types that are checked.

fib(n) %::% a : a
fib(0) %as% 1
fib(1) %as% 1
fib(n) %as% { fib(n-1) + fib(n-2) }

In this type constraint, both the input and output types must match.

Note that the only characters valid for a type variable are the lowercase letters (i.e. a-z). If you need more than this for a single function definition, you've got other problems.

The Ellipsis Type

The ellipsis can be inserted in a type constraint. This has interesting properties as the ellipsis represents a set of arguments. To specify that input values should be captured by the ellipsis, use ... within the type constraint. For example, suppose you want a function that multiplies the sum of a set of numbers. The ellipsis type tells lambda.r to bind the types associated with the ellipsis type.

sumprod(x, ..., na.rm=TRUE) %::% numeric : ... : logical : numeric
sumprod(x, ..., na.rm=TRUE) %as% { x * sum(..., na.rm=na.rm) }

> sumprod(4, 1,2,3,4)
[1] 40

Alternatively, suppose you want all the values bound to the ellipsis to be of a certain type. Then you can append ... to a concrete type.

sumprod(x, ..., na.rm=TRUE) %::% numeric : numeric... : logical : numeric
sumprod(x, ..., na.rm=TRUE) %as% { x * sum(..., na.rm=na.rm) }

> sumprod(4, 1,2,3,4)
[1] 40
> sumprod(4, 1,2,3,4,'a')
Error in UseFunction(sumprod, "sumprod", ...) :
  No valid function for 'sumprod(4,1,2,3,4,a)'

If you want to preserve polymorphism but still constrain values bound to the ellipsis to a single type, you can use a type variable. Note that the same rules for type variables apply. Hence a type variable represents a type that is not specified elsewhere.

sumprod(x, ..., na.rm=TRUE) %::% a : a... : logical : a
sumprod(x, ..., na.rm=TRUE) %as% { x * sum(..., na.rm=na.rm) }

> sumprod(4, 1,2,3,4)
[1] 40
> sumprod(4, 1,2,3,4,'a')
Error in UseFunction(sumprod, "sumprod", ...) :
  No valid function for 'sumprod(4,1,2,3,4,a)'

The Don't-Care Type

Sometimes it is useful to ignore a specific type in a constraint. Since we are not inferring all types in a program, this is an acceptable action. Using the . within a type constraint tells lambda.r to not check the type for the given argument.

For example in R f(x, y) %::% . : numeric : numeric, the type of x will not be checked.

One Shot

Here is the complete example using built-in types:

fib(n) %::% numeric : numeric
fib(0) %as% 1
fib(1) %as% 1
fib(n) %as% { fib(n-1) + fib(n-2) }

fib(5)
seal(fib)

To ignore types altogether, just omit the type declaration in the above listing and the code will evaluate the same.

Here is the same example with custom types:

Integer(x) %as% x
     
fib(n) %::% Integer : Integer
fib(0) %as% Integer(1)
fib(1) %as% Integer(1)
fib(n) %as% { fib(n-1) + fib(n-2) }

x <- Integer(5)
fib(x)

The seal command in the first example prevents new statements from being added to an existing function definition. Instead new definitions reset the function. Typically you don't need this function as lambda.r will auto-replace function definitions that have the same signature.

Sugar Coating

All the great features of R function calls are still supported in lambda.r. In addition, lambda.r provides some parse transforms to add some extra features to make application development even faster.

Object Attributes

Attributes are a form of meta data that decorate an object. This information can be used to simplify type structures retaining polymorphism and compatibility with existing functions while providing the detail needed for your application. Lambda.R provides convenient syntax for interacting with attributes via the @ symbol.

Temperature(x, system, units) %as%
{
  x@system <- system
  x@units <- units
  x
}

These attributes can then be accessed in guards and function bodies using the same syntax.

freezing(x) %::% Temperature : logical
freezing(x) %when% {
  x@system == 'metric'
  x@units == 'celsius'
} %as% {
  if (x < 0) { TRUE }
  else { FALSE }
}

Note that outside of lambda.r you must use the standard attr() function to access specific attributes. Also note that attributes have not been tested with S4 objects.

Optional Arguments

A nice convenience in R is the ability to specify optional arguments with default values. Lambda.R preserves this feature in multipart function definitions. Functions are matched based on the order in which they are defined, and this holds true with functions with optional arguments.

Temperature(x, system="metric", units='celsius') %as%
{
  x@system <- system
  x@units <- units
  x
}

> ctemp <- Temperature(20)
> ctemp
[1] 20
attr(,"system")
[1] "metric"
attr(,"units")
[1] "celsius"
attr(,"class")
[1] "Temperature" "numeric"

The Ellipsis Argument

Support for the ellipsis argument is built into lambda.r. Required arguments must still be matched, while any additional arguments will be enclosed in the ellipsis. Here's an example using the plant data included in R's lm help page.

regress(formula, ..., na.action='na.fail') %as% {
  lm(formula, ..., na.action=na.action)
}

ctl <- c(4.17,5.58,5.18,6.11,4.50,4.61,5.17,4.53,5.33,5.14)
trt <- c(4.81,4.17,4.41,3.59,5.87,3.83,6.03,4.89,4.32,4.69)
data <- data.frame(group=gl(2,10,20,labels=c("Ctl","Trt")), weight=c(ctl, trt))
lm.D9 <- regress(weight ~ group, data=data)

Care does need to be used with the ellipsis as it behaves like a greedy match, so subsequent definitions may not work as you intend when using the ellipsis argument in a function variant.

Named Arguments

The examples above all hint at supporting named arguments. Named arguments can be mixed and matched with positional arguments just as in legacy function definitions.

lm.D9 <- regress(data=data, weight ~ group)

Auto Replace and Sealing Definitions

As of version 1.1.0, lambda.r can detect a duplicate function signature and update an existing definition. This means development is more efficient since you can re-source files and the existing definitions will update as you expect. This process is compatible with multi-part function definitions and type constraints. Do note that when using type constraints, only functions associated with the active type constraint can be auto replaced. The reason is that there can be two identical function signatures and lambda.r really has no way of knowing which one you mean. Hence, you have to tell lambda.r via the type constraint.

For example take this simple reciprocal function. There are two type constraint clauses, and three total function variants. The signatures for variants 2 and 3 are identical, so the only thing that distinguishes them are the different type constraints associated with each one. Notice that there is an explicit bug in the definition of variant 2.

reciprocal(n) %::% numeric : numeric
reciprocal(0) %as% stop("Reciprocal of 0 is undefined")
reciprocal(n) %as% { 2/n }

reciprocal(n) %::% character : numeric
reciprocal(n) %as% { reciprocal(as.numeric(n)) }

To change the definition of variant 2, you must re-declare the first type constraint. Otherwise, lambda.r would not know whether to update variant 2 or 3.

reciprocal(n) %::% numeric : numeric
reciprocal(n) %as% { 1/n }

Lambda.R has no way of knowing whether a function definition is complete or not. Explicitly telling lambda.r will ensure that any new function definitions will reset the function as opposed to append another definition.

seal(freezing)

If providing a broad interface, be careful not to seal the function. Sealing is analogous to making a variable final in Java, such that no further modifications can be made. The key difference is that attempting to add further defintions to the sealed function will overwrite the existing definition. This behavior is intended to make application and package development more iterative.

Introspection

A function in lambda.r has a lot of meta data attached to it. Accessing the raw data can be overwhelming, so lambda.r provides facilities to extract the useful bits. Viewing basic information about a function is accomplished by just typing out the function in the shell. This results in a dump of the type declarations and function signatures for the function.

> fib
<function>
[[1]]
fib(n) %::% Integer:Integer 
fib(0) %as% ...
[[2]]
fib(n) %::% Integer:Integer 
fib(1) %as% ...
[[3]]
fib(n) %::% Integer:Integer 
fib(n) %as% ...

Actual function bodies are not displayed to minimize clutter.

Examining Functions

To view a full function definition, use the 'describe' function to get the definition of a specific function variant. The numbers separating each variant is the index to use.

> describe(fib,3)
function(n) { Integer ( fib ( n - 1 ) + fib ( n - 2 ) ) }
<environment: 0x10488ed10>

Examining Types

A type constructor is similar to a normal function, and the same technique works to view a type body.

> describe(Integer,1)
function(x) { x }
<environment: 0x10494aca8>

Monads

If you want to play around with monads in R, lambda.r has your back. Here are some examples. Note that lambda.tools implements some common monadic operators.

Maybe(a) %:=% a
Just(a) %:=% Maybe(a)
Nothing() %:=% Maybe(NA)

mreturn(x) %as% Just(x)


m %>>=% g %when% { is.null(m) } %as% NULL
m %>>=% g %::% Just : Function : Maybe
m %>>=% g %as% g(m)



m %>>=% g %::% Nothing : Function : Maybe
m %>>=% g %as% m

m %>>=% g %::% Just : Function : Maybe
m %>>=% g %as% g(m)

Composition

f %.% g %:=% function(...) f(g(...))

> unsafelogsqrt <- log %.% sqrt
> unsafelogsqrt(100)
 [1] 2.302585

Monadic composition

f %>=>% g %:=% { function(x) f(x) %>>=% g }
f %<=<% g %:=% { function(x) g(x) %>>=% f }

safelog(x) %::% numeric : Maybe
safelog(x) %when% { x <= 0 } %as% Nothing()
safelog(x) %:=% Just(log(x))

safesqrt(x) %::% numeric : Maybe
safesqrt(x) %when% { x <= 0 } %as% Nothing()
safesqrt(x) %:=% Just(sqrt(x))

safelogsqrt <- safelog %<=<% safesqrt

Debugging

The standard debug function will not work with lambda.r functions. Instead, use the included functions debug.lr and undebug.lr. These functions will allow you to debug through a complete multipart function call.

Known Limitations

If you try to break lambda.r, you will most likely succeed. There are things that won't work, but most use cases should work fine. Do let me know if you find something that fails, but don't break it just to break it. Below are some things that won't work.

  1. Complex mix and match of named and positional arguments
lm.D9 <- regress(data=data, formula=weight ~ group, NULL)

Don't do this, please. It's bad style.

What's New

Version 1.1.5

  • Support the ellipsis (...) in type constraints
  • Support a typed ellipsis (numeric...) in type constraints
  • Support ellipsis type variable (a...) in type constraints
  • Support debug.lr in functions defined in packages (currently locked)
  • Show which functions are being debugged
  • Handle default arguments that execute a function
  • Support more pattern matching (like empty lists)
  • Support guards of the form f(a,b,c) %when% { sum(a,b,c) == 1 } %as% { 1 }
  • Support guards of the form f(x) %when% { length(grep('foo',x)) > 0 } %as% { 1 }
  • Support proper import namespace for packages
  • Install from github using devtools: install_github('lambda.r','zatonovo')
  • Travis CI integration: https://travis-ci.org/zatonovo/lambda.r

Version 1.1.1

  • Support Function in every type position (only supported for return type)
  • Auto-replacing a function with 0 arguments fails
  • Fix type inheritance
  • Functions that return non-scalar values work as default values on arguments
  • Support pattern matching on NULL and NA
  • Support pattern matching on special symbol EMPTY

Version 1.1.0

  • Handle function types in type declarations
  • Support type variables
  • Auto-replace function definitions with a matching signature (no need for seal)
  • Handle 0 argument functions

Future

  • Support *apply and lambda expressions in guard statements
  • Support defining operators
  • Lock functions by default (check when next function is different name). Use public() as way to indicate function can be globally modified
  • Think about supporting namespaces
  • Support take, drop, cycle
  • Support partial function application
  • Check for side effects
  • Support tail recursion
  • Support type inference

Author: Zatonovo
Source Code: https://github.com/zatonovo/lambda.r 

#r #lambda #functional

Lambda.r: Functional Programming in R

Crie Microsserviços Sem Servidor Com Node.js E AWS Lambda

 Se você sempre quis escrever um aplicativo da web ou API sem mexer no servidor, o Lambda da Amazon pode ser o que você está procurando.

Amazon Web Services (AWS) é uma coleção de ferramentas de desenvolvedor que a Amazon desenvolve e oferece publicamente. Usaremos o Lambda para criar um endpoint HTTP GET que fará solicitações usando a API do GitHub para extrair informações do repositório do GitHub e retornar uma resposta JSON.

O slogan do Lambda é “Executar código sem pensar em servidores”. À primeira vista, isso pode parecer confuso. Onde ou como o código é executado então? Vamos descobrir.

Para acompanhar este artigo, você precisará de uma conta da AWS própria. Você pode criar uma conta gratuita da AWS em aws.amazon.com .

Crie microsserviços sem servidor com Node.js e AWS Lambda

Sem servidor e funções como serviço

“Sem servidor” é um termo de infraestrutura de software sobre o qual você já deve ter ouvido falar. Ele descreve uma solução para execução de código sob demanda. O termo “sem servidor” pode ser enganoso porque ainda há servidores na equação. Um descritor melhor é FaaS, ou “funções como serviço”.

Ambas as definições descrevem uma nova experiência de desenvolvimento e implantação. Essa experiência é considerada "sem servidor" porque você, como desenvolvedor, não precisa mais gerenciar, monitorar ou dimensionar nenhum servidor que esteja executando seu código. Você carrega seu código para um provedor de FaaS (AWS Lambda, neste caso) e o provedor de FaaS o executa e gerencia qualquer infraestrutura para você nos bastidores.

Os prós e contras da arquitetura sem servidor

Dada essa definição expandida da arquitetura “Serverless”, vejamos alguns dos prós e contras ao trabalhar com o Lambda.

Prós

Preços de uso sob demanda.
A hospedagem de servidor tradicional usa um ciclo de cobrança recorrente. Seu servidor está sempre funcionando, usando recursos e aguardando entrada. Você paga uma taxa mensal ou anual para mantê-lo funcionando durante o ciclo de cobrança. Com o Lambda, você é cobrado apenas pelos recursos computacionais que usa, não pelo tempo ocioso. O Lambda tem dois modelos de precificação de uso: duração e simultaneidade.

Preços
de duração O preço de duração do Lambda calcula os preços com base no momento em que a função começa a ser executada até o seu término. Esse cálculo de preço é benéfico para projetos que utilizam recursos computacionais de curta duração. Você pode economizar uma quantia significativa de dinheiro em relação às soluções tradicionais de hospedagem “ociosas”.

O preço da duração do lambda é o seguinte:

  • US$ 0,20 por 1 milhão de solicitações
  • $ 0,00001667 para cada GB-segundo de duração do tempo de computação, com cada execução arredondada para os 100 ms mais próximos

Precificação de simultaneidade A precificação
do modo "Concorrência provisionada" calcula o preço desde o momento em que é ativada até a desativação. O modo de simultaneidade mantém as funções lambda prontas e remove qualquer tempo de inicialização do modo de duração.

Os preços de simultaneidade do Lambda são os seguintes:

  • A simultaneidade provisionada é de US$ 0,0000041667 para cada GB-segundo
  • As solicitações custam US$ 0,20 por 1 milhão de solicitações
  • A duração é de US$ 0,0000097222 para cada GB-segundo

Auto dimensionamento integrado
Em uma infraestrutura hospedada tradicional, chega um momento em que você pode precisar se preocupar com desempenho e dimensionamento. À medida que o tráfego e o uso do seu aplicativo aumentam, pode ser necessário adicionar mais servidores hospedados à sua infraestrutura para acompanhar a demanda. O dimensionamento autogerenciado pode causar falhas e gargalos para seus usuários. O Lambda cuida do dimensionamento automaticamente quando necessário, removendo a sobrecarga cognitiva adicional.

Contras

Fluxo de trabalho de desenvolvimento local inconsistente.

Você pode escrever o código da função Lambda localmente e testá-lo isoladamente. Ainda assim, você não poderá simular um ambiente de produção localmente sem criar sua versão hackeada do Lambda.

Conceitos-chave do Lambda: código e gatilhos

O Lambda tem dois conceitos principais: código e gatilhos . O código é autoexplicativo. No nosso caso, é o código JavaScript que você escreve e carrega no Lambda para produzir os comportamentos desejados.

Uma vez carregado, o código não será executado por conta própria. É aí que entram os gatilhos. Os gatilhos são eventos disparados por outros serviços da AWS que passam dados para a função do Lambda para execução.

Alguns exemplos de gatilhos são vistos quando:

  • uma solicitação HTTP para o AWS API Gateway aciona o código Lambda
  • um evento é acionado em um intervalo, como um cron job do CloudWatch Events
  • uma tabela do DynamoDB é atualizada e aciona o código Lambda

Assinatura de função de código lambda

Você define uma função Lambda exportando uma função regular do JavaScript que corresponde à assinatura Lambda esperada:

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

A função recebe três argumentos:

event: um dicionário de par chave-valor de “dados de gatilho” que o Lambda passa para a função.

context: informações internas da AWS, como ID de solicitação da AWS, tempo limite de expiração do Lambda e informações de log. Para obter mais informações, consulte os documentos do Lambda .

callback: um manipulador de retorno de chamada JavaScript assíncrono padrão. Para obter mais informações, consulte os documentos do Lambda

Construindo uma função Lambda

Para começar a criar uma nova função do Lambda, visite o painel do Lambda .

Deve ser semelhante a isto:

O painel Lambda

Clique no botão Criar função para começar.

Criar função

A próxima tela apresentará algumas opções para criar a função Lambda.

Opções de criação do Lambda

As opções são:

  • Autor do zero
  • Use um plano
  • Imagem do contêiner
  • Navegue pelo repositório de aplicativos sem servidor

Para nossos propósitos, selecione Autor do zero e preencha a seção “Informações básicas”. Adicione um nome de função. (Eu usei “GithubGet” abaixo.) Clique no botão Criar função para continuar.

Visão geral da função

Estamos agora na tela de visão geral da função.

A visão geral da função

O painel de visão geral da função superior contém o acionador, a função e o destino das funções. O painel inferior contém a fonte de código e guias para outras configurações. Em seguida, adicionaremos um gatilho à função. Clique no botão Adicionar gatilho .

Adicionar gatilho

Na tela Adicionar gatilho, faça o seguinte:

  1. selecione "API Gateway" no menu suspenso
  2. selecione "Criar uma API" no menu suspenso da API
  3. selecione a opção API HTTP
  4. selecione "Abrir" no menu suspenso Segurança

A configuração final do acionador deve ficar assim:

A tela Adicionar gatilho

Clique no botão Adicionar para continuar.

Especificando o código de função do Lambda

Agora temos um gatilho do API Gateway registrado na página de visão geral da função antes de nossa função GithubGet.

A função com gatilho

No painel inferior, clique na guia “Código” para visualizar o editor de código. Há um "Hello, World!" pré-configurado exemplo de código que se parece com isso:

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Agora que temos o gatilho do API Gateway, podemos acessar publicamente essa função. Clique na aba “Configuration” e na aba “Triggers” e expanda o trigger “API Gateway”.

A configuração do gatilho

Você deve ver um endpoint de API: entrada com um URL. Clique nesse URL e você deve acessar uma página que renderiza um “Hello From Lambda!” mensagem. Parabéns! Você configurou uma instância simples do AWS Lambda. O editor embutido requer pouca sobrecarga para colocar o código Lambda em funcionamento, mas faremos algo mais avançado para este tutorial.

Criando funções complexas com dependências

Na maioria dos cenários do mundo real, você desejará criar funções mais complexas usando bibliotecas de terceiros instaladas via npm.

Vamos criar uma função personalizada que usa uma dependência npm e carregá-la no Lambda. Você pode seguir as etapas abaixo ou ficar à vontade para pegar o código do repositório de exemplo .

Criando uma nova função

Vamos configurar uma pasta para nossa nova função e, de dentro, inicializar o npm com um package.jsonarquivo padrão:

npm init -f

Em seguida, instalaremos o cliente oficial do GitHub:

npm install @octokit/rest

Crie o arquivo index.jscom o seguinte código:

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

Aqui está um detalhamento do que esse código está fazendo:

  • Inclui e inicializa a API de descanso “Octokit” do GitHub.
  • Ele define uma função handlerque corresponde à assinatura do Lambda.
  • Quando handleré chamado, ele faz uma solicitação de pesquisa ao GitHub para todos os repositórios que correspondem sitepointa uma consulta.
  • Com a resposta do Github, é criado um mapa que inclui URL e contagem de estrelas para cada repositório.
  • Por fim, ele retorna uma resposta HTTP como um objeto que corresponde à integração esperada do API Gateway .

Carregar no AWS Lambda

Crie um arquivo zip dos arquivos da função usando qualquer utilitário zip com o qual você esteja familiarizado. Eu usei o utilitário de linha zipde comando no macOS, assim:

zip -r lambdaupload.zip ./index.js ./node_modules/

Para fazer upload de código para o Lambda, retorne ao Editor de código na visão geral da função e clique no seletor Upload from e selecione “.zip”.

O carregamento zip

Em seguida, selecione o lambdaupload.ziparquivo do seu computador e faça upload para a AWS. Você deve ver a atualização do editor de código e fazer o upload do manipulador que escrevemos acima. Se você visitar a URL do endpoint da API que encontramos na configuração do gatilho, você verá uma nova resposta em vez de “Hello from Lambda!” mensagem. Parabéns! Você implantou e acionou o código com êxito no Lambda.

Próximos passos e o futuro da Lambda

Espero que este projeto tenha lhe dado uma boa base para trabalhar com o AWS Lambda. Embora tenhamos usado uma integração de cliente de terceiros (GitHub) em nosso código de função, isso pode ser substituído por qualquer outra API de cliente ou uma conexão de cliente de banco de dados.

Estruturas sem servidor

Este artigo demonstra um processo muito manual e um tanto efêmero de configuração do Lambda. Existem outras maneiras de configurar e inicializar o Lambda orientado pela API da AWS.

Algumas ferramentas e estruturas estão sendo criadas com base na API da AWS que ajudam a simplificar esse processo:

serverless.com : este é o framework FaaS mais maduro. Ele oferece uma experiência Lambda muito abrangente e se aplica a outros provedores de FaaS não AWS. Ele fornece uma configuração de ambiente de desenvolvimento local para iteração rápida, implantação automatizada de código Lambda, vários ambientes de teste de implantação e muito mais.

terraform.io : esta é uma ferramenta de gerenciamento de configuração e infraestrutura como código amplamente adotada. O Terraform permite que os desenvolvedores definam de forma declarativa as configurações de infraestrutura de nuvem e, em seguida, implantem e sincronizem automaticamente essas configurações. No exercício anterior do Lambda, fizemos muitas configurações manuais por meio da interface do usuário do navegador da AWS. Esse trabalho foi bastante tedioso e, se precisarmos alterar alguma coisa, teríamos que trabalhar mais na interface do usuário da AWS. Em vez disso, poderíamos definir os recursos que usamos na AWS com o Terraform e fazer com que o Terraform implante automaticamente a função Lambda. 

Fonte: https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Crie Microsserviços Sem Servidor Com Node.js E AWS Lambda
Anne  de Morel

Anne de Morel

1659456000

Créez Des Microservices Sans Serveur Avec Node.js Et AWS Lambda

 Si vous avez toujours voulu écrire une application Web ou une API sans vous soucier du serveur, Lambda d'Amazon pourrait être ce que vous recherchez.

Amazon Web Services (AWS) est une collection d'outils de développement qu'Amazon développe et propose publiquement. Cet article vous permettra d'être opérationnel avec Lambda, un outil de la suite AWS. Nous utiliserons Lambda pour créer un point de terminaison HTTP GET qui effectuera des requêtes à l'aide de l' API GitHub pour extraire les informations du référentiel de GitHub et renvoyer une réponse JSON.

Le slogan de Lambda est « Exécuter le code sans penser aux serveurs ». À première vue, cela peut sembler déroutant. Où ou comment le code s'exécute-t-il alors? Découvrons-le.

Pour suivre cet article, vous aurez besoin de votre propre compte AWS. Vous pouvez créer un compte AWS gratuit sur aws.amazon.com .

Créez des microservices sans serveur avec Node.js et AWS Lambda

Sans serveur et fonctionne en tant que service

"Serverless" est un terme d'infrastructure logicielle dont vous avez peut-être entendu parler. Il décrit une solution pour l'exécution de code à la demande. Le terme "sans serveur" peut être trompeur car il y a encore des serveurs dans l'équation. Un meilleur descripteur est FaaS, ou "fonctionne comme un service".

Les deux définitions décrivent une nouvelle expérience de développement et de déploiement. Cette expérience est considérée comme "sans serveur" car vous, en tant que développeur, n'avez plus à gérer, surveiller ou mettre à l'échelle les serveurs qui exécutent votre code. Vous téléchargez votre code vers un fournisseur FaaS (AWS Lambda, dans ce cas), et le fournisseur FaaS l'exécute et gère toute infrastructure pour vous dans les coulisses.

Les avantages et les inconvénients de l'architecture sans serveur

Compte tenu de cette définition élargie de l'architecture « sans serveur », examinons quelques-uns des avantages et des inconvénients de l'utilisation de Lambda.

Avantages

Tarification d'utilisation à la demande.
L'hébergement de serveur traditionnel utilise un cycle de facturation récurrent. Votre serveur est toujours opérationnel, utilise des ressources et attend une entrée. Vous payez des frais mensuels ou annuels pour le faire fonctionner pendant toute la durée de votre cycle de facturation. Avec Lambda, vous n'êtes facturé que pour les ressources de calcul que vous utilisez, pas pour le temps d'inactivité. Lambda a deux modèles de tarification d'utilisation : la durée et la simultanéité.

Tarification
de la durée La tarification de la durée Lambda calcule les prix en fonction du moment où la fonction commence à s'exécuter jusqu'à ce qu'elle se termine. Ce calcul de prix est avantageux pour les projets utilisant des ressources de calcul à courte durée de vie. Vous pouvez économiser beaucoup d'argent par rapport aux solutions d'hébergement traditionnelles "inactives".

La tarification de la durée Lambda est la suivante :

  • 0,20 $ pour 1 million de requêtes
  • 0,00001667 $ pour chaque Go-seconde de temps de calcul, chaque exécution étant arrondie aux 100 ms les plus proches

Tarification de la simultanéité La tarification
du mode « Concurrence provisionnée » calcule le prix à partir du moment où elle est activée jusqu'à sa désactivation. Le mode simultané maintient les fonctions lambda prêtes et supprime tout temps de démarrage du mode durée.

La tarification de la simultanéité Lambda est la suivante :

  • La simultanéité provisionnée est de 0,0000041667 $ pour chaque Go-seconde
  • Les demandes sont de 0,20 $ par 1 million de demandes
  • La durée est de 0,0000097222 $ pour chaque Go-seconde

Mise à l'échelle automatique intégrée
Dans une infrastructure hébergée traditionnelle, il arrive un moment où vous devrez peut-être vous soucier des performances et de la mise à l'échelle. À mesure que le trafic et l'utilisation de votre application augmentent, vous devrez peut-être ajouter davantage de serveurs hébergés à votre infrastructure pour répondre à la demande. La mise à l'échelle autogérée peut entraîner des pannes et des goulots d'étranglement pour vos utilisateurs. Lambda s'occupe de la mise à l'échelle automatiquement en cas de besoin, supprimant ainsi les frais généraux cognitifs supplémentaires.

Les inconvénients

Workflow de développement local incohérent.

Vous pouvez écrire le code de la fonction Lambda localement et le tester de manière isolée. Néanmoins, vous ne pourrez pas simuler un environnement de production localement sans créer votre version piratée de Lambda.

Concepts clés Lambda : code et déclencheurs

Lambda a deux concepts principaux : le code et les déclencheurs . Le code est explicite. Dans notre cas, il s'agit du code JavaScript que vous écrivez et chargez sur Lambda pour produire les comportements souhaités.

Une fois téléchargé, le code ne s'exécutera pas tout seul. C'est là qu'interviennent les déclencheurs. Les déclencheurs sont des événements déclenchés par d'autres services AWS qui transmettent des données à la fonction Lambda pour exécution.

Quelques exemples de déclencheurs s'affichent lorsque :

  • une requête HTTP à AWS API Gateway déclenche le code Lambda
  • un événement est déclenché sur un intervalle, comme une tâche cron de CloudWatch Events
  • une table DynamoDB est mise à jour et déclenche le code Lambda

Signature de la fonction de code Lambda

Vous définissez une fonction Lambda en exportant une fonction standard à partir de JavaScript qui correspond à la signature Lambda attendue :

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

La fonction reçoit trois arguments :

event: un dictionnaire de paires clé-valeur de « données de déclenchement » que Lambda transmet à la fonction.

context: informations internes AWS telles que l'ID de demande AWS, le délai d'expiration Lambda et les informations de journal. Pour plus d'informations, consultez la documentation Lambda .

callback: un gestionnaire de rappel JavaScript asynchrone standard. Pour plus d'informations, consultez les documents Lambda

Création d'une fonction Lambda

Pour commencer à créer une nouvelle fonction Lambda, consultez le tableau de bord Lambda .

Cela devrait ressembler à ceci :

Le tableau de bord Lambda

Cliquez sur le bouton Créer une fonction pour commencer.

Créer une fonction

L'écran suivant vous proposera quelques options pour créer la fonction Lambda.

Lambda créer des options

Les options sont :

  • Auteur à partir de rien
  • Utiliser un plan
  • Image du conteneur
  • Parcourir le référentiel d'applications sans serveur

Pour nos besoins, sélectionnez Auteur à partir de zéro et remplissez la section « Informations de base ». Ajoutez un nom de fonction. (J'ai utilisé "GithubGet" ci-dessous.) Cliquez sur le bouton Créer une fonction pour continuer.

Aperçu des fonctions

Nous sommes maintenant à l'écran d'aperçu des fonctions.

La vue d'ensemble des fonctions

Le volet supérieur de présentation des fonctions contient le déclencheur, la fonction et la destination des fonctions. Le volet inférieur contient le code source et des onglets pour d'autres configurations. Ensuite, nous ajouterons un déclencheur à la fonction. Cliquez sur le bouton Ajouter un déclencheur .

Ajouter un déclencheur

Sur l'écran Ajouter un déclencheur, procédez comme suit :

  1. sélectionnez "API Gateway" dans la liste déroulante
  2. sélectionnez "Créer une API" dans la liste déroulante des API
  3. sélectionnez l'option API HTTP
  4. sélectionnez "Ouvrir" dans le menu déroulant Sécurité

La configuration finale du déclencheur devrait ressembler à ceci :

L'écran Ajouter un déclencheur

Cliquez sur le bouton Ajouter pour continuer.

Spécification du code de la fonction Lambda

Nous avons maintenant un déclencheur API Gateway enregistré sur la page de présentation de la fonction avant notre fonction GithubGet.

La fonction avec gâchette

Dans le volet inférieur, cliquez sur l'onglet "Code" pour afficher l'éditeur de code. Il y a un pré-configuré "Hello, World!" exemple de code qui ressemble à ceci :

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Maintenant que nous avons le déclencheur API Gateway en place, nous pouvons accéder publiquement à cette fonction. Cliquez sur l'onglet "Configuration" et l'onglet "Déclencheurs" et développez le déclencheur "API Gateway".

La configuration du déclencheur

Vous devriez voir une entrée API endpoint : avec une URL. Cliquez sur cette URL, et vous devriez atteindre une page qui affiche un "Hello From Lambda!" message. Toutes nos félicitations! Vous avez configuré une instance AWS Lambda simple. L'éditeur en ligne nécessite peu de surcharge pour que le code Lambda soit opérationnel, mais nous allons faire quelque chose de plus avancé pour ce didacticiel.

Créer des fonctions complexes avec des dépendances

Dans la plupart des scénarios réels, vous souhaiterez créer des fonctions plus complexes à l'aide de bibliothèques tierces installées via npm.

Créons une fonction personnalisée qui utilise une dépendance npm et chargeons-la sur Lambda. Vous pouvez suivre les étapes ci-dessous, ou n'hésitez pas à récupérer le code à partir de l'exemple de référentiel .

Créer une nouvelle fonction

Configurons un dossier pour notre nouvelle fonction et, de l'intérieur, initialisons npm avec un package.jsonfichier par défaut :

npm init -f

Ensuite, nous allons installer le client GitHub officiel :

npm install @octokit/rest

Créez le fichier index.jsavec le code suivant :

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

Voici une ventilation de ce que fait ce code :

  • Il inclut et initialise l'API de repos GitHub "Octokit".
  • Il définit une fonction handlerqui correspond à la signature Lambda.
  • Lorsqu'il handlerest appelé, il envoie une requête de recherche à GitHub pour tous les dépôts qui correspondent sitepointà une requête.
  • Avec la réponse de Github, une carte est créée qui inclut l'URL et le nombre d'étoiles pour chaque référentiel.
  • Enfin, il renvoie une réponse HTTP comme un objet qui correspond à l' intégration attendue de la passerelle API .

Charger sur AWS Lambda

Créez un fichier zip des fichiers de la fonction à l'aide de l'utilitaire zip que vous connaissez. J'ai utilisé l' ziputilitaire de ligne de commande sur macOS, comme ceci :

zip -r lambdaupload.zip ./index.js ./node_modules/

Pour charger du code dans Lambda, revenez à l'éditeur de code dans la vue d'ensemble des fonctions et cliquez sur le sélecteur Charger depuis et sélectionnez « .zip ».

Le téléchargement de zip

Sélectionnez ensuite le lambdaupload.zipfichier sur votre ordinateur et chargez-le sur AWS. Vous devriez voir l'éditeur de code s'actualiser et télécharger le gestionnaire que nous avons écrit ci-dessus. Si vous visitez l'URL du point de terminaison de l'API que nous avons trouvée à partir de la configuration du déclencheur, vous devriez voir une nouvelle réponse au lieu du « Hello from Lambda ! message. Toutes nos félicitations! Vous avez déployé et déclenché avec succès du code sur Lambda.

Prochaines étapes et avenir de Lambda

J'espère que ce projet vous a donné une bonne base pour travailler avec AWS Lambda. Bien que nous ayons utilisé une intégration de client tiers (GitHub) dans notre code de fonction, celle-ci peut être remplacée par toute autre API client ou une connexion client de base de données.

Frameworks sans serveur

Cet article illustre un processus très manuel et quelque peu éphémère de configuration Lambda. Il existe d'autres façons de configurer et d'initialiser Lambda piloté par l'API AWS.

Certains outils et cadres sont construits sur l'API AWS pour aider à rationaliser ce processus :

serverless.com : c'est le framework FaaS le plus mature. Il offre une expérience Lambda très complète et s'applique à d'autres fournisseurs FaaS non AWS. Il fournit une configuration d'environnement de développement local pour une itération rapide, un déploiement de code Lambda automatisé, plusieurs environnements de déploiement de déploiement, et bien plus encore.

terraform.io : il s'agit d'un outil de gestion d'infrastructure en tant que code et de configuration largement adopté. Terraform permet aux développeurs de définir de manière déclarative des configurations d'infrastructure cloud, puis de déployer et de synchroniser automatiquement ces configurations. Dans l'exercice Lambda précédent, nous avons effectué de nombreuses configurations manuelles via l'interface utilisateur du navigateur AWS. Ce travail était assez fastidieux, et si nous devions changer quoi que ce soit, nous devions travailler davantage dans l'interface utilisateur AWS. Au lieu de cela, nous pourrions définir les ressources que nous utilisions sur AWS avec Terraform et demander à Terraform de déployer automatiquement la fonction Lambda. 

Source : https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Créez Des Microservices Sans Serveur Avec Node.js Et AWS Lambda
Diego  Elizondo

Diego Elizondo

1659454620

Cree Microservicios Sin Servidor Con Node.js Y AWS Lambda

 Si alguna vez ha querido escribir una aplicación web o una API sin jugar con el servidor, Lambda de Amazon podría ser lo que está buscando.

Amazon Web Services (AWS) es una colección de herramientas para desarrolladores que Amazon desarrolla y ofrece públicamente. Este artículo lo pondrá en funcionamiento con Lambda, una herramienta en la suite de AWS. Usaremos Lambda para crear un punto final HTTP GET que realizará solicitudes usando la API de GitHub para extraer información del repositorio de GitHub y devolver una respuesta JSON.

El lema de Lambda es "Ejecutar código sin pensar en los servidores". A primera vista, esto puede sonar confuso. ¿Dónde o cómo se ejecuta el código entonces? Vamos a averiguar.

Para continuar con este artículo, necesitará una cuenta de AWS propia. Puede crear una cuenta gratuita de AWS en aws.amazon.com .

Cree microservicios sin servidor con Node.js y AWS Lambda

Sin servidor y funciones como servicio

"Sin servidor" es un término de infraestructura de software del que quizás haya oído hablar. Describe una solución para la ejecución de código bajo demanda. El término "sin servidor" puede ser engañoso porque todavía hay servidores en la ecuación. Una mejor descripción es FaaS, o "funciones como servicio".

Ambas definiciones describen una nueva experiencia de desarrollo e implementación. Esta experiencia se considera "sin servidor" porque usted, como desarrollador, ya no tiene que administrar, monitorear o escalar los servidores que ejecutan su código. Sube su código a un proveedor de FaaS (AWS Lambda, en este caso), y el proveedor de FaaS lo ejecuta y administra cualquier infraestructura detrás de escena.

Los pros y los contras de la arquitectura sin servidor

Dada esta definición ampliada de la arquitectura "sin servidor", veamos algunos de los pros y los contras cuando se trabaja con Lambda.

ventajas

Precios de uso bajo demanda.
El alojamiento de servidor tradicional utiliza un ciclo de facturación recurrente. Su servidor siempre está en funcionamiento, utilizando recursos y esperando entradas. Usted paga una tarifa mensual o anual para mantenerlo en funcionamiento durante la duración de su ciclo de facturación. Con Lambda, solo se le factura por los recursos informáticos que utiliza, no por el tiempo de inactividad. Lambda tiene dos modelos de precios de uso: duración y concurrencia.

Fijación de precios
por duración La fijación de precios por duración de Lambda calcula los precios en función del momento en que la función comienza a ejecutarse hasta que finaliza. Este cálculo de precio es beneficioso para proyectos que utilizan recursos computacionales de corta duración. Puede ahorrar una cantidad significativa de dinero en comparación con las soluciones de alojamiento tradicionales "inactivas".

El precio de duración de Lambda es el siguiente:

  • $0.20 por 1 millón de solicitudes
  • $0.00001667 por cada GB-segundo de tiempo de computación, con cada ejecución redondeada a los 100ms más cercanos

Precios de simultaneidad Los precios
del modo "Simultaneidad aprovisionada" calculan el precio desde el momento en que se habilita hasta que se deshabilita. El modo de concurrencia mantiene listas las funciones lambda y elimina cualquier tiempo de inicio del modo de duración.

Los precios de simultaneidad de Lambda son los siguientes:

  • La simultaneidad aprovisionada es de $0.0000041667 por cada GB-segundo
  • Las solicitudes cuestan $0.20 por 1 millón de solicitudes
  • La duración es $0.0000097222 por cada GB-segundo

Escalado automático integrado
En una infraestructura alojada tradicional, llega un momento en el que es posible que deba preocuparse por el rendimiento y el escalado. A medida que aumenta el tráfico y el uso de su aplicación, es posible que deba agregar más servidores alojados a su infraestructura para satisfacer la demanda. El escalado autogestionado puede causar fallas y cuellos de botella para sus usuarios. Lambda se encarga de escalar automáticamente cuando es necesario, eliminando la sobrecarga cognitiva adicional.

Contras

Flujo de trabajo de desarrollo local inconsistente.

Puede escribir el código de la función Lambda localmente y probarlo de forma aislada. Aún así, no podrá simular un entorno de producción localmente sin crear su versión pirateada de Lambda.

Conceptos clave de Lambda: código y disparadores

Lambda tiene dos conceptos principales: código y disparadores . El código se explica por sí mismo. En nuestro caso, es el código JavaScript que escribe y carga en Lambda para producir los comportamientos deseados.

Una vez cargado, el código no se ejecutará por sí solo. Aquí es donde entran los disparadores. Los disparadores son eventos disparados por otros servicios de AWS que pasan datos a la función de Lambda para su ejecución.

Algunos desencadenantes de ejemplo se ven cuando:

  • una solicitud HTTP a AWS API Gateway activa el código Lambda
  • un evento se activa en un intervalo, como un trabajo cron de CloudWatch Events
  • una tabla de DynamoDB se actualiza y activa el código Lambda

Firma de función de código lambda

Una función Lambda se define exportando una función normal desde JavaScript que coincida con la firma Lambda esperada:

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

La función recibe tres argumentos:

event: un diccionario de par clave-valor de "datos de activación" que Lambda pasa a la función.

context: información interna de AWS, como el ID de solicitud de AWS, el tiempo de espera de caducidad de Lambda y la información de registro. Para obtener más información, consulte los documentos de Lambda .

callback: un controlador de devolución de llamada de JavaScript asíncrono estándar. Para obtener más información, consulte los documentos de Lambda

Creación de una función Lambda

Para comenzar a crear una nueva función de Lambda, visite el panel de control de Lambda .

Debería verse similar a esto:

El tablero de Lambda

Haga clic en el botón Crear función para comenzar.

Crear función

La siguiente pantalla le mostrará algunas opciones para crear la función Lambda.

Opciones de creación de Lambda

Las opciones son:

  • Autor desde cero
  • Usa un plano
  • Imagen del contenedor
  • Examinar el repositorio de aplicaciones sin servidor

Para nuestros propósitos, seleccione Autor desde cero y complete la sección "Información básica". Agregue un nombre de función. (He usado "GithubGet" a continuación). Haga clic en el botón Crear función para continuar.

Resumen de funciones

Ahora estamos en la pantalla de resumen de funciones.

Resumen de funciones

El panel superior de descripción general de funciones contiene el disparador de funciones, la función y el destino. El panel inferior contiene el código fuente y las pestañas para otras configuraciones. A continuación, agregaremos un disparador a la función. Haga clic en el botón Agregar activador .

Agregar disparador

En la pantalla Agregar disparador, haga lo siguiente:

  1. seleccione "Puerta de enlace API" en el menú desplegable
  2. seleccione "Crear una API" en el menú desplegable de API
  3. seleccione la opción API HTTP
  4. seleccione "Abrir" en el menú desplegable Seguridad

La configuración final del disparador debería verse así:

La pantalla Agregar activador

Haga clic en el botón Agregar para continuar.

Especificación del código de la función Lambda

Ahora tenemos un disparador API Gateway registrado en la página de descripción general de la función antes de nuestra función GithubGet.

La función con gatillo

En el panel inferior, haga clic en la pestaña "Código" para ver el editor de código. Hay un "¡Hola, mundo!" preconfigurado. ejemplo de código que se ve así:

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Ahora que tenemos el activador de API Gateway en su lugar, podemos acceder públicamente a esta función. Haga clic en la pestaña "Configuración" y en la pestaña "Activadores" y expanda el activador "API Gateway".

La configuración del disparador

Debería ver un punto final de API: entrada con una URL. Haga clic en esa URL y debería acceder a una página que muestra un mensaje de "¡Hola de Lambda!" mensaje. ¡Felicidades! Ha configurado una instancia simple de AWS Lambda. El editor en línea requiere poca sobrecarga para poner en funcionamiento el código Lambda, pero vamos a hacer algo más avanzado para este tutorial.

Creación de funciones complejas con dependencias

En la mayoría de los escenarios del mundo real, querrá crear funciones más complejas utilizando bibliotecas de terceros instaladas a través de npm.

Vamos a crear una función personalizada que use una dependencia npm y subirla a Lambda. Puede seguir los pasos a continuación, o siéntase libre de obtener el código del repositorio de ejemplo .

Creando una nueva función

Configuremos una carpeta para nuestra nueva función y, desde dentro, inicialicemos npm con un package.jsonarchivo predeterminado:

npm init -f

A continuación, instalaremos el cliente oficial de GitHub:

npm install @octokit/rest

Cree el archivo index.jscon el siguiente código:

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

Aquí hay un desglose de lo que está haciendo este código:

  • Incluye e inicializa la API de reposo "Octokit" de GitHub.
  • Define una función handlerque coincide con la firma de Lambda.
  • Cuando handlerse llama, realiza una solicitud de búsqueda a GitHub para todos los repositorios que coincidan sitepointcon una consulta.
  • Con la respuesta de Github, se crea un mapa que incluye URL y recuento de estrellas para cada repositorio.
  • Finalmente, devuelve una respuesta HTTP como un objeto que coincide con la integración esperada de API Gateway .

Subir a AWS Lambda

Cree un archivo zip de los archivos de la función utilizando cualquier utilidad zip con la que esté familiarizado. Usé la ziputilidad de línea de comandos en macOS, así:

zip -r lambdaupload.zip ./index.js ./node_modules/

Para cargar código en Lambda, regrese al editor de código en la descripción general de la función y haga clic en el selector Cargar desde y seleccione ".zip".

La carga zip

Luego, seleccione el lambdaupload.ziparchivo de su computadora y cárguelo en AWS. Debería ver la actualización del editor de código y tener cargado el controlador que escribimos anteriormente. Si visita la URL del punto final de la API que encontramos en la configuración del disparador, debería ver una nueva respuesta en lugar de "¡Hola, de Lambda!" mensaje. ¡Felicidades! Implementó y activó correctamente el código en Lambda.

Próximos pasos y el futuro de Lambda

Espero que este proyecto le haya brindado una buena base para trabajar con AWS Lambda. Aunque usamos una integración de cliente de terceros (GitHub) dentro de nuestro código de función, esto puede ser reemplazado por cualquier otra API de cliente o una conexión de cliente de base de datos.

Marcos sin servidor

Este artículo demuestra un proceso muy manual y algo efímero de configuración de Lambda. Hay otras formas de configurar e inicializar Lambda impulsado por la API de AWS.

Algunas herramientas y marcos se están construyendo sobre la API de AWS que ayudan a optimizar este proceso:

serverless.com : este es el marco FaaS más maduro. Ofrece una experiencia Lambda muy completa y se aplica a otros proveedores de FaaS que no son de AWS. Proporciona una configuración de entorno de desarrollo local para una iteración rápida, implementación automatizada de código Lambda, múltiples entornos de prueba de implementación y mucho más.

terraform.io : esta es una herramienta de administración de configuración e infraestructura como código ampliamente adoptada. Terraform permite a los desarrolladores definir de forma declarativa las configuraciones de la infraestructura de la nube y luego implementar y sincronizar automáticamente esas configuraciones. En el ejercicio anterior de Lambda, hicimos mucha configuración manual a través de la interfaz de usuario del navegador de AWS. Este trabajo fue bastante tedioso y, si necesitamos cambiar algo, tendríamos que trabajar más en la interfaz de usuario de AWS. En cambio, podríamos definir los recursos que usamos en AWS con Terraform y hacer que Terraform implemente automáticamente la función Lambda. 

Fuente: https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Cree Microservicios Sin Servidor Con Node.js Y AWS Lambda
Thai  Son

Thai Son

1659452400

Tạo Các Dịch Vụ Không Máy Chủ Với Node.js Và AWS Lambda

 If you’ve ever wanted to write a web app or API without messing around with the server, Amazon’s Lambda might be what you’re looking for.

Amazon Web Services (AWS) is a collection of developer tools that Amazon develops and publicly offers.This article will get you up and running with Lambda, a tool in the AWS suite. We’ll be using Lambda to create an HTTP GET endpoint that will make requests using the GitHub API to pull repository info from GitHub and return a JSON response.

The Lambda tagline is “Run Code without Thinking about Servers”. At first glance, this may sound confusing. Where or how does the code run then? Let’s find out.

To follow along with this article, you’ll need an AWS account of your own. You can create a free AWS account at aws.amazon.com.

Create Serverless Microservices with Node.js and AWS Lambda

Serverless and Functions as a Service

“Serverless” is a software infrastructure term you may have heard about. It describes a solution for on-demand code execution. The term “serverless” can be misleading because there are still servers in the equation. A better descriptor is FaaS, or “functions as a service.”

Both definitions describe a new development and deployment experience. This experience is considered “serverless” because you, as a developer, no longer have to manage, monitor, or scale any servers that are running your code. You upload your code to a FaaS provider (AWS Lambda, in this case), and the FaaS provider executes it and manages any infrastructure for you behind the scenes.

The Pros and Cons of Serverless Architecture

Given this expanded definition of the “Serverless” architecture, let’s look at some of the pros and cons when working with Lambda.

Pros

On-demand usage pricing.
Traditional server hosting uses a recurring billing cycle. Your server is always up and running, using resources and waiting for input. You pay a monthly or yearly fee to keep it running for the duration of your billing cycle. With Lambda, you’re only billed for computational resources that you use, not idle time. Lambda has two usage pricing models: duration and concurrency.

Duration pricing
Lambda duration pricing calculates prices based on the time the function begins executing until it terminates. This price calculation is beneficial for projects using short-lived computational resources. You can save a significant amount of money over traditional “idle” hosting solutions.

Lambda duration pricing is as follows:

  • $0.20 per 1 million requests
  • $0.00001667 for every GB-second duration of computing time, with every execution rounded up to the nearest 100ms

Concurrency pricing
“Provisioned Concurrency” mode pricing calculates the price from the time it’s enabled until disabled. Concurrency mode keeps lambda functions ready and removes any startup time from duration mode.

Lambda concurrency pricing is as follows:

  • Provisioned Concurrency is $0.0000041667 for every GB-second
  • Requests are $0.20 per 1M requests
  • Duration is $0.0000097222 for every GB-second

Built-in auto scaling
In a traditional hosted infrastructure, there comes a time where you may need to worry about performance and scaling. As the traffic and usage of your application increase, you may need to add more hosted servers to your infrastructure to keep up with demand. Self-managed scaling can cause failures and bottlenecks for your users. Lambda takes care of scaling automatically when needed, removing additional cognitive overhead.

Cons

Inconsistent local development workflow.

You can write Lambda function code locally and test it in isolation. Still, you won’t be able to simulate a production environment locally without creating your hacked-together version of Lambda.

Lambda Key Concepts: Code and Triggers

Lambda has two main concepts: code and triggers. Code is self-explanatory. In our case, it’s the JavaScript code that you write and upload to Lambda to produce your desired behaviors.

Once uploaded, the code won’t execute on its own. This is where triggers come in. Triggers are events fired by other AWS services that pass data to the Lambda function for execution.

Some example triggers are seen when:

  • an HTTP request to AWS API Gateway fires Lambda code
  • an event is fired on an interval, like a cron job from CloudWatch Events
  • a DynamoDB table is updated and triggers Lambda code

Lambda code function signature

You define a Lambda function by exporting a regular function from JavaScript that matches the expected Lambda signature:

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

The function receives three arguments:

event: a key-value pair dictionary of “trigger data” that Lambda passes to the function.

context: AWS internal information such as AWS request ID, Lambda expiration timeout, and Log info. For more info, see the Lambda docs.

callback: a standard async JavaScript callback handler. For more info see the Lambda docs

Building a Lambda Function

To get started creating a new Lambda function, visit the Lambda dashboard.

It should look similar to this:

The Lambda dashboard

Click the Create function button to get started.

Create function

The next screen will prompt you with a few options for creating the Lambda function.

Lambda create options

The options are:

  • Author from scratch
  • Use a blueprint
  • Container image
  • Browse serverless app repository

For our purposes, select Author from scratch and fill out the “Basic information” section. Add a function name. (I’ve used “GithubGet” below.) Click the Create function button to continue.

Function overview

We’re now at the function overview screen.

The function overview

The upper function overview pane contains the functions trigger, function, and destination. The lower pane contains the code source and tabs for other configurations. Next, we will add a trigger to the function. Click the Add trigger button.

Add trigger

On the Add trigger screen, do the following:

  1. select “API Gateway” from the dropdown
  2. select “Create an API” from the API dropdown
  3. select the HTTP API option
  4. select “Open” from the Security dropdown

The final trigger configuration should look like this:

The Add trigger screen

Click the Add button to continue.

Specifying Lambda function code

We now have an API Gateway trigger registered back on the function overview page before our GithubGet function.

The function with trigger

In the lower pane, click the “Code” tab to view the code editor. There is a pre-configured “Hello, World!” code example that looks like this:

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Now that we have the API Gateway trigger in place, we can publicly access this function. Click on the “Configuration” tab and the “Triggers” tab and expand the “API Gateway” trigger.

The trigger configuration

You should see an API endpoint: entry with a URL. Click that URL, and you should hit a page that renders a “Hello From Lambda!” message. Congratulations! You’ve set up a simple AWS Lambda instance. The inline editor requires little overhead to get Lambda code up and running, but we’re going to do something more advanced for this tutorial.

Creating complex functions with dependencies

In most real-world scenarios, you’re going to want to create more complex functions using third-party libraries installed via npm.

Let’s create a custom function that uses an npm dependency and upload it to Lambda. You can follow the steps below, or feel free to grab the code from the example repository.

Creating a new function

Let’s set up a folder for our new function and, from within, initialize npm with a default package.json file:

npm init -f

Next, we’ll install the official GitHub client:

npm install @octokit/rest

Create the file index.js with the following code:

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

Here’s a breakdown of what this code is doing:

  • It includes and initializes the GitHub “Octokit” rest API.
  • It defines a function handler that matches the Lambda signature.
  • When handler is called, it makes a search request to GitHub for all repos that match sitepoint as a query.
  • With the response from Github, a map is created that includes URL and star count for each repo.
  • Finally, it returns an HTTP response like an object that matches the API Gateway’s expected integration.

Upload to AWS Lambda

Create a zip file of the function’s files using whatever zip utility you’re familiar with. I used the command line zip utility on macOS, like this:

zip -r lambdaupload.zip ./index.js ./node_modules/

To upload code to Lambda, return to the Code editor on the function overview and click the Upload from selector and select “.zip”.

The zip upload

Then select the lambdaupload.zip file from your computer and upload it to AWS. You should see the code editor refresh and have the handler we wrote above uploaded. If you visit the API endpoint URL that we found from the trigger configuration, you should see a new response instead of the “Hello from Lambda!” message. Congratulations! You’ve successfully deployed and triggered code on Lambda.

Next steps and the Future of Lambda

I hope this project has given you a good foundation for working with AWS Lambda. Although we used a third-party client (GitHub) integration within our function code, this can be replaced by any other client API or a database client connection.

Serverless frameworks

This article demonstrates a very manual and somewhat ephemeral process of Lambda configuration. There are other ways to configure and initialize Lambda driven by the AWS API.

Some tools and frameworks are being built on top of the AWS API that help streamline this process:

serverless.com: this is the most mature FaaS framework. It delivers a very comprehensive Lambda experience and applies to other non-AWS FaaS providers. It provides a local development environment setup for rapid iteration, automated Lambda code deployment, multiple deployment staging environments, and much more.

terraform.io: this is a widely adopted infrastructure-as-code and configuration management tool. Terraform lets developers declaratively define cloud infrastructure configurations and then automatically deploy and sync those configurations. In the previous Lambda exercise, we did a lot of manual configuration through the AWS browser UI. This work was fairly tedious, and if we need to change anything, we’d have to do further work in the AWS UI. Instead, we could define the resources we used on AWS with Terraform and have Terraform automatically deploy the Lambda function. 

Source: https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Tạo Các Dịch Vụ Không Máy Chủ Với Node.js Và AWS Lambda
郝 玉华

郝 玉华

1659450720

使用 Node.js 和 AWS Lambda 创建无服务器微服务

 如果您曾经想编写一个 Web 应用程序或 API 而不会弄乱服务器,那么Amazon 的 Lambda可能就是您想要的。

Amazon Web Services (AWS) 是 Amazon 开发并公开提供的一组开发人员工具。本文将帮助您使用 AWS 套件中的工具 Lambda 启动和运行。我们将使用 Lambda 创建一个 HTTP GET 端点,该端点将使用GitHub API发出请求,从 GitHub 提取存储库信息并返回 JSON 响应。

Lambda 的标语是“运行代码而不考虑服务器”。乍一看,这可能听起来令人困惑。那么代码在哪里或如何运行?让我们来了解一下。

要继续阅读本文,您需要一个自己的 AWS 账户。您可以在aws.amazon.com创建一个免费的 AWS 账户。

使用 Node.js 和 AWS Lambda 创建无服务器微服务

无服务器和功能即服务

“无服务器”是您可能听说过的软件基础架构术语。它描述了按需代码执行的解决方案。“无服务器”一词可能会产生误导,因为等式中仍然存在服务器。更好的描述是 FaaS,或“作为服务的功能”。

这两个定义都描述了一种新的开发和部署体验。这种体验被认为是“无服务器”,因为作为开发人员,您不再需要管理、监控或扩展任何运行您的代码的服务器。您将代码上传到 FaaS 提供商(在本例中为 AWS Lambda),FaaS 提供商会执行它并在幕后为您管理任何基础设施。

无服务器架构的优缺点

鉴于“无服务器”架构的这种扩展定义,让我们看看使用 Lambda 时的一些优缺点。

优点

按需使用定价。
传统的服务器托管使用循环计费周期。您的服务器始终启动并运行,使用资源并等待输入。您支付月费或年费以使其在计费周期内保持运行。使用 Lambda,您只需为您使用的计算资源付费,而不是空闲时间。Lambda 有两种使用定价模型:持续时间和并发性。

持续时间定价
Lambda 持续时间定价根据函数开始执行直到终止的时间计算价格。这种价格计算有利于使用短期计算资源的项目。与传统的“空闲”托管解决方案相比,您可以节省大量资金。

Lambda 持续时间定价如下:

  • 每 100 万个请求 0.20 美元
  • 每 GB 秒的计算时间为 0.00001667 USD,每次执行四舍五入到最接近的 100 毫秒

并发定价
“Provisioned Concurrency”模式定价计算从启用到禁用的价格。并发模式使 lambda 函数准备就绪,并从持续模式中删除任何启动时间。

Lambda 并发定价如下:

  • 预置并发为每 GB 秒 0.0000041667 USD
  • 每 100 万个请求的请求为 0.20 美元
  • 持续时间为每 GB 秒 0.0000097222 USD

内置自动扩展
在传统的托管基础​​架构中,有时您可能需要担心性能和扩展。随着应用程序的流量和使用量增加,您可能需要在基础架构中添加更多托管服务器以跟上需求。自我管理的扩展可能会导致用户出现故障和瓶颈。Lambda 会在需要时自动进行扩展,从而消除额外的认知开销。

缺点

本地开发工作流程不一致。

您可以在本地编写 Lambda 函数代码并单独对其进行测试。尽管如此,如果不创建 Lambda 的破解版本,您将无法在本地模拟生产环境。

Lambda 关键概念:代码和触发器

Lambda 有两个主要概念:代码触发器。代码是不言自明的。在我们的例子中,它是您编写并上传到 Lambda 以产生所需行为的 JavaScript 代码。

上传后,代码不会自行执行。这就是触发器的用武之地。触发器是由其他 AWS 服务触发的事件,它们将数据传递给 Lambda 函数以供执行。

在以下情况下会看到一些示例触发器:

  • 对 AWS API Gateway 的 HTTP 请求会触发 Lambda 代码
  • 一个事件按一定时间间隔触发,例如来自 CloudWatch Events 的 cron 作业
  • 更新 DynamoDB 表并触发 Lambda 代码

Lambda 代码函数签名

您可以通过从 JavaScript 中导出与预期 Lambda 签名匹配的常规函数​​来定义 Lambda 函数:

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

该函数接收三个参数:

event:Lambda 传递给函数的“触发数据”的键值对字典。

context:AWS 内部信息,例如 AWS 请求 ID、Lambda 过期超时和日志信息。有关更多信息,请参阅Lambda 文档

callback:一个标准的异步 JavaScript 回调处理程序。有关更多信息,请参阅Lambda 文档

构建 Lambda 函数

要开始创建新的 Lambda 函数,请访问Lambda 仪表板

它应该类似于:

Lambda 仪表板

单击创建函数按钮开始。

创建函数

下一个屏幕将提示您提供一些用于创建 Lambda 函数的选项。

Lambda 创建选项

选项包括:

  • 从零开始作者
  • 使用蓝图
  • 容器镜像
  • 浏览无服务器应用程序存储库

出于我们的目的,从头开始选择作者并填写“基本信息”部分。添加函数名称。(我在下面使用了“GithubGet”。)单击创建函数按钮继续。

功能概述

我们现在位于功能概览屏幕。

功能概述

上方的函数概览窗格包含函数触发器、函数和目标。下部窗格包含其他配置的代码源和选项卡。接下来,我们将在函数中添加一个触发器。单击添加触发器按钮。

添加触发器

在添加触发器屏幕上,执行以下操作:

  1. 从下拉列表中选择“API 网关”
  2. 从 API 下拉菜单中选择“创建 API”
  3. 选择 HTTP API 选项
  4. 从安全下拉菜单中选择“打开”

最终的触发器配置应如下所示:

添加触发器屏幕

单击添加按钮继续。

指定 Lambda 函数代码

现在,我们在 GithubGet 函数之前的函数概览页面上注册了一个 API Gateway 触发器。

带触发器的功能

在下部窗格中,单击“代码”选项卡以查看代码编辑器。有一个预先配置好的“Hello, World!” 如下所示的代码示例:

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

现在我们已经有了 API Gateway 触发器,我们可以公开访问这个函数。单击“配置”选项卡和“触发器”选项卡并展开“API 网关”触发器。

触发器配置

您应该会看到一个API 端点:带有 URL 的条目。单击该 URL,您应该会点击呈现“来自 Lambda 的您好!”的页面。信息。恭喜!您已经设置了一个简单的 AWS Lambda 实例。内联编辑器需要很少的开销来启动和运行 Lambda 代码,但我们将为本教程做一些更高级的事情。

创建具有依赖关系的复杂函数

在大多数实际场景中,您将希望使用通过 npm 安装的第三方库创建更复杂的函数。

让我们创建一个使用 npm 依赖项的自定义函数并将其上传到 Lambda。您可以按照以下步骤操作,或者随意从示例存储库中获取代码。

创建一个新函数

让我们为我们的新函数设置一个文件夹,并在其中使用默认package.json文件初始化 npm:

npm init -f

接下来,我们将安装官方 GitHub 客户端:

npm install @octokit/rest

index.js使用以下代码创建文件:

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

以下是此代码正在执行的操作的细分:

  • 它包含并初始化 GitHub “Octokit” REST API。
  • 它定义了一个handler与 Lambda 签名匹配的函数。
  • handler被调用时,它会向 GitHub 发出搜索请求,以查找所有匹配sitepoint为查询的存储库。
  • 使用来自 Github 的响应,创建了一个地图,其中包括每个 repo 的 URL 和星数。
  • 最后,它返回一个 HTTP 响应,就像一个与API Gateway 的预期集成相匹配的对象。

上传到 AWS Lambda

使用您熟悉的任何 zip 实用程序创建函数文件的 zip 文件。zip我在 macOS 上使用了命令行实用程序,如下所示:

zip -r lambdaupload.zip ./index.js ./node_modules/

要将代码上传到 Lambda,请返回函数概览上的代码编辑器,然后单击从选择器上传并选择“.zip”。

压缩包上传

然后lambdaupload.zip从您的计算机中选择文件并将其上传到 AWS。您应该会看到代码编辑器刷新并上传了我们上面编写的处理程序。如果您访问我们从触发器配置中找到的 API 端点 URL,您应该会看到一个新的响应,而不是“来自 Lambda 的您好!” 信息。恭喜!您已在 Lambda 上成功部署和触发代码。

下一步和 Lambda 的未来

我希望这个项目为您使用 AWS Lambda 打下了良好的基础。尽管我们在函数代码中使用了第三方客户端 (GitHub) 集成,但这可以被任何其他客户端 API 或数据库客户端连接替换。

无服务器框架

本文演示了一个非常手动且有些短暂的 Lambda 配置过程。还有其他方法可以配置和初始化由 AWS API 驱动的 Lambda。

一些工具和框架正在 AWS API 之上构建,以帮助简化此过程:

serverless.com:这是最成熟的 FaaS 框架。它提供了非常全面的 Lambda 体验,并适用于其他非 AWS FaaS 提供商。它为快速迭代、自动化 Lambda 代码部署、多个部署暂存环境等提供了本地开发环境设置。

terraform.io:这是一种广泛采用的基础设施即代码和配置管理工具。Terraform 允许开发人员以声明方式定义云基础设施配置,然后自动部署和同步这些配置。在之前的 Lambda 练习中,我们通过 AWS 浏览器 UI 进行了大量手动配置。这项工作相当乏味,如果我们需要更改任何内容,我们必须在 AWS UI 中做进一步的工作。相反,我们可以使用 Terraform 定义我们在 AWS 上使用的资源,并让 Terraform 自动部署 Lambda 函数。 

来源:https ://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

使用 Node.js 和 AWS Lambda 创建无服务器微服务
伊藤  直子

伊藤 直子

1659450540

Node.js と AWS Lambda を使用してサーバーレス マイクロサービスを作成する

 サーバーをいじらずに Web アプリや API を書きたいと思ったことがあるなら、Amazon の Lambdaが最適かもしれません。

アマゾン ウェブ サービス (AWS) は、Amazon が開発し、一般に提供している開発者向けツールのコレクションです。この記事では、AWS スイートのツールである Lambda を起動して実行する方法について説明します。Lambda を使用して、GitHub APIを使用してリクエストを行い、GitHub からリポジトリ情報をプルして JSON レスポンスを返す HTTP GET エンドポイントを作成します。

Lambda のキャッチフレーズは「サーバーのことを考えずにコードを実行する」です。一見すると、これは紛らわしく聞こえるかもしれません。その場合、コードはどこで、またはどのように実行されますか? 確認してみましょう。

この記事を進めるには、独自の AWS アカウントが必要です。aws.amazon.comで無料の AWS アカウントを作成できます。

Node.js と AWS Lambda を使用してサーバーレス マイクロサービスを作成する

サーバーレスとサービスとしての機能

「サーバーレス」は、聞いたことのあるソフトウェア インフラストラクチャの用語です。オンデマンド コード実行のソリューションについて説明します。「サーバーレス」という用語は誤解を招く可能性があります。これは、まだサーバーが存在するためです。より適切な記述子は FaaS、つまり「サービスとしての機能」です。

どちらの定義も、新しい開発と展開のエクスペリエンスを表しています。開発者は、コードを実行しているサーバーを管理、監視、スケーリングする必要がなくなるため、このエクスペリエンスは「サーバーレス」と見なされます。コードを FaaS プロバイダー (この場合は AWS Lambda) にアップロードすると、FaaS プロバイダーがそれを実行し、バックグラウンドでインフラストラクチャを管理します。

サーバーレス アーキテクチャの長所と短所

この「サーバーレス」アーキテクチャの拡張された定義を考慮して、Lambda を使用する場合の長所と短所をいくつか見てみましょう。

長所

オンデマンドの使用料金。
従来のサーバー ホスティングでは、定期的な請求サイクルが使用されます。サーバーは常に稼働しており、リソースを使用して入力を待機しています。月額料金または年額料金をお支払いいただくと、請求サイクルの期間中、サービスを継続してご利用いただけます。Lambda では、アイドル時間ではなく、使用したコンピューティング リソースに対してのみ課金されます。Lambda には、期間と同時実行数という 2 つの使用料金モデルがあります。

期間の料金
Lambda 期間の料金は、関数が実行を開始して終了するまでの時間に基づいて料金を計算します。この価格計算は、短期間の計算リソースを使用するプロジェクトに役立ちます。従来の「アイドル状態」のホスティング ソリューションに比べて、かなりの金額を節約できます。

ラムダ期間の料金は次のとおりです。

  • 100 万リクエストあたり 0.20 USD
  • コンピューティング時間の GB 秒ごとに $0.00001667、実行ごとに最も近い 100 ミリ秒に切り上げ

同時実行料金
「Provisioned Concurrency」モードの料金は、有効になってから無効になるまでの料金を計算します。同時実行モードでは、ラムダ関数の準備が整い、期間モードから起動時間が削除されます。

Lambda 同時実行の料金は次のとおりです。

  • プロビジョニングされた同時実行数は、GB 秒ごとに $0.0000041667 です
  • リクエストは 100 万リクエストあたり $0.20 です
  • 期間は GB 秒ごとに $0.0000097222 です

組み込みの自動スケーリング
従来のホスト型インフラストラクチャでは、パフォーマンスとスケーリングについて心配する必要がある場合があります。アプリケーションのトラフィックと使用量が増加するにつれて、需要に対応するために、ホストされたサーバーをインフラストラクチャに追加することが必要になる場合があります。セルフマネージド スケーリングは、ユーザーに障害やボトルネックを引き起こす可能性があります。Lambda は必要に応じて自動的にスケーリングを行い、追加の認知オーバーヘッドを取り除きます。

短所

一貫性のないローカル開発ワークフロー。

Lambda 関数コードをローカルで記述し、それを分離してテストできます。それでも、ハッキングされたバージョンの Lambda を作成せずに、本番環境をローカルでシミュレートすることはできません。

Lambda の主要な概念: コードとトリガー

Lambda には、コードトリガーという 2 つの主要な概念があります。コードは自明です。この場合、必要な動作を生成するために作成して Lambda にアップロードするのは JavaScript コードです。

アップロードすると、コードは単独では実行されません。ここでトリガーの出番です。トリガーは、実行のために Lambda 関数にデータを渡す他の AWS サービスによって起動されるイベントです。

トリガーの例は、次の場合に見られます。

  • AWS API Gateway への HTTP リクエストが Lambda コードを起動する
  • イベントは、CloudWatch Events からの cron ジョブのように、一定間隔で発生します
  • DynamoDB テーブルが更新され、Lambda コードがトリガーされる

Lambda コード関数の署名

予想される Lambda 署名に一致する JavaScript から通常の関数をエクスポートすることにより、Lambda 関数を定義します。

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

この関数は 3 つの引数を受け取ります。

event: Lambda が関数に渡す「トリガー データ」のキーと値のペアの辞書。

context: AWS リクエスト ID、Lambda 有効期限タイムアウト、ログ情報などの AWS 内部情報。詳細については、Lambda ドキュメントを参照してください。

callback: 標準の非同期 JavaScript コールバック ハンドラ。詳細については、Lambda ドキュメントを参照してください。

Lambda 関数の構築

新しい Lambda 関数の作成を開始するには、Lambda ダッシュボードにアクセスしてください。

次のようになります。

Lambda ダッシュボード

[関数の作成] ボタンをクリックして開始します。

関数の作成

次の画面では、Lambda 関数を作成するためのいくつかのオプションが表示されます。

Lambda 作成オプション

オプションは次のとおりです。

  • ゼロから作成
  • 設計図を使用する
  • コンテナ イメージ
  • サーバーレス アプリ リポジトリを閲覧する

ここでは、作成者を最初から選択し、「基本情報」セクションに入力します。関数名を追加します。(以下では「GithubGet」を使用しました。) [関数の作成] ボタンをクリックして続行します。

機能概要

機能概要画面です。

機能概要

上部の関数概要ペインには、関数トリガー、関数、および宛先が含まれています。下部のペインには、コード ソースとその他の構成のタブが含まれています。次に、関数にトリガーを追加します。[トリガーの追加] ボタンをクリックします。

トリガーを追加

[トリガーの追加] 画面で、次の操作を行います。

  1. ドロップダウンから「API ゲートウェイ」を選択します
  2. APIドロップダウンから「APIの作成」を選択します
  3. HTTP API オプションを選択します
  4. [セキュリティ] ドロップダウンから [開く] を選択します

最終的なトリガー構成は次のようになります。

トリガーの追加画面

[追加] ボタンをクリックして続行します。

Lambda 関数コードの指定

GithubGet 関数の前に、API Gateway トリガーが関数概要ページに登録されました。

トリガー付き機能

下のペインで、「コード」タブをクリックしてコードエディタを表示します。事前設定された「Hello, World!」があります。次のようなコード例:

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

API Gateway トリガーが配置されたので、この関数にパブリックにアクセスできます。「構成」タブと「トリガー」タブをクリックし、「API Gateway」トリガーを展開します。

トリガー構成

URLを含むAPI endpoint:エントリが表示されます。その URL をクリックすると、「Hello From Lambda!」をレンダリングするページにヒットするはずです。メッセージ。おめでとう!シンプルな AWS Lambda インスタンスをセットアップしました。インライン エディターでは、Lambda コードを起動して実行するために必要なオーバーヘッドはほとんどありませんが、このチュートリアルではさらに高度なことを行います。

依存関係のある複雑な関数の作成

ほとんどの現実のシナリオでは、npm 経由でインストールされたサードパーティ ライブラリを使用して、より複雑な関数を作成する必要があります。

npm 依存関係を使用するカスタム関数を作成し、Lambda にアップロードしましょう。以下の手順に従うか、サンプル リポジトリから自由にコードを取得してください。

新しい関数の作成

新しい関数用のフォルダーをセットアップし、その中からデフォルトpackage.jsonファイルで npm を初期化しましょう。

npm init -f

次に、公式の GitHub クライアントをインストールします。

npm install @octokit/rest

index.js次のコードでファイルを作成します。

const { Octokit } = require("@octokit/rest");
const octokit = new Octokit();

exports.handler = async (event) => {
  try{
    const ghres = await octokit.rest.search.repos({
      q: "sitepoint",
      sort: "stars"
    });

    const result = ghres.data.items.map(function(repo){
      return { url: repo.html_url, "stars": repo.stargazers_count };
    });

    return {
      statusCode: 200,
      body: JSON.stringify(result)
    }

  }catch(error){
    return {
      statusCode: 500,
      body: {error: error}
    }
  }
};

このコードの実行内容の内訳は次のとおりです。

  • これには、GitHub の「Octokit」rest API が含まれ、初期化されます。
  • handlerLambda 署名に一致する関数を定義します。
  • handler呼び出されると、クエリとして一致するすべてのリポジトリについて GitHub に検索要求を行いsitepointます。
  • Github からの応答により、各リポジトリの URL と星の数を含むマップが作成されます。
  • 最後に、 API Gateway の予想される統合に一致するオブジェクトのような HTTP 応答を返します。

AWS Lambda にアップロード

使い慣れた zip ユーティリティを使用して、関数のファイルの zip ファイルを作成します。zip次のように、macOS でコマンド ライン ユーティリティを使用しました。

zip -r lambdaupload.zip ./index.js ./node_modules/

コードを Lambda にアップロードするには、関数の概要でコード エディターに戻り、[アップロード元]セレクターをクリックして [.zip] を選択します。

zipアップロード

次にlambdaupload.zip、コンピューターからファイルを選択し、AWS にアップロードします。コード エディターが更新され、上記で記述したハンドラーがアップロードされているはずです。トリガー構成から見つかった API エンドポイント URL にアクセスすると、「Hello from Lambda!」の代わりに新しい応答が表示されるはずです。メッセージ。おめでとう!Lambda にコードを正常にデプロイしてトリガーしました。

次のステップと Lambda の将来

このプロジェクトによって、AWS Lambda を使用するための優れた基盤が得られたことを願っています。関数コード内でサードパーティ クライアント (GitHub) 統合を使用しましたが、これは他のクライアント API またはデータベース クライアント接続に置き換えることができます。

サーバーレス フレームワーク

この記事では、Lambda 構成の非常に手動で、やや一時的なプロセスを示します。AWS API によって駆動される Lambda を設定および初期化する方法は他にもあります。

このプロセスの合理化に役立ついくつかのツールとフレームワークは、AWS API の上に構築されています。

serverless.com : これは最も成熟した FaaS フレームワークです。非常に包括的な Lambda エクスペリエンスを提供し、AWS 以外の他の FaaS プロバイダーに適用されます。迅速なイテレーション、自動化された Lambda コードのデプロイ、複数のデプロイ ステージング環境などのためのローカル開発環境のセットアップを提供します。

terraform.io : これは広く採用されているコードとしてのインフラストラクチャおよび構成管理ツールです。Terraform を使用すると、開発者はクラウド インフラストラクチャ構成を宣言的に定義し、それらの構成を自動的にデプロイして同期できます。前の Lambda 演習では、AWS ブラウザー UI を介して多くの手動構成を行いました。この作業はかなり面倒で、何かを変更する必要がある場合は、AWS UI でさらに作業を行う必要がありました。代わりに、Terraform を使用して AWS で使用したリソースを定義し、Terraform に Lambda 関数を自動的にデプロイさせることができます。 

ソース: https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Node.js と AWS Lambda を使用してサーバーレス マイクロサービスを作成する

Create Serverless Microservices with Node.js and AWS Lambda

 If you’ve ever wanted to write a web app or API without messing around with the server, Amazon’s Lambda might be what you’re looking for.

Amazon Web Services (AWS) is a collection of developer tools that Amazon develops and publicly offers.This article will get you up and running with Lambda, a tool in the AWS suite. We’ll be using Lambda to create an HTTP GET endpoint that will make requests using the GitHub API to pull repository info from GitHub and return a JSON response.

The Lambda tagline is “Run Code without Thinking about Servers”. At first glance, this may sound confusing. Where or how does the code run then? Let’s find out.

See more at: https://www.sitepoint.com/getting-started-node-js-aws-lambda/

#aws #nodejs #lambda 

Create Serverless Microservices with Node.js and AWS Lambda
Saul  Alaniz

Saul Alaniz

1659176102

Representación De Escenas De Blender En La Nube Con AWS Lambda

Puede aprovechar AWS Lambda con bastante facilidad para renderizar escenas con Blender. Puede tener sentido utilizar las funciones de Lambda si necesita representar una gran cantidad de recursos en poco tiempo y si cada recurso es lo suficientemente simple como para cargarse y procesarse en un tiempo razonable (dentro de la vida útil máxima de Lambda) dados los recursos limitados que se ofrecen. por funciones Lambda (máximo 6 vCPU y 10 GB de RAM en el momento de escribir este artículo). Si tiene que renderizar activos más complejos, optar por instancias EC2 o AWS Thinkbox Deadline es una mejor solución.

Cuando se me ocurrió la idea de ejecutar Blender en Lambda, naturalmente verifiqué si alguien lo estaba haciendo en alguna parte y descubrí que @awsgeek había hecho algo similar en 2019 , así que al menos sabía que era posible. Sin embargo, lo que vamos a presentar en este artículo difiere ligeramente de su enfoque.

La arquitectura

Aquí está la arquitectura muy simple que le permite renderizar escenas de Blender en AWS Lambda almacenadas en un S3 Bucket. Los renders finales se almacenan en el mismo cubo.

Los archivos que necesitará para ejecutar esto "en casa" (en la nube)

Para ejecutar esto en su propia cuenta de AWS, necesitará cuatro archivos:

  • Dockerfiledescribe la imagen del contenedor que ejecutará cada ejecución de la función lambda
  • serverless.ymldescribe la infraestructura anterior
  • app.pymaneja el evento desde la infraestructura de Lambda y pone en marcha blender
  • script.pymanipula Blender desde adentro para crear una escena y renderizarla.

Estructura de archivos

Así es como se deben organizar estos archivos:

project directory
+-- Dockerfile
+-- serverless.yml
+-- app
|   +-- app.py
|   +-- script.py

Dockerfile

Para el Dockerfile, comencé con un gran conjunto de imágenes de Docker para Blender mantenidas por el equipo de I+D del New York Times. Estamos usando la imagen más reciente que ejecuta el renderizado de Blender solo con CPU (ya que, lamentablemente, Lambdas no tiene capacidades de GPU).

FROM nytimes/blender:2.93-cpu-ubuntu18.04

ARG FUNCTION_DIR="/home/app/"
RUN mkdir -p ${FUNCTION_DIR}
COPY app/* ${FUNCTION_DIR}
RUN pip install boto3
RUN pip install awslambdaric --target ${FUNCTION_DIR}

WORKDIR ${FUNCTION_DIR}

ENTRYPOINT [ "/bin/2.93/python/bin/python3.9", "-m", "awslambdaric" ]

CMD [ "app.handler" ]

Archivo de configuración sin servidor

El serverless.ymlarchivo es bastante simple:

service: blender-on-lambda
frameworkVersion: '2'
configValidationMode: error

custom:
  destinationBucket: blender-on-lambda-bucket

provider:
  name: aws
  region: us-east-1
  memorySize: 10240
  timeout: 900
  ecr:
    images:
      blender-container-image:
        path: ./

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:PutObject"
        - "s3:GetObject"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::"
            - "${self:custom.destinationBucket}"
            - "/*"

functions:
  render:
    image:
      name: blender-container-image
    maximumRetryAttempts: 0

resources:
  Resources:
    S3BucketOutputs:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.destinationBucket}

En este ejemplo, estoy usando las funciones Lambda más grandes disponibles con 10 GB o RAM y 6 vCPU para que la representación sea lo más rápida posible.

El controlador Python Lambda

El app.pyarchivo contiene la lógica que activará la infraestructura de Lambda y recibirá el evento pasado como activador. En este caso, el evento debe contener el widthy heightde la imagen a renderizar.

import json
import os


def handler(event, context):
    os.system(f"blender -b -P script.py -- {event.get('width', 0)} {event.get('height', 0)}")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": 'ok'})
    }

La secuencia de comandos de Python Blender

Y finalmente, aquí está el script de python que se ejecutará desde dentro de Blender para hacer el renderizado real.

from datetime import datetime
import os
import sys

import boto3
import bpy


argv = sys.argv
argv = argv[argv.index("--") + 1:]

s3 = boto3.resource("s3")
BUCKET_NAME = "jrb-material-renderer-bucket"
filename = f"{datetime.now().strftime('%Y_%m_%d-%I:%M:%S_%p')}.png"

s3.Bucket(BUCKET_NAME).download_file("scenes/scene.blend", "/tmp/scene.blend")

bpy.ops.wm.open_mainfile(filepath="/tmp/scene.blend", load_ui=False)
bpy.context.scene.render.filepath = f"/tmp/{filename}"
bpy.context.scene.render.resolution_x = int(argv[0])
bpy.context.scene.render.resolution_y = int(argv[1])
bpy.ops.render.render(write_still = True)

s3.Bucket(BUCKET_NAME).upload_file(f"/tmp/{filename}", f"renders/{filename}")

Costo

En la región us-east-1 de AWS, la lambda más grande disponible le costará 0,01 USD por minuto. El cargo por solicitud (la cantidad cobrada por cada invocación) es probablemente insignificante en comparación. Además, tenga en cuenta que el generoso nivel gratuito de Lambda podría cubrir sus costos. Lo mismo para S3.

Espero que esto pueda ayudar a cualquiera que enfrente la misma necesidad que yo.

Fuente: https://blog.theodo.com/2021/08/blender-serverless-lambda/

#lambda 

Representación De Escenas De Blender En La Nube Con AWS Lambda
Rui  Silva

Rui Silva

1659175980

Renderizando Cenas Do Blender Na Nuvem Com AWS Lambda

Você pode facilmente aproveitar o AWS Lambda para renderizar cenas com o Blender. Pode fazer sentido usar funções do Lambda se você precisar renderizar um grande número de ativos em pouco tempo e se cada ativo for simples o suficiente para ser carregado e renderizado em tempo razoável (dentro da vida útil máxima de um Lambda), devido aos recursos limitados oferecidos por funções Lambda (máximo de 6 vCPUs e 10 GB de RAM no momento da escrita). Se você precisar renderizar ativos mais complexos, usar instâncias do EC2 ou AWS Thinkbox Deadline é uma solução melhor.

Quando tive a ideia de rodar o Blender no Lambda, naturalmente verifiquei se alguém estava fazendo isso em algum lugar e descobri que o @awsgeek havia feito algo semelhante em 2019 , então pelo menos eu sabia que era possível. O que vamos apresentar neste artigo difere ligeiramente de sua abordagem.

A arquitetura

Aqui está a arquitetura muito simples que permite renderizar cenas do Blender no AWS Lambda armazenadas em um S3 Bucket. As renderizações finais são armazenadas no mesmo bucket.

Os arquivos que você vai precisar para rodar isso "em casa" (na nuvem)

Para executar isso em sua própria conta da AWS, você precisará de quatro arquivos:

  • Dockerfiledescreve a imagem do contêiner que cada execução da função lambda irá executar
  • serverless.ymldescreve a infraestrutura acima
  • app.pylida com o evento da infraestrutura Lambda e inicia o blender
  • script.pymanipula o Blender por dentro para gravar uma cena e renderizá-la.

Estrutura do arquivo

Veja como esses arquivos devem ser organizados:

project directory
+-- Dockerfile
+-- serverless.yml
+-- app
|   +-- app.py
|   +-- script.py

Dockerfile

Para o Dockerfile, parti de um grande conjunto de imagens do Docker para o Blender mantido pela equipe de P&D do New York Times. Estamos usando a imagem mais recente que executa a renderização do Blender apenas com CPU (já que os Lambdas não têm recursos de GPU, infelizmente).

FROM nytimes/blender:2.93-cpu-ubuntu18.04

ARG FUNCTION_DIR="/home/app/"
RUN mkdir -p ${FUNCTION_DIR}
COPY app/* ${FUNCTION_DIR}
RUN pip install boto3
RUN pip install awslambdaric --target ${FUNCTION_DIR}

WORKDIR ${FUNCTION_DIR}

ENTRYPOINT [ "/bin/2.93/python/bin/python3.9", "-m", "awslambdaric" ]

CMD [ "app.handler" ]

Arquivo de configuração sem servidor

O serverless.ymlarquivo é bastante simples:

service: blender-on-lambda
frameworkVersion: '2'
configValidationMode: error

custom:
  destinationBucket: blender-on-lambda-bucket

provider:
  name: aws
  region: us-east-1
  memorySize: 10240
  timeout: 900
  ecr:
    images:
      blender-container-image:
        path: ./

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:PutObject"
        - "s3:GetObject"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::"
            - "${self:custom.destinationBucket}"
            - "/*"

functions:
  render:
    image:
      name: blender-container-image
    maximumRetryAttempts: 0

resources:
  Resources:
    S3BucketOutputs:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.destinationBucket}

Neste exemplo, estou usando as maiores funções Lambda disponíveis com 10 GB ou RAM e 6 vCPUs para que a renderização seja o mais rápida possível.

O manipulador Python Lambda

O app.pyarquivo contém a lógica que será acionada pela infraestrutura do Lambda e receberá o evento passado como acionador. Nesse caso, o evento deve conter o widthe heightda imagem a ser renderizada.

import json
import os


def handler(event, context):
    os.system(f"blender -b -P script.py -- {event.get('width', 0)} {event.get('height', 0)}")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": 'ok'})
    }

O script do Blender Python

E finalmente, aqui está o script python que será executado de dentro do Blender para fazer a renderização real.

from datetime import datetime
import os
import sys

import boto3
import bpy


argv = sys.argv
argv = argv[argv.index("--") + 1:]

s3 = boto3.resource("s3")
BUCKET_NAME = "jrb-material-renderer-bucket"
filename = f"{datetime.now().strftime('%Y_%m_%d-%I:%M:%S_%p')}.png"

s3.Bucket(BUCKET_NAME).download_file("scenes/scene.blend", "/tmp/scene.blend")

bpy.ops.wm.open_mainfile(filepath="/tmp/scene.blend", load_ui=False)
bpy.context.scene.render.filepath = f"/tmp/{filename}"
bpy.context.scene.render.resolution_x = int(argv[0])
bpy.context.scene.render.resolution_y = int(argv[1])
bpy.ops.render.render(write_still = True)

s3.Bucket(BUCKET_NAME).upload_file(f"/tmp/{filename}", f"renders/{filename}")

Custo

Na região us-east-1 da AWS, o maior lambda disponível custará US$ 0,01 por minuto. A cobrança de solicitação (o valor cobrado por cada invocação) é provavelmente insignificante em comparação. Além disso, lembre-se de que o generoso nível gratuito do Lambda pode cobrir seus custos! O mesmo para S3.

Espero que isso possa ajudar quem está enfrentando a mesma necessidade que eu.

Fonte: https://blog.theodo.com/2021/08/blender-serverless-lambda/

#lambda 

Renderizando Cenas Do Blender Na Nuvem Com AWS Lambda

Rendering Blender Scenes in The Cloud with AWS Lambda

You can fairly easily leverage AWS Lambda to render scenes with Blender. It can make sense to use Lambda functions if you need to render a large number of assets in little time and if each asset is simple enough to be loaded and rendered in reasonable time (within the maximum lifetime of a Lambda) given the limited resources offered by Lambda functions (maximum 6 vCPUs and 10GB of RAM at the time of writing). If you have to render more complex assets, going with EC2 instances or AWS Thinkbox Deadline is a better solution.

When I came up with the idea of running Blender on Lambda, I naturally checked if someone was doing it somewhere and found out that @awsgeek had done something similar in 2019 so at least I knew it was possible. What we are going to present in this article slightly differs from his approach though.

See more at: https://blog.theodo.com/2021/08/blender-serverless-lambda/

#lambda 

Rendering Blender Scenes in The Cloud with AWS Lambda

Rendu De Scènes Blender Dans Le Cloud Avec AWS Lambda

Vous pouvez assez facilement tirer parti d'AWS Lambda pour rendre des scènes avec Blender. Il peut être judicieux d'utiliser les fonctions Lambda si vous avez besoin de rendre un grand nombre d'actifs en peu de temps et si chaque actif est suffisamment simple pour être chargé et rendu dans un délai raisonnable (dans la durée de vie maximale d'un Lambda) compte tenu des ressources limitées offertes par les fonctions Lambda (maximum 6 vCPU et 10 Go de RAM au moment de la rédaction). Si vous devez rendre des actifs plus complexes, opter pour des instances EC2 ou AWS Thinkbox Deadline est une meilleure solution.

Quand j'ai eu l'idée d'exécuter Blender sur Lambda, j'ai naturellement vérifié si quelqu'un le faisait quelque part et j'ai découvert que @awsgeek avait fait quelque chose de similaire en 2019 , donc au moins je savais que c'était possible. Ce que nous allons présenter dans cet article diffère cependant légèrement de son approche.

L'architecture

Voici l'architecture très simple qui permet de restituer des scènes Blender sur AWS Lambda stockées sur un Bucket S3. Les rendus finaux sont stockés dans le même bucket.

Les fichiers dont vous aurez besoin pour l'exécuter "à la maison" (dans le cloud)

Pour l'exécuter sur votre propre compte AWS, vous aurez besoin de quatre fichiers :

  • Dockerfiledécrit l'image de conteneur que chaque exécution de la fonction lambda va exécuter
  • serverless.ymldécrit l'infrastructure ci-dessus
  • app.pygère l'événement depuis l'infrastructure Lambda et démarre Blender
  • script.pymanipule Blender de l'intérieur pour charger une scène et la rendre.

Structure du fichier

Voici comment ces fichiers doivent être organisés :

project directory
+-- Dockerfile
+-- serverless.yml
+-- app
|   +-- app.py
|   +-- script.py

Fichier Docker

Pour le Dockerfile, je suis parti d'un super ensemble d' images Docker pour Blender maintenu par l'équipe R&D du New York Times. Nous utilisons la dernière image qui exécute le rendu Blender avec CPU uniquement (car les Lambda n'ont malheureusement pas de capacités GPU).

FROM nytimes/blender:2.93-cpu-ubuntu18.04

ARG FUNCTION_DIR="/home/app/"
RUN mkdir -p ${FUNCTION_DIR}
COPY app/* ${FUNCTION_DIR}
RUN pip install boto3
RUN pip install awslambdaric --target ${FUNCTION_DIR}

WORKDIR ${FUNCTION_DIR}

ENTRYPOINT [ "/bin/2.93/python/bin/python3.9", "-m", "awslambdaric" ]

CMD [ "app.handler" ]

Fichier de configuration sans serveur

Le serverless.ymlfichier est assez simple :

service: blender-on-lambda
frameworkVersion: '2'
configValidationMode: error

custom:
  destinationBucket: blender-on-lambda-bucket

provider:
  name: aws
  region: us-east-1
  memorySize: 10240
  timeout: 900
  ecr:
    images:
      blender-container-image:
        path: ./

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:PutObject"
        - "s3:GetObject"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::"
            - "${self:custom.destinationBucket}"
            - "/*"

functions:
  render:
    image:
      name: blender-container-image
    maximumRetryAttempts: 0

resources:
  Resources:
    S3BucketOutputs:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.destinationBucket}

Dans cet exemple, j'utilise les plus grandes fonctions Lambda disponibles avec 10 Go ou RAM et 6 vCPU afin que le rendu soit aussi rapide que possible.

Le gestionnaire Python Lambda

Le app.pyfichier contient la logique qui sera déclenchée par l'infrastructure Lambda et il recevra l'événement transmis comme déclencheur. Dans ce cas, l'événement doit contenir le widthet heightde l'image à rendre.

import json
import os


def handler(event, context):
    os.system(f"blender -b -P script.py -- {event.get('width', 0)} {event.get('height', 0)}")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": 'ok'})
    }

Le script Python Blender

Et enfin, voici le script python qui sera exécuté depuis l'intérieur de Blender pour faire le rendu réel.

from datetime import datetime
import os
import sys

import boto3
import bpy


argv = sys.argv
argv = argv[argv.index("--") + 1:]

s3 = boto3.resource("s3")
BUCKET_NAME = "jrb-material-renderer-bucket"
filename = f"{datetime.now().strftime('%Y_%m_%d-%I:%M:%S_%p')}.png"

s3.Bucket(BUCKET_NAME).download_file("scenes/scene.blend", "/tmp/scene.blend")

bpy.ops.wm.open_mainfile(filepath="/tmp/scene.blend", load_ui=False)
bpy.context.scene.render.filepath = f"/tmp/{filename}"
bpy.context.scene.render.resolution_x = int(argv[0])
bpy.context.scene.render.resolution_y = int(argv[1])
bpy.ops.render.render(write_still = True)

s3.Bucket(BUCKET_NAME).upload_file(f"/tmp/{filename}", f"renders/{filename}")

Coût

Dans la région us-east-1 d'AWS, le plus grand lambda disponible vous coûtera 0,01 USD par minute. Les frais de demande (le montant facturé pour chaque invocation) sont probablement négligeables en comparaison. N'oubliez pas non plus que le généreux niveau gratuit de Lambda peut couvrir vos frais ! Idem pour S3.

J'espère que cela pourra aider toute personne confrontée au même besoin que moi.

Source : https://blog.theodo.com/2021/08/blender-serverless-lambda/

#lambda 

Rendu De Scènes Blender Dans Le Cloud Avec AWS Lambda
曾 俊

曾 俊

1659172270

使用 AWS Lambda 在云中渲染 Blender 场景

您可以相当轻松地利用 AWS Lambda 使用 Blender 渲染场景。如果您需要在短时间内渲染大量资产,并且鉴于所提供的资源有限,如果每个资产都足够简单,可以在合理的时间内(在 Lambda 的最大生命周期内)加载和渲染,那么使用 Lambda 函数是有意义的通过 Lambda 函数(在撰写本文时最多 6 个 vCPU 和 10GB RAM)。如果您必须渲染更复杂的资产,使用 EC2 实例或 AWS Thinkbox Deadline 是更好的解决方案。

当我想出在 Lambda 上运行 Blender 的想法时,我自然而然地检查了是否有人在某个地方这样做,并发现 @awsgeek 在 2019 年做了类似的事情,所以至少我知道这是可能的。我们将在本文中介绍的内容与他的方法略有不同。

架构

这是一个非常简单的架构,允许您在存储在 S3 Bucket 上的 AWS Lambda 上渲染 Blender 场景。最终渲染存储在同一个存储桶中。

您需要“在家”运行此文件(在云中)

要在您自己的 AWS 账户上运行它,您将需要四个文件:

  • Dockerfile描述每个 lambda 函数执行将要运行的容器映像
  • serverless.yml描述了上面的基础设施
  • app.py处理来自 Lambda 基础设施的事件并启动搅拌机
  • script.py从内部操纵 Blender 来渲染场景并渲染它。

文件结构

以下是这些文件的排列方式:

project directory
+-- Dockerfile
+-- serverless.yml
+-- app
|   +-- app.py
|   +-- script.py

Dockerfile

对于Dockerfile,我从纽约时报的研发团队维护的一组很棒的Blender Docker 镜像开始。我们正在使用仅使用 CPU 运行 Blender 渲染的最新图像(因为 Lambda 很遗憾没有 GPU 功能)。

FROM nytimes/blender:2.93-cpu-ubuntu18.04

ARG FUNCTION_DIR="/home/app/"
RUN mkdir -p ${FUNCTION_DIR}
COPY app/* ${FUNCTION_DIR}
RUN pip install boto3
RUN pip install awslambdaric --target ${FUNCTION_DIR}

WORKDIR ${FUNCTION_DIR}

ENTRYPOINT [ "/bin/2.93/python/bin/python3.9", "-m", "awslambdaric" ]

CMD [ "app.handler" ]

无服务器配置文件

serverless.yml文件相当简单:

service: blender-on-lambda
frameworkVersion: '2'
configValidationMode: error

custom:
  destinationBucket: blender-on-lambda-bucket

provider:
  name: aws
  region: us-east-1
  memorySize: 10240
  timeout: 900
  ecr:
    images:
      blender-container-image:
        path: ./

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:PutObject"
        - "s3:GetObject"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::"
            - "${self:custom.destinationBucket}"
            - "/*"

functions:
  render:
    image:
      name: blender-container-image
    maximumRetryAttempts: 0

resources:
  Resources:
    S3BucketOutputs:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.destinationBucket}

在此示例中,我使用了具有 10GB 或 RAM 和 6 个 vCPU 的最大可用 Lambda 函数,以便尽可能快地进行渲染。

Python Lambda 处理程序

app.py文件包含将由 Lambda 基础设施触发的逻辑,它将接收作为触发器传递的事件。在这种情况下,事件必须包含要渲染的图像的width和。height

import json
import os


def handler(event, context):
    os.system(f"blender -b -P script.py -- {event.get('width', 0)} {event.get('height', 0)}")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": 'ok'})
    }

Python Blender 脚本

最后,这是将从 Blender 内部执行以进行实际渲染的 python 脚本。

from datetime import datetime
import os
import sys

import boto3
import bpy


argv = sys.argv
argv = argv[argv.index("--") + 1:]

s3 = boto3.resource("s3")
BUCKET_NAME = "jrb-material-renderer-bucket"
filename = f"{datetime.now().strftime('%Y_%m_%d-%I:%M:%S_%p')}.png"

s3.Bucket(BUCKET_NAME).download_file("scenes/scene.blend", "/tmp/scene.blend")

bpy.ops.wm.open_mainfile(filepath="/tmp/scene.blend", load_ui=False)
bpy.context.scene.render.filepath = f"/tmp/{filename}"
bpy.context.scene.render.resolution_x = int(argv[0])
bpy.context.scene.render.resolution_y = int(argv[1])
bpy.ops.render.render(write_still = True)

s3.Bucket(BUCKET_NAME).upload_file(f"/tmp/{filename}", f"renders/{filename}")

成本

在 AWS 的 us-east-1 区域,最大的可用 lambda 将花费您每分钟 0.01 美元。相比之下,请求费用(每次调用收取的金额)可能可以忽略不计。另外,请记住,慷慨的 Lambda 免费套餐可能会支付您的费用!S3 也一样。

我希望这可以帮助任何面临与我相同需求的人。

来源:https ://blog.theodo.com/2021/08/blender-serverless-lambda/

#lambda 

使用 AWS Lambda 在云中渲染 Blender 场景
藤本  結衣

藤本 結衣

1659168562

AWS Lambda を使用してクラウドで Blender シーンをレンダリングする

AWS Lambda を利用して、Blender でシーンをレンダリングするのはかなり簡単です。多数のアセットを短時間でレンダリングする必要がある場合、および提供されるリソースが限られている場合、各アセットが妥当な時間 (Lambda の最大有効期間内) でロードおよびレンダリングできるほど単純である場合、Lambda 関数を使用することは理にかなっています。 Lambda 関数による (執筆時点で最大 6 個の vCPU と 10 GB の RAM)。より複雑なアセットをレンダリングする必要がある場合は、EC2 インスタンスまたは AWS Thinkbox Deadline を使用することをお勧めします。

Lambda で Blender を実行するというアイデアを思いついたとき、誰かがどこかでそれを行っているかどうかを自然に調べたところ、@awsgeek が 2019 年に同様のことを行っていることがわかったので、少なくともそれが可能であることはわかっていました。ただし、この記事で紹介することは、彼のアプローチとは少し異なります。

建築学、建築物、建築様式

これは、S3 バケットに保存された AWS Lambda で Blender シーンをレンダリングできる非常にシンプルなアーキテクチャです。最終的なレンダリングは同じバケットに保存されます。

これを「自宅で」(クラウドで)実行するために必要なファイル

これを自分の AWS アカウントで実行するには、次の 4 つのファイルが必要です。

  • Dockerfile各ラムダ関数の実行が実行されるコンテナ イメージを記述します
  • serverless.yml上記のインフラストラクチャについて説明します
  • app.pyLambda インフラストラクチャからのイベントを処理し、blender を起動します
  • script.py内部から Blender を操作してシーンを作成し、レンダリングします。

ファイル構造

これらのファイルの配置方法は次のとおりです。

project directory
+-- Dockerfile
+-- serverless.yml
+-- app
|   +-- app.py
|   +-- script.py

Dockerfile

については、New York Times の R&D チームによって維持されているBlender 用の Docker イメージDockerfileの素晴らしいセットから始めました。Blender レンダリングを CPU のみで実行する最新のイメージを使用しています (残念ながら Lambda には GPU 機能がないため)。

FROM nytimes/blender:2.93-cpu-ubuntu18.04

ARG FUNCTION_DIR="/home/app/"
RUN mkdir -p ${FUNCTION_DIR}
COPY app/* ${FUNCTION_DIR}
RUN pip install boto3
RUN pip install awslambdaric --target ${FUNCTION_DIR}

WORKDIR ${FUNCTION_DIR}

ENTRYPOINT [ "/bin/2.93/python/bin/python3.9", "-m", "awslambdaric" ]

CMD [ "app.handler" ]

サーバーレス構成ファイル

serverless.ymlファイルはかなり単純です。

service: blender-on-lambda
frameworkVersion: '2'
configValidationMode: error

custom:
  destinationBucket: blender-on-lambda-bucket

provider:
  name: aws
  region: us-east-1
  memorySize: 10240
  timeout: 900
  ecr:
    images:
      blender-container-image:
        path: ./

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:PutObject"
        - "s3:GetObject"
      Resource:
        Fn::Join:
          - ""
          - - "arn:aws:s3:::"
            - "${self:custom.destinationBucket}"
            - "/*"

functions:
  render:
    image:
      name: blender-container-image
    maximumRetryAttempts: 0

resources:
  Resources:
    S3BucketOutputs:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:custom.destinationBucket}

この例では、レンダリングが可能な限り高速になるように、10GB または RAM と 6 個の vCPU で利用可能な最大の Lambda 関数を使用しています。

Python Lambda ハンドラー

このapp.pyファイルには、Lambda インフラストラクチャによってトリガーされるロジックが含まれており、トリガーとして渡されたイベントを受け取ります。この場合、イベントには、レンダリングされるイメージのwidthとが含まれている必要があります。height

import json
import os


def handler(event, context):
    os.system(f"blender -b -P script.py -- {event.get('width', 0)} {event.get('height', 0)}")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": 'ok'})
    }

Python Blender スクリプト

最後に、実際のレンダリングを行うために Blender 内から実行される python スクリプトを次に示します。

from datetime import datetime
import os
import sys

import boto3
import bpy


argv = sys.argv
argv = argv[argv.index("--") + 1:]

s3 = boto3.resource("s3")
BUCKET_NAME = "jrb-material-renderer-bucket"
filename = f"{datetime.now().strftime('%Y_%m_%d-%I:%M:%S_%p')}.png"

s3.Bucket(BUCKET_NAME).download_file("scenes/scene.blend", "/tmp/scene.blend")

bpy.ops.wm.open_mainfile(filepath="/tmp/scene.blend", load_ui=False)
bpy.context.scene.render.filepath = f"/tmp/{filename}"
bpy.context.scene.render.resolution_x = int(argv[0])
bpy.context.scene.render.resolution_y = int(argv[1])
bpy.ops.render.render(write_still = True)

s3.Bucket(BUCKET_NAME).upload_file(f"/tmp/{filename}", f"renders/{filename}")

料金

AWS の us-east-1 リージョンでは、利用可能な最大のラムダは 1 分あたり 0.01 USD かかります。リクエスト料金 (呼び出しごとに請求される金額) は、比較するとおそらく無視できる程度です。また、Lambda の寛大な無料利用枠がコストをカバーする可能性があることにも注意してください! S3も同様。

これが私と同じニーズに直面している人の助けになることを願っています.

ソース: https://blog.theodo.com/2021/08/blender-serverless-lambda/ 

#lambda 

AWS Lambda を使用してクラウドで Blender シーンをレンダリングする