ERPC

Implante uma aplicação que você já tem com o erpc worker import

O erpc worker import recebe uma aplicação que você já tem, do jeito que ela está. Ele escreve o erpc.toml da aplicação e não altera nada do código dela.
Esta página descreve o ERPC CLI v0.1.0-rc.4, uma versão de pré-lançamento.

Importar e implantar

A aplicação pode ser um bot que hoje roda sob systemd ou Docker, ou um serviço em outra linguagem. O import lê o diretório da aplicação e escreve o erpc.toml que corresponde ao que ele encontra ali. Nada mais é escrito na aplicação, nada nela é executado e o código dela não é alterado. O erpc adiciona a aplicação à própria lista, como o init faz.
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
  • Um pacote Cargo é compilado com cargo build --release, como uma aplicação criada pelo init. A aplicação recebe o nome do pacote, a menos que --name indique outro, e --bin escolhe o binário quando o pacote tem vários. A raiz de um workspace é recusada: aponte o import para o pacote.
  • Um binário Linux compilado em qualquer lugar, em qualquer linguagem, é implantado da mesma forma com --binary <PATH> e enviado como está. O erpc lê o cabeçalho dele e recusa um binário que o servidor não consegue executar: um binário de macOS ou Windows, um script, uma biblioteca compartilhada, um arquivo truncado ou uma arquitetura diferente de build.target. O binário precisa ser estático, ou linkado à glibc com o loader no caminho habitual. Ele é um arquivo da aplicação: um link com esse nome que leva para fora do diretório da aplicação é recusado. Uma implantação para diante de um binário inutilizável antes de um servidor ser comprado. Compile o binário de novo antes de uma implantação que deva levar uma alteração.

O que o import lê

No diretórioO que o import faz com isso
.env.example e arquivos de exemplo semelhantesCada nome vira uma configuração quando pode ser uma: fica de fora um nome que não seja formado por letras maiúsculas, dígitos e _ (sem começar por dígito), ou um que o erpc ou o servidor define por conta própria (ERPC_WORKER_…, LD_…). Um nome comum vai para [vars] com o valor do exemplo. Um que parece segredo pelo nome, ou cujo valor contém uma credencial, é indicado junto com o comando que o guarda, e o valor dele não é copiado
.envSó os nomes são lidos, exceto um número de porta
PORT, API_PORT, o EXPOSE de um Dockerfilerun.port, a menos que --port o informe. --health <PATH> adiciona o health check nessa porta
GRPC_ENDPOINT, SHREDS_ENDPOINT e outras configurações que uma linha de dados forneceFicam fora de [vars]: a flag da linha no deploy as define
wallet.json, id.json, *keypair.jsonIndicados, com erpc worker key import <FILE> --wipe, que guarda a chave onde o erpc worker a lê e apaga o arquivo
Um arquivo compose com Redis ou PostgreSQL[services], para que o deploy os coloque no servidor
Dockerfile, o próprio arquivo composeNão são usados para executar a aplicação: o próprio erpc worker executa o binário, sob uma unidade systemd com hardening
O import --chain indica a chain da aplicação, solana por padrão.

Como o import lê um diretório

O diretório pode ser um que você clonou há um minuto, então o import o lê com cuidado.
  • O erpc.toml é criado do zero. Quando existe qualquer coisa nesse caminho, o import recusa: ele nunca escreve por cima de um arquivo nem através de um link.
  • Ele lê arquivos regulares dentro do diretório, de até 1 MiB cada. Um link que leva para fora do diretório, um pipe, um dispositivo, um arquivo maior e um arquivo que não está em UTF-8 não são lidos, e cada um deles é informado.
  • Nenhum valor que ele toma por segredo é copiado. Ele procura credenciais pelo formato, então a verificação é uma rede, não uma prova: um segredo em um formato que ele não conhece é copiado como qualquer outro valor. Cabe a você ler o erpc.toml antes de fazer o commit.
  • O erpc worker check avisa sobre menos tipos do que o import retém. Ele não diz nada sobre uma URL de RPC com uma chave no caminho, nem sobre uma frase de recuperação, em [vars]: guarde esses valores com erpc worker secret put.

O que sua aplicação encontra no servidor

  • As configurações chegam como variáveis de ambiente, tanto as de [vars] quanto as de [secrets]. Não há .env no servidor, e uma aplicação que lê um arquivo .env com uma biblioteca dotenv continua funcionando.
  • O próprio diretório da aplicação é somente leitura. Os arquivos que ela escreve ficam no diretório indicado por ERPC_WORKER_STATE_DIR (que também é o HOME dela), que uma implantação mantém e que o erpc worker backup inclui no backup.
  • Uma chave de trading chega por um pipe, não em um arquivo: 64 bytes no descritor de arquivo indicado por ERPC_WORKER_KEY_FD, uma única vez, quando a aplicação inicia, com a chave pública em ERPC_WORKER_PUBKEY. Uma aplicação que lê um arquivo de chave só precisa mudar essa leitura; o src/wallet.rs do modelo pumpfun mostra como.
  • Ela é um binário e os arquivos que run.files lista. Qualquer outra coisa que ela abra em tempo de execução precisa estar nessa lista.

Próximos passos

  • Chaves e segredos: Guarde as configurações que o import reteve e a chave de trading.
  • Firewall e WAF: Escolha quem pode acessar a aplicação.
  • O guia do worker: Todos os arquivos que o import lê e os formatos de credencial que ele procura.
AnteriorInício rápidoPróximoChaves e segredos