[ 一日30分 인생승리의 학습법] PocketBase Attempt to simplify the serve command for prod : 포켓베이스 프로덕션 포트 도메인 네임 설정
2024.06.10 00:25
[ 一日30分 인생승리의 학습법] PocketBase Attempt to simplify the serve command for prod : 포켓베이스 프로덕션 포트 도메인 네임 설정
TL;DR: With the next release you'll be able to run on prod ./pocketbase serve example.com and this should start a HTTPS server out of the box without requiring the users to edit their /etc/hosts file when a direct mapping between the domain and the vm local network interface is missing.
A lot of users reported issues related to the auto issued Let's encrypt certificate when using the PocketBase executable with a domain name (see #2795, #3179, #1510 (comment), #107 (comment), etc.)
The issues originate from the fact that when you have something like:
./pocketbase serve --http=example.com:80 --https=example.com:443
we currently try to bind only to the single IPv4/IPv6 address that example.com is resolving to.
This is not a problem when the domain is managed within the VPS vendor interface (eg. in Hetzner DNS Console, DigitalOcean Domains control panel, etc.), since this "mapping" between the VPS network interface and the domain is handled automatically by the vendor (most of the times).
But in some cases, users usually have to register manually an entry in their /etc/hosts file that describes the local network interface - domain relation (see #107 (comment)), which may no be always immediately clear.
This could be avoided if we listen to all local IPv4/IPv6 interfaces, aka. 0.0.0.0/[::] (most reverse proxies do the same thing). This is usually recommended/"safe" only for services that we want to be public accessible (as it is in our case when a Let's encrypt certificate is issued for a public domain). But it could also has some security implications, specifically on local dev environments with misconfigured/disabled firewall, because users may accidentally and unknowingly expose their service to the public (this is also why the default PocketBase address is 127.0.0.1:8090 and not 0.0.0.0:8090), so the default listener addresses ideally should be conditional.
With that said, in order to have a smoother out of the box deployment experience, with the next release the serve command will support domain(s) names as optional argument(s) that will auto set the default values behind the scene of the related --http and --https listener addresses. When at least one domain name argument is specified, the default flags values will be autoset to --http="0.0.0.0:80" and --https="0.0.0.0:443", otherwise - the current "safe" local dev defaults will be used (aka. --http="127.0.0.1:8090" and --https="")
For example:
./pocketbase serve example.com sub.example.com
Note that the --http and --https flags are still used and not deprecated!
They allow explicitly specifying the listener addresses and users can use them in combination with the above for example to listen to all IPv6 interfaces, instead of the default IPv4:
./pocketbase serve example.com --http="[::]:80" --https="[::]:443"
Additionally, in case the domain argument is missing, the existing behavior is preserved, aka.:
./pocketbase serve --http="example.com:80" --https="example.com:443"
would be more-or-less the same as running:
./pocketbase serve example.com --http="93.184.216.34:80" --https="93.184.216.34:443"
(93.184.216.34 is the IP of the example.com DNS A record)
핵심요약: 다음 릴리스에서는 prod에서 실행할 수 있게 되며 도메인과 vm 로컬 네트워크 인터페이스 간의 직접 매핑이 이루어질 때 ./pocketbase serve example.com사용자가 파일을 편집할 필요 없이 즉시 HTTPS 서버를 시작할 수 있습니다. /etc/hosts없어진.
많은 사용자가 도메인 이름과 함께 PocketBase 실행 파일을 사용할 때 자동 발급된 Let's encrypt 인증서와 관련된 문제를 보고했습니다( #2795 , #3179 , #1510(코멘트) , #107(코멘트) 등 참조).
문제는 다음과 같은 경우에 발생합니다.
./pocketbase serve --http=example.com:80 --https=example.com:443
현재는 확인되는 단일 IPv4/IPv6 주소에만 바인딩 하려고 합니다 .example.com
VPS 네트워크 인터페이스와 도메인 간의 이러한 "매핑"은 VPS 공급업체 인터페이스(예: Hetzner DNS 콘솔 , DigitalOcean 도메인 제어판 등) 내에서 관리되는 경우에는 문제가 되지 않습니다. 공급업체( 대부분의 경우 ).
/etc/hosts그러나 어떤 경우에는 사용자가 로컬 네트워크 인터페이스 - 도메인 관계( #107(설명) 참조 )를 설명하는 항목을 파일에 수동으로 등록해야 하는데 , 이는 항상 즉시 명확하지 않을 수도 있습니다.
모든 로컬 IPv4/IPv6 인터페이스(일명)를 수신하면 이 문제를 피할 수 있습니다. 0.0.0.0/ [::]( 대부분의 역방향 프록시는 동일한 작업을 수행합니다 ). 이는 일반적으로 공개적으로 액세스할 수 있기를 원하는 서비스에 대해서만 권장/"안전"합니다( 공개 도메인에 대해 Let's 암호화 인증서가 발행되는 경우 ). 그러나 특히 방화벽이 잘못 구성/비활성화된 로컬 개발 환경에서는 보안에 영향을 미칠 수도 있습니다. 사용자가 실수로 무의식적으로 자신의 서비스를 대중에게 노출할 수 있기 때문입니다(이것이 기본 PocketBase 주소가 이고 127.0.0.1:8090아닌 이유이기도 합니다 0.0.0.0:8090). 이상적으로 주소는 조건부여야 합니다.
즉, 보다 원활한 배포 환경을 제공하기 위해 다음 릴리스에서는 serve명령이 도메인 이름을 선택적 인수로 지원하여 관련 항목 뒤에 기본값을 자동으로 설정합니다 --http. --https청취자 주소. 하나 이상의 도메인 이름 인수가 지정되면 기본 플래그 값은 --http="0.0.0.0:80"및 으로 자동 설정됩니다 --https="0.0.0.0:443". 그렇지 않으면 현재 "안전한" 로컬 개발자 기본값이 사용됩니다( --http="127.0.0.1:8090"및 라고도 함 --https="") .
예를 들어:
./pocketbase serve example.com sub.example.com
--http및 플래그 --https는 여전히 사용되고 있으며 더 이상 사용되지 않습니다!
이를 통해 리스너 주소를 명시적으로 지정할 수 있으며 사용자는 이를 위와 조합하여 사용할 수 있습니다. 예를 들어 기본 IPv4 대신 모든 IPv6 인터페이스를 수신할 수 있습니다.
./pocketbase serve example.com --http="[::]:80" --https="[::]:443"
또한 도메인 인수가 누락된 경우 기존 동작이 유지됩니다.
./pocketbase serve --http="example.com:80" --https="example.com:443"
실행하는 것과 거의 동일합니다.
./pocketbase serve example.com --http="93.184.216.34:80" --https="93.184.216.34:443"
( DNS A 레코드 93.184.216.34의 IP입니다 )example.com
[출처] https://github.com/pocketbase/pocketbase/discussions/3190
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.

