--- title: "Déployer une application existante avec erpc worker import" description: "erpc worker import lit le répertoire d'une application et écrit son erpc.toml, pour qu'un package Cargo ou un binaire Linux de tout langage se déploie tel quel." canonical: "https://erpc.global/fr/doc/erpc-cli/worker-import/" locale: "fr" --- # 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 `, 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épertoire | Ce que `import` en fait | | --- | --- | | `.env.example` et les fichiers d'exemple similaires | Chaque 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 | | `.env` | Seuls les noms sont lus, sauf un numéro de port | | `PORT`, `API_PORT`, l'`EXPOSE` d'un Dockerfile | `run.port`, sauf si `--port` le fournit. `--health ` 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.json` | Indiqués, avec `erpc worker key import --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ême | Non 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](https://erpc.global/fr/doc/erpc-cli/worker-secrets/) : conservez les paramètres qu'`import` a écartés, ainsi que la clé de trading. - [Pare-feu et WAF](https://erpc.global/fr/doc/erpc-cli/worker-firewall-and-waf/) : choisissez qui peut atteindre l'application. - [Le guide du worker](https://github.com/elsoul/erpc-cli/blob/v0.1.0-rc.4/docs/worker.md) : chaque fichier que lit `import`, et les formes d'identifiants qu'il recherche.