--- title: "erpc worker import로 이미 가지고 있는 앱 배포하기" description: "erpc worker import는 앱의 디렉터리를 읽어 erpc.toml을 작성하므로, Cargo 패키지나 어떤 언어로 만든 Linux 바이너리든 코드를 바꾸지 않고 배포할 수 있습니다." canonical: "https://erpc.global/ko/doc/erpc-cli/worker-import/" locale: "ko" --- # erpc worker import로 이미 가지고 있는 앱 배포하기 `erpc worker import`는 이미 가지고 있는 앱을 있는 그대로 가져옵니다. 앱의 `erpc.toml`을 작성하며, 앱의 코드는 하나도 바꾸지 않습니다. 이 페이지는 프리릴리스인 ERPC CLI `v0.1.0-rc.4`를 설명합니다. ## 가져와서 배포하기 앱은 현재 systemd나 Docker에서 실행 중인 봇일 수도 있고, 다른 언어로 만든 서비스일 수도 있습니다. `import`는 앱의 디렉터리를 읽고, 그 내용을 기술하는 `erpc.toml`을 작성합니다. 앱 안에는 그 밖에 아무것도 쓰지 않고, 앱 안의 어떤 것도 실행하지 않으며, 앱의 코드도 바꾸지 않습니다. erpc는 `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 패키지**는 `init`으로 만든 앱과 마찬가지로 `cargo build --release`로 빌드됩니다. 앱의 이름은 `--name`으로 따로 지정하지 않는 한 패키지 이름을 따르며, 패키지에 바이너리가 여러 개 있으면 `--bin`으로 고릅니다. 워크스페이스 루트는 거부되므로, `import`에는 패키지를 지정하세요. - **어디서든, 어떤 언어로든 빌드한 Linux 바이너리**도 `--binary `로 같은 방식으로 배포되며, 있는 그대로 전송됩니다. erpc는 바이너리의 헤더를 읽고 서버에서 실행할 수 없는 것은 거부합니다. macOS나 Windows 바이너리, 스크립트, 공유 라이브러리, 중간에 잘린 파일, `build.target`과 다른 아키텍처가 이에 해당합니다. 바이너리는 정적이거나, 로더가 일반적인 경로에 있는 glibc에 링크되어 있어야 합니다. 바이너리는 앱의 파일이어야 하므로, 그 이름으로 된 링크가 앱의 디렉터리 밖을 가리키면 거부됩니다. 쓸 수 없는 바이너리이면 배포는 서버를 구매하기 전에 멈춥니다. 변경 사항을 반영해야 하는 배포 전에는 바이너리를 다시 빌드하세요. ## import가 읽는 것 | 디렉터리에 있는 것 | `import`가 하는 일 | | --- | --- | | `.env.example` 및 비슷한 예시 파일 | 각 이름은 설정이 될 수 있으면 설정이 됩니다. 대문자, 숫자, `_`로 이루어지지 않은 이름(숫자로 시작하는 이름 포함)과, erpc나 서버가 직접 설정하는 이름(`ERPC_WORKER_…`, `LD_…`)은 제외됩니다. 일반 설정은 예시의 값과 함께 `[vars]`에 들어갑니다. 이름으로 보아 시크릿으로 보이거나 값에 자격 증명이 들어 있는 설정은 그것을 보관하는 명령과 함께 안내되며, 값은 복사되지 않습니다 | | `.env` | 포트 번호를 제외하면 이름만 읽습니다 | | `PORT`, `API_PORT`, Dockerfile의 `EXPOSE` | `--port`로 지정하지 않으면 `run.port`가 됩니다. `--health `를 주면 그 포트에 헬스 체크가 추가됩니다 | | `GRPC_ENDPOINT`, `SHREDS_ENDPOINT` 및 데이터 회선이 제공하는 그 밖의 설정 | `[vars]`에서 제외됩니다. `deploy`에 주는 해당 회선의 플래그가 이 설정을 정합니다 | | `wallet.json`, `id.json`, `*keypair.json` | `erpc worker key import --wipe`와 함께 안내됩니다. 이 명령은 키를 erpc worker가 읽는 곳에 보관하고 파일을 지웁니다 | | Redis나 PostgreSQL이 있는 compose 파일 | `[services]`가 되어 `deploy`가 서버에 배치합니다 | | `Dockerfile`, compose 파일 자체 | 앱 실행에는 사용하지 않습니다. erpc worker가 보안이 강화된 systemd 유닛으로 바이너리를 직접 실행합니다 | `import --chain`은 앱이 대상으로 하는 체인을 지정하며, 기본값은 `solana`입니다. ## import가 디렉터리를 읽는 방식 방금 클론한 디렉터리일 수도 있으므로 `import`는 신중하게 읽습니다. - **`erpc.toml`은 새로 만듭니다.** 그 경로에 무엇이든 있으면 `import`는 거부합니다. 파일을 덮어쓰거나 링크를 통해 쓰는 일은 절대 없습니다. - **디렉터리 안의 일반 파일을 각각 1 MiB까지 읽습니다.** 디렉터리 밖을 가리키는 링크, 파이프, 장치, 그보다 큰 파일, UTF-8이 아닌 파일은 읽지 않으며, 각각 그 사실을 알려 줍니다. - **시크릿으로 판단한 값은 복사하지 않습니다.** 자격 증명은 형태로 찾으므로 이 검사는 그물일 뿐 증명이 아닙니다. 알지 못하는 형태의 시크릿은 다른 값처럼 복사됩니다. 커밋하기 전에 `erpc.toml`을 직접 읽어 보세요. - **`erpc worker check`가 경고하는 종류는 `import`가 보류하는 종류보다 적습니다.** `[vars]` 아래에 경로에 키가 들어간 RPC URL이나 복구 문구가 있어도 아무 말도 하지 않습니다. 이런 값은 `erpc worker secret put`으로 보관하세요. ## 앱이 서버에서 보게 되는 것 - **설정은 환경 변수로 전달됩니다.** `[vars]`와 `[secrets]` 모두 마찬가지입니다. 서버에는 `.env`가 없으며, dotenv 라이브러리로 `.env` 파일을 읽는 앱도 계속 동작합니다. - **앱 자신의 디렉터리는 읽기 전용입니다.** 앱이 쓰는 파일은 `ERPC_WORKER_STATE_DIR`이 가리키는 디렉터리(앱의 `HOME`이기도 함) 아래에 놓이며, 이 디렉터리는 배포 후에도 유지되고 `erpc worker backup`이 백업합니다. - **트레이딩 키는 파일이 아니라 파이프로 전달됩니다.** 앱이 시작될 때 한 번, `ERPC_WORKER_KEY_FD`가 가리키는 파일 디스크립터로 64바이트가 전달되고, 공개 키는 `ERPC_WORKER_PUBKEY`에 들어 있습니다. 키 파일을 읽는 앱은 그 읽기 한 곳을 바꿔야 합니다. pumpfun 템플릿의 `src/wallet.rs`에 그 예가 있습니다. - **앱은 바이너리 하나와 `run.files`에 나열된 파일로 이루어집니다.** 실행 중에 여는 그 밖의 파일은 모두 이 목록에 있어야 합니다. ## 다음 단계 - [키 및 시크릿](https://erpc.global/ko/doc/erpc-cli/worker-secrets/): `import`가 보류한 설정과 트레이딩 키를 보관합니다. - [방화벽 및 WAF](https://erpc.global/ko/doc/erpc-cli/worker-firewall-and-waf/): 누가 앱에 접근할 수 있는지 정합니다. - [worker 가이드](https://github.com/elsoul/erpc-cli/blob/v0.1.0-rc.4/docs/worker.md): `import`가 읽는 모든 파일과, 찾는 자격 증명의 형태를 다룹니다.