双重部署:在生产中运行容器的低风险方法

你们中有多少人在生产中运行容器?

自DockerCon 2014以来,我已经多次问过这个问题。在过去三年中,采用Docker一直很艰难,但是生产中的容器仍然被证明是一个挑战。 2015年12月, Robin Systems对来自不同行业的200名代表进行了调查 ,了解他们的容器采用情况。 在受访者中,有36%的人正在生产中使用容器,而59%的人计划采用,仍在调查中或只是在玩容器。

Demonware ,我们已经使用Docker超过两年了。 但是,我们仍然处在“计划采用,仍在研究中或只是在玩容器”的类别中。 为什么跳转到生产如此困难? 有没有办法以低风险,低成本的方式将容器按摩到生产中?

作为构建工程(BE)团队的成员,我曾与开发团队合作,对他们的持续集成(CI)管道进行Docker化。 当BE团队于2013年9月开始使用Docker时,我们几乎一致同意我们可以在构建,测试和开发环境中利用容器,而无需在生产中运行容器。 此后,我们的态度发生了变化。

容器化我们的CI管道,工具,构建基础结构和测试基础结构的好处是巨大的。 我们希望在生产中看到这些类似的好处。 那么阻止我们的是什么?

大多数障碍都不是技术性的。 在某些方面,人们仍然担心容器不是使用正确的技术。 我们希望继续前进,同时向有关各方保证我们正在以可控且低风险的方式这样做。

双重部署

该计划是要调整现有的连续交付(CD)管道,以使容器更接近生产,而不会对现有部署造成任何风险。 我们已经有许多不同的构建管道来构建服务包(RPM),服务容器(Docker)和Amazon Machine Images(AMI)。

我们结合了这些管道,以产生“双重部署” AMI工件。 该AMI工件是使用Packer创建的。 Packer是用于构建和配置任何类型映像的出色工具,并支持各种提供商和供应商。 Packer完全免费,并基于JSON格式模板提供可靠,可重复的图像。 可以在此处找到示例模板

{
  "variables": {
    "base_image": "change me with the '-var base_image=whatever' arg",
    "new_image": "change me with the '-var new_image=whatever' arg",
    "access_key": "change me with the '-var access_key=whatever' arg",
    "secret_key": "change me with the '-var secret_key=whatever' arg",
    "script": "change me with the '-var script=whatever' arg",
    "script_args": "change me with the '-var script_args=whatever' arg"
  },
  "builders": [{
    "type": "amazon-ebs",
    "region": "us-west-2",
    "vpc_id": "",
    "subnet_id": "",
    "instance_type": "t2.micro",
    "access_key": "{{user `access_key`}}",
    "secret_key": "{{user `secret_key`}}",
    "ssh_username": "centos",
    "ami_name": "{{user `new_image`}} {{timestamp}}",
    "source_ami": "{{user `base_image`}}",
    "ami_block_device_mappings": [
        {
          "device_name": "/dev/sda1",
          "volume_size": 30
        }
    ],
    "ssh_pty" : "true",
    
    "tags": {
      "project": "demo"
    },
    "run_tags":{
      "project": "demo"
    }
    }],
    "provisioners": [
    {
    "type": "shell",
    "execute_command":    "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}' {{user `script_args`}}",
    "scripts": "{{user `script`}}"
    },
    {
      "type": "shell",
      "inline": [
        "echo 'Rebooting for bootstrap changes to take effect.';sudo systemctl reboot"
      ]
    },
    {
      "type": "shell",
      "execute_command":    "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}'",
      "scripts": "install_service_rpm.sh"
    },
    {
      "type": "shell",
      "execute_command":    "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}'",
      "scripts": "build_service_container.sh"
    }
    ]

}

“双重部署” AMI构建包含两个部分。

  1. 启动EC2实例后,将安装,配置并准备好运行服务包(RPM)。
  2. 该服务容器基于与我们的服务包相同的来源,是在AMI构建阶段构建的。
好处

这使我们能够以通常的方式部署服务,还可以选择通过服务容器路由流量以进行测试。 这需要对AMI Packer模板进行一些细微调整,并将构建时间延长了几分钟。

这是通过背负现有CD管道使容器投入生产的低风险方法。 启动服务容器仍然是一项手动任务,我们目前使用它来测试容器。 启动容器时,我们使用--host docker run选项将流量路由通过服务容器。

让我们来看一下流程示例和适用于AWS的示例Packer模板的外观。

双重部署的示例

在此示例中,我们的服务安装在EC2实例(Centos 7)上,可以使用VM接口处理流量。 相同的代码已容器化,可用于使用主机(VM)接口处理流量。 目前,我们出于测试目的手动重定向流量。

使用Packer构建双重部署环境

Packer模板aws.json用于构建Amazon Machine Image。 该映像将被引导,我们的服务将作为RPM安装,并构建我们的服务容器。

bootstrap.sh可以根据需要简单或复杂。 我们使用它来安装一些辅助工具并安装Docker。

container.sh从GitHub container.sh提取服务容器代码,并在AMI构建中构建容器映像。 aws.json模板支持六个参数:

base_image : The AMI ID of the base image you want to build from.
    new_image  : The name of the new AMI you are building.
    access_key : AWS access key 
    secret_key : AWS secret key
    script     : The name of the script you want to run to bootstrap the base image.
    script_args: Pass in additional arguments to the script.

创建包含服务和服务容器的Primed Centos 7 AMI:

packer build -var 'base_image=ami-c7d092f7' -var 'new_image=CentOS-7-x86_64 (Demo)' -var 'script=bootstrap.sh' -var 'access_key=12345674345456454' -var 'secret_key=erewrwrw2424esfsfdfwrwerwe2423wer' -var 'script_args=' aws.centos.json

当build命令成功完成时,您将拥有一个AMI,其中安装了服务并构建了服务容器。

我们的CD管道已经支持AMI构建和基于RPM的服务安装了一段时间。 我们希望运行一个单一的容器化服务,同时尽可能不破坏现有管道。 通过调整Packer模板,我们有了一种简单,低风险的方法来将我们的容器化服务投入生产。

结论

目前,我们正在这些“双重部署”环境中测试我们的容器化服务。 消除了将容器投入生产的恐惧和污名。 我们对容器的部署有了更好的了解,并且我们正在搭载一个定义明确的CD管道。

这篇文章的目的不是解决在生产中部署容器的任何技术障碍。 它仅是提出一种使用现有过程以低风险方式将容器引入CD管道的方法。

因此第一步通常是最难的。 这种方法可能会提供一种使您的服务更接近于生产中的集装箱化未来的更简单的方法。

翻译自: https://www.javacodegeeks.com/2016/03/dual-deployment-low-risk-way-run-containers-production.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值