Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Implementare il codice prima o dopo gli snapshot della funzione Lambda
Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime sono utili per diversi scopi, ad esempio:
+ **Pulizia e inizializzazione:** prima di creare uno snapshot, è possibile utilizzare un hook di runtime per eseguire operazioni di pulizia o rilascio delle risorse. Dopo il ripristino di uno snapshot, è possibile utilizzare un runtime hook per reinizializzare tutte le risorse o lo stato che non sono stati acquisiti nello snapshot.
+ **Configurazione dinamica:** è possibile utilizzare gli hook di runtime per aggiornare dinamicamente la configurazione o altri metadati prima della creazione di uno snapshot o dopo il suo ripristino. Ciò può essere utile se la funzione deve adattarsi ai cambiamenti nell'ambiente di runtime.
+ **Integrazioni esterne:** è possibile utilizzare gli hook di runtime per l'integrazione con servizi o sistemi esterni, ad esempio l'invio di notifiche o l'aggiornamento dello stato esterno, come parte del processo di checkpoint e ripristino.
+ **Ottimizzazione delle prestazioni:** è possibile utilizzare gli hook di runtime per ottimizzare la sequenza di avvio della funzione, ad esempio precaricando le dipendenze. Per ulteriori informazioni, consulta [Ottimizzazione prestazioni](snapstart-best-practices.md#snapstart-tuning).
Le pagine seguenti spiegano come implementare gli hook di runtime per il runtime preferito.
**Topics**
+ [Java](snapstart-runtime-hooks-java.md)
+ [Python](snapstart-runtime-hooks-python.md)
+ [.NET](snapstart-runtime-hooks-dotnet.md)
# Hook di SnapStart runtime Lambda per Java
Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime sono disponibili come parte del progetto open source Coordinated Restore at Checkpoint (C)CRa. CRaC è in fase di sviluppo per l'[Open Java Development Kit (OpenJDK](https://wiki.openjdk.org/display/crac)). Per un esempio di come usare CRa C con un'applicazione di riferimento, consulta il repository [CRaC](https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md) su. GitHub CRaC utilizza tre elementi principali:
+ `Resource`: un'interfaccia con due metodi, `beforeCheckpoint()` e `afterRestore()`. Utilizza questi metodi per implementare il codice che desideri eseguire prima di uno snapshot e dopo un ripristino.
+ `Context `: per ricevere notifiche relative ai checkpoint e ai ripristini, è necessario registrare una `Resource` con un `Context`.
+ `Core`: il servizio di coordinamento, che fornisce il `Context` globale predefinito tramite il metodo statico `Core.getGlobalContext()`.
Per ulteriori informazioni su `Context` and`Resource`, vedere [Package org.crac nella CRa documentazione C.](https://javadoc.io/doc/io.github.crac/org-crac/latest/index.html)
Completa le seguenti operazioni per implementare gli hook di runtime con il [pacchetto org.crac](https://github.com/CRaC/org.crac). Il runtime Lambda contiene un'implementazione di contesto CRa C personalizzata che richiama gli hook di runtime prima del checkpoint e dopo il ripristino.
## Registrazione ed esecuzione di hook di runtime
L'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione. L'ordine di registrazione segue l'ordine di importazione, definizione o esecuzione nel codice.
+ `beforeCheckpoint()`: eseguito nell'ordine di registrazione inverso
+ `afterRestore()`: eseguito nell'ordine di registrazione
Assicurati che tutti gli hook registrati siano stati importati e inclusi correttamente nel codice della tua funzione. Se registri gli hook di runtime in un file o modulo separato, dovrai assicurarti che il modulo venga importato, direttamente o come parte di un pacchetto più grande, nel file handler della funzione. Se il file o il modulo non viene importato nell'handler della funzione, Lambda ignorerà gli hook di runtime.
**Nota**
Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `beforeCheckpoint()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `afterRestore()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un. SnapStartTimeoutException
## Fase 1: aggiornamento della configurazione di build
Aggiungi la dipendenza `org.crac` alla configurazione della build. Nell'esempio seguente viene utilizzato Gradle. Per esempi di altri sistemi di compilazione, consulta la [documentazione di Apache Maven](https://search.maven.org/artifact/io.github.crac/org-crac/0.1.3/jar).
```
dependencies {
compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1'
# All other project dependecies go here:
# ...
# Then, add the org.crac dependency:
implementation group: 'org.crac', name: 'crac', version: '1.4.0'
}
```
## Fase 2: aggiornamento del gestore Lambda
Il *gestore* di funzioni Lambda è il metodo nel codice della funzione che elabora gli eventi. Quando viene richiamata la funzione, Lambda esegue il metodo del gestore. La funzione viene eseguita fino a quando il gestore non restituisce una risposta, termina o scade.
Per ulteriori informazioni, consulta [Definire l'handler della funzione Lambda in Java](java-handler.md).
Il seguente gestore di esempio mostra come eseguire il codice prima del checkpoint (`beforeCheckpoint()`) e dopo il ripristino (`afterRestore()`). Questo gestore registra anche la `Resource` nel `Context` gestito dal runtime.
**Nota**
Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `beforeCheckpoint()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime (JVM) deve essere caricato e gli hook di runtime `afterRestore()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, avrai un SnapStartTimeoutException.
```
...
import org.crac.Resource;
import org.crac.Core;
...
public class CRaCDemo implements RequestStreamHandler, Resource {
public CRaCDemo() {
Core.getGlobalContext().register(this);
}
public String handleRequest(String name, Context context) throws IOException {
System.out.println("Handler execution");
return "Hello " + name;
}
@Override
public void beforeCheckpoint(org.crac.Context context)
throws Exception {
System.out.println("Before checkpoint");
}
@Override
public void afterRestore(org.crac.Context context)
throws Exception {
System.out.println("After restore");
```
`Context` mantiene solo un [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html) all'oggetto registrato. Se per una [https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html](https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html) viene eseguita la rimozione di oggetti inutili (garbage collection), gli hook di runtime non vengono eseguiti. Il codice deve mantenere un forte riferimento alla `Resource` per garantire l'esecuzione dell'hook di runtime.
Ecco due esempi di modelli da evitare:
**Example : oggetto senza un forte riferimento**
```
Core.getGlobalContext().register( new MyResource() );
```
**Example : oggetti di classi anonime**
```
Core.getGlobalContext().register( new Resource() {
@Override
public void afterRestore(Context context) throws Exception {
// ...
}
@Override
public void beforeCheckpoint(Context context) throws Exception {
// ...
}
} );
```
Invece, mantieni un riferimento forte. Nell'esempio seguente, per la risorsa registrata non viene eseguita la rimozione di oggetti inutili (garbage collection) e gli hook di runtime vengono eseguiti in modo coerente.
**Example : oggetto con un forte riferimento**
```
Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected
Core.getGlobalContext().register( myResource );
```
# Hook di runtime SnapStart per Lambda per Python
Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime Python sono disponibili come parte della libreria open source [Snapshot Restore for Python](https://pypi.org/project/snapshot-restore-py/), che è inclusa nei runtime gestiti da Python. Questa libreria fornisce due decoratori che possono essere utilizzati per definire i tuoi hook di runtime:
+ `@register_before_snapshot`: per le funzioni che si desidera eseguire prima che Lambda crei uno snapshot.
+ `@register_after_restore`: per le funzioni che si desidera eseguire quando Lambda riprende una funzione da uno snapshot.
In alternativa, è possibile utilizzare i seguenti metodi per registrare gli elementi chiamabili per gli hook di runtime:
+ `register_before_snapshot(func, *args, **kwargs)`
+ `register_after_restore(func, *args, **kwargs)`
## Registrazione ed esecuzione di hook di runtime
L'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione:
+ Prima dello snapshot: eseguito nell'ordine di registrazione inverso
+ Dopo lo snapshot: eseguito nell'ordine di registrazione
L'ordine di registrazione degli hook di runtime dipende da come vengono definiti gli hook. Quando si utilizzano i decoratori (`@register_before_snapshot` e `@register_after_restore`), l'ordine di registrazione segue l'ordine di importazione, definizione o esecuzione nel codice. Se hai bisogno di un maggiore controllo sull'ordine di registrazione, usa i metodi `register_before_snapshot()` e `register_after_restore()` anziché i decoratori.
Assicurati che tutti gli hook registrati siano stati importati e inclusi correttamente nel codice della tua funzione. Se registri gli hook di runtime in un file o modulo separato, dovrai assicurarti che il modulo venga importato, direttamente o come parte di un pacchetto più grande, nel file handler della funzione. Se il file o il modulo non viene importato nell'handler della funzione, Lambda ignorerà gli hook di runtime.
**Nota**
Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `@register_before_snapshot` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `@register_after_restore` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un'eccezione SnapStartTimeoutException.
## Esempio
Il seguente gestore di esempio mostra come eseguire il codice prima del checkpoint (`@register_before_snapshot`) e dopo il ripristino (`@register_after_restore`).
```
from snapshot_restore_py import register_before_snapshot, register_after_restore
def lambda_handler(event, context):
# Handler code
@register_before_snapshot
def before_checkpoint():
# Logic to be executed before taking snapshots
@register_after_restore
def after_restore():
# Logic to be executed after restore
```
Per altri esempi, consulta [Ripristino di snapshot per Python](https://github.com/aws/snapshot-restore-py/tree/main/examples) nel repository AWS GitHub.
# Hook di runtime SnapStart per Lambda per .NET
Gli hook di runtime possono essere utilizzati per implementare il codice prima che Lambda crei uno snapshot o dopo che ha ripristinato una funzione da uno snapshot. Gli hook di runtime .NET sono disponibili come parte del pacchetto [Amazon.Lambda.Core](https://www.nuget.org/packages/Amazon.Lambda.Core) (versione 2.5.0 o successiva). Questa libreria fornisce due metodi che possono essere utilizzati per definire i tuoi hook di runtime:
+ `RegisterBeforeSnapshot()`: codice da eseguire prima della creazione dello snapshot
+ `RegisterAfterSnapshot()`: codice da eseguire dopo la ripresa di una funzione da uno snapshot
**Nota**
Se utilizzi il [framework Lambda Annotations per .NET](csharp-handler.md#csharp-handler-annotations), esegui l'upgrade alla versione 1.6.0 o successiva di [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) per garantire la compatibilità con SnapStart.
## Registrazione ed esecuzione di hook di runtime
Registra i tuoi hook nel codice di inizializzazione. Prendi in considerazione le seguenti linee guida basate sul [modello di esecuzione](csharp-handler.md#csharp-handler-setup) della tua funzione Lambda:
+ Per l'[approccio all'assembly eseguibile](csharp-handler.md#csharp-executable-assembly-handlers), registra i tuoi hook prima di avviare il bootstrap Lambda con `RunAsync`.
+ Per l'[approccio basato sulle librerie di classi](csharp-handler.md#csharp-class-library-handlers), registra i tuoi hook nel costruttore della classe handler.
+ Per le [applicazioni ASP.NET Core](csharp-package-asp.md), registra gli hook prima di chiamare il metodo `WebApplications.Run`.
Per registrare gli hook di runtime per SnapStart in .NET, utilizza i seguenti metodi:
```
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
```
Quando vengono registrati più tipi di hook, l'ordine in cui Lambda esegue gli hook di runtime è determinato dall'ordine di registrazione:
+ `RegisterBeforeSnapshot()`: eseguito nell'ordine di registrazione inverso
+ `RegisterAfterSnapshot()`: eseguito nell'ordine di registrazione
**Nota**
Quando Lambda crea uno snapshot, il codice di inizializzazione può essere eseguito per un massimo di 15 minuti. Il limite di tempo è 130 secondi o il [timeout della funzione configurato](configuration-timeout.md) (massimo 900 secondi), a seconda di quale dei due valori sia più elevato. I tuoi hook di runtime `RegisterBeforeSnapshot()` contano ai fini del limite di tempo del codice di inizializzazione. Quando Lambda ripristina uno snapshot, il runtime deve essere caricato e gli hook di runtime `RegisterAfterSnapshot()` devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un'eccezione SnapStartTimeoutException.
## Esempio
La seguente funzione di esempio mostra come eseguire il codice prima del checkpoint (`RegisterBeforeSnapshot`) e dopo il ripristino (`RegisterAfterRestore`).
```
public class SampleClass
{
public SampleClass()
{
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
}
private ValueTask BeforeCheckpoint()
{
// Add logic to be executed before taking the snapshot
return ValueTask.CompletedTask;
}
private ValueTask AfterCheckpoint()
{
// Add logic to be executed after restoring the snapshot
return ValueTask.CompletedTask;
}
public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
// Add business logic
return new APIGatewayProxyResponse
{
StatusCode = 200
};
}
}
```