老司机实战Windows Server Docker:3 单节点Windows Docker服务器简单运维(上)

经过上两篇实战Windows Server Docker系列文章,大家对安装Windows Docker服务以及如何打包现有IIS应用为docker镜像已经有了基本认识。接下来我们来简单讲讲一些最基本的运维问题。鉴于到目前为止我们只谈到单服务器部署。这里暂时不涉及集群模式下的复杂生产环境运维。

本主题将涵盖下面这些主要内容,由于这个主题包含的内容较多,将分成上下两篇发布:

上篇

  • 远程操作Windows Docker服务器
  • 自动化Docker编译和部署
  • Windows Docker网络配置和端口映射

下篇

  • 负载均衡和反向代理
  • 日志解析和监控

远程操作Windows Docker服务器

和Linux下的Docker服务默认通过TCP 2375/2376端口执行docker命令不同,Windows Docker服务默认只支持本机基于命名管道来执行docker命令。如果安装完Windows Docker服务后,在命令窗口执行netstat -an,可以看到,服务器并不监听2375或者2376这样的端口。当然,我们可以通过修改daemon.json这个配置文件(关于如何修改daemon.json文件,请参考本系列的第一篇),来开启2375/2376端口。2375端口和linux下的2375端口一样,用于非TLS的远程连接;而2376则支持基于证书的安全连接。对于,开发测试环境,一般开启2375端口就行,而对于生产环境,则应该使用2376端口,基于TLS安全连接来远程管理Docker服务器。

要开启2375端口,只需要如下在daemon.json添加hosts配置项,然后重启Docker服务:

{
    "hosts": ["tcp://0.0.0.0:2375"]
}

要开启2376端口也类似,就是稍微复杂一点,需要生成和配置证书,具体的可以参考微软的这篇官方文档这里就不详述了。

开启2375端口之后,可以通过在命令窗口执行如下的netstat命令,确保2375端口已经正确监听:

netstat -an | findstr 2375

如果返回类似下面,就说明已经在监听了:

  TCP    0.0.0.0:2375           0.0.0.0:0              LISTENING
  TCP    [::]:2375              [::]:0                 LISTENING

只是开始监听还不够,要允许外部机器能够远程访问本机的2375端口,我们还要添加防火墙的Inbound规则,可以通过下面的powershell命令开启:

New-NetFirewallRule -DisplayName 'Docker TCP Inbound' -Profile @('Domain', 'Public', 'Private') -Direction Inbound -Action Allow -Protocol TCP -LocalPort 2375

接下来,我们就可以尝试从安装了Docker client的远程机器,访问这台Windows Docker服务器了。Docker client有各种跨平台版本,所以只要是相兼容的版本,我既可以从Windows的docker client,也可以从linux的docker client通过2375端口远程访问docker服务器。

当我们从当前机器,比如你的开发机访问一台远程docker服务器时,我们需要为docker client指定目标HOST。一般有两种方式:一种是可以通过在每个docker命令执行时,添加-H server_name_or_ip参数,另一种是设置DOCKER_HOST环境变量,这样,就不需要每个docker命令都带-H参数了。例如,下面的命令会列出远程服务器1.2.3.4的所有docker images:

docker -H 1.2.3.4 images
docker -H tcp://1.2.3.4 images
docker -H tcp://1.2.3.4:2375 images

上面的几种指定host的语法都是可以的,如果使用默认的2375端口,最简单的就可以用第一种,少打不少字符。如果要指定DOCKER_HOST环境变量,那么必须使用完整的格式,比如:

SET DOCKER_HOST=tcp://1.2.3.4:2375

开启远程访问之后,当需要从开发或者编译环境编译和发布docker镜像时,我们就不需要像上一篇中那么蛋疼的先copy发布出来的应用网站文件到docker服务器,然后在服务器上执行docker build了,只需要直接从开发环境执行docker build,就能直接在远程docker服务器上生成和运行docker镜像了。

自动化Docker编译和部署

docker的命令行工具,有许多子命令和参数。如果要经常编译和运行docker镜像,我们当然不希望每次都手打所有参数,例如,下面的命令编译一个docker镜像,并运行一个docker容器,每次手打一边实在没啥乐趣:

docker build -t iis-demo:1.0 .
docker run --ip 172.24.128.2 -p 80 -v "c:/temp:c:/inetpub/logs/LogFiles" -e "env1=LIVE1" -e "env2=LIVE2" -e "HOSTS=1.2.3.4:TEST.COM" iis-demo:1.0

为了简化这个过程,通常我们会写一些带参数的powershell脚本;或者,我们可以使用另一个docker的必备命令行工具:docker-compose

docker-compose是一个docker官方发布的docker容器编排工具,用于通过yml格式的配置文件来简化docker命令的执行。例如,上面这两个编译并运行docker容器的脚本,如果我们定义如下这个docker-compose.yml配置文件:

version: "2.1"
services:
  iis-demo:
    build: .
    image: "iis-demo:1.0"
    ports:
    - "80"
    networks:
      nat:
        ipv4_address: 172.24.128.2
    volumes:
    - "c:/temp:c:/inetpub/logs/LogFiles"
    environment:
    - "env1=LIVE1"
    - "env2=LIVE2"
    - "HOSTS=1.2.3.4:TEST.COM"
networks:
  nat:
    external: true

那么,我们就可以在docker-compose.yml所在的目录,通过下面这一条命令,就能自动编译docker镜像,并且运行一个docker容器了:

docker-compose up

是不是超级简单?事实上,docker-compose几乎包装了所有通过docker命令行可以执行的参数,而且,一个docker-compose.yml文件,可以包含多个相关的docker镜像的配置,比如,你的这个应用可能依赖于某一个DB,或者另一个应用的,那么,写在一个yml文件里,就能很方便的一键编译,一键发布,一键关闭这些相关容器。限于篇幅,本文就不细说docker-compose各种功能了,大家可以参看官方文档和示例自行摸索。

这里简单讲一下,在windows下,如何安装docker-compose。

  • 首先,docker-compose是一个客户端工具,也就是,它应该安装于安装了docker client的机器,并不需要安装于docker服务器;
  • 对Windows版本的docker-compose来说,它就是一个单个文件的.exe文件,你只需要从官网下载Windows版本的.exe文件,将文件名改成docker-compose.exe,然后随便放到任何方便访问的目录就可以了。我比较懒,一般直接丢到c:\windows\system32目录,那样就不需要设置额外的PATH路径,就能在任何当前目录下,在命令窗口直接执行了。

有了,docker-compose,我们也可以很简单的设置我们的docker服务器每次机器启动之后,自动运行指定的docker容器,只需要配置一个机器的启动脚本,每次机器启动后自动运行docker-compose up,就可以了。

有人可能想问,如何为windows设置自动启动脚本?一个简单的方法是,使用NSSM这个小工具。例如,下载nssm的exe到本地后,只需要在命令行执行:

nssm install "Docker Startup" command param1 param2 ...

就能将指定的命令变成自动开机执行的windows service了。是不是很方便?网上介绍NSSM也文章也很多的,大家可以搜索一些,这里我就给几个link,不过多介绍了:

Windows Docker网络配置和端口映射

微软官方,主要就这一篇文档介绍了windows容器的网络设置。介绍得其实并不是很深入。主要来说,它介绍了Windows Docker支持的几种网络模式,例如:nat、transparent、overlay、l2bridge。其中,最常用的,大家最容易理解的,也是Windows Docker服务安装后的默认模式是nat模式。简单的说,就是:

  • 宿主机上运行的所有的容器,都属于一个子网段,每个容器运行时,可以静态指定网段内可用的ip,或者自动分配一个网段内的ip;
  • 子网段内的ip,在宿主机外部无法直接访问,只能从宿主机上直接访问;
  • 可以通过docker命令的-p参数,设置静态或者动态的宿主机ip到容器ip的端口映射,这样宿主机的外部网络,就可以通过宿主机的ip和端口,间接访问到容器内的网站了;

例如,在上面的示例中的docker run --ip 172.24.128.2 -p 80 ...里,-p 80这个参数就会导致docker命令执行时,动态分配一个宿主机上的端口,映射到容器ip的80端口上。如果我们执行上面的docker run命令,或者docker-compose up命令后,在命令窗口执行docker ps,可以看到下面的正在运行的容器:

0f0e07424d80        iis-demo:latest     "C:\\SetHostsAndSta..."   5 minutes ago       Up 4 minutes        0.0.0.0:39924->80/tcp        windowsdockeriisdemo_iis-demo_1

其中,0.0.0.0:39924就是指的,对宿主机上任意ip的39924端口的访问,已经被映射到这个容器的子网ip的80端口了。

但是,这里有个坑,很深的坑,让我一度差点怀疑人生,甚至重装了机器的坑!!!——如果你在宿主机上的浏览器里,访问比如http://localhost:39924/iis-demo,按这个端口映射,你天真的以为就能访问到容器内的网站,尤其示玩过linux下容器的小伙伴,更绝对会认为它能访问。但是,它其实不能!!什么原因呢?我为此一度差点崩溃,最后,在某个windows docker的github issuer中,有开发人员解释说,这个是因为windows版本的实现问题,在宿主机本机,这个映射的端口无法访问,但是,在宿主机外部,访问宿主机上的ip加这个端口是可以访问的!!只允许从外部访问!!WTF?这是什么鬼的道理?不过,反正,现状就是如此,也只能忍了。

除了使用动态分配的端口,如果我们把参数改成例如-p 80:80,那么就能通过宿主机的ip:80端口,访问到容器内的网站了。再提醒一遍,记住,只能从宿主机外部访问!!

微软的官方文档,除了介绍了几种常见的网络模式如何配置,还提到了一些Windows版本的Docker相对于linux版本的docker没有实现的功能,下面的这些docker命令的参数,对Windows Docker无效:

  • --add-host
  • --dns-opt
  • --dns-search
  • --aux-address
  • --internal
  • --ip-range

其中,最遗憾的就是--add-host参数没有实现。--add-host参数原本是用于为容器内的系统的hosts文件添加静态dns解析的,这是一个非常常用的功能,没有它,部署到容器内的应用可能无法解析某些服务器名称或者域名。当然,我们可以自己实现类似功能,例如,在上一篇 docker化现有iis应用中,我们就实现了一个通过环境变量,传入,并设置hosts的简单功能,从而避免了这个参数没实现带来的痛点。

上篇完

下篇 4 单节点Windows Docker服务器简单运维(下)

posted @ 2017-03-23 00:06 Teddy's Knowledge Base Views(...) Comments(...) Edit 收藏