La pagina Processi mostra i processi di runtime e di build di un’applicazione. Qui è anche possibile modificare e definire i comandi di runtime. Si dia un’occhiata al nostro esempio di meteo logger per la configurazione di un processo.

Processi di Runtime

Questi sono i processi necessari per l’applicazione.

Tipi di Processo

Processo Web

Il processo web esegue l’applicazione. Quando si aggiunge un’applicazione, se non si specifica il comando di avvio del processo web, Kinsta tenta di rilevarlo automaticamente durante la prima distribuzione. Ad esempio, il comando di avvio per un’applicazione Node.js può essere npm start o yarn start.

Non è possibile rimuovere il processo web ed è possibile avere un solo processo web per applicazione.

Background worker

Un processo background worker viene eseguito in background, separato dall’applicazione principale. I processi worker in background sono ideali per le attività di lunga durata, come la generazione di report o l’elaborazione di grandi quantità di dati. Non c’è limite al numero di background worker che si possono aggiungere; tuttavia, ogni processo richiede almeno un pod per essere eseguito.

Processi Cron job

Con un processo cron job, è possibile programmare un processo a un intervallo specifico per l’applicazione, in modo da automatizzare le attività ripetitive. Come per un background worker, ogni processo cron job richiede l’esecuzione di almeno un pod, ma si avvia solo in base alla tempistica configurata e si spegne al termine dell’operazione richiesta.

Definire i Processi in MyKinsta

Per aggiungere un nuovo processo, fare clic su Crea processo e compilare i campi come segue:

  • Nome: Il nome del processo, ad esempio “Worker”.
  • Tipo: Background worker.
  • Comando di avvio: Il comando richiesto per avviare il processo, ad esempio npm run [process].
  • Dimensione del Pod: Scegliere la CPU e la RAM dedicate al processo.
  • Istanze: Il numero di istanze necessarie, fino a un massimo di 50. Ogni istanza rappresenta un pod e le istanze utilizzano tutte un pod della stessa dimensione. Non è possibile definire un pod di dimensione diversa per ogni istanza.

Definire i Processi in un Procfile

I Procfile definiscono i processi dal codice dell’applicazione e devono essere inseriti nel repository. Un Procfile contiene un processo per riga nel seguente formato:

process_name: command

Ad esempio, per eseguire un’applicazione Laravel, si potrebbe utilizzare la seguente procedura:

web: php artisan serve --host 0.0.0.0 --port 8080

Se si utilizza un Procfile, bisogna definire un processo chiamato web per garantire che il container soddisfi le richieste web.

Scalare le Risorse dell’Applicazione

È possibile modificare la dimensione del pod di qualsiasi processo (scalatura verticale) e cambiare il numero di pod eseguiti contemporaneamente (scalatura orizzontale).

  • Il vertical scaling è ottimo per dare ai pod più potenza per completare attività ad alto consumo di risorse.
  • Lo scaling orizzontale è ottimo per la resilienza e il bilanciamento del carico per le applicazioni che elaborano molte richieste. Ad esempio, è possibile eseguire 3 versioni dello stesso pod. La tecnologia sottostante indirizza le richieste a uno dei tre pod, distribuendo di fatto il carico tra di essi. Se un pod diventa instabile, le richieste vengono indirizzate agli altri due fino a quando il terzo pod non torna in salute.

È possibile modificare i dettagli di qualsiasi processo in qualsiasi momento, ad esempio la dimensione del Pod. Tutte le modifiche apportate, ad eccezione del nome, attivano automaticamente il processo di rollout dell’applicazione. Per saperne di più sulla modifica delle dimensioni del pod e su altre opzioni di scalabilità, si legga Come scalare le risorse di un’applicazione.

Processo di Build

Mostra la build machine in uso dal processo di build. Cliccando su Aggiorna build è possibile modificare le risorse utilizzate per il processo di build.