ERPC

erpc worker import से अपना मौजूदा app deploy करें

erpc worker import आपके पास पहले से मौजूद app को जैसा है वैसा ही ले लेता है। यह app का erpc.toml लिखता है और उसके code में कुछ नहीं बदलता।
यह पेज ERPC CLI v0.1.0-rc.4 के बारे में है, जो एक प्री-रिलीज़ है।

इम्पोर्ट और deploy करें

App कोई bot हो सकता है जो आज systemd या Docker के तहत चलता है, या किसी दूसरी भाषा में लिखी कोई service। import app की directory पढ़ता है और वह erpc.toml लिखता है जिसका वर्णन वह directory करती है। App में और कुछ नहीं लिखा जाता, उसमें कुछ भी चलाया नहीं जाता, और उसका code नहीं बदला जाता। erpc app को अपनी सूची में जोड़ता है, जैसा 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
  • Cargo package cargo build --release से build होता है, जैसे init से बना app। App का नाम package के नाम पर रखा जाता है, जब तक --name कुछ और न कहे, और package में कई binaries हों तो --bin binary चुनता है। Workspace root अस्वीकार होता है: import को package की ओर point करें।
  • कहीं भी, किसी भी भाषा में build किया गया Linux binary --binary <PATH> के साथ उसी तरह deploy होता है, और जैसा है वैसा ही भेजा जाता है। erpc उसका header पढ़ता है और ऐसा binary अस्वीकार करता है जिसे सर्वर नहीं चला सकता: macOS या Windows binary, script, shared library, बीच में कटी हुई फ़ाइल, या build.target से अलग architecture। Binary static होना चाहिए, या glibc से link हो और उसका loader सामान्य path पर हो। यह app की एक फ़ाइल है: उस नाम का कोई link जो app की directory से बाहर ले जाता है, अस्वीकार होता है। अनुपयोगी binary होने पर deploy सर्वर खरीदे जाने से पहले रुक जाता है। जिस deploy में कोई बदलाव जाना है, उससे पहले binary फिर से build करें।

import क्या पढ़ता है

Directory मेंimport उसके साथ क्या करता है
.env.example और ऐसी ही example फ़ाइलेंहर नाम, जब वह सेटिंग बन सकता हो, एक सेटिंग बनता है: ऐसा नाम जो capital letters, अंकों और _ से बना (और अंक से शुरू न होने वाला) नाम नहीं है, या ऐसा नाम जिसे erpc या सर्वर खुद सेट करता है (ERPC_WORKER_…, LD_…), छोड़ दिया जाता है। सादा नाम example की value के साथ [vars] में जाता है। जो नाम से secret जैसा लगता है, या जिसकी value में कोई credential है, उसके लिए वह कमांड बताई जाती है जो उसे रखती है, और उसकी value copy नहीं की जाती
.envसिर्फ़ नाम पढ़े जाते हैं, पोर्ट नंबर को छोड़कर
PORT, API_PORT, किसी Dockerfile का EXPOSErun.port, जब तक --port इसे न दे। --health <PATH> उस पोर्ट पर हेल्थ चेक जोड़ता है
GRPC_ENDPOINT, SHREDS_ENDPOINT और डेटा लाइन से मिलने वाली दूसरी सेटिंग[vars] से बाहर छोड़ी जाती हैं: deploy पर लाइन का flag उन्हें सेट करता है
wallet.json, id.json, *keypair.jsonइनका नाम बताया जाता है, साथ में erpc worker key import <FILE> --wipe, जो key को वहाँ रखता है जहाँ से erpc worker उसे पढ़ता है और फ़ाइल को wipe करता है
Redis या PostgreSQL वाली compose फ़ाइल[services], ताकि deploy उन्हें सर्वर पर लगाए
Dockerfile, खुद compose फ़ाइलapp चलाने के लिए इस्तेमाल नहीं होतीं: erpc worker binary को खुद चलाता है, हार्डन की गई systemd यूनिट के तहत
import --chain बताता है कि app किस चेन के लिए है, default solana।

import directory कैसे पढ़ता है

हो सकता है directory आपने एक मिनट पहले clone की हो, इसलिए import उसे सावधानी से पढ़ता है।
  • erpc.toml नया बनाया जाता है। उस path पर कुछ भी मौजूद हो, तो import अस्वीकार करता है: यह कभी किसी फ़ाइल के ऊपर या किसी link के ज़रिए नहीं लिखता।
  • यह directory के अंदर की regular फ़ाइलें पढ़ता है, हर एक 1 MiB तक। Directory से बाहर ले जाने वाला link, pipe, device, इससे बड़ी फ़ाइल और ऐसी फ़ाइल जो UTF-8 नहीं है, नहीं पढ़ी जाती, और हर एक के बारे में बताया जाता है।
  • जिस value को यह secret मानता है, वह copy नहीं की जाती। यह credentials को उनके आकार से ढूँढता है, इसलिए यह जाँच एक जाल है, सबूत नहीं: ऐसे आकार का secret जिसे यह नहीं पहचानता, किसी भी दूसरी value की तरह copy हो जाता है। erpc.toml को commit करने से पहले पढ़ना आपके ज़िम्मे है।
  • erpc worker check उतनी तरह की चीज़ों की चेतावनी नहीं देता जितनी import रोक लेता है। [vars] के तहत, path में key वाले RPC URL के बारे में या recovery phrase के बारे में यह कुछ नहीं कहता: उन्हें erpc worker secret put से रखें।

सर्वर पर आपके app को क्या मिलता है

  • सेटिंग environment variables के रूप में आती हैं, [vars] और [secrets] दोनों। सर्वर पर कोई .env नहीं होता, और जो app dotenv library से .env फ़ाइल पढ़ता है, वह काम करता रहता है।
  • उसकी अपनी directory read-only है। वह जो फ़ाइलें लिखता है, वे उस directory के नीचे जाती हैं जिसका नाम ERPC_WORKER_STATE_DIR देता है (यही उसका HOME भी है), जिसे deploy बनाए रखता है और erpc worker backup जिसका बैकअप लेता है।
  • Trading key किसी फ़ाइल में नहीं, pipe पर आती है: ERPC_WORKER_KEY_FD जिस file descriptor का नाम देता है, उस पर 64 bytes, एक बार, जब app शुरू होता है, और public key ERPC_WORKER_PUBKEY में। जो app key फ़ाइल पढ़ता है, उसे वही एक read बदलना होता है; pumpfun template का src/wallet.rs इसे दिखाता है।
  • App में एक binary और वे फ़ाइलें होती हैं जिनकी सूची run.files में है। Run time पर यह जो कुछ और खोलता है, वह उस सूची में होना चाहिए।

अगले चरण

  • keys और secrets: जो सेटिंग import ने रोक लीं, उन्हें और trading key को रखें।
  • फ़ायरवॉल और WAF: चुनें कि app तक कौन पहुँच सकता है।
  • worker गाइड: हर फ़ाइल जिसे import पढ़ता है, और credentials के वे आकार जिन्हें यह ढूँढता है।
पिछलाक्विकस्टार्टअगलाkeys और secrets