三个生产环境中使用Docker的案例
|
像Kontena这样的平台,就像“预先准备完毕,做好开车的准备”,这让你可以把注意力集中在你的应用上,而不是在汽车的外壳上.其中包括你需要完成日常任务的大部分功能以及不同的焦点,比如Kontena专注于易用性和易于维护,其他服务可能会关注可伸缩性. Docker引擎如果你不想改变默认的设置,Jari强烈建议你使用一个专为容器做的发行版.一个不错的选择是Core OS,它叫做容器Linux；Red Hat有自己的原子发行平台；SUSE也有自己定制的容器配置.通常,这些类型的发行版会有更好的默认值,这些默认值实际上可能在生产环境中起作用. 您必须检查的一个关键问题是图形驱动程序,如果您使用的是最近的内核版本,您可以使用Overlay2.这是“今天的热门话题”,但随着下一个内核版本的发布,这种情况可能会有所改变.它是最快的选择,你不应该使用它来解决很多问题,大多数发行版都是Overlay1. 默认的Overlay有一些缺点,但是您仍然可以在生产环境中使用它.如果你使用的是Ubuntu那么你可能会切换到Aufs,当你为核安装了额外的软件包后,可以切换到它,它也可以和Overlay2一样工作. “最痛点”的部分是设备映射,Jari认为这仍然是来源于Red Hat且通常会引起痛点的地方.如果您知道如何配置设备映射的内部关系,那么可以使用设备映射器. Docker引擎有一个很酷的功能叫做“插件”.插件可以用来提供Overlay网络,并为引擎提供容量存储,但是有一个缺点：你不能在一个容器中运行这些插件,尽管他们说你可以,实际上你不能.所以尽量避免它. 从Docker版本1.13开始,插件架构 v0.2 被引入进来,它应该可以解决大部分的问题. CI/CD 管道在构建阶段,您不应该在自己的机器上构建或运行这些映像.相反,应该有一个CI系统来构建、测试并最终将它们部署到正确的环境中. 一些有用的建议：您应该将构建到测试,再到部署的所有内容(这不是容器特定的)放入脚本中.此外,拥有的配置和脚本都应该由版本控制管理.如果您没有这样做,那么在生产环境中运行时,就会遇到麻烦.最后,不要将关键信息放入配置文件中;这不是个好实践. 一些优秀的管道工具在这个管道示例中,我们构建自己的云服务时,senor开发人员正在尝试以类似于Kontena的方式使用管道.
开发人员正在打包下一件重要的事情,当他将变更推送到GitHub时,drone就会集成在那里,获取we hook,触发构建,在容器内的管道内运行测试.如果一切正常,它将把实际的Docker镜像推送到内部注册中心.最后,它将触发对Kontena的部署,取决于它是否是一个发布版本等等.通常情况下,它可能只需要几分钟的时间,就可以从Git-push部署到生产环境中.Kontena平台在此过程中充当中介,它将负责所有的滚动部署,并处理负载均衡器的配置.因此,您不需要手动地将每个部件组装起来. 安全在生产中使用容器的前几次,您可能会很高兴有一些在生产中运行的东西,您可能不会真正考虑安全性以及应该如何处理它.但是,应该从测试和预发环境中考虑这一点. 审计跟踪 安全补丁 值得推荐作为容器本地操作系统使用,例如,CoreOS将自动更新主机,并在更新完成时重新启动.您还可以使用配置管理工具,如Chef、Ansible或Puppet来处理安全补丁.您应该为镜像扫描服务投入一些时间,帮助识别您的Docker映像中的安全问题.例如,Docker Hub和CoreOS的Quay.io 均提供了这种功能. 一些平台提供网络安全功能(如Kontena做的).它们可能会加密主机之间或数据中心之间的所有通信.一些平台包括的额外安全措施包括:创建网络段、定义策略,以及作为最后的手段：配置防火墙. 为混乱做准备 混乱是生活的一个真实写照,包括宿主机故障,引擎故障,容器失败,应用程序崩溃.为“混乱可控”做好准备,意味着当事情发生的时候,这将不是什么大不了的事情. 在计划生产环境时,强烈建议您这样做,这样您就可以在任何时候“杀死”任何主机、任何节点,这样至少一个主机就可以被完全的暴力所强制,而其他服务一切都还正常.另一个建议是,如果您使用前面提到的任何一个平台,请信任调度程序,使用集群数据库,并尽可能将状态开放,以尽可能流畅的运行Docker. 关于 Kontena（编辑：上饶站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
