GN⁺: 자동 HTTPS 기능을 갖춘 궁극의 서버, Caddy
(caddyserver.com)Caddy의 주요 기능
- 보안 및 확장성: Caddy는 모든 사이트에 대해 기본적으로 TLS 인증서를 자동으로 획득하고 갱신함. 이는 사이트를 더 안전하고 신뢰할 수 있게 만듦.
- 온디맨드 TLS: 고객 소유의 도메인에 대해 TLS 인증서를 동적으로 관리하여 SaaS 비즈니스를 쉽게 확장할 수 있음.
- 대규모 TLS 관리: Caddy는 수십만 개의 사이트와 수천 개의 인스턴스를 안정적으로 관리할 수 있도록 설계됨.
Caddy의 장점
- 무료 소프트웨어: Caddy는 무료로 제공되며, 후원을 통해 지속적인 개발이 가능함.
- 고급 HTTPS 서버: Caddy는 TLS와 PKI를 기본으로 제공하며, 내부 PKI 관리도 가능함.
- 구성 API: JSON 문서를 RESTful API로 내보내고 조작할 수 있음.
- 규정 준수: PCI, HIPAA, NIST 규정을 기본적으로 준수함.
Caddy의 고급 기능
- 클러스터 조정: 여러 Caddy 인스턴스를 동일한 저장소로 구성하여 인증서 관리를 자동으로 조정할 수 있음.
- 동적 백엔드: 요청 시 동적으로 백엔드를 검색하여 빠르게 변화하는 환경에 적합함.
- 고가용성: 고급 상태 검사, 구성 변경, 회로 차단, 부하 제한 등의 기능을 제공함.
Caddy의 구성 및 확장성
- 유연한 구성: JSON을 기본 구성 형식으로 사용하며, 다양한 형식의 구성 어댑터를 지원함.
- 무한한 확장성: Caddy는 모듈식 아키텍처로 설계되어 필요한 기능만 컴파일하여 사용할 수 있음.
- 고성능: 네이티브 CPU 성능을 제공하며, 플러그인은 정적 바이너리에 컴파일됨.
Caddy의 사용 사례
- PHP 애플리케이션 서버: FrankenPHP를 통해 PHP 페이지를 빠르게 제공하며, 별도의 PHP 설치가 필요 없음.
- 정적 파일 서버: Caddy는 강력한 파일 서버 기능을 제공하며, 다양한 미들웨어 기능과 결합 가능함.
- 자동 인증서 관리: Caddy는 인증서를 자동으로 관리하여 사이트를 항상 온라인 상태로 유지함.
사용자 및 전문가의 추천
- Caddy는 사용하기 쉽고, 보안이 뛰어나며, 강력한 기능 세트를 제공하여 많은 사용자와 전문가들로부터 추천받음.
- 다양한 사용자들이 Caddy의 간단한 구성과 자동화된 기능에 만족하고 있음.
mholt님 개인 프로젝트 시절인 프로젝트 초창기부터 사용해왔고 초기에 PR도 날렸었는데 이렇게 큰 거 보니 저도 뿌듯하네요. 새로 셋업하는 서버 중 k8s 환경이 아닌 곳들은 전부 caddy만 쓰고 있습니다. throughput이 높지 않다는 말은 오래 전부터 있어왔지만 정말 caddy의 throughput이 문제가 될 수준의 트래픽이 나오는 서비스를 운영하는 게 너무 부럽네요.
몇년전부터 사용중인데, HTTPS 자동 지원이 기본설정이라 필요없는 경우 이를 회피하기 위한 설정을 해야하는 것이 처음엔 어색하게 느껴졌습니다.
웹서버가 이렇게 간단해도 되나 싶을정도로 간단해서 애용중입니다.
caddy가 압도적으로 강하고 간편하긴 한데, 스루풋이 그렇게 좋은편은 아닌 것 같아요.
그리고 장점일 수도 단점일 수도 있는데, 원하는 플러그인이 있으면 포함해서 빌드해야합니다.
기본적으로 있을거라 예상했던 캐시 기능이 플러그인으로 있고 그걸 또 빌드해서 사용해야 하더라구요.. 그 단점을 제외하면 잘 사용하고 있습니다
https://www.youtube.com/watch?v=N5PAU-vYrN8&t=663s
확실히 소규모 프로젝트에서 사용하기 좋습니다. https 붙일때, nginx에서는 certbot 를 붙이고 했는데, 여기는 기본지원이었습니다.
단점은 성능은 nginx > caddy 입니다.
Hacker News 의견
-
Caddy는 개발 중 HTTP2로 API를 로컬 테스트할 때 매우 유용함
- 대부분의 개발 서버는 HTTP1만 지원하여 로컬호스트에 최대 6개의 동시 연결만 가능함
- HTTP2는 SSL이 필요하여 로컬에서 테스트/설정하기 번거로움
- Caddy 리버스 프록시를 사용하면 OS 신뢰 저장소에 루트 인증서를 설치하여 HTTP2를 즉시 사용할 수 있음
- ElectricSQL은 사용자에게 이를 추천하며, HTTP2는 6개의 동시 연결을 잠그지 않음
- Vite 앞에 Caddy를 배치하면 리로드가 훨씬 빨라짐
- Vite는 브라우저에서 개별 파일을 로드하는 JS 모듈 시스템을 사용하며 HMR을 지원함
- HTTP2를 통해 Caddy를 Vite 앞에 두면 이러한 문제를 모두 해결할 수 있음
-
nginx에서 caddy-docker-proxy로 전환한 후 Pangolin으로 이동하여 매우 만족스러움
- Pangolin은 traefik의 프론트엔드로, 내장 인증과 Wireguard를 통한 트래픽 터널링 기능을 제공함
- Minecraft 서버를 위한 TCP 포워딩이 필요했으며, 이를 매우 간단하게 해결함
- Nginx Proxy Manager의 더 나은 버전을 원하는 사람에게 추천함
- 문서가 아직 부족하지만, 유지 관리자는 Discord에서 매우 도움을 줌
-
Caddy에 대해 나쁜 말을 할 수 없지만, Nginx보다 인증서 설정이 더 쉬운 것이 유일한 장점으로 들림
- Kubernetes 클러스터를 몇 년 전에 자동으로 인증서를 생성하고 갱신하도록 구성함
- Ingress를 통해 모든 것이 처리되며, Nginx 로드 밸런서를 새 도메인에 지정하면 알아서 처리됨
- 로컬 HTTPS가 자주 필요하지 않지만, 필요할 때는 외부 접근도 필요함
- Nginx를 실행하는 서버를 사용하여 로컬호스트로 프록시함
- 이 방법이 나에게는 잘 맞으며, 바꿀 이유가 없기 때문에 계속 사용할 것임
-
Caddy를 매우 좋아하며, 몇 년 동안 사용해왔음
- 매우 신뢰할 수 있으며 기본을 배우면 설정이 매우 쉬움
- 문서가 조금 어렵지만, NGINX 위에 letsencrypt를 신뢰성 있게 작동시키려는 것보다 훨씬 많은 시간과 에너지를 절약함
-
친근한 라이선스(Apache v2)도 중요하며, 특히 Caddy의 모듈식 아키텍처와 관련이 있음
- Caddy 주변의 생태계가 더 간단하고 안전하게 만들어짐
- 예를 들어, 인터넷 클라이언트를 제공하면서 서버를 비공개로 유지함
- Tailscale이나 OpenZiti와 같은 VPN이 이에 해당함
-
자동 HTTPS는 모든 사이트에 대해 TLS 인증서를 제공하고 갱신함
- HTTP를 HTTPS로 자동으로 리디렉션함
- 도메인의 IP를 Caddy에 지정할 때, 첫 번째 HTTPS 호출 시 인증서가 즉석에서 생성되는지 궁금함
- apex 도메인을 www로 리디렉션해야 하는 필요성 때문에 중요함
- 무료로 제공되는 서비스로 해결할 수 있지만, Caddy를 사용하면 더 간단할 수 있음
-
웹사이트를 처음부터 끝까지 읽고 나니 프로젝트의 신뢰성에 대해 확신이 서지 않음
- 너무 자화자찬하는 내용이 많아 불쾌한 느낌이 남음
- 저자들이 알려진 단점에 대해 솔직하지 않을 것 같음
- 과거에 어떻게 공개했는지 아는 사람이 있는지 궁금함
-
Caddy와 Caddy-Docker-Proxy를 결합하여 여러 도커 프로젝트가 있는 서버를 설정하는 훌륭한 방법임
- 몇 대의 서버에서 실행 중이며 잘 작동함
-
Caddy를 사랑함
- 2년 전 NGINX/OpenResty에서 전환했으며, 설정이 훨씬 간단해짐
- lua-resty-auto-ssl을 사용했지만, 이제는 사용하지 않음
- 매달 70,000명의 방문자를 잘 처리함
-
Traefik은 훌륭한 대안임
- 몇 년 동안 v1과 v2를 사용해왔으며, 도커 레이블을 사용하여 서비스 구성을 함