ERPC

Distribuisci un'app che hai già con erpc worker import

erpc worker import accoglie un'app che hai già, così com'è. Scrive per l'app il suo erpc.toml e non modifica nulla del suo codice.
Questa pagina descrive ERPC CLI v0.1.0-rc.4, una versione pre-release.

Importare e distribuire

L'app può essere un bot che oggi gira sotto systemd o Docker, oppure un servizio in un altro linguaggio. import legge la directory dell'app e scrive il file erpc.toml che quella directory descrive. Nient'altro viene scritto nell'app, nulla al suo interno viene eseguito e il suo codice non viene modificato. erpc aggiunge l'app al proprio elenco, come fa init.
bash
cd my-bot                                   # a Cargo package
erpc worker import                          # writes erpc.toml from what is there
erpc worker check                           # what it describes, and what is missing
erpc worker deploy                          # your VPS, or a new hourly one

cd my-go-service && make linux              # any other toolchain: build the Linux binary your way
erpc worker import --binary dist/service --port 8080 --health /healthz
erpc worker deploy
  • Un pacchetto Cargo viene compilato con cargo build --release, come un'app creata da init. L'app prende il nome del pacchetto, a meno che --name non indichi altro, e --bin sceglie il binario quando il pacchetto ne ha diversi. La radice di un workspace viene rifiutata: punta import al pacchetto.
  • Un binario Linux compilato ovunque, in qualsiasi linguaggio, si distribuisce allo stesso modo con --binary <PATH>, e viene inviato così com'è. erpc ne legge l'intestazione e rifiuta un binario che un server non può eseguire: un binario macOS o Windows, uno script, una libreria condivisa, un file troncato o un'architettura diversa da build.target. Il binario deve essere statico, oppure collegato a glibc con il suo loader nel percorso consueto. È un file dell'app: un link con quel nome che porta fuori dalla directory dell'app viene rifiutato. Una distribuzione con un binario inutilizzabile si ferma prima che venga acquistato un server. Compila di nuovo il binario prima di una distribuzione che debba portare una modifica.

Cosa legge import

Nella directoryCosa ne fa import
.env.example e file di esempio similiOgni nome diventa un'impostazione quando può esserlo: un nome che non è fatto di lettere maiuscole, cifre e _ (senza iniziare con una cifra), oppure uno che erpc o il server impostano da sé (ERPC_WORKER_…, LD_…), viene escluso. Uno semplice va in [vars] con il valore dell'esempio. Uno che dal nome sembra un secret, o il cui valore contiene una credenziale, viene indicato con il comando che lo conserva, e il suo valore non viene copiato
.envVengono letti solo i nomi, tranne un numero di porta
PORT, API_PORT, l'istruzione EXPOSE di un Dockerfilerun.port, a meno che --port non lo indichi. --health <PATH> aggiunge l'health check su quella porta
GRPC_ENDPOINT, SHREDS_ENDPOINT e le altre impostazioni fornite da una linea datiEsclusi da [vars]: li imposta il flag della linea su deploy
wallet.json, id.json, *keypair.jsonIndicati, con erpc worker key import <FILE> --wipe, che conserva la chiave dove erpc worker la legge e cancella il file
Un file compose con Redis o PostgreSQL[services], così che deploy li metta sul server
Dockerfile, il file compose stessoNon usati per eseguire l'app: erpc worker esegue il binario da sé, sotto un'unità systemd con hardening
import --chain indica la chain a cui è destinata l'app, solana per impostazione predefinita.

Come import legge una directory

La directory può essere una che hai clonato un minuto fa, quindi import la legge con cautela.
  • erpc.toml viene creato da zero. Quando in quel percorso c'è già qualcosa, import si rifiuta: non scrive mai sopra un file né attraverso un link.
  • Legge i file regolari all'interno della directory, fino a 1 MiB ciascuno. Un link che porta fuori dalla directory, una pipe, un dispositivo, un file più grande e un file che non è UTF-8 non vengono letti, e ciascuno viene segnalato.
  • Nessun valore che considera un secret viene copiato. Cerca le credenziali in base alla loro forma, quindi il controllo è una rete, non una prova: un secret in una forma che non conosce viene copiato come qualsiasi altro valore. Sta a te leggere erpc.toml prima di includerlo in un commit.
  • erpc worker check avvisa di meno tipi di quanti import ne trattenga. Non dice nulla di un URL RPC con una chiave nel percorso, né di una frase di recupero, sotto [vars]: conservali con erpc worker secret put.

Cosa trova la tua app sul server

  • Le impostazioni arrivano come variabili d'ambiente, sia [vars] sia [secrets]. Sul server non c'è alcun .env, e un'app che legge un file .env con una libreria dotenv continua a funzionare.
  • La sua directory è di sola lettura. I file che scrive vanno sotto la directory indicata da ERPC_WORKER_STATE_DIR (che è anche la sua HOME), che una distribuzione conserva e che erpc worker backup include nel backup.
  • Una chiave di trading arriva su una pipe, non in un file: 64 byte sul file descriptor indicato da ERPC_WORKER_KEY_FD, una sola volta, all'avvio dell'app, con la chiave pubblica in ERPC_WORKER_PUBKEY. In un'app che legge un file di chiave è quella sola lettura a dover cambiare; src/wallet.rs del template pumpfun mostra come.
  • È un unico binario più i file elencati in run.files. Qualsiasi altra cosa che apre durante l'esecuzione deve essere in quell'elenco.

Prossimi passi

PrecedenteAvvio rapidoSuccessivoChiavi e secret