Caddy 一个用Go实现的Web Server
这是一个Web Server的时期,apache2与nginx共舞,在寻求极致机能的路上,没有最高,只要更高。但这又是一个寻求个性化的时期,有些Web Server并没有去挤“Performance晋升”这一独木桥,而是有着本人的定位,Caddy就是这样一个开源Web Server。
Caddy的作者Matt Holt在caddy官网以及FAQ中对caddy的指标阐释如下: 其他Web Server为Web而设计,Caddy为human设计。功能定位上,与经常充当最前端反向代理的nginx不一样,caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性,运用配置简略。并且得益于Go的跨平台特性,caddy很容易的支撑了三大主流平台:Windows、 Linux、Mac。在Caddy开发者文档中,我们可以看到caddy还可以在Android(linux arm)上运转。caddy当前版本为0.7.1,还不不乱,且后续版本可能变化较大,甚至与前期版本不兼容,因而作者当前不举荐caddy在生产环境被 重度运用。
关注caddy,是由于caddy弥补了go在通用web server这块的空白(或许有其他,但我还不晓得),同时Web server in go也“相应”了近期Golang去C化的趋势(Go 1.5中C is gone!),即使caddy作者提到caddy的指标并非如nginx那样。但将来谁晓得呢?一旦Go机能足够高时,一旦caddy足够不乱时,天然而 然的就会有人将其用在某些利用的生产环境中替换nginx或apache2了。一套全Go的系统,在部署、运维方面也是有优势的。
一、安装和运转caddy
和诸多go利用同样,我们可以直接从caddy的github.com releases页中找到最新发表版(当前是0.7.1)的二进制包。这里运用的是caddy_darwin_amd64.zip。
下载解压后,进入目录,直接施行./caddy即可将caddy运转起来。
$caddy
0.0.0.0:2015
在阅读器里访问localhost:2015,页面上没有预期显示的相似"caddy works!”之类的默许Welcome页面,而是“404 Not Found"。虽然这注明caddy已经work了,但没有一个default welcome page究竟关于caddy beginer来说并不友爱。这里已经向作者提了一个sugguestion issue。
二、caddy道理
Go的net/http规范库已经供给了http server的实现,大多数场所这个http server都能知足你的需要,不管是功能还是机能。Caddy实质上也是一个Go web app,它也import net/http,嵌入*http.Server,并通过handler的ServeHTTP要领为每个请求供给服务。caddy运用 http.FileServer作为处置 静态文件的根基。caddy的诱人之处在于其middleware,将诸多middleware串成一个middleware chain以供给了灵活的web服务。另外caddy中的middleware还可以独立于caddy以外运用。
caddy从目前目录的Caddyfile(默许)文件中读取配置,当然你也可以通过-conf指定配置文件途径。Caddyfile的配置格局 确实非常easy,这也相符caddy的指标。
Caddyfile总是以站点的Addr开端的。
单一站点的Caddyfile样例如下:
//Caddyfile localhost:2015 gzip log ./2015.log
Caddy也支撑配置多个站点,相似virtualhost的 配置(80端口多路复用):
//Caddyfile foo.com:80 { log ./foo.log gzip } bar.com:80 { log ./bar.log gzip }
为了实现格调上的同一,单一站点也最佳配置为如下这种格局(代码内部称之为 Server Block):
localhost:2015 { gzip log ./2015.log }
这样Caddyfile的配置文件模板样式相似于下面这样:
host1:port { middleware1 middleware2 { … … } … … } host2:port { middleware1 middleware2 { … … } … … } … …
对于middleware,在caddy文档中有较为细致的注明和例子。关于caddy这样一个年轻的开源项目而言,其文档还算是相对较全的,虽 然此刻还不能和nginx、 apache比。
caddy中的middleware就是一个实现了middleware.Handler接口的struct,例如gzip这个 middleware:
// middleware.go type Middleware func(Handler) Handler type Handler interface { ServeHTTP(http.ResponseWriter, *http.Request) (int, error) } // gzip/gzip.go type Gzip struct { Next middleware.Handler } func (g Gzip) ServeHTTP(w http.ResponseWriter, r *http.Request) (int, error) { if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") { return g.Next.ServeHTTP(w, r) } …. … gz := gzipResponseWriter{Writer: gzipWriter, ResponseWriter: w} // Any response in forward middleware will now be compressed status, err := g.Next.ServeHTTP(gz, r) … … }
middleware.Handler的函数原型与http.Handler的不一样,不能直接作为http.Server的Handler运用。caddy运用了下面这个idiomatic go pattern:
type appHandler func(http.ResponseWriter, *http.Request) (int, error)
func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { if status, err := fn(w, r); err != nil { http.Error(w, err.Error(), status) } }
当然这个pattern有许多变种,但思绪大致相似。一个middleware chain大致就是handler1(handler2(handler3))的调用通报。
前面说过caddy是基于http.FileServer的静态文件Web Server,FileServer总会作为middleware chain的最后一环,要是没有配置任何middleware,那你的server就是一个静态文件server。
三、caddy典型利用
【静态文件Server】
caddy的最根基利用现实就是一个静态文件Server,底层由http.FileServer承载,当然caddy封装了http.FileServer,做了一些拦截处置,最后将w, r通报给http.ServeContent去处置文件数据。
第一次施行./caddy,现实上就启动了一个静态文件Server。但这个server不默许支撑你navigate directory。要是你晓得website root目录(要是没有指定root,则caddy施行的目前途径会作为website的root途径)下的文件名,比方foo.txt,你可以在阅读器 中输入:localhost:2015/foo.txt,caddy会施行准确的服务,阅读器也会显示foo.txt的全文。
关于静态文件Server,caddy支撑在website的root途径下首先查找是否有如下四个文件:
//caddy/middleware/browse/browse.go var IndexPages = []string{ "index.html", "index.htm", "default.html", "default.htm", }
要是查到有其中一个,则优先返回这个文件内容,这就是静态站点的首页。
要是要支撑目录文件列表阅读,则需要为website配置browse middleware,这样关于无index file的目录,我们可以看到目录文件列表。
localhost:2015 { browse }
【反向代理】
caddy支撑根本的反向代理功能。反向代理配置通过proxy middleware实现。
localhost:2015 { log ./2015.log proxy /foo localhost:9001 proxy /bar localhost:9002 }
当你访问localhost:2015/foo时,现实上访问的是9001端口的服务程序;
当你访问localhost:2015/bar时,现实上访问的是9002端口的服务程序。
【负载平衡】
Caddy支撑负载平衡配置,并支撑三种负载平衡算法:random(随机)、least_conn(最少连贯)以及round_robin(轮询调度)。
负载平衡一样是通过proxy middleware实现的。
localhost:2015 { log ./2015.log proxy / localhost:9001 localhost:9003 { policy round_robin } proxy /bar localhost:9002 localhost:9004 { policy least_conn } }
【支撑fastcgi代理】
caddy一样支撑fastcgi代理,可以将请求通过fastcgi接口发送给后端的实现fastcgi的server。我们以一个"hello world"的php server为例。
mac os上自带了php-fpm,一个实现了fastcgi的php cgi进程治理器。caddy将请求转发给php-fpm监听的端口,后者会启动php-cgi解释器,解释index.php,并将效果返回给caddy。
mac os上的php-fpm默许没有随机启动。我们需要简略配置一下:
$mkdir phptest
$mkdir -p phptest/etc
$mkdir -p phptest/log
$cd phptest
$sudo cp /private/etc/php-fpm.conf.default ./etc
$cd ./etc
$sudo chown tony php-fpm.conf.default
$mv php-fpm.conf.default php-fpm.conf
编辑php-fpm.conf,保证下面两项是非注释状态的:
error_log = log/php-fpm.log
listen = 127.0.0.1:9000
我们通过network socket进行fastcgi通讯。
回到phptest目录下,施行:
php-fpm -p ~/test/go/caddy/phptest
施行后,php-fpm就会转入后台施行了。
接下来我们来配置Caddyfile:
localhost:2015 { fastcgi / 127.0.0.1:9000 php log ./2015.log }
这里配置的含义是:将全部请求转发到9000端口,这里的php是一个preset(预配置汇合),相当于:
ext .php split .php index index.php
我们在phptest目录下新建一个index.php文件,内容如下:
<?php echo "Hello World\n"; ?>
好了,此刻启动caddy,并运用阅读器访问localhost:2015试试。你会看到"Hello World"呈此刻阅读器中。
【git push发表】
关于一些静态站点,caddy支撑git directive,实此刻server启动以及运转时按期git pull你的项目库,将最新更新pull到server上。
caddy文档中给出两个例子:
第一个是一个php站点,按期pull项目库,实现server更新:
git git@github.com:user/myphpsite { key /home/user/.ssh/id_rsa } fastcgi / 127.0.0.1:9000 php
第二个是一个hugo支持的静态站点,每次pull后,施行hugo下令生成新的静态页面:
git github.com/user/site { path ../ then hugo –destination=/home/user/hugosite/public }
注意:git directive并非middleware,而是一个独自的goroutine实现的。
四、小结
caddy的功能不局限于上面的几个例子,上面只是几个最为常见的场景而已。caddy当前还很年轻,利用不多,但知名golang网站 gopheracademy.com(GopherCon组织方)是由Caddy support的。caddy还在积极进化,有乐趣的Gopher可延续关注。
热门标签:dede模板 / destoon模板 / dedecms模版 / 织梦模板