Caddy web server configuration: the easy way using Caddyfile

아직 caddy(참조)에 대해 모르는 사람이 많을 것이다. 이것은 apache, nginx, lighttpd와 openlitespeed 등과 같은 웹 서버로, 현재 caddy와 nginx를 실제 서버에 운용해보고 있다.

설치 부분은 우선 제외하고, 설정만 본다면 caddyfile을 통한 쉬운 설정이 가능하다. nginx에서는 여러 부분에 걸쳐 설정해야 하는 부분이 기본적으로 되어 있어서 편리한 부분이 크다. 예를 들어:

ghkim.net {

encode gzip zstd
file_server
root * /somewhere/to/serve
php_fastcgi unix//var/run/php.sock

}Code language: JavaScript (javascript)

이 설정이면 WordPress 사이트를 운용할 수 있다. 또한 기본적으로 http/2가 자동 적용되기 때문에(인증서 포함), 매우 편리하다. v2.3 이후부터는 http/3도 자동으로 적용되며, 이전 버전이라면, 아래와 같은 부분을 caddyfile 최상단에 추가하면 된다.

{
experimental_http3
}

이전에 사용했던 XpressEngine v1.x용 rewrite는 아래와 같다. caddy v2.1.1에서 작동을 확인했다.

@a {
        path_regexp a ^/(layouts|m.layouts)/(.+)/(.+).html$
}
rewrite @a /index.php
@b {
        path_regexp b ^/(modules|addons|widgets)/(.+)/(conf|queries|schemas)/(.+).xml$
}
rewrite @b /index.php
@c {
        path_regexp c ^/(.+)/files/(member_extra_info|attach|cache|faceOff)/(.*)
}
rewrite @c /files/{http.regexp.c.2}/{http.regexp.c.3}
@d {
        path_regexp d ^/(.+)/(files|modules|widgets|widgetstyles|layouts|m.layouts|addons)/(.*)
}
rewrite @d /{http.regexp.d.2}/{http.regexp.d.3}
@e {
        path_regexp e ^/(rss|atom)$
}
rewrite @e /index.php?module=rss&act={http.matchers.path_regexp.e.1}
@f {
        path_regexp f ^/([a-zA-Z0-9_]+)/(rss|atom|api)$
}
rewrite @f /index.php?mid={http.regexp.f.1}&act={http.regexp.f.2}
@g {
        path_regexp g ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/(rss|atom|api)$
}
rewrite @g /index.php?vid={http.regexp.g.1}&mid={http.regexp.g.2}&act={http.regexp.g.3}
@h {
        path_regexp h ^/([0-9]+)/(.+)/trackback$
}
rewrite @h /index.php?document_srl={1}&key={2}&act=trackback
@i {
        path_regexp i ^/([a-zA-Z0-9_]+)/([0-9]+)/(.+)/trackback$
}
rewrite @i /index.php?vid={http.regexp.i.1}&document_srl={http.regexp.i.2}&key={http.regexp.i.3}&act=trackback
@j {
        path_regexp j ^/admin/?$
}
rewrite @j /index.php?module=admin
@k {
        path_regexp k ^/([0-9]+)$
}
rewrite @k /index.php?document_srl={http.regexp.k.1}
@l {
        path_regexp l ^/([a-zA-Z0-9_]+)/?$
}
rewrite @l /index.php?mid={http.regexp.l.1}
@m {
        path_regexp m ^/([a-zA-Z0-9_]+)/([0-9]+)$
}
rewrite @m /index.php?mid={http.regexp.m.1}&document_srl={http.regexp.m.2}
@n {
        path_regexp n ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/?$
}
rewrite @n /index.php?vid={http.regexp.n.1}&mid={http.regexp.n.2}
@o {
        path_regexp o ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/([0-9]+)$
}
rewrite @o /index.php?vid={http.regexp.o.1}&mid={http.regexp.o.2}&document_srl={http.regexp.o.3}
@p {
        path_regexp p ^/([a-zA-Z0-9_]+)/entry/(.+)$
}
rewrite @p /index.php?mid={http.regexp.p.1}&entry={http.regexp.p.2}
@q {
        path_regexp q ^/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/entry/(.+)$
}
rewrite @q /index.php?vid={http.regexp.q.1}&mid={http.regexp.q.2}&entry={http.regexp.q.3}

rewrite 부분은 다소 복잡하다. 하지만 이 부분에 한해서 한 번만 시간을 들여 놓으면, 다른 부분들은 nginx나 httpd보다 훨씬 편리하게 설정하여 전체적으로는 시간을 절약할 수 있다. 다만 사이트 동작이 미묘하게 이상할 때 웹서버 탓을 하게 되는 것은 단점. 보통은 각 디렉토리의 소유권 문제부터 확인해야 한다.