Fly.io 클라우드 서버에 Syncthing 배포하기
최근에 여러 기기 간 파일을 동기화하는 오픈소스 도구인 Syncthing을 알게 되었습니다.
개인 기기에서 Syncthing을 설정하는 건 쉬웠지만, 클라우드 서버에 배포하는 과정은 꽤 흥미로운 여정이었습니다.
왜 클라우드에서 Syncthing을 실행할까요?
Syncthing은 파일을 P2P 방식으로 동기화합니다. 즉, 동기화를 유지하려면 최소 두 대의 기기가 동시에 온라인 상태이고 Syncthing을 실행하고 있어야 합니다. 데스크톱에서 파일을 수정한 뒤 전원을 끄고 노트북만 들고 출장을 가면, 데스크톱에서 한 변경 사항이 노트북에 반영되지 않습니다.
만약 항상 온라인 상태로 대기하는 클라우드 서버 한 대에서 Syncthing을 실행한다면, 기기들이 서로 동기화되지 않는 상황을 방지할 수 있습니다.
인생 이야기는 됐고 — Syncthing 배포 방법만 알려 주세요
실패했던 Syncthing 배포 시도들도 함께 공유하려고 합니다. 바로 해결책으로 넘어가고 싶다면 “Fly.io에 Syncthing 배포하는 방법” 섹션을 참고하세요.
기존 사례: Fly.io에서 Syncthing + Tailscale
지난 2년간 Fly.io는 제가 가장 선호하는 클라우드 호스팅 제공업체였기 때문에, Fly.io에서 Syncthing을 다룬 글이 있는지 찾아보았습니다. 마침 1년도 채 되지 않아 Andrew Katz가 멋진 튜토리얼을 작성해 두었다는 사실을 알게 되었습니다.
Andrew의 튜토리얼은 제 아이디어가 실현 가능하다는 것을 보여 주었기 때문에 정말 반가운 소식이었습니다. 다만 한 가지 아쉬운 점은 인기 있는 VPN 솔루션인 Tailscale에 의존한다는 것이었습니다. 저는 Tailscale을 좋아하지만, 이 맥락에서는 분명한 단점이 있습니다.
Syncthing과 Tailscale을 함께 사용하려면 커스텀 Docker 이미지를 빌드해야 합니다. 두 도구가 계속 발전하는 동안 이미지를 계속 업데이트해야 하는 건 적지 않은 유지보수 부담입니다. 그리고 하나의 컨테이너에 두 애플리케이션을 섞는 것은 Docker 관점에서도 그다지 바람직하지 않습니다.
모든 Fly.io 서버에는 기본적으로 WireGuard VPN이 포함되어 있습니다. Tailscale을 굳이 섞는 대신 이미 존재하는 WireGuard 연결을 활용하면 Andrew의 방법을 더 개선할 수 있지 않을까 생각했습니다.
linuxserver Docker 이미지는 Fly.io에서 동작하지 않습니다
Syncthing Docker 이미지를 검색할 때 저는 어쩌다 공식 Docker 이미지를 놓치고 대신 비공식 LinuxServer.io 버전을 찾았습니다.
linuxserver.io 버전을 Fly.io에 배포해 보았지만, 서버가 즉시 크래시 루프에 빠졌습니다.
2023-05-23T12:44:17.247 [info] Preparing to run: `/init` as root
2023-05-23T12:44:17.258 [info] 2023/05/23 12:44:17 listening on [fdaa:0:20ad:a7b:cb:a9e9:30cd:2]:22 (DNS: [fdaa::3]:53)
2023-05-23T12:44:17.261 [info] s6-overlay-suexec: fatal: can only run as pid 1같은 문제를 다룬 Fly.io 지원 스레드를 발견했습니다.
조금 더 파고들어 보니 원인을 알 것 같습니다! 마지막 메시지에 나온 오류
s6-overlay-suexec: fatal: can only run as pid 1덕분에조금 더 찾아보니 제가 사용하는 이미지가 pid 1으로 실행되어야 하는 프로세스 매니저를 사용하는데, Fly.io 앱 내부에서 여러 프로세스 실행하기 문서에 따르면 그건 불가능하다고 합니다.
linuxserver Docker 소스를 살펴보니, 런타임 이미지가 linuxserver/baseimage-alpine에 의존하고 있었습니다. 해당 이미지의 소스를 열어 보니 init 프로세스에 대해 잘 알지는 못하지만 파일 안에 init과 관련된 코드가 여러 줄 있었고, @mpaupulaire님이 지적한 문제가 제가 겪은 크래시 루프를 설명하는 것으로 보였습니다.
공식 Syncthing Docker 이미지가 있는지 더 꼼꼼히 확인하는 대신, 3시간을 들여 직접 이미지를 만들었습니다. 이 튜토리얼을 작성하려고 앉았을 때 공식 이미지를 놓쳤다는 사실을 깨달았고, 그래서 그 부분은 건너뛰겠습니다.
Fly.io에 Syncthing 기본 배포하기
공식 Syncthing Docker 이미지를 확보했으니 Fly.io에 배포할 준비가 되었습니다. 먼저 새로운 Fly.io 앱을 만들었습니다.
$ fly apps create --name syncthing-mtlynch
? Select Organization: Michael Lynch (personal)
New app created: syncthing-mtlynchSyncthing은 데이터를 저장할 공간이 필요하므로, syncthing_data라는 Fly.io 영구 볼륨을 만들었습니다.
SIZE_IN_GB=3 # This is the limit of fly.io's free tier as of 2023-05-29
fly volumes create syncthing_data \
--size "${SIZE_IN_GB}" \
--yes다음으로 Syncthing용 최소 Fly.io 설정을 만들었습니다.
app = "syncthing-mtlynch"
[build]
image = "syncthing/syncthing:1.23.4"
[mounts]
source="syncthing_data"
destination="/var/syncthing"이제 진짜 순간입니다. 앱을 실행했습니다.
$ fly deploy
==> Verifying app config
Validating /tmp/tmp.mezhLZdpSv/fly.toml
Platform: machines
✓ Configuration is valid
--> Verified app config
==> Building image
Searching for image 'syncthing/syncthing:1.23.4' remotely...
image found: img_98dgp8mlx504xw05
Watch your app at https://fly.io/apps/syncthing-mtlynch/monitoring
Updating existing machines in 'syncthing-mtlynch' with rolling strategy
[1/1] Replacing 6e82ddd3ae5698 [app] by new machine
[1/1] Machine 918570e1f96283 [app] update finished: success
Finished deploying그리고 성공했습니다! 로그를 보니 Syncthing이 정상적으로 실행되고 있었습니다.
2023/05/25 12:09:52 INFO: My ID: YERKMWG-WMUKYOR-J57TFK7-LQ3NHPX-6TI5AFU-IX7SEEW-GX7QO3C-NPYATQT
2023/05/25 12:09:53 INFO: GUI and API listening on [::]:8384
2023/05/25 12:09:53 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
2023/05/25 12:09:53 INFO: My name is "918570e1f96283"
2023/05/25 12:09:53 INFO: Completed initial scan of sendreceive folder "Default Folder" (default)
2023/05/25 12:10:12 INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT
2023/05/25 12:10:12 INFO: quic://0.0.0.0:22000 resolved external address quic://66.225.222.75:22000 (2023/05/25 12:10:32 INFO: Joined relay relay://54.175.93.212:443로그에 Syncthing 서버의 Device ID가 표시되어, 로컬 Syncthing 서버에서 피어로 추가할 수 있었습니다.
안타깝게도 로컬 Syncthing 인스턴스가 클라우드 서버에 연결하지 못했습니다.
이는 Fly.io 서버에서 인바운드 트래픽을 허용하도록 설정하지 않았기 때문에 예상된 결과입니다.
서버를 그대로 두면 결국 릴레이를 통해 연결되겠지만, 수신 포트를 올바르게 설정하는 것이 Syncthing이 더 원활하게 동작하는 방법입니다.
Syncthing 방화벽 포트 설정하기
이 시점에서 Syncthing은 Fly.io에서 실행되고 있었지만, 다른 기기들의 트래픽을 받을 수 없는 상태였습니다.
다행히 Syncthing은 피어와 통신하는 데 필요한 포트를 노출하도록 방화벽을 설정하는 방법을 문서에 매우 명확하게 설명해 두고 있습니다.
포트 22000/TCP: TCP 기반 동기화 프로토콜 트래픽
포트 22000/UDP: QUIC 기반 동기화 프로토콜 트래픽
포트 21027/UDP: IPv4 디스커버리 브로드캐스트 및 IPv6 멀티캐스트용
이 내용을 Fly.io 설정으로 옮기면 다음과 같습니다.
[[services]]
internal_port = 22000
protocol = "tcp"
[[services.ports]]
port = 22000
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 0
timeout = "2s"
[[services]]
internal_port = 22000
protocol = "udp"
[[services.ports]]
port = 22000
[[services]]
internal_port = 21027
protocol = "udp"
[[services.ports]]
port = 21027저는 22000번 포트를 헬스 체크 포트로 사용했습니다. Fly.io가 주기적으로 해당 포트를 확인하고, 연결할 수 없으면 Syncthing에 문제가 있다는 것을 알게 됩니다.
Syncthing Docker 이미지의 관리 인터페이스는 기본적으로 0.0.0.0:8384에서 동작하므로, 사설 네트워크와 공용 네트워크 인터페이스 모두에서 연결을 받습니다. Fly.io 설정에서 8384 포트를 노출하지 않았기 때문에 사실 큰 문제는 되지 않습니다. 하지만 다중 방어 차원에서 Syncthing이 루프백 인터페이스에서만 수신하도록 설정했습니다.
Syncthing의 문서에는 STGUIADDRESS 환경 변수를 비워 두면 관리 UI 접근을 제한할 수 있다고 설명되어 있습니다.
[env]
# Only listen for connections to admin GUI through localhost.
STGUIADDRESS = ""모두 합치면 fly.toml 파일은 다음과 같이 됩니다.
app = "syncthing-mtlynch"
[build]
image = "syncthing/syncthing:1.23.4"
[env]
# Only listen for connections to admin GUI through localhost.
STGUIADDRESS = ""
[mounts]
source="syncthing_data"
destination="/var/syncthing"
[[services]]
internal_port = 22000
protocol = "tcp"
[[services.ports]]
port = 22000
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 0
timeout = "2s"
[[services]]
internal_port = 22000
protocol = "udp"
[[services.ports]]
port = 22000
[[services]]
internal_port = 21027
protocol = "udp"
[[services.ports]]
port = 21027Tailscale 없이 Syncthing 설정하기
이제 Fly.io에서 Syncthing이 실행되고 있습니다! 로그에서 Device ID를 가져와 Fly.io Syncthing 노드를 피어로 추가할 수 있습니다.
아직 문제가 하나 남아 있습니다. Syncthing에서 피어 관계는 상호 동의가 필요합니다. 제 기기들이 클라우드 서버와 관계를 맺도록 하려면 클라우드 서버의 관리 대시보드에 접속해야 합니다.
클라우드 서버의 Syncthing 관리 인터페이스를 인터넷 전체에 공개하고 싶지는 않았습니다. 이론적으로는 강력한 비밀번호로 보호할 수도 있지만, 네트워크 계층에서의 보호가 더 강력하고 믿을 수 있습니다.
Andrew Katz는 이 문제를 자신의 Fly.io Syncthing 서버를 개인 Tailscale VPN에 연결하는 방식으로 해결했습니다. 이를 통해 VPN 내부에서는 관리 인터페이스에 접근할 수 있으면서도 외부의 접근은 차단할 수 있었습니다.
앞서 말씀드렸듯이 모든 Fly.io 서버에는 WireGuard VPN이 내장되어 있는데, 그렇다면 그 방식으로 관리 인터페이스에 접근할 수는 없을까요?
먼저 서버에 SSH로 접속을 시도해 보았습니다.
$ fly ssh console
Connecting to fdaa:0:20ad:a7b:15f:92b0:4091:2... complete
32874e1dc76685:/#쉽네요. 이제 Syncthing 서버에 대한 콘솔 접근 권한을 얻었고, 원하는 명령을 무엇이든 실행할 수 있게 되었습니다.
일반적인 ssh 유틸리티에서는 로컬 포트를 SSH 연결 반대편으로 터널링할 수 있습니다. 로컬 포트 8384를 Syncthing 서버의 8384 포트로 터널링할 수 있다면, Syncthing 서버의 관리 대시보드에 접근할 수 있을 것입니다.
안타깝게도 fly ssh 명령은 포트 포워딩을 지원하지 않아서 그 방법은 사용할 수 없었습니다. 하지만 fly 유틸리티에 proxy 명령이 있다는 것을 발견하고 시도해 보았습니다.
$ fly proxy 8384:8384
Proxying local port 8384 to remote [syncthing-mtlynch.internal]:8384뭔가 동작하는 것처럼 보였습니다. 하지만 연결을 시도해 보니 되지 않았습니다.
$ curl http://localhost:8384
curl: (56) Recv failure: Connection reset by peer더 간단한 테스트로 포트 8000에서 netcat을 실행한 뒤 그 포트로 프록시를 시도해 보았습니다.
32874e1dc76685:/# nc -l 8000$ fly proxy 8000:8000
Proxying local port 8000 to remote [syncthing-mtlynch.internal]:8000$ curl http://localhost:8000
curl: (56) Recv failure: Connection reset by peerFly.io 서버에서 netcat은 아무런 연결 시도도 표시하지 않았습니다. 도대체 왜 그런 걸까요?
“Fly proxy seemingly doesn't work”이라는 제목의 Fly.io 포럼 글을 찾았는데, 그 순간 제 심정을 정확히 대변하는 제목이었습니다.
로컬 컴퓨터를 fly proxy 8080을 통해 연결하려고 하는데 다음과 같은 메시지가 표시됩니다.
Proxying local port 8080 to remote [notion-to-calendar.internal]:8080그런데
curl localhost:8080이나curl 0.0.0.0:8080을 실행하면 프록시를 종료할 때까지 그냥 멈춰 있습니다.
Fly.io 팀의 @jerome님이 원인을 설명해 주었습니다.
ipv6에 바인딩된 리스너만
fly proxy명령으로 접근할 수 있습니다.
아, IPv6! 그렇다면 설명이 됩니다. Syncthing이 IPv4 인터페이스에서 수신 대기 중이었다면 Fly.io 프록시로부터의 연결을 받지 못했을 것입니다.
이전에 Sia Docker 이미지를 유지보수할 때 비슷한 문제를 겪은 적이 있습니다. 그때의 해결책은 socat이라는 도구로 연결을 프록시하는 것이었기 때문에, 이번에도 IPv6 포트 8386에서 수신 대기하고 IPv4 포트 8384로 연결을 전달하도록 시도해 보았습니다.
apk add socat && \
socat TCP6-LISTEN:8386,fork,su=nobody TCP4:localhost:8384그런 다음 fly proxy 명령을 IPv6 포트로 트래픽을 보내도록 업데이트했습니다.
fly proxy 8384:8386그리고 짜잔! 성공했습니다. 로컬 기기에서 클라우드 서버의 Syncthing 관리 대시보드에 접근할 수 있게 되었습니다.
Andrew Katz의 방법은 Fly.io 서버의 관리 인터페이스를 언제든지 사용할 수 있게 해준다는 장점이 있습니다. 제 Fly.io 서버에서 관리 작업을 하려면 임시 프록시를 설정하는 번거로운 과정을 거쳐야 하지만, 사실 저에게는 괜찮습니다. 유지보수는 자주 일어나지 않을 것 같으니, 약간의 불편함은 감수할 수 있습니다.
socat 꼼수를 피할 수는 없을까요?
IPv6를 socat으로 프록시하는 방법은 동작했지만, 보기에도 복잡하고 깔끔하지 않습니다. 더 나은 방법은 없을까요?
Syncthing이 기본적으로 IPv6를 지원하는 것 같았기 때문에, Fly.io 서버의 IPv6 루프백 인터페이스인 ::1에서 수신 대기하도록 설정해 보았습니다.
[env]
STGUIADDRESS = "[::1]:8384"fly deploy로 재배포하니 모든 것이 정상적으로 시작되었습니다. 로그에도 Syncthing이 이제 ::1에서 수신 대기 중이라고 표시되었습니다.
INFO: Access the GUI via the following URL: http://[::1]:8384/좋습니다. 프록시 명령을 다시 시도해 보겠습니다.
$ fly proxy 8384:8384
Proxying local port 8384 to remote [syncthing-mtlynch.internal]:8384그리고 이제 8384 포트로 연결을 시도해 보겠습니다.
$ curl http://localhost:8384/
curl: (56) Recv failure: Connection reset by peer아이고! 아깝습니다.
Syncthing 서버 로그에는 다음과 같은 메시지가 수십 줄 찍혀 있었습니다.
[UPMD6] 2023/05/25 11:41:16 INFO: Listen (BEP/tcp): TLS handshake: EOFTLS? 어? Syncthing 로그에는 평문 http:// 연결을 수신 대기 중이라고 되어 있었는데. 혹시나 해서 HTTPS 프로토콜로도 시도해 보았습니다.
$ curl https://localhost:8384/
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to localhost:8384역시 안 됩니다. 해결책에 거의 다다른 것 같은데, 혹시 아이디어가 있는 독자분이 있다면 알려 주세요.
제가 고려했던 다른 방법은 웹 GUI를 아예 건너뛰고 진정한 해커처럼 CLI로 모든 작업을 처리하는 것이었습니다.
$ syncthing cli --home /var/syncthing/config config devices
NAME:
syncthing cli config devices -
USAGE:
syncthing cli config devices command [command options] [arguments...]
COMMANDS:
ACTIONS:
list List item keys in the collection
add Add a new item to collection
add-json Add a new item to collection deserialised from JSON하지만 Syncthing의 CLI는 꽤 복잡해 보였기 때문에, 웹 GUI를 사용하는 것으로 만족하기로 했습니다.
업데이트 (2023-06-29): 해결책을 찾았습니다!
독자분들께서 fly-local-6pn 주소를 알려주신 덕분입니다. fly.toml에 다음과 같이 환경 변수를 업데이트할 수 있습니다.
STGUIADDRESS = "fly-local-6pn:8384"이제 flyctl proxy 8384:8384를 사용해 평소처럼 연결할 수 있습니다. 아래 튜토리얼도 이 개선 사항을 반영해 업데이트했습니다.
Fly.io에 Syncthing 배포하는 방법
이제 여러 번의 시행착오 끝에 Syncthing과 Fly.io를 충분히 살펴보았으니, Fly.io에 Syncthing을 배포하는 깔끔한 방법을 소개하겠습니다. 처음부터 끝까지 5분 정도면 충분합니다.
사전 준비 사항
시작하기 전에 다음이 필요합니다.
- Fly.io 계정(결제 활성화 완료)
flyCLI가 설치되고 인증된 로컬 머신
앱 만들기
먼저 새로운 Fly.io 앱을 만듭니다.
아래 예시는 앱 이름을 syncthing- 뒤에 무작위 접미사를 붙인 형태로 만들지만, Fly.io에서 아직 사용되지 않은 이름이라면 어떤 이름이든 선택할 수 있습니다.
RANDOM_SUFFIX="$(head /dev/urandom | tr -dc 'a-z0-9' | head -c 6 ; echo '')"
APP_NAME="syncthing-${RANDOM_SUFFIX}"
fly apps create --name "${APP_NAME}"Fly.io 설정 파일 만들기
다음으로 배포를 위한 Fly.io 설정 파일을 만듭니다.
저는 실행 중인 버전을 정확히 알고 있는 것을 선호하므로, SYNCTHING_VERSION을 명시적인 1.23.4 버전 이미지로 설정하고 있습니다. 매번 새로운 서버 배포 시 최신 안정 버전을 실행하고 싶다면 버전을 latest로 설정하세요. 좀 더 과감하게 가고 싶다면, 최신 기능을 담은 불안정한 릴리스인 edge나 nightly를 선택할 수도 있습니다.
REGION은 가까운 Fly.io 리전을 선택하세요.
VOLUME_NAME은 중요하지 않으며, 원하는 이름으로 변경해도 됩니다.
SYNCTHING_VERSION="1.23.4"
REGION="ewr" # Deploy to Fly.io's Newark, NJ, USA data center.
VOLUME_NAME="syncthing_data"
cat <<EOF > fly.toml
app = "${APP_NAME}"
primary_region = "${REGION}"
[build]
image = "syncthing/syncthing:${SYNCTHING_VERSION}"
[env]
# Only listen for connections to admin GUI through fly.io's private Wireguard
# network.
STGUIADDRESS = "fly-local-6pn:8384"
[mounts]
source="${VOLUME_NAME}"
destination="/var/syncthing"
[[services]]
internal_port = 22000
protocol = "tcp"
[[services.ports]]
port = 22000
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 0
timeout = "2s"
[[services]]
internal_port = 22000
protocol = "udp"
[[services.ports]]
port = 22000
[[services]]
internal_port = 21027
protocol = "udp"
[[services.ports]]
port = 21027
EOF영구 볼륨 만들기
서버가 재시작될 때마다 Syncthing의 설정과 데이터가 사라지지 않도록 영구 볼륨이 필요합니다.
볼륨 크기는 원하는 대로 선택할 수 있지만, 이 글을 쓰는 시점 기준으로 Fly.io는 무료 티어에서 3GB를 제공합니다.
SIZE_IN_GB="3" # This is the limit of fly.io's free tier as of 2023-05-24
fly volumes create "${VOLUME_NAME}" \
--region "${REGION}" \
--size "${SIZE_IN_GB}" \
--yes서버 배포하기
마지막으로 앱을 배포할 차례입니다. Syncthing에는 공용 IPv4 주소가 필요하지 않으므로 --no-public-ips 플래그를 추가할 수 있습니다.
fly deploy --no-public-ips모든 것이 정상이라면 다음과 같은 메시지가 표시됩니다.
No machines in group app, launching a new machine
Machine e286537dbd3586 [app] update finished: success
Finished launching new machines
Updating existing machines in 'syncthing-ccdb2x' with rolling strategy
Finished deployingSyncthing 클라우드 서버를 피어로 추가하기
Syncthing 서버가 실행되면 연결을 위해 Device ID가 필요합니다. 서버 로그를 확인하면 찾을 수 있습니다.
$ fly logs | grep "My ID: "
2023-05-26T04:20:28Z app[e784e736c90283] ewr [info][GHLLB] 2023/05/26 04:20:28 INFO: My ID: GHLLBWT-QJ4LGHJ-RT43QUV-DWFRMGS-5OTXHGH-LAZAIMG-HQ3TVAE-UUC2SA5로컬 Syncthing 기기에서는 “Add Device”를 클릭하고 Device ID를 입력해 클라우드 Syncthing 서버를 추가하세요. 서버 이름은 아무렇게나 지어도 됩니다. 저는 cloud-syncthing이라는 무척 창의적인 이름을 선택했습니다.
클라우드 Syncthing 서버를 “Untrusted”로 표시하면 보안을 강화할 수 있습니다. 이렇게 하면 다른 기기들이 데이터를 암호화한 뒤에만 서버로 전송하게 됩니다. 만약 공격자가 Fly.io 서버를 탈취하더라도 해독할 수 없는 암호화된 데이터만 얻게 됩니다.
마지막으로 폴더 중 하나를 새로운 Syncthing 서버와 공유하세요. Edit Folder > Sharing으로 이동해 새로운 피어의 체크박스를 선택하세요. Untrusted로 표시했다면 데이터를 암호화할 강력한 패스프레이즈를 설정하세요.
웹 UI 접속하기
Fly.io 서버의 Syncthing 관리 대시보드에 접근하려면, 로컬 포트 8388을 Fly.io 서버의 8384 포트에 연결하는 프록시를 여세요.
fly proxy 8388:8384프록시가 설정되면 로컬 기기에서 localhost URL을 통해 클라우드 서버의 Syncthing 대시보드에 접근할 수 있습니다.
다음과 같은 관리 대시보드가 표시됩니다.
축하합니다! Syncthing 서버를 클라우드에 성공적으로 배포했고, 이제 모든 권한으로 접근할 수 있습니다. 이제 다른 기기에서 Syncthing을 설정하듯이 클라우드 서버를 설정할 수 있습니다.
Fly.io 서버에서 Syncthing 설정을 마쳤다면 Ctrl+C로 fly proxy 명령을 종료하세요.