ERPC

Déployer une application existante avec erpc worker import

erpc worker import prend en charge une application que vous avez déjà, telle quelle. Il écrit son erpc.toml et ne modifie rien de son code.
Cette page décrit ERPC CLI v0.1.0-rc.4, une préversion.

Importer et déployer

L'application peut être un bot qui tourne aujourd'hui sous systemd ou Docker, ou un service écrit dans un autre langage. import lit le répertoire de l'application et écrit le erpc.toml que ce répertoire décrit. Rien d'autre n'est écrit dans l'application, rien n'y est exécuté et son code n'est pas modifié. erpc ajoute l'application à sa propre liste, comme le fait 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 package Cargo est compilé avec cargo build --release, comme une application créée par init. L'application prend le nom du package, sauf si --name en décide autrement, et --bin choisit le binaire lorsque le package en contient plusieurs. Une racine de workspace est refusée : pointez import sur le package.
  • Un binaire Linux compilé n'importe où, dans n'importe quel langage, se déploie de la même façon avec --binary <PATH>, livré tel quel. erpc lit son en-tête et refuse un binaire qu'un serveur ne peut pas exécuter : un binaire macOS ou Windows, un script, une bibliothèque partagée, un fichier tronqué, ou une autre architecture que build.target. Le binaire doit être statique, ou lié à la glibc avec son chargeur à l'emplacement habituel. C'est un fichier de l'application : un lien portant ce nom qui mène hors du répertoire de l'application est refusé. Un déploiement s'arrête sur un binaire inutilisable avant l'achat d'un serveur. Recompilez le binaire avant un déploiement qui doit embarquer une modification.

Ce que lit import

Dans le répertoireCe que import en fait
.env.example et les fichiers d'exemple similairesChaque nom devient un paramètre lorsqu'il peut en être un : un nom qui n'est pas composé de lettres majuscules, de chiffres et de _ (sans chiffre au début), ou un nom qu'erpc ou le serveur définit lui-même (ERPC_WORKER_…, LD_…), est écarté. Un nom ordinaire va dans [vars] avec la valeur de l'exemple. Un nom qui ressemble à un secret d'après son nom, ou dont la valeur contient des identifiants, est indiqué avec la commande qui le conserve, et sa valeur n'est pas copiée
.envSeuls les noms sont lus, sauf un numéro de port
PORT, API_PORT, l'EXPOSE d'un Dockerfilerun.port, sauf si --port le fournit. --health <PATH> ajoute le contrôle de santé sur ce port
GRPC_ENDPOINT, SHREDS_ENDPOINT et les autres paramètres que fournit une ligne de donnéesÉcartés de [vars] : l'option de la ligne sur deploy les définit
wallet.json, id.json, *keypair.jsonIndiqués, avec erpc worker key import <FILE> --wipe, qui conserve la clé là où erpc worker la lit et efface le fichier
Un fichier compose avec Redis ou PostgreSQL[services], pour que deploy les installe sur le serveur
Dockerfile, le fichier compose lui-mêmeNon utilisés pour exécuter l'application : erpc worker exécute lui-même le binaire, sous une unité systemd durcie
import --chain indique la chaîne à laquelle l'application est destinée, solana par défaut.

Comment import lit un répertoire

Le répertoire peut être un dépôt que vous avez cloné il y a une minute, aussi import le lit-il avec précaution.
  • erpc.toml est créé à neuf. Si quoi que ce soit existe à ce chemin, import refuse : il n'écrit jamais par-dessus un fichier ni à travers un lien.
  • Il lit les fichiers ordinaires situés dans le répertoire, jusqu'à 1 MiB chacun. Un lien qui mène hors du répertoire, un pipe, un périphérique, un fichier plus gros et un fichier qui n'est pas en UTF-8 ne sont pas lus, et chacun est signalé.
  • Aucune valeur qu'il prend pour un secret n'est copiée. Il recherche les identifiants d'après leur forme : la vérification est donc un filet, pas une preuve, et un secret d'une forme qu'il ne connaît pas est copié comme n'importe quelle valeur. C'est à vous de relire erpc.toml avant de le commiter.
  • erpc worker check avertit pour moins de types de valeurs que ceux qu'import écarte. Il ne dit rien d'une URL RPC contenant une clé dans son chemin, ni d'une phrase de récupération, placées sous [vars] : conservez-les avec erpc worker secret put.

Ce que votre application trouve sur le serveur

  • Les paramètres arrivent sous forme de variables d'environnement, [vars] comme [secrets]. Il n'y a pas de .env sur le serveur, et une application qui lit un fichier .env avec une bibliothèque dotenv continue de fonctionner.
  • Son propre répertoire est en lecture seule. Les fichiers qu'elle écrit vont dans le répertoire que désigne ERPC_WORKER_STATE_DIR (c'est aussi son HOME), qu'un déploiement conserve et que erpc worker backup sauvegarde.
  • Une clé de trading arrive par un pipe, pas dans un fichier : 64 octets sur le descripteur de fichier que désigne ERPC_WORKER_KEY_FD, une seule fois, au démarrage de l'application, avec la clé publique dans ERPC_WORKER_PUBKEY. Une application qui lit un fichier de clé n'a que cette lecture à modifier ; le src/wallet.rs du modèle pumpfun montre comment.
  • C'est un seul binaire, plus les fichiers que liste run.files. Tout autre fichier qu'elle ouvre à l'exécution doit figurer dans cette liste.

Prochaines étapes

  • Clés et secrets : conservez les paramètres qu'import a écartés, ainsi que la clé de trading.
  • Pare-feu et WAF : choisissez qui peut atteindre l'application.
  • Le guide du worker : chaque fichier que lit import, et les formes d'identifiants qu'il recherche.
PrécédentDémarrage rapideSuivantClés et secrets