本文讲的是Docker Workflow(一):一个可用于生产环境的Docker工作流,
【编者的话】作者工作于墨西哥IIIEPE研究院,他将通过一系列文章,为我们逐一讲述他们在Docker实际应用过程中的经验与教训,给后来者提供一些参考。本文主要介绍了他基于Docker的开发工作流,包括GitLab、Jenkins、Registry、Nginx。
Docker现在已经两岁了(译者注:Docker于2013年3月13日首次发布), IIIEPE 已经在生产环境中使用Docker3个来月。在此,我分享一些我们的经验和设计的工作流。
我们运行着多个使用Drupal、PHP和Node.js的网站,我们的目标是使用Docker运行所有的应用,因此我们设计了以下工作流:
- 所有开发人员使用Docker来创建应用。
- 我们的GitLab实例配置了Webhook,当检测到一个新的推送时,它将命令Jenkins运行一个任务。
- 每个Jenkins任务都包含相同的布置:从GitLab中克隆最新代码,运行测试,登录到我们的私有Docker Registry,使用最新代码构建一个新的镜像,然后将镜像推送上去。
- 最后,我们的编排软件Maestro-NG将部署新版本的镜像。
- 我们的负载均衡器将检测这些变化,并重载新的配置。
每一个步骤都需要几天的规划、测试和工作来设计基本准则。
我们做的第一件事是构建满足自己要求的基础镜像。镜像发布到 Docker Hub 中,它们包含了除了应用本身之外所有用于运行应用的东西。每次修改其中一个基础镜像,我们就会运行一个Jenkins任务来拉取新镜像,并触发后续任务来重新构建依赖此基础镜像的所有镜像。
创建完镜像之后,我们需要为所有应用定义一个标准结构。我们所有的应用都使用以下结构来组织:
/application /logs /files Dockerfile fig.yml.example docker-compose.yml.example Makefile
/application 目录是应用的根目录。
/logs 和 /files 目录用于开发,以便应用可以写入日志和文件。这两个目录会被Git忽略,并在生产环境中完全排除。
Dockerfile 是Jenkins用于构建镜像的文件,开发人员几乎不需要接触这个文件,后面详述。
fig.yml.example 和 docker-compose-yml.example 是开发人员用于启动应用的文件。这二者均不用于生产环境,当开发人员克隆一个项目时,他需要复制这个example文件并填入他/她的值。
Makefile 是拼图的最后一块,通过它我们可以拥有一个标准的命令集用于所有应用,并对开发人员隐藏各种各样的复杂性。
Dockerfile
每个应用的Dockerfile与其它应用非常类似,这个文件的最重要工作就是构建包含所有待部署代码的最终镜像。我们来看一个例子:FROM iiiepe/nginx-drupal6 ENV MYSQL_ENV_MYSQL_DATABASE somedb ENV MYSQL_ENV_MYSQL_USER root ENV MYSQL_ENV_MYSQL_PASSWORD 123 ENV MYSQL_PORT_3306_TCP_ADDR localhost ENV MYSQL_PORT_3306_TCP_PORT 3306 ENV BASE_URL http://example.com ENV DRUPAL_ENVIRONMENT production EXPOSE 80 RUN usermod -u 1000 www-data RUN usermod -a -G users www-data ADD ./application /var/www RUN chown -R www-data:www-data /var/www
Dockerfile依赖于我们构建的基础镜像,在此之上,它只是设置了一些环境变量默认值、声明要暴露的端口,并将应用代码添加到
/var/www
。
正因为我们构建镜像的这种方式,在Jenkins和开发人员之间唯一的差别是,Jenkins将添加整个应用目录到
/var/www
中,而开发人员只是映射一下目录。
接下来这个是Docker Compose,他非常酷。
mysql: image: mysql:latest expose: - "3306" ports: - "3307:3306" environment: MYSQL_DATABASE: database MYSQL_USER: root MYSQL_PASSWORD: admin123 MYSQL_ROOT_PASSWORD: admin123 web: image: iiiepe/nginx-drupal6 volumes: - application:/var/www - logs:/var/log/supervisor - files:/var/www/sites/default/files ports: - "80:80" links: - mysql:mysql environment: BASE_URL: http://local.iiiepe.net DRUPAL_ENVIRONMENT: development
Docker Compose用此文件来初始化。在本例中,我们定义了一个应用,它包括两个容器:一个MySQL容器和一个Web容器。
MySQL容器定义了mysql镜像要使用的环境变量。同时将宿主的3307端口映射到窗口的3306端口上。这允许我们使用任何客户端访问MySQL服务器。
web容器使用了与Jenkins构建最终镜像时使用的相同镜像(见上述Dockerfile),但它同时共享了一些数据卷。在宿主和容器间共享的卷有应用、文件和日志。这实际是开发环境和生产环境间最大的改变:在生产环境中,容器的代码是在镜像中的,这允许我们在任何服务器上启动容器;而在开发环境中,目录只是共享的,因此在应用目录里,任何新的文件或对文件的修改都将即时地反映到容器里。
BASE_URL变量指向了 http://local.iiiepe.net ,这不是个真实的地址,只是用于标准化应用访问的一个方式。因为我们有些人使用Mac和Boot2Docker,我们需要一个标准的地址以便所有人可以将其写入到/etc/hosts文件中。
我的Mac上的/etc/hosts是这样的:
127.0.0.1 localhost 192.168.59.103 local.iiiepe.net
在一台Linux机器上,看起来是这样的:
127.0.0.1 localhost local.iiiepe.net
最后,我们定义了两个环境变量来决定应用的配置文件的一些设置。
自定义设置
Drupal需要一个settings.php来存储数据库信息,包括密码。该文件将被Git忽略,以免将你的密码提交上去,我们决定修改这个文件,让它使用环境变量并将其提交。以下是一个Drupal 6网站的settings.php里的重要部分:
$username = getenv("MYSQL_ENV_MYSQL_USER"); $password = getenv("MYSQL_ENV_MYSQL_PASSWORD"); $host = getenv("MYSQL_PORT_3306_TCP_ADDR"); $port = getenv("MYSQL_PORT_3306_TCP_PORT"); $database = getenv("MYSQL_ENV_MYSQL_DATABASE"); $db_url = 'mysql://' . $username . ':' . $password . '@' . $host . '/' . $database;
正如你所看到的,没有密码会被提交。密码和其它敏感值将通过ENV变量注入。
有些网站使用Apache Solr作为搜索引擎,但在开发时,我们不希望能写入到Apache Solr,因此需要一个类似DRUPAL_ENVIRONMENT的ENV变量,完成类似下面的settings.php文件的事情:
$conf = array(); if(getenv("DRUPAL_ENVIRONMENT") === "development") { // Disable apache solr writting $conf["apachesolr_read_only"] = 1; }
Makefile
由于命令很长,使用Docker非常不便,因此Docker Compose(fig)对此很有帮助。我们更进一步尝试让事情变得更简单一些。这是我们使用在一个Drupal网站上的Makefile:
CURRENT_DIRECTORY := $(shell pwd) start: @fig up -d clean: @fig rm --force stop: @fig stop status: @fig ps cli: @fig run --rm web bash log: @tail -f logs/nginx-error.log cc: @fig run --rm web drush cc all restart: @fig stop web @fig start web @tail -f logs/nginx-error.log .PHONY: clean start stop status cli log cc restart
使用Makefile比使用Docker Compose或Fig简单得多,因为我们可以创建类似
make cc
的快捷方式来运行类似
drush cc all
这样频繁使用的命令。
有关Makefile的最后一点说明是:我们依然使用Fig。因为在我们设计这个工作流时,Docker Compose还不可用,而且我们团队里的一些开发人员还在使用它,我们决定为Docker Compose建立名为Fig的符号连接,名称更短且更实用。安装Docker Compose后,你可以删除fig并创建符号连接:
sudo rm /usr/local/bin/fig sudo ln -s /usr/local/bin/docker-compose /usr/local/bin/fig
走的弯路
我们走过一些弯路,我将在别的文章中做介绍,不过有一个我想特别说一下。使用Docker最大的好处是,开发人员可以在与生产环境相同的环境上运行应用,且只损失一点点性能。我看过一些文章,说他们在Docker之外做开发,然后在需要部署时构建镜像并发送到生产环境。如果你这么做,那你就错了,因为你开发所用的环境与生产机上运行的不一致。不要每次都构建镜像,相反的,在宿主和容器间共享卷,让别人在你每次推送时构建镜像。
未完待续……
文章还远未结束,不过它已经太长了。我们依然需要说明我们是如何整合Maestro-NG、配置Jenkins以及负载均衡器是如何工作的。咱们回见!
原文链接:A production ready Docker workflow(翻译:梁晓勇 校对:李颖杰)
原文发布时间为:2015-03-26
本文作者:sean
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:Docker Workflow(一):一个可用于生产环境的Docker工作流