标签 Apache 下的文章

搭建你自己的Go Runtime metrics环境

自从Go 1.5开始,每次Go release, Gopher Brian Hatfield都会将自己对新版Go的runtime的性能数据(与之前Go版本的比较)在twitter上晒出来。就连Go team staff在世界各地做speaking时也在slide中引用Brian的图片。后来,Brian Hatfield将其用于度量runtime性能数据的代码打包成library并放在github上开源了,我们也可以使用这个library来建立我们自己的Go Runtime metrics设施了。这里简要说一下搭建的步骤。

一、环境与原理

Brian Hatfield的go-runtime-metrics library实现的很简单,其runtime data来自于Go runtime package中的MemStats、NumGoroutine和NumCgoCall等。被测试目标程序只需要import该library即可输出runtime states数据:

import _ "github.com/bmhatfield/go-runtime-metrics"

go-runtime-metrics library将启动一个单独的goroutine,并定时上报runtime数据。目前该library仅支持向statsD输出数据,用户可以通过配置将statsD的数据导入graphite并使用graphite web查看,流程如下图:

img{512x368}

本次实验环境为ubuntu 16.04.1:

$ uname -rmn
tonybai-ThinkCentre-M6600s-N000 4.4.0-83-generic x86_64

二、搭建步骤

1、安装go-runtime-metrics library

我们直接go get就可以下载go-runtime-metrics library:

$ go get github.com/bmhatfield/go-runtime-metrics

我们编写一个目标程序:

//main.go
package main

import (
    "flag"
    "log"
    "net/http"
    "os"

    _ "github.com/bmhatfield/go-runtime-metrics"
)

func main() {
    flag.Parse()

    cwd, err := os.Getwd()
    if err != nil {
        log.Fatal(err)
    }

    srv := &http.Server{
        Addr:    ":8000", // Normally ":443"
        Handler: http.FileServer(http.Dir(cwd)),
    }
    log.Fatal(srv.ListenAndServe())
}

我的ubuntu主机上安装了四个go版本,它们分别是go 1.5.4、go 1.7.6、go 1.8.3和go1.9beta2,于是我们分别用这四个版本的server作为被测程序进行go runtime数据上报,以便对比。

$ GOROOT=~/.bin/go154 ~/.bin/go154/bin/go build -o server-go154 main.go
$ GOROOT=~/.bin/go174 ~/.bin/go174/bin/go build -o server-go174 main.go
$ GOROOT=~/.bin/go183 ~/.bin/go183/bin/go build -o server-go183 main.go
$ GOROOT=~/.bin/go19beta2 ~/.bin/go19beta2/bin/go build -o server-go19beta2 main.go

$ ls -l

-rwxr-xr-x 1 tonybai tonybai 6861176 7月   4 13:49 server-go154
-rwxrwxr-x 1 tonybai tonybai 5901876 7月   4 13:50 server-go174
-rwxrwxr-x 1 tonybai tonybai 6102879 7月   4 13:51 server-go183
-rwxrwxr-x 1 tonybai tonybai 6365648 7月   4 13:51 server-go19beta2

2、安装、配置和运行statsD

statsD这个工具用于收集统计信息,并将聚合后的信息发给后端服务(比如:graphite)。statsD是采用js实现的服务,因此需要安装nodejsnpm和相关modules:

$ sudo apt-get install nodejs
$ sudo apt-get install npm

接下来,我们将statsD项目clone到本地并根据exampleConfig.js模板配置一个我们自己用的goruntimemetricConfig.js(基本上就是保留默认配置):

// goruntimemetricConfig.js
{
  graphitePort: 2003
, graphiteHost: "127.0.0.1"
, port: 8125
, backends: [ "./backends/graphite" ]
}

启动statsD:

$ nodejs stats.js goruntimemetricConfig.js
3 Jul 11:14:20 - [7939] reading config file: goruntimemetricConfig.js
3 Jul 11:14:20 - server is up INFO

启动成功!

3、安装、配置和运行graphite

graphite是一种存储时序监控数据,并可以按用户需求以图形化形式展示数据的工具,它包括三个组件:

whisper是一种基于file的时序数据库格式,同时whisper也提供了相应的命令和API供其他组件调用以操作时序数据库;

carbon用于读取外部推送的metrics信息,进行聚合并写入db,它还支持缓存热点数据,提升访问效率。

graphite-web则是针对用户的图形化系统,用于定制展示监控数据的。

Graphite的安装和配置是略微繁琐的,我们一步一步慢慢来。

a) 安装graphite

$sudo apt-get install graphite-web graphite-carbon

whisper将作为依赖自动被安装。

b) local_settings.py

graphite的主配置文件在/etc/graphite/local_settings.py,文件里面有很多配置项,这里仅列出有关的,且本次生效的配置:

// /etc/graphite/local_settings.py

TIME_ZONE = 'Asia/Shanghai'

LOG_RENDERING_PERFORMANCE = True
LOG_CACHE_PERFORMANCE = True
LOG_METRIC_ACCESS = True

GRAPHITE_ROOT = '/usr/share/graphite-web'

CONF_DIR = '/etc/graphite'
STORAGE_DIR = '/var/lib/graphite/whisper'
CONTENT_DIR = '/usr/share/graphite-web/static'

WHISPER_DIR = '/var/lib/graphite/whisper'
LOG_DIR = '/var/log/graphite'
INDEX_FILE = '/var/lib/graphite/search_index'  # Search index file

DATABASES = {
    'default': {
        'NAME': '/var/lib/graphite/graphite.db',
        'ENGINE': 'django.db.backends.sqlite3',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': ''
    }
}

c) 同步数据库

接下来执行下面两个命令来做database sync(同步):

$ sudo graphite-manage migrate auth
.. ....
Operations to perform:
  Apply all migrations: auth
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0001_initial... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK

$ sudo graphite-manage syncdb

Operations to perform:
  Synchronize unmigrated apps: account, cli, render, whitelist, metrics, url_shortener, dashboard, composer, events, browser
  Apply all migrations: admin, contenttypes, tagging, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Creating table account_profile
    Creating table account_variable
    Creating table account_view
    Creating table account_window
    Creating table account_mygraph
    Creating table dashboard_dashboard
    Creating table events_event
    Creating table url_shortener_link
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying admin.0001_initial... OK
  Applying sessions.0001_initial... OK
  Applying tagging.0001_initial... OK

You have installed Django's auth system, and don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'root'):
Email address: xx@yy.com
Password:
Password (again):
Superuser created successfully.

这里我们创建一个superuser:root,用于登录graphite-web时使用。

d) 配置carbon

涉及carbon的配置文件如下,我们保持默认配置不动:

/etc/carbon/carbon.conf(内容太多,这里不列出来了)

/etc/carbon/storage-schemas.conf
[carbon]
pattern = ^carbon\.
retentions = 60:90d

[default_1min_for_1day]
pattern = .*
retentions = 60s:1d

[stats]
pattern = ^stats.*
retentions = 10s:6h,1min:6d,10min:1800d

carbon有一个cache功能,我们通过下面步骤可以将其打开:

打开carbon-cache使能开关:

$ vi /etc/default/graphite-carbon
CARBON_CACHE_ENABLED=true

启动carbon-cache:

$ sudo cp /usr/share/doc/graphite-carbon/examples/storage-aggregation.conf.example /etc/carbon/storage-aggregation.conf
$ systemctl start carbon-cache

e) 启动graphite-web

graphite-web支持多种主流web server,这里以apache2为例,graphite-web将mod-wsgi方式部署在apache2下面:

$sudo apt-get install apache2 libapache2-mod-wsgi

$ sudo service apache2 start

$ sudo a2dissite 000-default
Site 000-default disabled.

$ sudo service apache2 reload

$ sudo cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available

$ sudo  a2ensite apache2-graphite
Enabling site apache2-graphite.
To activate the new configuration, you need to run:
  service apache2 reload

$ sudo systemctl reload apache2

由于apache2的Worker process默认以www-data:www-data用户权限运行,但数据库文件的访问权限却是:_graphite:_graphite:

$ ll /var/lib/graphite/graphite.db
-rw-r--r-- 1 _graphite _graphite 72704 7月   3 13:48 /var/lib/graphite/graphite.db

我们需要修改一下apache worker的user:

$ sudo vi /etc/apache2/envvars

export APACHE_RUN_USER=_graphite
export APACHE_RUN_GROUP=_graphite

重启apache2生效!使用Browser打开:http://127.0.0.1,如无意外,你将看到下面graphite-web的首页:

img{512x368}

三、执行benchmarking

这里我将使用wrk这个http benchmarking tool分别对前面的四个版本的目标程序(server-go154 server-go174 server-go183 server-go19beta2)进行benchmarking test,每个目标程序接收10分钟的请求:

$ ./server-go154
$ wrk -t12 -c400 -d10m http://127.0.0.1:8000

$ ./server-go174
$ wrk -t12 -c400 -d10m http://127.0.0.1:8000

$ ./server-go183
$ wrk -t12 -c400 -d10m http://127.0.0.1:8000

$ ./server-go19beta2
$ wrk -t12 -c400 -d10m http://127.0.0.1:8000

四、结果展示

用浏览器打开graphite-web,在左边的tree标签下以此打开树形结构:Metrics -> stats -> gauges -> go -> YOUR_HOST_NAME -> mem -> gc -> pause,如果顺利的话,你将会在Graphite Composer窗口看到折线图,我们也以GC pause为例,GC pause也是gopher们最为关心的:

img{512x368}

通过这幅图(左侧坐标轴的单位为nanoseconds),我们大致可以看出:

Go 1.5.4的GC pause约在600μs左右;
Go 1.7.4的GC pause约在300μs左右;
Go 1.8.3和Go 1.9beta2的GC pause基本都在100μs以下了。Go 1.9的GC改进似乎不大。不过这里我的程序也并不足够典型。

其他结果:

Go routines number:

img{512x368}

GC count:

img{512x368}

memory allocations:

img{512x368}

除了查看单个指标曲线,你也可以通过graphite-web提供的dashboard功能定制你要monitor的面板,这里就不赘述了。

五、参考资料


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

使用wukong全文搜索引擎

近期项目中有一个全文索引和全文搜索的业务需求,组内同事在这方面都没啥经验,找一个满足我们需求的开源的全文搜索引擎势在必行。我们这一期对全文搜索引擎的需求并不复杂,最主要的是引擎可以很好的支持中文分词、索引和搜索,并能快速实现功能。在全文搜索领域,基于Apache luceneElasticSearch舍我其谁,其强大的分布式系统能力、对超大规模数据的支持、友好的Restful API以及近实时的搜索性能都是业内翘楚,并且其开发社区也是相当活跃,资料众多。但也正式由于其体量较大,我们并没有在本期项目中选择使用ElasticSearch,而是挑选了另外一个“fame”不是那么响亮的引擎:wukong

一、wukong简介

wukong,是一款golang实现的高性能、支持中文分词的全文搜索引擎。我个人觉得它最大的特点恰恰是不像ElasticSearch那样庞大和功能完备,而是可以以一个Library的形式快速集成到你的应用或服务中去,这可能也是在当前阶段选择它的最重要原因,当然其golang技术栈也是让我垂涎于它的另外一个原因:)。

第一次知道wukong,其实是在今年的GopherChina大会上,其作者陈辉作为第一个演讲嘉宾在大会上分享了“Go与人工智能”。在这个presentation中,chen hui详细讲解了wukong搜索引擎以及其他几个关联的开源项目,比如:sego等。

在golang世界中,做full text search的可不止wukong一个。另外一个比较知名的是bleve,但默认情况下,bleve并不支持中文分词和搜索,需要结合中文分词插件才能支持,比如:gojieba

wukong基本上是陈辉一个人打造的项目,在陈辉在阿里任职期间,他将其用于阿里内部的一些项目中,但总体来说,wukong的应用还是很小众的,相关资料也不多,基本都集中在其github站点上。关于wukong源码的分析,倒是在国外站点上发现一篇:《Code reading: wukong full-text search engine》。

本文更多聚焦于应用wukong引擎,而不是来分析wukong代码。

二、全文索引和检索

1、最简单的例子

我们先来看一个使用wukong引擎编写的最简单的例子:

//example1.go

package main

import (
    "fmt"

    "github.com/huichen/wukong/engine"
    "github.com/huichen/wukong/types"
)

var (
    searcher = engine.Engine{}
    docId    uint64
)

const (
    text1 = `在苏黎世的FIFA颁奖典礼上,巴萨球星、阿根廷国家队队长梅西赢得了生涯第5个金球奖,继续创造足坛的新纪录`
    text2 = `12月6日,网上出现照片显示国产第五代战斗机歼-20的尾翼已经涂上五位数部队编号`
)

func main() {
    searcher.Init(types.EngineInitOptions{
        IndexerInitOptions: &types.IndexerInitOptions{
            IndexType: types.DocIdsIndex,
        },
        SegmenterDictionaries: "./dict/dictionary.txt",
        StopTokenFile:         "./dict/stop_tokens.txt",
    })
    defer searcher.Close()

    docId++
    searcher.IndexDocument(docId, types.DocumentIndexData{Content: text1}, false)
    docId++
    searcher.IndexDocument(docId, types.DocumentIndexData{Content: text2}, false)

    searcher.FlushIndex()

    fmt.Printf("%#v\n", searcher.Search(types.SearchRequest{Text: "巴萨 梅西"}))
    fmt.Printf("%#v\n", searcher.Search(types.SearchRequest{Text: "战斗机 金球奖"}))
}

在这个例子中,我们创建的wukong engine索引了两个doc:text1和text2,建立好索引后,我们利用引擎进行关键词查询,我们来看看查询结果:

$go run example1.go
2016/12/06 21:40:04 载入sego词典 ./dict/dictionary.txt
2016/12/06 21:40:08 sego词典载入完毕
types.SearchResponse{Tokens:[]string{"巴萨", "梅西"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x1, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}
types.SearchResponse{Tokens:[]string{"战斗机", "金球奖"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

可以看出当查询“巴萨 梅西”时,引擎正确匹配到了第一个文档(DocId:0×1)。而第二次查询关键词组合“战斗机 金球奖”则没有匹配到任何文档。从这个例子我们也可以看出,wukong引擎对关键词查询支持的是关键词的AND查询,只有文档中同时包含所有关键词,才能被匹配到。这也是目前wukong引擎唯一支持的一种关键词搜索组合模式。

wukong引擎的索引key是一个uint64值,我们需要保证该值的唯一性,否则将导致已创建的索引被override。

另外我们看到:在初始化IndexerInitOptions时,我们传入的IndexType是types.DocIdsIndex,这将指示engine在建立的索引和搜索结果中只保留匹配到的DocId信息,这将最小化wukong引擎对内存的占用。

如果在初始化EngineInitOptions时不给StopTokenFile赋值,那么当我们搜索”巴萨 梅西”时,引擎会将keywords分成三个关键词:”巴萨”、空格和”梅西”分别搜索并Merge结果:

$go run example1.go
2016/12/06 21:57:47 载入sego词典 ./dict/dictionary.txt
2016/12/06 21:57:51 sego词典载入完毕
types.SearchResponse{Tokens:[]string{"巴萨", " ", "梅西"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}
types.SearchResponse{Tokens:[]string{"战斗机", " ", "金球奖"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

2、FrequenciesIndex和LocationsIndex

wukong Engine的IndexType支持的另外两个类型是FrequenciesIndex和LocationsIndex,分别对应的是保留词频信息以及关键词在文档中出现的位置信息,这两类IndexType对内存的消耗量也是逐渐增大的,毕竟保留的信息是递增的:

当IndexType = FrequenciesIndex时:

$go run example1.go
2016/12/06 22:03:47 载入sego词典 ./dict/dictionary.txt
2016/12/06 22:03:51 sego词典载入完毕
types.SearchResponse{Tokens:[]string{"巴萨", "梅西"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x1, Scores:[]float32{3.0480049}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}
types.SearchResponse{Tokens:[]string{"战斗机", "金球奖"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

当IndexType = LocationsIndex时:

$go run example1.go
2016/12/06 22:04:31 载入sego词典 ./dict/dictionary.txt
2016/12/06 22:04:38 sego词典载入完毕
types.SearchResponse{Tokens:[]string{"巴萨", "梅西"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x1, Scores:[]float32{3.0480049}, TokenSnippetLocations:[]int{37, 76}, TokenLocations:[][]int{[]int{37}, []int{76}}}}, Timeout:false, NumDocs:1}
types.SearchResponse{Tokens:[]string{"战斗机", "金球奖"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

3、分词对结果的影响

在前面,当不给StopTokenFile赋值时,我们初步看到了分词对搜索结果的影响。wukong的中文分词完全基于作者的另外一个开源项目sego实现的。分词的准确程度直接影响着索引的建立和关键词的搜索结果。sego的词典和StopTokenFile来自于网络,如果你需要更加准确的分词结果,那么是需要你定期更新dictionary.txt和stop_tokens.txt。

举个例子,如果你的源文档内容为:”你们很感兴趣的 .NET Core 1.1 来了哦”,你的搜索关键词为:兴趣。按照我们的预期,应该可以搜索到这个源文档。但实际输出却是:

types.SearchResponse{Tokens:[]string{"兴趣"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

其原因就在于sego对”你们很感兴趣的 .NET Core 1.1 来了哦”这句话的分词结果是:

你们/r 很感兴趣/l 的/uj  /x ./x net/x  /x core/x  /x 1/x ./x 1/x  /x 来/v 了/ul 哦/zg

sego并没有将“兴趣”分出来,而是将“很感兴趣”四个字放在了一起,wukong引擎自然就不会单独为“兴趣”单独建立文档索引了,搜索不到也就能理解了。因此,sego可以被用来检验wukong引擎分词情况,这将有助于你了解wukong对文档索引的建立情况。

三、持久化索引和启动恢复

上面的例子中,wukong引擎建立的文档索引都是存放在内存中的,程序退出后,这些数据也就随之消失了。每次启动程序都要根据源文档重新建立索引显然是一个很不明智的想法。wukong支持将已建立的索引持久化到磁盘文件中,并在程序重启时从文件中间索引数据恢复出来,并在后续的关键词搜索时使用。wukong底层支持两种持久化引擎,一个是boltdb,另外一个是cznic/kv。默认采用boltdb。

我们来看一个持久化索引的例子(考虑文章size,省略一些代码):

// example2_index_create.go
... ...
func main() {
    searcher.Init(types.EngineInitOptions{
        IndexerInitOptions: &types.IndexerInitOptions{
            IndexType: types.DocIdsIndex,
        },
        UsePersistentStorage:    true,
        PersistentStorageFolder: "./index",
        SegmenterDictionaries:   "./dict/dictionary.txt",
        StopTokenFile:           "./dict/stop_tokens.txt",
    })
    defer searcher.Close()

    os.MkdirAll("./index", 0777)

    docId++
    searcher.IndexDocument(docId, types.DocumentIndexData{Content: text1}, false)
    docId++
    searcher.IndexDocument(docId, types.DocumentIndexData{Content: text2}, false)
    docId++
    searcher.IndexDocument(docId, types.DocumentIndexData{Content: text3}, false)

    searcher.FlushIndex()
    log.Println("Created index number:", searcher.NumDocumentsIndexed())
}

这是一个创建持久化索引的源文件。可以看出:如果要持久化索引,只需在engine init时显式设置UsePersistentStorage为true,并设置PersistentStorageFolder,即索引持久化文件存放的路径。执行一下该源文件:

$go run example2_index_create.go
2016/12/06 22:41:49 载入sego词典 ./dict/dictionary.txt
2016/12/06 22:41:53 sego词典载入完毕
2016/12/06 22:41:53 Created index number: 3

执行后,我们会在./index路径下看到持久化后的索引数据文件:

$tree index
index
├── wukong.0
├── wukong.1
├── wukong.2
├── wukong.3
├── wukong.4
├── wukong.5
├── wukong.6
└── wukong.7

0 directories, 8 files

现在我们再建立一个程序,该程序从持久化的索引数据恢复索引到内存中,并针对搜索关键词给出搜索结果:

// example2_index_search.go
... ...
var (
    searcher = engine.Engine{}
)

func main() {
    searcher.Init(types.EngineInitOptions{
        IndexerInitOptions: &types.IndexerInitOptions{
            IndexType: types.DocIdsIndex,
        },
        UsePersistentStorage:    true,
        PersistentStorageFolder: "./index",
        SegmenterDictionaries:   "./dict/dictionary.txt",
        StopTokenFile:           "./dict/stop_tokens.txt",
    })
    defer searcher.Close()

    searcher.FlushIndex()
    log.Println("recover index number:", searcher.NumDocumentsIndexed())

    fmt.Printf("%#v\n", searcher.Search(types.SearchRequest{Text: "巴萨 梅西"}))
}

执行这个程序:

$go run example2_index_search.go
2016/12/06 22:48:37 载入sego词典 ./dict/dictionary.txt
2016/12/06 22:48:41 sego词典载入完毕
2016/12/06 22:48:42 recover index number: 3
types.SearchResponse{Tokens:[]string{"巴萨", "梅西"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x1, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}

该程序成功从前面已经建立好的程序中恢复了索引数据,并针对Search request给出了正确的搜索结果。

需要注意的是:boltdb采用了flock保证互斥访问底层文件数据的,因此当一个程序打开了boltdb,此时如果有另外一个程序尝试打开相同的boltdb,那么后者将阻塞在open boltdb的环节。

四、动态增加和删除索引

wukong引擎支持运行时动态增删索引,并实时影响搜索结果。

我们以上一节建立的持久化索引为基础,启动一个支持索引动态增加的程序:

//example3.go

func main() {
    searcher.Init(types.EngineInitOptions{
        IndexerInitOptions: &types.IndexerInitOptions{
            IndexType: types.DocIdsIndex,
        },
        UsePersistentStorage:    true,
        PersistentStorageFolder: "./index",
        PersistentStorageShards: 8,
        SegmenterDictionaries:   "./dict/dictionary.txt",
        StopTokenFile:           "./dict/stop_tokens.txt",
    })
    defer searcher.Close()
    searcher.FlushIndex()
    log.Println("recover index number:", searcher.NumDocumentsIndexed())
    docId = searcher.NumDocumentsIndexed()

    os.MkdirAll("./source", 0777)

    go func() {
        for {
            var paths []string

            //update index dynamically
            time.Sleep(time.Second * 10)
            var path = "./source"
            err := filepath.Walk(path, func(path string, f os.FileInfo, err error) error {
                if f == nil {
                    return err
                }
                if f.IsDir() {
                    return nil
                }

                fc, err := ioutil.ReadFile(path)
                if err != nil {
                    fmt.Println("read file:", path, "error:", err)
                }

                docId++
                fmt.Println("indexing file:", path, "... ...")
                searcher.IndexDocument(docId, types.DocumentIndexData{Content: string(fc)}, true)
                fmt.Println("indexed file:", path, " ok")
                paths = append(paths, path)

                return nil
            })
            if err != nil {
                fmt.Printf("filepath.Walk() returned %v\n", err)
                return
            }

            for _, p := range paths {
                err := os.Remove(p)
                if err != nil {
                    fmt.Println("remove file:", p, " error:", err)
                    continue
                }
                fmt.Println("remove file:", p, " ok!")
            }

            if len(paths) != 0 {
                // 等待索引刷新完毕
                fmt.Println("flush index....")
                searcher.FlushIndex()
                fmt.Println("flush index ok")
            }
        }
    }()

    for {
        var s string
        fmt.Println("Please input your search keywords:")
        fmt.Scanf("%s", &s)
        if s == "exit" {
            break
        }

        fmt.Printf("%#v\n", searcher.Search(types.SearchRequest{Text: s}))
    }
}

example3这个程序启动了一个goroutine,定期到source目录下读取要建立索引的源文档,并实时更新索引数据。main routine则等待用户输入关键词,并通过引擎搜索返回结果。我们来Run一下这个程序:

$go run example3.go
2016/12/06 23:07:17 载入sego词典 ./dict/dictionary.txt
2016/12/06 23:07:21 sego词典载入完毕
2016/12/06 23:07:21 recover index number: 3
Please input your search keywords:
梅西
types.SearchResponse{Tokens:[]string{"梅西"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x1, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}
Please input your search keywords:
战斗机
types.SearchResponse{Tokens:[]string{"战斗机"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x2, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}
Please input your search keywords:

可以看到:基于当前已经恢复的索引,我们可以正确搜索到”梅西”、”战斗机”等关键词所在的文档。

这时我们如果输入:“球王”,我们得到的搜索结果如下:

Please input your search keywords:
球王
types.SearchResponse{Tokens:[]string{"球王"}, Docs:[]types.ScoredDocument{}, Timeout:false, NumDocs:0}

没有任何文档得以匹配。

没关系,现在我们就来增加一个文档,里面包含球王等关键字。我们创建一个文档: soccerking.txt,内容为:

《球王马拉多纳》是一部讲述世界上被公认为现代足球坛上最伟大的传奇足球明星迭戈·马拉多纳的影片。他出身于清贫家庭,九岁展露过人才华,十一岁加入阿根廷足球青少年队,十六岁便成为阿根廷甲级联赛最年轻的>球员。1986年世界杯,他为阿根廷队射入足球史上最佳入球,并带领队伍勇夺金杯。他的一生充满争议、大起大落,球迷与人们对他的热爱却从未减少过,生命力旺盛的他多次从人生谷底重生。

将soccerking.txt移动到source目录中,片刻后,可以看到程序输出以下日志:

indexing file: source/soccerking.txt ... ...
indexed file: source/soccerking.txt  ok
remove file: source/soccerking.txt  ok!
flush index....
flush index ok

我们再尝试搜索”球王”、”马拉多纳”等关键词:

Please input your search keywords:
球王
types.SearchResponse{Tokens:[]string{"球王"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x4, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}
Please input your search keywords:
马拉多纳
types.SearchResponse{Tokens:[]string{"马拉多纳"}, Docs:[]types.ScoredDocument{types.ScoredDocument{DocId:0x4, Scores:[]float32{0}, TokenSnippetLocations:[]int(nil), TokenLocations:[][]int(nil)}}, Timeout:false, NumDocs:1}

可以看到,这回engine正确搜索到了对应的Doc。

五、分布式索引和搜索

从前面的章节内容,我们大致了解了wukong的工作原理。wukong将索引存储于boltdb中,每个wukong instance独占一份数据,无法共享给其他wukong instance。当一个node上的内存空间不足以满足数据量需求时,需要将wukong引擎进行分布式部署以实现分布式索引和搜索。关于这点,wukong官方提供了一段方案描述:

分布式搜索的原理如下:

当文档数量较多无法在一台机器内存中索引时,可以将文档按照文本内容的hash值裂分(sharding),不同块交由不同服务器索引。在查找时同一请求分发到所有裂分服务器上,然后将所有服务器返回的
结果归并重排序作为最终搜索结果输出。

为了保证裂分的均匀性,建议使用Go语言实现的Murmur3 hash函数:

https://github.com/huichen/murmur

按照上面的原理很容易用悟空引擎实现分布式搜索(每个裂分服务器运行一个悟空引擎),但这样的分布式系统多数是高度定制的,比如任务的调度依赖于分布式环境,有时需要添加额外层的服务器以
均衡负载

实质就是索引和搜索的分片处理。目前我们项目所在阶段尚不需这样一个分布式wukong,因此,这里也没有实战经验可供分享。

六、wukong引擎的局限

有了上面的内容介绍,你基本可以掌握和使用wukong引擎了。不过在选用wukong引擎之前,你务必要了解wukong引擎的一些局限:

1、开发不活跃,资料较少,社区较小
wukong引擎基本上是作者一个人的项目,社区参与度不高,资料很少。另外由于作者正在创业,忙于造轮子^_^,因此wukong项目更新的频度不高。

2、缺少计划和愿景

似乎作者并没有持续将wukong引擎持续改进和发扬光大的想法和动力。Feature上也无增加。这点和bleve比起来就要差很多。

3、查询功能简单,仅支持关键词的AND查询

如果你要支持灵活多样的全文检索的查询方式,那么当前版本的wukong很可能不适合你。

4、搜索的准确度基于dictionary.txt的规模

前面说过,wukong的索引建立和搜索精确度一定程度上取决于分词引擎的分词精确性,这样dictionary.txt文件是否全面,就会成为影响搜索精确度的重要因素。

5、缺少将索引存储于关系DB中的插件支持

当前wukong引擎只能将索引持久化存储于文件中,尚无法和MySQL这样的数据库配合索引的存储和查询。

总之,wukong绝非一个完美的全文搜索引擎,是否选用,要看你所处的context。

七、小结

选用wukong引擎和我们的项目目前所处的context情况不无关系:我们需要快速实现出一个功能简单却可用的全文搜索服务。也许在后续版本中,对查询方式、数据规模有进一步要求时,就是可能考虑更换引擎的时刻了。bleve、elasticsearch到时候就都会被我们列为考虑对象了。

本文代码在可在这里下载。

Rancher使用入门

上个月末,Rancher Labs在其官方博客上宣布了 Rancher 1.0正式版本发布。 这是继Apache MesosGoogle Kubernetes以及Docker 原生 Swarm 之后,又一个可用于Production环境中的容器管理和服务编排工具,而Rancher恰似这个领域的最后一张拼图(请原谅我的孤陋寡闻,如 果有其他 厂商在做这方面产品,请在评论中留言告诉我)。从Rancher Labs的官方about中我们可以看到:Rancher Labs致力于为DevOps team打造一个最好的容器管理平台,让容器的部署和管理变得更加Easy。

本文将带大家与Rancher来个亲密接触,直观的体会一下Rancher的入门级使用方法。

注意:由于Rancher还在active development中,本文仅适用于刚刚发布的v1.0.0版本,包括:

rancher/server:v1.0.0
rancher/agent:v0.11.0
rancher/agent-instance:v0.8.1
rancher-compose-v0.7.3

后续版本演进可能会导致本文中某些操作不再适用或某些UI元素发生变化。

零、实验环境

这里继续使用之前文章中的两个Ubuntu 14.04主机环境(kernel版本 >= 3.16.7),Docker 1.9.1+。

其中:

rancher server:
    10.10.126.101

rancher agents:
    10.10.126.101
    10.10.105.71
    10.10.105.72

一、搭建单节点Rancher Server

Rancher的各种容器管理理念均架构在由Rancher server和rancher agent构建的Infrastructure之上。Rancher server是Rancher的核心,其地位就类似于k8s、Docker swarm或mesos中的master,提供核心容器管理服务以及API服务。作为正式版发布的Rancher v1.0.0支持HA(high available)的多节点rancher server集群,不过Install起来也的确复杂些,依赖的第三方组件也较多,什么MySQLRedisZooKeeper等统统都要额外部署。由于是入门,这里就偷个赖儿,我们就搭建一个单节点的Rancher Server。

Rancher的一个设计理念是所有组件都Containerized(容器化),更有甚者Rancher Labs的另外一个产品RancherOS(地位类似于CoreOS,一款专门为运行容器而设计的Linux发行版)中所有系统服务都是 Dockerized的,这里的Rancher Server也不例外,极大的方便了我们的Install。

下面我们就在126.101 host上安装一个Rancher server。

首先,我们将rancher/server image pull到local,这个image size很大,需要耐心等待一段时间,即便是使用国内容器云厂商提供的加速器:

$ docker pull rancher/server
... ...

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
rancher/server      latest              26bce58807d1        22 hours ago        775.9 MB

接下来,启动rancher server:

$ docker run -d --restart=always -p 8080:8080 rancher/server
d8ce1654ff9f1d056d7cdc9216cf19173d85037bf23be44f802d627eabc8e607

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
d8ce1654ff9f        rancher/server      "/usr/bin/s6-svscan /"   12 seconds ago      Up 8 seconds        3306/tcp, 0.0.0.0:8080->8080/tcp   agitated_ardinghelli

映射的8080端口既服务于Rancher UI,也是Rancher API的服务端口。用浏览器打开http://10.10.126.101:8080,如果你看到如下页面,则说明你的Rancher Server搭建成功了:

img{512x368}

Rancher image size之所以大,是因为其内部安装和运行了诸多服务程序,我们来hack一下:

$ docker exec d8ce1654ff9f ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0    188     4 ?        Ss   03:50   0:00 /usr/bin/s6-svscan /service
root         5  0.0  0.0    188     4 ?        S    03:50   0:00 s6-supervise cattle
root         6  0.0  0.0    188     4 ?        S    03:50   0:00 s6-supervise mysql
root         7  6.5 18.1 3808308 710284 ?      Ssl  03:50   1:05 java -Xms128m -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/cattle/logs -Dlogback.bootstrap.level=WARN -cp /usr/share/cattle/9283c067b6f96f5ff1e38fb0ddfd8649:/usr/share/cattle/9283c067b6f96f5ff1e38fb0ddfd8649/etc/cattle io.cattle.platform.launcher.Main
mysql       28  0.4  2.3 2135756 92164 ?       Ssl  03:50   0:04 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root       170  0.1  0.2 264632 11552 ?        Sl   03:52   0:01 websocket-proxy
root       179  0.0  0.2 274668  8632 ?        Sl   03:52   0:00 rancher-catalog-service -catalogUrl library=https://github.com/rancher/rancher-catalog.git,community=https://github.com/rancher/community-catalog.git -refreshInterval 300
root       180  0.0  0.3 254044 12652 ?        Sl   03:52   0:00 rancher-compose-executor
root       181  0.5  0.4 1579572 16692 ?       Sl   03:52   0:05 go-machine-service
root       610  0.0  0.0  14988  2576 ?        S    04:06   0:00 git -C ./DATA/library pull -r origin master
root       611  0.0  0.0   4448  1696 ?        S    04:06   0:00 /bin/sh /usr/lib/git-core/git-pull -r origin master
root       640  0.0  0.0  15024  3020 ?        S    04:06   0:00 git fetch --update-head-ok origin master
root       641  3.0  0.1 161180  6028 ?        S    04:06   0:00 git-remote-https origin https://github.com/rancher/rancher-catalog.git
root       643  0.0  0.0  15572  2120 ?        Rs   04:07   0:00 ps aux

可以看出里面有mysql、cattle、go-machine-service、rancher-compose-executor以及 websocket-proxy等。通过PID我们可以看出/usr/bin/s6-svscan是容器的第一个启动进程,/service这个 路径作为其命令行参数,估计这是一个类似于supervisord的进程控制程 序,由其 负责启动和管理Rancher server的两个重要服务:MySQL和cattle。注:单节点rancher server的数据都保存在其内部的MySQL中,而多节点rancher server则采用一个外部的MySQL存储数据。

二、设置Account

第一次启动Rancher后,Rancher的UI是没有访问控制的,所有人都可以访问这个地址并控制一切。

切换到API菜单,可以看到当前默认Environment(后续会详细说这个概念)的API访问endpoint是: http://10.10.126.101:8080/v1/projects/1a5

我们可以用curl来访问一下这个url:

$ curl http://10.10.126.101:8080/v1/projects/1a5
{"id":"1a5","type":"project","links":{"self":"http://10.10.126.101:8080/v1/projects/1a5","agents":"http://10.10.126.101:8080/v1/projects/1a5/agents","auditLogs":"http://10.10.126.101:8080/v1/projects/1a5/auditlogs","certificates":"http://10.10.126.101:8080/v1/projects/1a5/certificates",
... ...
"swarm":false,"transitioning":"no","transitioningMessage":null,"transitioningProgress":null,"uuid":"adminProject"}

返回超过一屏的信息,这同时也说明Rancher Server在正常工作。

在正式感受Rancher功能前,我们来给Rancher添加一个Account,相信这也是所有要在生产环境使用Rancher的朋友必须要做 的事情。

在Rancher UI中,也许你已经注意到了,在第一行菜单栏中,“ADMIN”菜单项右侧有一个红色的“!”,这也是在提醒你Rancher当前未设防。我们点击 “ADMIN”,选择出现的二级菜单中的”ACCOUNTS”菜单项,我们将看到如下页面:

img{512x368}

添加权限控制,需要在【”ADMIN” -> “ACCESS CONTROL”】中。Rancher支持四种权限控制方案,分别是:Active Directory、GitHub、Local Auth和OpenLDAP。我们使用最简单的Local Auth,即设置一个用户名和密码,然后点击“Enable Local Auth”按钮即可。然后我们再回到”ACCOUNTS”页面:

img{512x368}

可以看到我们已经建立了一个新的Admin权限的账号:tonybai。当前的登录账号也换成了tonybai。

这时如果你再用API访问当前默认环境的EndPoint的话,结果就会变成下面这样:

 curl http://10.10.126.101:8080/v1/projects/1a5
{"id":"b052db07-d58e-45bf-872e-06ced8bcc4e1","type":"error","links":{},"actions":{},"status":401,"code":"Unauthorized","message":"Unauthorized","detail":null}

提示错误:Unauthorized

这时如果还想用API访问,就需要为该环境添加一个API Key了。在”API”页面下,点击 “Add Environment API Key”按钮,在弹出的窗口中输入key的name:tonybai-default-env-key,点击”Create”创建:

img{512x368}

Rancher会随机生成一对access key和secret key,即user和password,使用它们即可通过API访问该环境,注意:secret key只显示这么一次,你需要手工将其记录下来,否则一旦关闭这个窗口,就无法再找到secret key的内容了,只能再重新生成一对。

$curl -u 5569108BE7489DEE47A5:76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh http://10.10.126.101:8080/v1/projects/1a5
{"id":"1a5","type":"project","links":{"self":"http://10.10.126.101:8080/v1/projects/1a5","agents":"http://10.10.126.101:8080/v1/projects/1a5/agents","auditLogs":"http://10.10.126.101:8080/v1/projects/1a5/auditlogs","certificates":"http://10.10.126.101:8080/v1/projects/1a5/certificates",
... ...
"swarm":false,"transitioning":"no","transitioningMessage":null,"transitioningProgress":null,"uuid":"adminProject"}

三、Environment

前面说过,Rancher中有个概念是Environment。在Rancher UI的右上角,我们可以看到”Default Enviromnet”字样,点击向下箭头,打开下拉菜单,选择:“Manage Enviromnets”,可以看到当前的Enviroments列表:

img{512x368}

在这个页面,我们可以看到Rancher对Enviroments的诠释:

Rancher supports grouping resources into multiple environments. Each one gets its own set of services and infrastructure resources, and is owned by one or more GitHub users, teams or organizations.

For example, you might create separate "dev", "test", and "production" environments to keep things isolated from each other, and give "dev" access to your entire organization but restrict the "production" environment to a smaller team.

大致意思就是一个Environment就是一个resource group,每个Environment都有自己的服务和基础设施资源,并且通过Access Control来赋予每个Account访问该Environments的权限。Rancher Labs的一个目标就是为DevOps Team打造一个Easy的容器管理工具,因此在解释Environment术语时,还特地以DevOps Workflow来解释,比如建立dev、test、production environment,保证Environments间的隔离。下面的这幅图可能会更直观的展现出Environment在Rancher中的“角 色”:

img{512x368}

Rancher Server建立后,会建立一个”Default” Environment,我们可以Edit一下这个Environment的信息,可以修改它的Name、Container Orchestration引擎(cattle、k8s和swarm,默认cattle)以及Access Control,我们看到tonybai的用户是这个Environment的Owner,当然我们也可以修改tonybai这个用户的Role,比如 member、readonly或restricted。这里我们将Default的名字改为”dev”。

我们再添加一个Environment “test”,引擎用cattle:

img{512x368}

我们看到dev environment后面有一个”对号”,说明dev environment是当前active environment,所有操作均针对该environment,你当然可以通过点击每个environment列表后面的切换图标来切换active environment。

到目前为止,虽然Rancher Server建立ok了,environment这个逻辑实体也建立了,但dev environment仍处于“无米下炊”的状态。因为除了Rancher自身外,该Environment下没有任何Resources(主机、存储 等)可供使用(比如创建Containers)。

我们来为dev environment添加两个主机资源:10.10.126.101和10.10.105.72。在”INFRASTRUCTURE”-> HOSTS中点击”Add Host”按钮添加主机资源。Rancher支持多种主机资源,包括Custom(本地自定义)、Amazon EC2Azure 以及 DigitalOcean 等。

我们以本地Host资源(选择Custom)为例,在添加Host页面中,我们输入第一个Host的IP,Rancher UI会生成下面这段命令行:

sudo docker run -e CATTLE_AGENT_IP='10.10.126.101'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v0.11.0 http://10.10.126.101:8080/v1/scripts/B0C997705263867F519F:1460440800000:1Rd9TyJIS2Fnae5lcjsvnIRDJE

我们需要手动在10.10.126.101这个Host上执行上述命令行:

$ sudo docker run -e CATTLE_AGENT_IP='10.10.126.101'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v0.11.0 http://10.10.126.101:8080/v1/scripts/B0C997705263867F519F:1460440800000:1Rd9TyJIS2Fnae5lcjsvnIRDJE
2d05764d42c52b1449021766a5c0e104098605cd7d53b632571c46f1e84f2a4b

$ docker ps
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS              PORTS                              NAMES
2d05764d42c5        rancher/agent:v0.11.0   "/run.sh http://10.10"   27 seconds ago      Up 22 seconds                                          big_bhabha
d8ce1654ff9f        rancher/server          "/usr/bin/s6-svscan /"   4 days ago          Up 4 days           0.0.0.0:8080->8080/tcp, 3306/tcp   agitated_ardinghelli

等待一会儿,我们刷新一下”INFRASTRUCTURE”-> HOSTS页面,我们会看到10.10.126.101这个Host被加入到dev environment的Infrastructure中了:

img{512x368}

按照同样的步骤,我们再将10.10.105.72加入到Infrastructure中:

$ sudo docker run -e CATTLE_AGENT_IP='10.10.105.72'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v0.11.0 http://10.10.126.101:8080/v1/scripts/B0C997705263867F519F:1460440800000:1Rd9TyJIS2Fnae5lcjsvnIRDJE
e1f335c665853348810aef8736c67f610ae7f4c93e4b6265361b95a354af434a

$docker ps
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                  PORTS               NAMES
2e212fda35d3        rancher/agent:v0.11.0   "/run.sh inspect-host"   23 seconds ago      Up Less than a second                       trusting_noyce
e1f335c66585        rancher/agent:v0.11.0   "/run.sh http://10.10"   39 seconds ago      Up 23 seconds                               clever_bohr

我们注意到:上面的命令启动了两个Container,image虽然都是rancher/agent:v0.11.0,但执行的命令行参数略有 不同(其中一个Container为临时Container,一段时间后会自动退出)。片刻,我们就在Hosts下看到了两个Host资源了。

我们点击Rancher UI右上角的下拉箭头,将当前Environment从dev切换到test,我们发现test Environment下的Hosts又为空了(不过此处似乎有个bug,在我的Mac Chrome浏览器中,等的时间足够久后,似乎test environment把dev enviroment的Host资源显示出来了,很怪异)。可以看出Infra是Environment相关的。我们在test环境下增加一个 10.10.105.71 host:

$ sudo docker run -e CATTLE_AGENT_IP='10.10.105.71'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v0.11.0 http://10.10.126.101:8080/v1/scripts/A63B9C5F8066E29377C3:1460448000000:UbPcmDXOqoI6mls6e75Qp17QR0
4a5f9e13615e562636cd515763e293449607a8b2d827d2599f80f9ad8f16aa2d

$ docker ps
CONTAINER ID        IMAGE                   COMMAND                  CREATED              STATUS                  PORTS                    NAMES
d101095c7709        rancher/agent:v0.11.0   "/run.sh run"            6 seconds ago        Up Less than a second                            rancher-agent
4a5f9e13615e        rancher/agent:v0.11.0   "/run.sh http://10.10"   About a minute ago   Up About a minute                                evil_khorana

到这里,test Environment下也有了一个Host了,从Rancher UI页面可以看到。

四、Stack

Rancher UI的左上角APPLICATIONS下面有一个“STACKS”的二级菜单项。Rancher官方docs对Stack的解释是:”A Rancher stack mirrors the same concept as a docker-compose project. It represents a group of services that make up a typical application or workload.”。同时Rancher UI上关于Service的解释如下:“A service is simply a group of containers created from the same Docker image but extends Docker’s “link” concept to leverage Rancher’s lightweight distributed DNS service for service discovery”。从这两段描述中,我们大致可以推出如下关系:

A Stack <=> An Application <=> A group of services(由类docker-compose的工具rancher-compose管理)

下面这幅图直观描述了user account, environment与stacks之间的关系:

img{512x368}

我们在dev environment下添加一个Service。Rancher UI “APPLICATIONS” -> “STACKS”下面支持两种添加Service的方式,一种是手工添加,一种是从Catalog添加。Catalog类似于一个Rancher App Market,里面有Rancher预定义好的service template。我们这次采用手工添加的方式,便于控制。我们基于nginx:1.8-alpine创建单一实例的service: nginx-alpine-service,端口映射:10086->80。其他采用默认配置。添加Service时,并没有位置让你为Stack 起名,但添加一个Service后,我们会看到当前Stack是Default Stack,你可以修改Stack name,这里改为nginx-app-stack。启动后,我们看到第一个nginx-alpine-service的Container运行在 105.72上。

img{512x368}

点击stack名字,可以查看stack的详细信息:

img{512x368}

点击”nginx-alpine-service”,进入到service属性页面,我们将nginx-alpine-service的 Scale +1。Rancher会自动在Resource host上根据默认调度策略,运行一个新的基于nginx image的Container。我们可以看到这个新Container运行在126.101上,这样dev Environmnet中的两个Host上就各自运行了一个nginx-alpine-service的Container:

img{512x368}

nginx-alpine-service的两个容器分别为:

 Running    Default_nginx-alpine-app_1  10.42.96.91 10.10.105.72  nginx:1.8-alpine
 Running    nginx-app-stack_nginx-alpine-service_1  10.42.164.174   10.10.126.101 nginx:1.8-alpine

Rancher内置“Internal DNS Services”,同一Stack下的Container可以通过Container name相互ping通。Rancher以Environment为界限,每个Environment下的Container name都是全局唯一的。

在10.10.105.72上,我们执行如下命令来ping 10.10.126.101上的容器:nginx-app-stack_nginx-alpine-service_1:

$ docker exec r-Default_nginx-alpine-app_1  ping -c 3 nginx-app-stack_nginx-alpine-service_1
PING nginx-app-stack_nginx-alpine-service_1 (10.42.164.174): 56 data bytes
64 bytes from 10.42.164.174: seq=0 ttl=62 time=0.729 ms
64 bytes from 10.42.164.174: seq=1 ttl=62 time=0.754 ms
64 bytes from 10.42.164.174: seq=2 ttl=62 time=0.657 ms

--- nginx-app-stack_nginx-alpine-service_1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.657/0.713/0.754 ms

在10.10.126.101上,我们执行如下命令来ping 10.10.105.72上的容器:Default_nginx-alpine-app_1:

$ docker exec r-nginx-app-stack_nginx-alpine-service_1 ping -c 3 Default_nginx-alpine-app_1
PING Default_nginx-alpine-app_1 (10.42.96.91): 56 data bytes
64 bytes from 10.42.96.91: seq=0 ttl=62 time=0.640 ms
64 bytes from 10.42.96.91: seq=1 ttl=62 time=0.814 ms
64 bytes from 10.42.96.91: seq=2 ttl=62 time=0.902 ms

--- Default_nginx-alpine-app_1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.640/0.785/0.902 ms

我们按照上述方法为nginx-app-stack再添加一个Service: redis-alpine-service,该service基于redis:alpine image,该service的Container被运行在105.72上了:

$ docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                                          NAMES
7246dce88ea6        redis:alpine                    "/entrypoint.sh redis"   3 minutes ago       Up 3 minutes        6379/tcp                                       r-nginx-app-stack_redis-service_1

我们来测试一下同一stack下,不同Service的互ping:

我们在redis-alpine-service的Container中来ping nginx-alpine-service,地址直接使用”nginx-alpine-service”这个service name即可:

$ docker exec r-nginx-app-stack_redis-service_1 ping -c 3 nginx-alpine-service
PING nginx-alpine-service (10.42.164.174): 56 data bytes
64 bytes from 10.42.164.174: seq=0 ttl=62 time=0.660 ms
64 bytes from 10.42.164.174: seq=1 ttl=62 time=0.634 ms
64 bytes from 10.42.164.174: seq=2 ttl=62 time=0.599 ms

--- nginx-alpine-service ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.599/0.631/0.660 ms

可以看到Rancher的Internal DNS Service将”nginx-alpine-service”这个service name解析为nginx-alpine-service的两个Container中的一个:10.42.164.174。

我们再添加一个Stack:memcached-app-stack,来看一下跨Stack的容器连通方法。ping之前我们需要为该Stack添加一个基于memcached:latest image的Service: memcached-service

10.10.105.72

$ docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                                          NAMES
184e8e8f448e        memcached:latest                "/entrypoint.sh memca"   24 seconds ago      Up 16 seconds       11211/tcp                                      r-memcached-app-stack_memcached-service_1

Rancher官方docs中明确说明:不同Stack间service互ping,需要采用“ service_name.stack_name”的地址格式,我们在memcached-app-stack中的“r-memcached-app-stack_memcached-service_1”容器里去ping nginx-app-stack中的nginx-alpine-service服务:

$ docker exec r-memcached-app-stack_memcached-service_1  ping -c 3 nginx-alpine-service.nginx-app-stack
PING nginx-alpine-service.nginx-app-stack (10.42.164.174): 56 data bytes
64 bytes from 10.42.164.174: icmp_seq=0 ttl=62 time=0.710 ms
92 bytes from 10.42.84.96: Redirect Host
64 bytes from 10.42.164.174: icmp_seq=1 ttl=62 time=2.543 ms
--- nginx-alpine-service.nginx-app-stack ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.710/1.627/2.543/0.917 ms

ping nginx-app-stack中的redis-alpine-service服务:

$ docker exec r-memcached-app-stack_memcached-service_1  ping -c 3 redis-alpine-service.nginx-app-stack
PING redis-alpine-service.nginx-app-stack (10.42.220.43): 56 data bytes
64 bytes from 10.42.220.43: icmp_seq=0 ttl=64 time=0.161 ms
64 bytes from 10.42.220.43: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 10.42.220.43: icmp_seq=2 ttl=64 time=0.051 ms
--- redis-alpine-service.nginx-app-stack ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.050/0.087/0.161/0.052 ms

我们通过cat /etc/resolv.conf可以查看到Rancher内部DNS的地址:

$docker exec r-memcached-app-stack_memcached-service_1  cat /etc/resolv.conf
search memcached-app-stack.rancher.internal memcached-service.memcached-app-stack.rancher.internal rancher.internal
nameserver 169.254.169.250

五、Rancher Compose CLI

Rancher除了提供UI工具外,还提供了一个名为rancher-compose的CLI工具,用于在一个stack的范围内管理各个services。rancher-compose的灵感来源于docker-compose,兼容docker-compose的配置文件格式,并有自己的扩展。此外与docker-compose不同的是rancher-compose支持跨多主机管理。

在Rancher UI的右下角有一个Rancher-compose的下载链接,支持Linux,Windows和Mac。rancher-compose当前版本是0.7.3,下载后将其路径放到PATH环境变量里,验证一下运行是否ok:

$ rancher-compose -v
rancher-compose version v0.7.3

要管理某个stack下的Service,我们至少需要提供一个docker-compose.yml文件,这里针对memcached-app-stack下的memcached-service这个服务做一些操作,我们提供一个docker-compose.yml:

memcached-service:
  log_driver: ''
  tty: true
  log_opt: {}
  image: memcached:latest
  stdin_open: true

利用dev环境的api key和secret,rancher-compose可以实现与rancher的交互:

$ rancher-compose --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh -p memcached-app-stack up
INFO[0000] Project [memcached-app-stack]: Starting project
INFO[0000] [0/1] [memcached-service]: Starting
INFO[0000] [1/1] [memcached-service]: Started
INFO[0000] Project [memcached-app-stack]: Project started

由于memcached-service已经存在并启动了相应Container,因此上面的命令实际上没有做任何改动。如果想看rancher-compose的执行细节,可以在rancher-compose后面加上–verbose命令行option,可以看到如下结果:

$ rancher-compose --verbose --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh -p memcached-app-stack up
DEBU[0000] Environment Context from file : map[]
DEBU[0000] Opening compose file: docker-compose.yml
DEBU[0000] [0/0] [memcached-service]: Adding
DEBU[0000] Opening rancher-compose file: /home1/tonybai/rancher-compose.yml
DEBU[0000] Looking for stack memcached-app-stack
DEBU[0000] Found stack: memcached-app-stack(1e3)
DEBU[0000] Launching action for memcached-service
DEBU[0000] Project [memcached-app-stack]: Creating project
DEBU[0000] Finding service memcached-service
DEBU[0000] [0/1] [memcached-service]: Creating
DEBU[0000] Found service memcached-service
DEBU[0000] [0/1] [memcached-service]: Created
DEBU[0000] Project [memcached-app-stack]: Project created
INFO[0000] Project [memcached-app-stack]: Starting project
DEBU[0000] Launching action for memcached-service
DEBU[0000] Finding service memcached-service
INFO[0000] [0/1] [memcached-service]: Starting
DEBU[0000] Found service memcached-service
DEBU[0000] Finding service memcached-service
INFO[0000] [1/1] [memcached-service]: Started
INFO[0000] Project [memcached-app-stack]: Project started
DEBU[0000] Found service memcached-service
DEBU[0000] Finding service memcached-service
DEBU[0000] Found service memcached-service

我们再通过rancher-compose将memcached-service扩展到两个Container:

$ rancher-compose --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh -p memcached-app-stack scale memcached-service=2
INFO[0000] Setting scale memcached-service=2...

几秒后,Rancher UI上memcached-service的Container数量就会从1变为2。在105.72上我们也可以看到两个memcached service container:

$ docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                                          NAMES
43c1443fec9f        memcached:latest                "/entrypoint.sh memca"   8 minutes ago       Up 7 minutes        11211/tcp                                      r-memcached-app-stack_memcached-service_2
184e8e8f448e        memcached:latest                "/entrypoint.sh memca"   14 hours ago        Up 13 hours         11211/tcp                                      r-memcached-app-stack_memcached-service_1

六、Service upgrade

Rancher支持stack中Service的upgrade管理。Rancher提供了两种Service Upgrade方法:In-service upgrade和Rolling upgrade(滚动升级)。rancher-compose同时支持两种升级方法,Rancher UI中针对stack下的service也有upgrade菜单选项,但UI提供的升级方式等同于in-service upgrade。

根据官方docs的说明,In-Service upgrade的默认upgrade步骤大致是:

1、停掉existing service的containers;
2、等待interval时间;
3、启动new version service的containers;
4、confirm upgrade or rollback。

而Rolling upgrade的升级步骤则是:

1、启动new service ;
2、将old service的scale降为0。

下面我们就每种method分别举一个例子说明一下(均采用rancher-compose工具)。

1、In-Service Upgrade

我们来将dev Environment下nginx-app-stack的nginx-alpine-service从nginx:1.8-alpine升级到nginx:1.9-alpine。为此我们需要给rancher-compose提供一份升级后的service的docker-compose.yml文件:

//docker-compose-nginx-service-upgrade.yml

nginx-alpine-service:
  ports:
  - 10086:80/tcp
  log_driver: ''
  labels:
    io.rancher.container.start_once: 'true'
  tty: true
  log_opt: {}
  image: nginx:1.9-alpine
  stdin_open: true

可以看到我们仅是将nginx-alpine-service的image从1.8-alpine改为1.9-alpine了。接下来我们就来升级nginx-alpine-service:

$ rancher-compose -f ./docker-compose-nginx-service-upgrade.yml --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh -p nginx-app-stack up --upgrade nginx-alpine-service
INFO[0000] Project [nginx-app-stack]: Starting project
INFO[0000] [0/1] [nginx-alpine-service]: Starting
INFO[0000] Updating nginx-alpine-service
INFO[0001] Upgrading nginx-alpine-service
INFO[0056] [1/1] [nginx-alpine-service]: Started
INFO[0056] Project [nginx-app-stack]: Project started

我们通过Rancher UI可以看到upgrade执行在界面上体现出来的变化:

img{512x368}

Upgrade后,nginx-alpine-service的详细信息如下:

img{512x368}

我们来Confirm一下:

$ rancher-compose -f ./docker-compose-nginx-service-upgrade.yml  --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SYQDYgVok7Co6HRncU7bUCEShXh -p nginx-app-stack up --upgrade --confirm-upgrade
INFO[0000] Project [nginx-app-stack]: Starting project
INFO[0000] [0/1] [nginx-alpine-service]: Starting
INFO[0001] [1/1] [nginx-alpine-service]: Started
INFO[0001] Project [nginx-app-stack]: Project started
ERRO[0002] Failed to get logs for Default_nginx-alpine-app_1: Failed to find action: logs
ERRO[0002] Failed to get logs for nginx-app-stack_nginx-alpine-service_1: Failed to find action: logs

Confirm后,Rancher UI上的upgrade标记不见了,两个没有running的old版本 container也被cleanup了。confirm时出现两个ERRO,不知何原因,但问题不大,没有影响到confirm结果。

2、Rolling Upgrade

与In-service upgrade服务中断不同,Rolling Upgrade会先启动new Service,然后再逐渐将old service的scale减少到0。这种情况下,如果其他服务配合到位,该服务是不会中断的。

我们以nginx-app-stack中的redis-alpine-service为例,将其从redis:alpine版本升级到3.0.7-alpine。

$docker images
redis                                  3.0.7-alpine        633ba621a23f        6 weeks ago         15.95 MB
redis                                  alpine              633ba621a23f        6 weeks ago         15.95 MB
... ...

我们同样要为这次Roll upgrade准备一份docker-compose.yml文件:

//docker-compose-redis-service-upgrade.yml

redis-alpine-service:
redis-alpine-service-v1:
  log_driver: ''
  tty: true
  log_opt: {}
  image: redis:3.0.7-alpine
  stdin_open: true

执行Rolling upgrade命令:

$rancher-compose -f ./docker-compose-redis-service-upgrade.yml --url http://10.10.126.101:8080  --access-key 5569108BE7489DEE47A5 --secret-key 76Yw5v63ag8SdKYQDYgVok7Co6HRncU7bUCEShXh -p nginx-app-stack upgrade  redis-alpine-service redis-alpine-service-v1
INFO[0000] Creating service redis-alpine-service-v1
INFO[0005] Upgrading redis-alpine-service to redis-alpine-service-v1, scale=2

Rancher UI上出现如下状态变化:

img{512x368}

最终redis-alpine-service-v1启动,redis-alpine-service停止,但Rancher UI并未将其Remove,你可以手动删除,或者在上面命令中加入–cleanup自动删除old service。

七、参考资料

关于Rancher,网上可用的资料并不多,这里主要是参考了官方文档:

http://rancher.com/announcing-rancher-1-0-ga/

http://docs.rancher.com/rancher/quick-start-guide/

不过Rancher的Doc文字太多,少图,尤其是在Rancher UI介绍这块,基本无图,还待改善。

另外国内的云舒网络与 Rancher Labs是深度的合作伙伴,云舒公司博客上的内容也值得大家认真参考。

八、小结

相比于Mesos、Kubernetes和Swarm这三位欧巴,Rancher还最为年轻(至少从发布时间上来看是这样的),也刚刚起步。而这个领域的激烈的竞争也才刚刚开始。 谁能笑道最后,还待观察。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多