标签归档:运维

nginx配置(location&rewrite)

location正则写法

一个示例:

location  = / {
  # 精确匹配 / ,主机名后面不能带任何字符串
  [ configuration A ] 
}

location  / {
  # 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ configuration B ] 
}

location /documents/ {
  # 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
  [ configuration C ] 
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条
  [ configuration CC ] 
}

location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。
  [ configuration D ] 
}

location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则
  [ configuration E ] 
}

location /images/ {
  # 字符匹配到 /images/,继续往下,会发现 ^~ 存在
  [ configuration F ] 
}

location /images/abc {
  # 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ configuration G ] 
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用
    [ configuration H ] 
}

location ~* /js/.*/\.js
  • =开头表示精确匹配
    如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。
  • ^~ 开头表示uri以某个常规字符串开头,不是正则匹配
  • ~ 开头表示区分大小写的正则匹配;
  • ~* 开头表示不区分大小写的正则匹配
  • / 通用匹配, 如果没有其它匹配,任何请求都会匹配到

顺序 no优先级:
(location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)

上面的匹配结果
按照上面的location写法,以下的匹配示例成立:

  • / -> config A
    精确完全匹配,即使/index.html也匹配不了
  • /downloads/download.html -> config B
    匹配B以后,往下没有任何匹配,采用B
  • /images/1.gif -> configuration D
    匹配到F,往下匹配到D,停止往下
  • /images/abc/def -> config D
    最长匹配到G,往下匹配D,停止往下
    你可以看到 任何以/images/开头的都会匹配到D并停止,FG写在这里是没有任何意义的,H是永远轮不到的,这里只是为了说明匹配顺序
  • /documents/document.html -> config C
    匹配到C,往下没有任何匹配,采用C
  • /documents/1.jpg -> configuration E
    匹配到C,往下正则匹配到E
  • /documents/Abc.jpg -> config CC
    最长匹配到C,往下正则顺序匹配到CC,不会往下到E

实际使用建议

所以实际使用中,个人觉得至少有三个匹配规则定义,如下:
#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。
#这里是直接转发给后端应用服务器了,也可以是一个静态首页
# 第一个必选规则
location = / {
    proxy_pass http://tomcat:8080/index
}
# 第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
    root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器
#非静态文件请求就默认是动态请求,自己根据实际把握
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了
location / {
    proxy_pass http://tomcat:8080/
}

http://tengine.taobao.org/book/chapter_02.html
http://nginx.org/en/docs/http/ngx_http_rewrite_module.html

Rewrite规则

rewrite功能就是,使用nginx提供的全局变量或自己设置的变量,结合正则表达式和标志位实现url重写以及重定向。rewrite只能放在server{},location{},if{}中,并且只能对域名后边的除去传递的参数外的字符串起作用,例如 http://seanlook.com/a/we/index.php?id=1&u=str 只对/a/we/index.php重写。语法rewrite regex replacement [flag];

如果相对域名或参数字符串起作用,可以使用全局变量匹配,也可以使用proxy_pass反向代理。

表明看rewrite和location功能有点像,都能实现跳转,主要区别在于rewrite是在同一域名内更改获取资源的路径,而location是对一类路径做控制访问或反向代理,可以proxy_pass到其他机器。很多情况下rewrite也会写在location里,它们的执行顺序是:

  1. 执行server块的rewrite指令
  2. 执行location匹配
  3. 执行选定的location中的rewrite指令

如果其中某步URI被重写,则重新循环执行1-3,直到找到真实存在的文件;循环超过10次,则返回500 Internal Server Error错误。

flag标志位

  • last : 相当于Apache的[L]标记,表示完成rewrite
  • break : 停止执行当前虚拟主机的后续rewrite指令集
  • redirect : 返回302临时重定向,地址栏会显示跳转后的地址
  • permanent : 返回301永久重定向,地址栏会显示跳转后的地址

因为301和302不能简单的只返回状态码,还必须有重定向的URL,这就是return指令无法返回301,302的原因了。这里 last 和 break 区别有点难以理解:

  1. last一般写在server和if中,而break一般使用在location中
  2. last不终止重写后的url匹配,即新的url会再从server走一遍匹配流程,而break终止重写后的匹配
  3. break和last都能组织继续执行后面的rewrite指令

if指令与全局变量

if判断指令
语法为if(condition){...},对给定的条件condition进行判断。如果为真,大括号内的rewrite指令将被执行,if条件(conditon)可以是如下任何内容:

  • 当表达式只是一个变量时,如果值为空或任何以0开头的字符串都会当做false
  • 直接比较变量和内容时,使用=!=
  • ~正则表达式匹配,~*不区分大小写的匹配,!~区分大小写的不匹配

-f!-f用来判断是否存在文件
-d!-d用来判断是否存在目录
-e!-e用来判断是否存在文件或目录
-x!-x用来判断文件是否可执行

例如:

if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
} //如果UA包含"MSIE",rewrite请求到/msid/目录下

if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
    set $id $1;
 } //如果cookie匹配正则,设置变量$id等于正则引用部分

if ($request_method = POST) {
    return 405;
} //如果提交方法为POST,则返回状态405(Method not allowed)。return不能返回301,302

if ($slow) {
    limit_rate 10k;
} //限速,$slow可以通过 set 指令设置

if (!-f $request_filename){
    break;
    proxy_pass  http://127.0.0.1; 
} //如果请求的文件名不存在,则反向代理到localhost 。这里的break也是停止rewrite检查

if ($args ~ post=140){
    rewrite ^ http://example.com/ permanent;
} //如果query string中包含"post=140",永久重定向到example.com

location ~* \.(gif|jpg|png|swf|flv)$ {
    valid_referers none blocked www.jefflei.com www.leizhenfang.com;
    if ($invalid_referer) {
        return 404;
    } //防盗链
}

全局变量
下面是可以用作if判断的全局变量

  • $args : #这个变量等于请求行中的参数,同$query_string
  • $content_length : 请求头中的Content-length字段。
  • $content_type : 请求头中的Content-Type字段。
  • $document_root : 当前请求在root指令中指定的值。
  • $host : 请求主机头字段,否则为服务器名称。
  • $http_user_agent : 客户端agent信息
  • $http_cookie : 客户端cookie信息
  • $limit_rate : 这个变量可以限制连接速率。
  • $request_method : 客户端请求的动作,通常为GET或POST。
  • $remote_addr : 客户端的IP地址。
  • $remote_port : 客户端的端口。
  • $remote_user : 已经经过Auth Basic Module验证的用户名。
  • $request_filename : 当前请求的文件路径,由root或alias指令与URI请求生成。
  • $scheme : HTTP方法(如http,https)。
  • $server_protocol : 请求使用的协议,通常是HTTP/1.0或HTTP/1.1。
  • $server_addr : 服务器地址,在完成一次系统调用后可以确定这个值。
  • $server_name : 服务器名称。
  • $server_port : 请求到达服务器的端口号。
  • $request_uri : 包含请求参数的原始URI,不包含主机名,如:”/foo/bar.php?arg=baz”。
  • $uri : 不带请求参数的当前URI,$uri不包含主机名,如”/foo/bar.html”。
  • $document_uri : 与$uri相同。

例:http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php
$document_uri:/test1/test2/test.php
$document_root:/var/www/html
$request_filename:/var/www/html/test1/test2/test.php

常用正则

  • . : 匹配除换行符以外的任意字符
  • ? : 重复0次或1次
  • + : 重复1次或更多次
  • * : 重复0次或更多次
  • \d :匹配数字
  • ^ : 匹配字符串的开始
  • $ : 匹配字符串的介绍
  • {n} : 重复n次
  • {n,} : 重复n次或更多次
  • [c] : 匹配单个字符c
  • [a-z] : 匹配a-z小写字母的任意一个

小括号()之间匹配的内容,可以在后面通过$1来引用,$2表示的是前面第二个()里的内容。正则里面容易让人困惑的是\转义特殊字符。

rewrite实例

例1

http {
    # 定义image日志格式
    log_format imagelog '[$time_local] ' $image_file ' ' $image_type ' ' $body_bytes_sent ' ' $status;
    # 开启重写日志
    rewrite_log on;

    server {
        root /home/www;

        location / {
                # 重写规则信息
                error_log logs/rewrite.log notice; 
                # 注意这里要用‘’单引号引起来,避免{}
                rewrite '^/images/([a-z]{2})/([a-z0-9]{5})/(.*)\.(png|jpg|gif)$' /data?file=$3.$4;
                # 注意不能在上面这条规则后面加上“last”参数,否则下面的set指令不会执行
                set $image_file $3;
                set $image_type $4;
        }

        location /data {
                # 指定针对图片的日志格式,来分析图片类型和大小
                access_log logs/images.log mian;
                root /data/images;
                # 应用前面定义的变量。判断首先文件在不在,不在再判断目录在不在,如果还不在就跳转到最后一个url里
                try_files /$arg_file /image404.html;
        }
        location = /image404.html {
                # 图片不存在返回特定的信息
                return 404 "image not found\n";
        }
}

对形如/images/ef/uh7b3/test.png的请求,重写到/data?file=test.png,于是匹配到location /data,先看/data/images/test.png文件存不存在,如果存在则正常响应,如果不存在则重写tryfiles到新的image404 location,直接返回404状态码。

例2

rewrite ^/images/(.*)_(\d+)x(\d+)\.(png|jpg|gif)$ /resizer/$1.$4?width=$2&height=$3? last;

对形如/images/bla_500x400.jpg的文件请求,重写到/resizer/bla.jpg?width=500&height=400地址,并会继续尝试匹配location。

例3
ssl部分页面加密

参考


ps:
我的wordpress一开始没有开启固定链接。结果外链出去的地址都是http://go2live.cn/archives/92943 这样的形式,修改成固定链接之后,访问地址 http://go2live.cn/archives/92943.html , 这就导致之前的地址打开都是404。
为了把http://go2live.cn/archives/92943 自动跳转成http://go2live.cn/archives/92943.html。
加了一条nginx规则后就好了。
location ~ /archives/\d+$
{
rewrite ^/archives/(\d+)$ /archives/$1.html permanent;
}

ps: 在另一篇文章数据过万后wordpress优化过程记录 中说wp-super-cache的$_GET的bug, 其实就是这次发现的nginx 配置问题,重改下配置规则就好了。

之前是网上抄的

if ( !-e $request_filename ) {
rewrite ^(.*)$ /index.php?url=$1 last;
}

后来改成

if ( !-e $request_filename ) {
rewrite ^(.*)$ /index.php;
}

就好了。

Nginx Upstream timed out (110: Connection timed out)

在Nginx错误日志中,有大量的下列信息:

Upstream timed out (110: Connection timed out) while reading response header from upstream

发生有两种情形:

  1. nginx proxy

需要适当的调整proxy_read_timeout值。

location / {
        ...
        proxy_read_timeout 150;
        ...
    }
  1. Nginx作为php-fpm等等其他的有上游服务

在这种情况下,适当的调整fastcgi_read_timeout选项值

location ~* .php$ {
    include         fastcgi_params;
    fastcgi_index   index.php;
    fastcgi_read_timeout 150;
    fastcgi_pass    127.0.0.1:9000;
    fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
}

运维利器:万能的strace

strace是什么?

按照strace官网的描述, strace是一个可用于诊断、调试和教学的Linux用户空间跟踪器。我们用它来监控用户空间进程和内核的交互,比如系统调用、信号传递、进程状态变更等。

strace底层使用内核的ptrace特性来实现其功能。

在运维的日常工作中,故障处理和问题诊断是个主要的内容,也是必备的技能。strace作为一种动态跟踪工具,能够帮助运维高效地定位进程和服务故障。它像是一个侦探,通过系统调用的蛛丝马迹,告诉你异常的真相。

strace能做什么?

运维工程师都是实践派的人,我们还是先来个例子吧。

我们从别的机器copy了个叫做some_server的软件包过来,开发说直接启动就行,啥都不用改。可是尝试启动时却报错,根本起不来!

启动命令:

./some_server ../conf/some_server.conf

输出:

FATAL: InitLogFile failed iRet: -1! Init error: -1655

为什么起不来呢?从日志看,似乎是初始化日志文件失败,真相到底怎样呢?我们用strace来看看。

strace -tt -f  ./some_server ../conf/some_server.conf

输出:

strace

我们注意到,在输出InitLogFile failed错误的前一行,有个open系统调用:

23:14:24.448034 open(“/usr/local/apps/some_server/log//server_agent.log”, O_RDWR|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = -1 ENOENT (No such file or directory)

它尝试打开文件/usr/local/apps/some_server/log//server_agent.log来写(不存在则创建),可是却出错了,返回码是-1, 系统错误号errorno为ENOENT。 查下open系统调用的手册页:

man 2 open

搜索ENOENT这个错误号errno的解释

ENOENT O_CREAT  is not set and the named file does not exist.  Or, a directory component in pathname does not exist or is a dangling symbolic link.

这里说得比较清楚,因为我们例子中的open选项指定了O_CREAT选项,这里errno为ENOENT的原因是日志路径中某个部分不存在或者是一个失效的符号链接。我们来一级一级看下路径中的哪部分不存在:

ls -l /usr/local/apps/some_server/log ls: cannot access /usr/local/apps/some_server/log: No such file or directory ls -l /usr/local/apps/some_server total 8 drwxr-xr-x 2 root users 4096 May 14 23:13 bin drwxr-xr-x 2 root users 4096 May 14 22:48 conf

原来是log子目录不存在!上层目录都是存在的。手工创建log子目录后,服务就能正常启动了。

回过头来, strace究竟能做什么呢?

它能够打开应用进程的这个黑盒,通过系统调用的线索,告诉你进程大概在干嘛。

strace怎么用?

既然strace是用来跟踪用户空间进程的系统调用和信号的,在进入strace使用的主题之前,我们的先理解什么是系统调用。

关于系统调用:

按维基百科中的解释,在计算机中,系统调用(英语:system call),又称为系统呼叫,指运行在用户空间的程序向操作系统内核请求需要更高权限运行的服务。

系统调用提供用户程序与操作系统之间的接口。操作系统的进程空间分为用户空间和内核空间:

  • 操作系统内核直接运行在硬件上,提供设备管理、内存管理、任务调度等功能。
  • 用户空间通过API请求内核空间的服务来完成其功能——内核提供给用户空间的这些API, 就是系统调用。

在Linux系统上,应用代码通过glibc库封装的函数,间接使用系统调用。

Linux内核目前有300多个系统调用,详细的列表可以通过syscalls手册页查看。这些系统调用主要分为几类:

文件和设备访问类 比如open/close/read/write/chmod等

进程管理类 fork/clone/execve/exit/getpid等

信号类 signal/sigaction/kill 等

内存管理 brk/mmap/mlock等

进程间通信IPC shmget/semget * 信号量,共享内存,消息队列等

网络通信 socket/connect/sendto/sendmsg 等

其他

熟悉Linux系统调用/系统编程,能够让我们在使用strace时得心应手。不过,对于运维的问题定位来说,知道strace这个工具,会查系统调用手册,就差不多够了。

想要深入了解的同学,建议阅读《Linux系统编程》, 《Unix环境高级编程》等书籍。

我们回到strace的使用上来。strace有两种运行模式。

一种是通过它启动要跟踪的进程。用法很简单,在原本的命令前加上strace即可。比如我们要跟踪 “ls -lh /var/log/messages” 这个命令的执行,可以这样:

strace ls -lh /var/log/messages

另外一种运行模式,是跟踪已经在运行的进程,在不中断进程执行的情况下,理解它在干嘛。 这种情况,给strace传递个-p pid 选项即可。

比如,有个在运行的some_server服务,第一步,查看pid:

pidof some_server

17553

得到其pid 17553然后就可以用strace跟踪其执行:

strace -p 17553

完成跟踪时,按ctrl + C 结束strace即可。

strace有一些选项可以调整其行为,我们这里介绍下其中几个比较常用的,然后通过示例讲解其实际应用效果。

strace常用选项:

从一个示例命令来看:

strace -tt -T -v -f -e trace=file -o /data/log/strace.log -s 1024 -p 23489

-tt 在每行输出的前面,显示毫秒级别的时间
-T 显示每次系统调用所花费的时间
-v 对于某些相关调用,把完整的环境变量,文件stat结构等打出来。
-f 跟踪目标进程,以及目标进程创建的所有子进程
-e 控制要跟踪的事件和跟踪行为,比如指定要跟踪的系统调用名称
-o 把strace的输出单独写到指定的文件
-s 当系统调用的某个参数是字符串时,最多输出指定长度的内容,默认是32个字节
-p 指定要跟踪的进程pid, 要同时跟踪多个pid, 重复多次-p选项即可。

实例:跟踪nginx, 看其启动时都访问了哪些文件

strace -tt -T -f -e trace=file -o /data/log/strace.log -s 1024 ./nginx

部分输出:

运维利器

输出中,第一列显示的是进程的pid, 接着是毫秒级别的时间,这个是-tt 选项的效果。

每一行的最后一列,显示了该调用所花的时间,是-T选项的结果。

这里的输出只显示和文件访问有关的内容,这是因为我们通过-e trace=file 选项指定了。

strace问题定位案例

1、定位进程异常退出

问题:机器上有个叫做run.sh的常驻脚本,运行一分钟后会死掉。需要查出死因。

定位:进程还在运行时,通过ps命令获取其pid, 假设我们得到的pid是24298

strace -o strace.log -tt -p 24298

查看strace.log, 我们在最后2行看到如下内容:

22:47:42.803937 wait4(-1,  <unfinished …>

22:47:43.228422 +++ killed by SIGKILL +++

这里可以看出,进程是被其他进程用KILL信号杀死的。

实际上,通过分析,我们发现机器上别的服务有个监控脚本,它监控一个也叫做run.sh的进程,当发现run.sh进程数大于2时,就会把它杀死重启。结果导致我们这个run.sh脚本被误杀。

进程被杀退出时,strace会输出killed by SIGX(SIGX代表发送给进程的信号)等,那么,进程自己退出时会输出什么呢?

这里有个叫做test_exit的程序,其代码如下:

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char **argv) {

exit(1);

}

我们strace看下它退出时strace上能看到什么痕迹。

strace -tt -e trace=process -f ./test_exit

说明: -e trace=process 表示只跟踪和进程管理相关的系统调用。

输出:

23:07:24.672849 execve(“./test_exit”, [“./test_exit”], [/* 35 vars */]) = 0

23:07:24.674665 arch_prctl(ARCH_SET_FS, 0x7f1c0eca7740) = 0

23:07:24.675108 exit_group(1)           = ?

23:07:24.675259 +++ exited with 1 +++

可以看出,进程自己退出时(调用exit函数,或者从main函数返回), 最终调用的是exit_group系统调用, 并且strace会输出exited with X(X为退出码)。

可能有人会疑惑,代码里面明明调用的是exit, 怎么显示为exit_group?

这是因为这里的exit函数不是系统调用,而是glibc库提供的一个函数,exit函数的调用最终会转化为exit_group系统调用,它会退出当前进程的所有线程。实际上,有一个叫做_exit()的系统调用(注意exit前面的下划线), 线程退出时最终会调用它。

2、定位共享内存异常

有个服务启动时报错:

shmget 267264 30097568: Invalid argument
Can not get shm...exit!

错误日志大概告诉我们是获取共享内存出错,通过strace看下:

strace -tt -f -e trace=ipc ./a_mon_svr     ../conf/a_mon_svr.conf

输出:

22:46:36.351798 shmget(0x5feb, 12000, 0666) = 0

22:46:36.351939 shmat(0, 0, 0)          = ?

Process 21406 attached

22:46:36.355439 shmget(0x41400, 30097568, 0666) = -1 EINVAL (Invalid argument)

shmget 267264 30097568: Invalid argument

Can not get shm…exit!

这里,我们通过-e trace=ipc 选项,让strace只跟踪和进程通信相关的系统调用。

从strace输出,我们知道是shmget系统调用出错了,errno是EINVAL。同样, 查询下shmget手册页,搜索EINVAL的错误码的说明:

EINVAL A new segment was to be created and size < SHMMIN or size >

SHMMAX, or no new segment was to be created, a segment with given key existed,

but size is greater than the size of that segment

翻译下,shmget设置EINVAL错误码的原因为下列之一:

  • 要创建的共享内存段比 SHMMIN小 (一般是1个字节)
  • 要创建的共享内存段比 SHMMAX 大 (内核参数kernel.shmmax配置)
  • 指定key的共享内存段已存在,其大小和调用shmget时传递的值不同。

从strace输出看,我们要连的共享内存key 0x41400, 指定的大小是30097568字节,明显与第1、2种情况不匹配。那只剩下第三种情况。使用ipcs看下是否真的是大小不匹配:

ipcs  -m | grep 41400

key        shmid      owner      perms      bytes      nattch     status

0x00041400 1015822    root       666        30095516   1

可以看到,已经0x41400这个key已经存在,并且其大小为30095516字节,和我们调用参数中的30097568不匹配,于是产生了这个错误。

在我们这个案例里面,导致共享内存大小不一致的原因,是一组程序中,其中一个编译为32位,另外一个编译为64位,代码里面使用了long这个变长int数据类型。

把两个程序都编译为64解决了这个问题。

这里特别说下strace的-e trace选项。

要跟踪某个具体的系统调用,-e trace=xxx即可。但有时候我们要跟踪一类系统调用,比如所有和文件名有关的调用、所有和内存分配有关的调用。

如果人工输入每一个具体的系统调用名称,可能容易遗漏。于是strace提供了几类常用的系统调用组合名字。

-e trace=file     跟踪和文件访问相关的调用(参数中有文件名)
-e trace=process  和进程管理相关的调用,比如fork/exec/exit_group
-e trace=network  和网络通信相关的调用,比如socket/sendto/connect
-e trace=signal    信号发送和处理相关,比如kill/sigaction
-e trace=desc  和文件描述符相关,比如write/read/select/epoll等
-e trace=ipc 进程见同学相关,比如shmget等

绝大多数情况,我们使用上面的组合名字就够了。实在需要跟踪具体的系统调用时,可能需要注意C库实现的差异。

比如我们知道创建进程使用的是fork系统调用,但在glibc里面,fork的调用实际上映射到了更底层的clone系统调用。使用strace时,得指定-e trace=clone, 指定-e trace=fork什么也匹配不上。

3、 性能分析

假如有个需求,统计Linux 4.5.4 版本内核中的代码行数(包含汇编和C代码)。这里提供两个Shell脚本实现:

poor_script.sh:

!/bin/bash

total_line=0
while read filename; do
line=$(wc -l $filename | awk ‘{print $1}’)
(( total_line += line ))
done < <( find linux-4.5.4 -type f  ( -iname ‘.c’ -o -iname ‘.h’ -o -iname ‘*.S’ ) )
echo “total line: $total_line”

good_script.sh:

!/bin/bash

find linux-4.5.4 -type f  ( -iname ‘.c’ -o -iname ‘.h’ -o -iname ‘*.S’ ) –

print0
| wc -l —files0-from – | tail -n 1

两段代码实现的目的是一样的。 我们通过strace的-c选项来分别统计两种版本的系统调用情况和其所花的时间(使用-f同时统计子进程的情况)

万能的strace

运维利器,万能的strace

从两个输出可以看出,good_script.sh 只需要2秒就可以得到结果:19613114行。它大部分的调用(calls)开销是文件操作(read/open/write/close)等,统计代码行数本来就是干这些事情。

而poor_script.sh完成同样的任务则花了539秒。它大部分的调用开销都在进程和内存管理上(wait4/mmap/getpid…)。

实际上,从两个图中clone系统调用的次数,我们可以看出good_script.sh只需要启动3个进程,而poor_script.sh完成整个任务居然启动了126335个进程!

而进程创建和销毁的代价是相当高的,性能不差才怪。

总结

当发现进程或服务异常时,我们可以通过strace来跟踪其系统调用,“看看它在干啥”,进而找到异常的原因。熟悉常用系统调用,能够更好地理解和使用strace。

当然,万能的strace也不是真正的万能。当目标进程卡死在用户态时,strace就没有输出了。

这个时候我们需要其他的跟踪手段,比如gdb/perf/SystemTap等。

中小公司统一用户认证方案


 

最近刚入职一家创业公司,因为账号问题各种发愁。以前所在的公司在这方面都很成熟,暂未遇到此类困扰。现将我在工作所遇到的问题分享出来,给大家借鉴与参考。


现象:

  •    开发账号混乱,GitLab、Jira、Confluence各一套账号,那叫一个乱

  •     两个机房 VPN 两套,开发、运维、测试各种切换

  •     WIFI 没有对用户做认证,只是统一密码连接

  •     内部各种运营平台,各种密码


对策:

  •     公司员工各种开发应用账号统一用 LDAP 认证

  •     VPN 账号用 LDAP 认证,机房专线打通(网络组同学做)

  •     WIFI 这边用的是 LDAP + FreeRADIUS + Cisco WLC

  •     为内部运营平台登陆提供LDAP API

 

帐号安全:(一个帐号虽然方便,但同时也又不安全)

  •    定期账号密码修改,根据 LDAP 存储的员工邮件信息,邮件提醒

  •     提供统一的修改密码功能、及密码找回功能

  •     密码复杂度

 

开源解决库:

  • 帐号密码安全这块,用Self Service Password,可以去 http://ltb-project.org/ 下载,上面还有一堆很好用的库

  •  监控,去开源的 http://ltb-project.org/,可以找到 Nagios 插件

  •  内部运营登陆用的接口 Python ldap 模块,用 Flask 封装,提供 HTTP 的接口,方便运营平台开发调用

  •   批量帐号添加,用 Python 写成脚本,生成  ldif  文件,导入 LDAP master

  •    LDAP,用的是 openldap-servers-2.4.40-8.el7.x86_64

  •    操作系统 Centos 7.1

  •    WIFI 认证这块 用到 FreeRADIUS

 

目前简单架构:

  • Ldap Master : ldap1.51reboot.com(提供所有的更新修改)

  • Ldap Slave:ldap2.51reboot.com(提供给各种应用帐号认证)

  • Office Ldap:ldap3.51reboot.com(提供wifi,VPN用)

其中没有用的LB,如果后续需要直接添加 LVS,或智能 DNS 解析一下

 

P.S. 上面的一些操作,从安装部署、sync、各种软件配置、LDAP API 会陆续写成详细的文档,定期更新 。欢迎关注。

 

自动化运维工具之ansible

一、什么样的情形需要批量部署

1、操作系统的安装

常见的有collber,red hat satelite(redhat)系统专用。

2、操作系统的配置

常见的有cfengine,puppet,chef,func。其中puppet最受欢迎

3、批量程序的部署

4、批量命令的运行查看状态信息

二、ansible介绍

ansible的架构大致如下

1

ansible是新出现的运维工具是基于Python研发的糅合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。

  1. 运维工具常见的工作模式  
  2. 1、agent模式: 基于ssl实现。代理工作在被监控端。像puppet。  
  3. 2、agentless模式: 基于ssh服务实现工作在被监控端。监控端是ssh的客户端。 

ansible是工作在agentless模式下具有幂等性。ansible在控制端只需要告诉监控端的期望状态就可以实现批量部署。

  1. 名词解释  
  2. 幂等性不会重复执行相同的指令。例如不会重复安装软件  
  3. 期望状态只需要告诉被监控端的期望状态 

ansible是基于模块工作的ansible本身没有批量部署的能力。真正具有批量部署的是ansible所运行的模块ansible只是提供一种框架。架构包括

  • 连接插件connection plugins负责和被监控端实现通信。
  • Host Inventory:指定操作的主机,是一个配置文件里面定义监控的主机
  • 各种模块核心模块command模块自定义模块
  • 借助于插件完成记录日志邮件等功能
  • PlayBooks:剧本执行多个任务时。并非必需可以让节点一次性运行多个任务

三、ansible的基本使用

  1. 安装软件yum install ansible -y # 对应的软件在 epel 仓库中也可自己手动编译  
  2. #源码地址 https://pypi.python.org/packages/source/a/ansible/ansible-1.5.tar.gz 

2 

  1. 2、定义Host Inventory  
  2. # vim /etc/ansible/hosts  
  3. [webhosts]  
  4. 172.16.10.22 ansible_ssh_user=root ansible_ssh_pass=guoting 
  5. 172.16.10.33 ansible_ssh_user=root ansible_ssh_pass=guoting 
  6. 解释  
  7. #ansible_ssh_user=root 是ssh登陆用户  
  8. #ansible_ssh_pass=guoting 是ssh登陆密码3、测试各个模块  
  9. # 注意每个模块的用法可以使用 ansible-doc MOD 来查看例如ansible-doc copy  
  10.    
  11. ansible命令最常用的用法  
  12. ansible <Host-partten> -m MOE -a ‘MOD_ARV’所支持的模块可以使用ansible-doc -l来查看 

ansible示例

1、查看时间信息。command、shell模块

3

2、在控制端添加添加用户。user模块

4

3、实现ssh秘钥认证。shell、copy模块

6

此时就可以实现基于ssh秘钥通信了此时/etc/ansible/hosts可以修改如下

  1. ###### /etc/ansible/hosts  
  2. [webhosts]  
  3. 172.16.10.22  
  4. 172.16.10.33 

7

4、安装软件和启动服务。yum、service模块

8

9

5、支持管道的命令。raw模块,类似于shell模块

wKioL1QaeV6QK9YUAACu77PB1cY454.jpg

四、YAML语言介绍

1、YAML简介

  1. YAML是一个可读性高的用来表达资料序列的格式。YAML参考了其他多种语言包括XML、C语言、Python、Perl以及电子邮件格式RFC2822等。Clark Evans在2001年在首次发表了这种语言另外Ingy dtNet与Oren Ben-Kiki也是这语言的共同设计者。  
  2. YAML Ain’t Markup Language即YAML不是XML。不过在开发的这种语言时YAML的意思其实是”Yet Another Markup Language”仍是一种标记语言。其特性  
  3. YAML的可读性好  
  4. YAML和脚本语言的交互性好  
  5. YAML使用实现语言的数据类型  
  6. YAML有一个一致的信息模型  
  7. YAML易于实现  
  8. YAML可以基于流来处理  
  9. YAML表达能力强扩展性好  
  10.    
  11. 更多的内容及规范参见http://www.yaml.org。  
  12.    
  13. ##########################YAML语法  
  14.    
  15. YAML的语法和其他高阶语言类似并且可以简单表达清单、散列表、标量等数据结构。其结构Structure通过空格来展示序列Sequence里的项用”-“来代表  
  16. Map里的键值对用”:”分隔。YAML文件扩展名通常为.yaml或者.yml。下面是一个示例。  
  17.    
  18. name: John Smith  
  19. age: 41gender: Male  
  20. spouse:  
  21. name: Jane Smith  
  22. age: 37  
  23. gender: Female  
  24. children:  
  25. – name: Jimmy Smith  
  26. age: 17  
  27. gender: Male  
  28. – name: Jenny Smith  
  29. age 13  
  30. gender: Female  
  31.    
  32. YAML 2 个重要的结构组成部分list和directory  
  33. ################################# list  
  34.    
  35. 列表的所有元素均使用“-”打头例如  
  36. # A list of tasty fruits  
  37. – Apple  
  38. – Orange  
  39. – Strawberry  
  40. – Mango  
  41.    
  42. ##############################dictionary  
  43.    
  44. 字典通过key与valuef进行标识例如  
  45. —  
  46. # An employee record  
  47. name: Example Developer  
  48. job: Developer  
  49. skill: Elite  
  50.    
  51. 也可以将key:value放置于{}中进行表示例如  
  52. —  
  53. # An employee record  
  54. {name: Example Developer, job: Developer, skill: Elite}  
  55.    
  56. 多个映射关系组成一个字典一个列表可以包含多个字典。 

2、ymal中的变量

  1. ################################## 变量命名  
  2. 变量名仅能由字母、数字和下划线组成且只能以字母开头。  
  3.    
  4. ################################## facts  
  5. facts是由正在通信的远程目标主机发回的信息这些信息被保存在ansible变量中。要获取指定的远程主机所支持的所有facts可使用如下命令进行  
  6. # ansible hostname -m setup 这个命令可以获得被监控端主机的各种信息将这些信息得到后保存到变量中。  
  7.    
  8. ################################ 自定义变量  
  9. 在 yaml 中可以使用vars关键字来定义变量  
  10. vars:  
  11. var_name: value  
  12.    
  13. ############################# 变量的引用  
  14. {{ var_name }}  
  15.    
  16.    
  17. ########################### 特殊的变量迭代  
  18. 当有需要重复性执行的任务时可以使用迭代机制。其使用格式为将需要迭代的内容定义为item变量引用并通过with_items语句来指明迭代的元素列表即可。  
  19.    
  20. #######################################示例  
  21. 例如在被控端添加 2 个用户  
  22.    
  23. 方式1一般做法  
  24. – name: add user testuser1  
  25. user: name=testuser1 state=present groups=wheel 
  26. – name: add user testuser2  
  27. user: name=testuser2 state=present groups=wheel 
  28.    
  29. 方式2使用变量方式  
  30. – name: add several users  
  31. vars:  
  32. user1: testuser1  
  33. user2: testuser2  
  34. user: name={{ user1 }} state=present groups=wheel 
  35. user: name={{ user2 }} state=present groups=wheel 
  36.    
  37. 方式3使用迭代方式  
  38. – name: add several users  
  39. user: name={{ item }} state=present groups=wheel 
  40. with_items:   
  41. – testuser1   
  42. – testuser2  
  43. 事实上with_items中可以使用元素还可为hashes例如  
  44. – name: add several users  
  45. user: name={{ item.name }} state=present groups={{ item.groups }}  
  46. with_items:  
  47. – { name: ‘testuser1’, groups: ‘wheel’ }  
  48. – { name: ‘testuser2’, groups: ‘root’ } 

3、Inentory文件的格式

  1. inventory文件遵循INI文件风格中括号中的字符为组名。可以将同一个主机同时归并到多个不同的组中此外当如若目标主机使用了非默认的SSH端口还可以在主机名称之后使用冒号加端口号来标明。  
  2.    
  3. [webservers]  
  4. www1.magedu.com:2222  
  5. www2.magedu.com  
  6. [dbservers]  
  7. db1.magedu.com  
  8. db2.magedu.com  
  9. db3.magedu.com  
  10.    
  11. 如果主机名称遵循相似的命名模式还可以使用列表的方式标识各主机例如  
  12. [webservers]  
  13. www[01:50].example.com  
  14. [databases]  
  15. db-[a:f].example.com  
  16.    
  17. #################### 主机变量  
  18. 可以在inventory中定义主机时为其添加主机变量以便于在playbook中使用。例如  
  19. [webservers]  
  20. www1.magedu.com http_port=80 maxRequestsPerChild=808 
  21. www2.magedu.com http_port=303 maxRequestsPerChild=909 
  22.    
  23. ################### 组变量  
  24. 组变量是指赋予给指定组内所有主机上的在playbook中可用的变量。例如  
  25.    
  26. [webservers]  
  27. www1.magedu.com  
  28. www2.magedu.com  
  29.    
  30. [webservers:vars]  
  31. ntpntp_server=ntp.magedu.com  
  32. nfsnfs_server=nfs.magedu.com  
  33.    
  34. ################## 组嵌套  
  35. inventory中组还可以包含其它的组并且也可以向组中的主机指定变量。不过这些变量只能在ansible-playbook中使用而ansible不支持。例如  
  36.    
  37. [apache]  
  38. httpd1.magedu.com  
  39. httpd2.magedu.com  
  40.    
  41. [nginx]  
  42. ngx1.magedu.com  
  43. ngx2.magedu.com  
  44.    
  45. [webservers:children]  
  46. apache  
  47. nginx  
  48.    
  49. [webservers:vars]  
  50. ntpntp_server=ntp.magedu.com  
  51.    
  52. ######################### inventory参数  
  53.    
  54. ansible基于ssh连接inventory中指定的远程主机时还可以通过参数指定其交互方式常用的参数如下所示  
  55. ansible_ssh_host # 要连接的主机名  
  56. ansible_ssh_port # 端口号默认是22  
  57. ansible_ssh_user # ssh连接时默认使用的用户名  
  58. ansible_ssh_pass # ssh连接时的密码  
  59. ansible_sudo_pass # 使用sudo连接用户是的密码  
  60. ansible_ssh_private_key_file # 秘钥文件如果不想使用ssh-agent管理时可以使用此选项  
  61. ansible_shell_type # shell的类型默认sh  
  62. #########################################################################################  
  63. ansible的循环机制还有更多的高级功能具体请参见官方文档http://docs.ansible.com/playbooks_loops.html。 

4、playbooks

  1. playbook是由一个或多个“play”组成的列表。play的主要功能在于将事先归并为一组的主机装扮成事先通过ansible中的task定义好的角色。  
  2. 从根本上来讲所谓task无非是调用ansible的一个module。将多个play组织在一个playbook中即可以让它们联同起来按事先编排的机制同唱一台大戏。  
  3.    
  4. ###########################playbook基础组件  
  5. 1、Hosts和Users  
  6.    
  7. playbook中的每一个play的目的都是为了让某个或某些主机以某个指定的用户身份执行任务。  
  8. hosts用于指定要执行指定任务的主机其可以是一个或多个由冒号分隔主机组。  
  9. remote_user则用于指定远程主机上的执行任务的用户。  
  10.    
  11. 不过remote_user也可用于各task中。也可以通过指定其通过sudo的方式在远程主机上执行任务其可用于play全局或某任务。  
  12. 此外甚至可以在sudo时使用sudo_user指定sudo时切换的用户。  
  13.    
  14. – hosts: webnodes  
  15. remote_user: mageedu  
  16. tasks:  
  17. – name: test connection ping:  
  18. remote_user: mageedu sudo: yes  
  19.    
  20. 2、任务列表和action  
  21. play的主体部分是task list。task list中的各任务按次序逐个在hosts中指定的所有主机上执行即在所有主机上完成第一个任务后再开始第二个。  
  22. 在运行自下而下某playbook时如果中途发生错误所有已执行任务都将回滚因此在更正playbook后重新执行一次即可。  
  23. task的目的是使用指定的参数执行模块而在模块参数中可以使用变量。模块执行是幂等的这意味着多次执行是安全的因为其结果均一致。  
  24. 每个task都应该有其name用于playbook的执行结果输出建议其内容尽可能清晰地描述任务执行步骤。如果未提供name则action的结果将用于输出。  
  25.    
  26. 定义task的可以使用“action: module options”或“module: options”的格式推荐使用后者以实现向后兼容。  
  27. 如果action一行的内容过多也中使用在行首使用几个空白字符进行换行。  
  28.    
  29. tasks:  
  30. – name: make sure apache is running  
  31. service: name=httpd state=running 
  32.    
  33. 在众多模块中只有command和shell模块仅需要给定一个列表而无需使用“key=value”格式例如  
  34. tasks:  
  35. – name: disable selinux  
  36. command: /sbin/setenforce 0如果命令或脚本的退出码不为零可以使用如下方式替代  
  37. tasks:  
  38. – name: run this command and ignore the result  
  39. shell: /usr/bin/somecommand || /bin/true  
  40. 或者使用ignore_errors来忽略错误信息  
  41. tasks:  
  42. – name: run this command and ignore the result  
  43. shell: /usr/bin/somecommand  
  44. ignore_errors: True   
  45.    
  46. 3、handlers  
  47.    
  48. 用于当关注的资源发生变化时采取一定的操作。  
  49.    
  50. “notify”这个action可用于在每个play的最后被触发这样可以避免多次有改变发生时每次都执行指定的操作取而代之仅在所有的变化发生完成后一次性地执行指定操作。在notify中列出的操作称为handler也即notify中调用handler中定义的操作。  
  51.    
  52. – name: template configuration file  
  53. template: src=template.j2 dest=/etc/foo.conf  
  54. notify:  
  55. – restart memcached  
  56. – restart apache   
  57.    
  58. handler是task列表这些task与前述的task并没有本质上的不同。  
  59.    
  60. handlers:  
  61. – name: restart memcached  
  62. service: name=memcached state=restarted 
  63. – name: restart apache  
  64. service: name=apache state=restarted 

5、tags

  1. tags用于让用户选择运行或路过playbook中的部分代码。ansible具有幂等性因此会自动跳过没有变化的部分即便如此有些代码为测试其确实没有发生变化的时间依然会非常地长。此时如果确信其没有变化就可以通过tags跳过此些代码片断。  
  2.    
  3. 示例基于playbooks实现web服务的部署  
  4. 1、提供好Inventory文件  
  5. # /etc/ansible/hosts基于秘钥认证  
  6. [webhosts]  
  7. 172.16.10.22  
  8. 172.16.10.33  
  9.    
  10. 2、编辑 palybooks 剧本  
  11. # vim /root/web.yaml  
  12. – name: web service  
  13. remote_user: root  
  14. hosts: webhosts  
  15. vars:  
  16. packages: httpd  
  17. tasks:  
  18. – name: install httpd yum: name={{ packages }} state=present 
  19. tags: install  
  20. – name: configuration httpd  
  21. copy: src=/root/httpd.conf dest=/etc/httpd/conf/httpd.conf  
  22. tags: conf  
  23. notify:  
  24. – restart httpd  
  25. – name: service httpd start  
  26. service: name=httpd enabled=no state=started 
  27. tags: start  
  28. – name: add centos and hadoop user  
  29. user: name={{ item }} state=absent 
  30. tags: adduser  
  31. with_items:  
  32. – centos  
  33. – hadoop  
  34. handlers:  
  35. – name: restart httpd  
  36. service: name=httpd state=restarted 
  37.    
  38. 3、准备好配置文件  
  39. 将web的配置放到指定目录 src=/root/httpd.conf  
  40.    
  41. 4、开始部署  
  42. ansible-playbooks /root/web.yml 

结果示例

11

查看端口

12

此时如果配置文件发生变化

13

至此基本使用配置完成。

博文地址:http://guoting.blog.51cto.com/8886857/1553446

apache域名重定向

需求

把www.abc.com 301重定向成 abc.com

  1. 为了SEO,任何一个域名 www和不带www的都应该301到其中一个,
    这样能传递权重,而且不至于造成重复内容的不同URL
  2. abc.com对移动端更友好。容易输入。

解决

百度之 apache htaccess 301。
有文章
有工具

总结下步骤

1. 确保apache 有安装rewrite模块,并且开启。
2. VirtualHost 有设置 AllowOverride All 
3. .htaccess文件正确编写
    RewriteEngine On
    RewriteCond %{http_host} ^www.abc.com$ [NC]
    RewriteRule ^(.*)$ http://abc.om/$1 [R=301,L]

如果一切正常,我可以很愉快地完成任务了。
!!!但是居然没有生效。。

原因

我有三个VirtualHost,配置的域名分别是aaa.com、bbb.com、ccc.com
当我访问www.bbb.com时,每次都会跳转到aaa.com。
查dns,对比配置文件,都没有问题呀。
突然灵机一动。
是不是www.bbb.com在虚拟host里找不到对应的配置文件,所以自动匹配了按字母序排第1的aaa.com呢?

试一下,去掉aaa.com。
访问www.ccc.com跳转到了bbb.com。
验证成功。

最终解决

分别为几个域名添加www的别名。如
ServerName aaa.com
ServerAlias *.aaa.com

然后愉快地完成了任务。

总结

知识缺乏。
vhosts配置文件
匹配规则

缺乏的知识点有:

1. ServerName是访问域名,ServerAlias提供的访问别名都会重定向到ServerName
2. 匹配规则:
    1. 有提供ip地址的优先级最高。(ps:ip地址一般用来区分内网和外网访问)
    2. 匹配到了域名
    3. 没有匹配到域名,第一个匹配到了端口号的生效。

细说Windows与Docker之间的趣事

众所周知,Docker能打通开发和运维的任督二脉,所谓DevOps是也。有朋友说,这符合王阳明的”知行合一”之教。

而Windows Server 2016内置的Windows Docker亦已经出来一段时间,这里就来和诸公汇报一下测试结果。

Linux和Windows,Docker里各有多少进程

在安装配置Container Host的时候,经常报错Container OS Image下载失败(没办法,墙内的缘故)。

什么是Container OS?顾名思义,是从容器角度看到的OS。

Container OS实际是应用所依赖的用户模式(User mode)OS组件,对于Windows容器来说,例如ntdll.dll、kernel32.dll或者coresystem.dll之类的System DLL。主机上的所有容器共享内核模式(Kernel mode)OS组件,对于Windows,就是ntoskrnl.exe,还有驱动等。

例如对于以下命令,意味着Windows系统从docker映像中获取Windows Server Core的用户模式OS组件,并启动cmd获得Shell。

docker run -it windowsservercore cmd

Linux也是一理,如果运行以下命令,意味着从docker映像中获取Ubuntu的用户模式组件,并且启动Bash Shell。

docker run -it ubuntu /bin/bash

对于以上两个容器,Linux容器里的进程比较少,可以参考以下截图:

而Windows容器,则情况略有不同。

在Windows主机上启动Process Explorer,可以看到这个Windows容器的进程相对多一些:

这是因为在Windows系统中,需要给应用提供一些用户模式的系统服务,例如DNS、DHCP、RPC等服务,这样从容器的角度来看,容器获得了自己独有的服务(一般是在各自的svchost或者其他服务宿主进程里运行),构成了所谓的Container OS。

我们可以用PowerShell命令查看容器内部启动的Windows服务,大概有27个,参考附图。

很可惜,这个版本的Windows docker里,虽然有远程桌面服务,但是目前还不支持远程桌面到容器,所以无法使用容器应用的图形化界面。

容器里的应用,到底应该启动多少Windows服务?由于Windows服务的具体作用是非文档化的,所以不像Linux可以做到最精简。但是由于这些服务几乎不占用什么额外的资源,对于容器性能没有影响。

Windows容器的进程如何隔离

由于在最新的测试版本里,容器对象的权限设置有了改变,只有SYSTEM权限才能查看。所以要查看Windows容器的进程隔离,需要用SYSTEM权限启动Winobj。这可以借助Psexec来实现:

Psexec -i -d -s winobj.exe

可以看到Windows对象空间里多了一个Containers的节点,其下有若干个GUID分支,这些GUID代表系统里的容器。其下每个容器有自己独立的BaseNamedObjects等命名空间,包括互斥信号量、内存Section、事件等。

可以用PowerShell查看容器的GUID,参考附图。

每个容器节点下,有自己的Session分支,例如该容器,占据了Windows系统的Session 2。如附图所示。

这就是为什么,不管用任务管理器,还是PowerShell,抑或是Process Explorer等工具,我们都在Windows主机里看到容器里的所有进程都会标记Session为2。

借助Process Explorer,我们可以看到容器里的进程,所打开的Handle,其中就指向先前所看到的Windows容器对象命名空间。

同时还能看到,容器进程所在的WindowStation并不是WinSta0,而是Service-0x0-3e7$,3e7的10进制等于999,等于九五之尊,这是SYSTEM服务所在的窗口站。所以容器进程无法在Windows桌面上拥有图形化界面。

还可以查看一个有意义的对象,Windows容器所挂载的主机目录,类似于Linux容器的Volume。

Windows容器的文件系统如何隔离

和Linux一样,Windows容器映像采用分层的文件系统,基于映像创建容器后,相当于在只读的分层文件系统上再覆盖一层可读写的文件系统层。如果要修改的文件在最上层的可读写层里没有,则沿着分层的Layer找到目标文件后,将其用COW(Copy on write:写时复制)复制到可读写层再修改。

让我们进入到Windows主机的以下目录:

C:\ProgramData\Microsoft\Windows\Hyper-V\Containers

该目录下列出所有通过PowerShell命令创建的容器文件。其下有文件夹和文件,都以容器的GUID来命名。

其中的926A300B-ACB7-4B28-9D86-45BF82C1211C.vhdx就是该容器的最上层的可读写层,是一个VHDX文件。

记住该可读写层并不是一个完整的文件系统,它需要和Image的现有文件系统组成Union File System。如果尝试双击该VHDX(只能尝试挂载停止状态的容器VHDX),试图挂载到Windows系统,会弹出以下报错信息,提示该虚拟硬盘无法挂载。

Image的文件系统位于以下路径(Windows Server Core的Container OS文件):

C:\ProgramData\Microsoft\Windows\Images\CN=Microsoft_WindowsServerCore_10.0.10586.0\Files

如果用Process Explorer查看容器进程访问的Dll,可以看到其访问的路径为Container OS文件。

如果是用docker命令创建的进程,道理类似,但是其可读写层文件系统位于以下路径:

C:\ProgramData\docker\windowsfilter

Windows容器还有注册表

和Linux不一样,Windows容器还需要考虑注册表的隔离问题。和文件系统命名空间隔离一样,注册表命名空间隔离也采用类似Union FS形式。

下面让我们进入PowerShell命令创建的Windows容器文件夹内部。

C:\ProgramData\Microsoft\Windows\Hyper-V\Containers\926A300B-ACB7-4B28-9D86-45BF82C1211C\Hives

在这个Hives文件夹下方,有很多命名为*_Delta的文件,这是容器所访问的注册表配置单元文件。

从命名方式中可以看到,容器的注册表和文件系统一样,也采用分层架构,最上层的是可读写的注册表命名空间。而Image映像也有只读部分的注册表空间,路径如下。

C:\ProgramData\Microsoft\Windows\Images\CN=Microsoft_WindowsServerCore_10.0.10586.0\Hives

在Process Explorer里可以看到可读写层、只读层注册表合并后所加载的内容。

Docker命令所创建的容器,方法类似,位于类似以下路径:

Windows容器的资源限制

大家知道,Docker可以调用CGroup技术来限制Linux容器的CPU、内存等资源占用。而在Windows容器里,内存资源的限制,则是通过Windows的JO(作业对象)技术来实现。

可以参考以下技术来限定Windows容器的CPU、内存和磁盘IO。例如可以将容器的内存限定为最大占用为5GB。

https://msdn.microsoft.com/en-us/virtualization/windowscontainers/management/manage_resources?f=255&MSPPError=-2147217396

然后用Process Explorer打开任意一个容器进程的属性对话框,切换到Job标签页。

可以看到所有容器进程共享一个作业对象,而且该作业对象的内存限额(Job Memory Limit)为5GB。

作者简介

彭爱华网名盆盆,微软混合云技术顾问。11届微软最有价值专家(MVP),微软高级认证讲师。出版过近20本技术图书,2005年创建ITECN博客(09年全国IT博客五十强)。微信公众号(华来四笑侃Windows):sysinternal。曾获得微软技术大会TechEd最佳讲师、中国首届IT管理技术大会(2009)最佳讲师的光荣称号。

感谢陈兴璐对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们。

更多文章请点击http://go2live.cn