HPE CMS团队推进NFV容器化的探索之路

正文

请到「今天看啥」查看全文

Clearwater早先针对虚机部署的方式提供了ISO镜像文件，最近官方也开始尝试容器化改造，下一节我们来分享这方面的内容。

Clearwater On Docker

Clearwater官方于2016年初尝试容器化改造，对应的GitHub地址为：https://github.com/Metaswitch/clearwater-docker，但资料比较少，进度也缓慢，截止此文时间，Docker hub上还没有官方发布的Clearwater镜像，因此需要从官方提供的Dockerfile手工编译，Clearwater镜像总共包括9个镜像，总大小6个G。官方公布了Clearwater镜像在Docker中运行的方式，有以下几个关键点：

下图是Clearwater官方在Github上公开的一个Docker化部署结果，可以看到Clearwater容器化部署还是相对比较复杂的过程，因为总共有10个容器！

下面我们分析一下Clearwater的Docker镜像的结构和特点。

首先，Clearwater的10个镜像都继承自Base镜像。Base镜像采用了supervisord来管理容器内的多个进程服务，默认装载了Clearwater基础设施（infrastructure）服务，下面是对应的supervisord的配置描述：

[program:clearwater-infrastructure]
command=bash -c '/etc/init.d/clearwater-auto-config-docker start && /etc/init.d/clearwater-infrastructure start && /etc/init.d/clearwater-etcd start && /etc/init.d/clearwater-cluster-manager start && supervisorctl start clearwater-group:*'
startsecs=0

我们看到，Clearwater基础设施服务完成的工作包括以下几点：

1. 实现Clearwater的自动配置功能（Clearwater auto config），在/etc/init.d/clearwater-auto-config-docker的脚本文件控制着Clearwater参数文件的生成，每个Clearwater组件的服务都从这个参数文件中获取自己所需的启动参数。

2. 启动clearwater-infrastructure服务，提供了大部分Clearwater组件运行时所依赖的基础设施服务，比如解决了SNMP采集与监控告警，系统的TCP参数优化与安全通讯等问题。

3. 启动本地的Etcd服务代理进程， Clearwater组件查询本地的Etcd的服务，可以减轻Etcd服务的压力以及提升数据查询的响应时间。

下面是Base镜像的Dockerfile，基于ubuntu镜像，可以看到，安装的是最新稳定版的Clearwater组件，并且开启了SSH服务：

FROM ubuntu:14.04
MAINTAINER [email protected]
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y openssh-server supervisor curl
RUN mkdir -p /var/run/sshd /var/log/supervisor
RUN echo 'root:root' | chpasswd
RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
EXPOSE 22
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf"]
RUN locale-gen en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
COPY sysctl /sbin/sysctl
RUN sed -e 's/\#\(precedence ::ffff:0:0\/96  100\)/\1/g' -i /etc/gai.conf
RUN echo deb http://repo.cw-ngv.com/stable binary/ > /etc/apt/sources.list.d/clearwater.list
RUN curl -L http://repo.cw-ngv.com/repo_key | apt-key add -
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --force-yes clearwater-infrastructure clearwater-auto-config-docker clearwater-management
RUN /etc/init.d/clearwater-auto-config-docker restart
RUN /etc/init.d/clearwater-infrastructure restart
COPY clearwater-infrastructure.supervisord.conf /etc/supervisor/conf.d/clearwater-infrastructure.conf
COPY clearwater-group.supervisord.conf /etc/supervisor/conf.d/clearwater-group.conf

由于继承了Base镜像，所以Clearwater的其他镜像的Dockerfile比较简单，下面是Bono组件的Dockerfile文件内容：

FROM clearwater/base
MAINTAINER [email protected]
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --force-yes bono
RUN sed -e 's/\(echo 0 > \/proc\/sys\/kernel\/yama\/ptrace_scope\)/# \0/g' -i /etc/init.d/bono
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --force-yes restund
RUN sed -e 's/\(echo 0 > \/proc\/sys\/kernel\/yama\/ptrace_scope\)/# \0/g' -i /etc/init.d/restund
COPY bono.supervisord.conf /etc/supervisor/conf.d/bono.conf
COPY restund.supervisord.conf /etc/supervisor/conf.d/restund.conf
COPY clearwater-group.supervisord.conf /etc/supervisor/conf.d/clearwater-group.conf
EXPOSE 3478 3478/udp 5058 5060 5060/udp 5062

可以看出，Bono镜像在Base镜像之上，安装了bono以及restund这两个服务，其中bono服务默认在5060（TCP&UDP）端口以及5062（用于TLS加密）端口对外提供SIP服务， 而restund服务启动了一个STUN server，STUN的全称是Session Traversal Utilities for NAT，为了协助解决位于防火墙之后的SIP终端通讯问题，STUN在3478（TCP&UDP）端口提供服务。需要说明的是Clearwater本身并不提供TURN Server（媒体转发服务）。从Clearwater的GitHub上下载源码，按照官方说明文档进行操作，即可完成Clearwater的镜像打包，执行下面的Docker命令即可启动一套Clearwater的测试环境。

Clearwater On Kubernetes

首先，我们来看看为什么Clearwater on Kubernetes的方案更为重要，这是 因为Kubernetes作为当前最有影响力的容器化微服务架构平台，很多公司已经用它来实现自己的弹性PaaS平台 ，所以相对于Clearwater on Docker来说，Clearwater On Kubernetes显得比较更为重要；此外，Clearwater on Docker的部署方案，目前不好解决弹性扩容问题，因为Docker本身没有提供Kubernetes的Service概念，我们很难部署多个Bono（或Sprout）组件并让它们自动成为Clearwater集群的一部分，而 如果在Kubernetes平台上，我们则可以将Clearwater的各个组件定义成Kubernetes Service ，然后不同组件之间用Service的DNS名称进行通信，这样我们就可以借助Kubernetes的能力来实现Clearwater集群的弹性扩容操作了，在Kubernetes 1.4的平台上，除了可以实现手动扩容之外，还能借助于Kubernetes的Auto-Scale功能实现基于容器负载压力的自动扩容能力，无需人工参与，除此之外， Kubernetes平台强大的自动化与自我治愈能力也大大降低了人工运维Clearwater这种复杂系统的的难度 。但不幸的是，虽然官方已经给出 Clearwater在Docker上的部署方案，但Clearwater on Kubernetes的方案却一直没有结果，主要是官方维持的Clearwater Docker项目都还有不少问题迟迟得不到资源投入和修复，更没有精力去研究Clearwater On Kuberntes了，从github上的一些问题我们可以验证这一点：

请到「今天看啥」查看全文