背景
RGW处理的报文本质上是一个HTTP报文,通常情况下使用http://<rgw-ip>:<rgw-port>/<bucket-name>
的方式来访问一个bucket。实际应用尤其是公有云环境中,通常要在rgw前架设Haproxy等负载均衡设备,且将Haproxy的ip:port
映射成一个域名,方便用户使用,这个域名也叫Endpoint。
在拥有Endpoint后,访问一个bucket的url变成了http://<endpoint>/<bucket-name>
形式。不过这也只是一个ip到域名映射,和RGW关系不大,但后面要说的功能就和RGW密切相关了。
使用url方式访问bucket主要用于静态网站托管,既然是网站,当然就要尽量满足常规网站访问形式。为此出现了两个需求:
需求1:bucket-domain方式访问
bucket-domain方式是指以http://<bucket-name>.<endpoint>
形式访问bucket。
如果用户在公有云上托管了一个网站,以http://<myblog>.aws-s3.com
形式访问肯定要好于http://aws-s3.com/myblog
,前者域名看起来更像是一个独立网站。
需求2:private-domain
private-domain方式是指使用自己的域名访问特定bucket。
如果用户自己已经有了现成的域名,那直接使用肯定是更接地气,而且访问者完全不知道这个网站到底是托管在公有云上还是使用的独立主机。
细说
bucket-domain方式代码实现
首先,对象存储服务提供方需要设置DNS,将<endpoint>
下的子域解析到RGW或其前端的负载均衡设备。
当HTTP请求到达RGW后,请求中会携带初始host请求信息,即<bucket-name>.<endpoint>
,RGW会根据配置的domain信息,将这个host信息解析成subdomain和domain两部分,分别对应bucket-name和endpoint,随后重新构造一个request url path,格式为/<bucket-name>,至此,整个逻辑回到了最原始的以http://<endpoint>/<bucket-name>
访问时的状态。
int RGWREST::preprocess(struct req_state *s, RGWClientIO* cio)
{
req_info& info = s->info; //info中存有此次请求相关的信息
...
if (info.host.size()) { // info.host中存放的就是用户请求的url domain部分
ldout(s->cct, 10) << "host=" << info.host << dendl;
string domain;
string subdomain;
bool in_hosted_domain_s3website = false;
bool in_hosted_domain = rgw_find_host_in_domains(info.host, &domain, &subdomain, hostnames_set);
...
if (in_hosted_domain && !subdomain.empty()) { //重新构建request uri
string encoded_bucket = "/";
encoded_bucket.append(subdomain);
if (s->info.request_uri[0] != '/')
encoded_bucket.append("/");
encoded_bucket.append(s->info.request_uri);
s->info.request_uri = encoded_bucket;
}
...
private-domain方式代码实现
首先,用户需要将自己的域名配置一条CNAME,使对域名的请求跳转到<bucket-name>.<endpoint>
。
当HTTP请求到达RGW后,请求中携带当host信息是<private-domain>
,RGW首先查询自己的domain配置信息,如果没有找到和这个域名相关的内容,则向DNS服务器请求,期待返回一个自己能使用的CNAME domain。
int RGWREST::preprocess(struct req_state *s, RGWClientIO* cio)
{
req_info& info = s->info;
...
/* 这一段和bucket-domain一样,首先尝试在rgw已配置的domain信息中进行解析 */
if (info.host.size()) {
ldout(s->cct, 10) << "host=" << info.host << dendl;
string domain;
string subdomain;
bool in_hosted_domain_s3website = false;
bool in_hosted_domain = rgw_find_host_in_domains(info.host, &domain, &subdomain, hostnames_set);
string s3website_domain;
string s3website_subdomain;
if (s3website_enabled) {
in_hosted_domain_s3website = rgw_find_host_in_domains(info.host, &s3website_domain, &s3website_subdomain, hostnames_s3website_set);
if (in_hosted_domain_s3website) {
in_hosted_domain = true; // TODO: should hostnames be a strict superset of hostnames_s3website?
domain = s3website_domain;
subdomain = s3website_subdomain;
}
}
...
/*解析失败后尝试请求DNS,得到CNAME后使用CNAME重新解析*/
if (g_conf->rgw_resolve_cname
&& !in_hosted_domain
&& !in_hosted_domain_s3website) {
string cname;
bool found;
int r = rgw_resolver->resolve_cname(info.host, cname, &found);
if (r < 0) {
ldout(s->cct, 0)
<< "WARNING: rgw_resolver->resolve_cname() returned r=" << r
<< dendl;
}
if (found) {
ldout(s->cct, 5) << "resolved host cname " << info.host << " -> "
<< cname << dendl;
in_hosted_domain =
rgw_find_host_in_domains(cname, &domain, &subdomain, hostnames_set);
...
/* 解析成功后,后面的逻辑就又回到了bucket-domain上,即重新构建request uri,然后就进入了常规处理阶段。*/
...
配置RGW domain信息
前面提到RGW会根据自己配置的domain信息对用户的host进行解析,这个domain信息是一个域名列表,列表包括RGW可以识别的domain,由于存在常规s3和s3website两种访问方式,因此会有两个domain信息配置列表
//file: src/rgw/rgw_rest.cc
static set<string> hostnames_set;
static set<string> hostnames_s3website_set;
列表初始化时会加载rgw_dns_name配置项,但此配置项只能配置一条domain,因此如果需要增加多条domain(比如使用private-domain方式,但RGW又无法和解析private-domain的DNS通信的情况下),需要修改zonegroup的hostnames和hostnames_s3website配置。
radosgw-admin zonegroup get > zonegroup.conf
按需修改 zonegroup.conf文件中的hostnames和hostnames_s3website
radosgw-admin zonegroup set --infile=zonegroup.conf
总结
域名访问分三个方式
- 初级方式:
http://<public-cloud-domain>/<bucket-name>
- 中级方式:
http://<bucket-name>.<public-cloud-domain>
- 高级方式:
http://<private-domain>
前两种方式比较简单,无需用户进行额外操作。
第三种方式需要用户配置DNS CNAME,将请求转发到http://<bucket-name>.<public-cloud-domain>
上。这种场景需要注意的是,RGW要能够访问到用户配置了CNAME的DNS服务器,否则只能通过增加RGW domain配置信息的方式来进行弥补。