Docker容器云平台
1、硬件资源利用率的问题，造成部分成本的浪费
在网站功能中不同的业务场景有计算型的，有IO读写型的，有网络型，有内存型的，集中部署应用就会导致资源利用率不合理的问题。比如，一个机器上部署的服务都是内存密集型，那么CPU资源就都很容易浪费了。
2、单物理机多应用无法进行有效的隔离，导致应用对资源的抢占和相互影响
一个物理机器跑多个应用，无法进行所使用的CPU，内存，进程进行限制，如果一个应用出现对资源的抢占问题，就会引起连锁反应，最终导致网站部分功能不可用。
3、环境、版本管理复杂，上线部署流程缺乏，增加问题排查的复杂度
由于内部开发流程的不规范，代码在测试或者上线过程中，对一些配置项和系统参数进行随意的调整，在发布时进行增量发布，一旦出现问题，就会导致测试的代码和线上运行的代码是不一致的，增加了服务上线的风险，也增加了线上服务故障排查的难度。
4、环境不稳定，迁移成本高，增加上线风险
在开发过程中存在多个项目并行开发和服务的依赖问题，由于环境和版本的复杂性很高，不能快速搭建和迁移一个环境，导致无法在测试环境中无法模拟出线上的流程进行测试，很多同学在线上环境进行测试，这里有很高的潜在风险，同时导致开发效率降低。
5、传统虚拟机和物理机占用空间大，启动慢，管理复杂等问题
传统虚拟机和物理机在启动过程进行加载内核，执行内核和init进行，导致在启动过程占用很长时间，而且在管理过程中会遇到各种各样的管理问题。
由于后端开发基于阿里的HSF框架，生产者和消费者之间需要网络可达，对网络要求比较高，需要以真实IP地址进行注册和拉取服务。所以在选择容器网络时，我们使用了Host模式，在容器启动过程中会执行脚本检查宿主机并分配给容器一个独立的端口，来避免冲突的问题。
持续集成
监测代码提交状态，对代码进行持续集成，在集成过程中执行单元测试，代码Sonar和安全工具进行静态扫描，将结果通知给开发同学同时部署集成环境，部署成功后触发自动化测试（自动化测试部分后续会更新)
持续部署
是一种能力，这种能力非常重要，把一个包快速部署在你想要的地方。平台采用分布式构建、部署，master管理多个slave节点，每个slave节点分属不同的环境。在master上安装并更新插件、创建job、管理各开发团队权限。slave用于执行job。
基于上述架构，我们定义了持续部署规范的流程：
（1）开发同学向gitlab提交代码；
（2）拉取项目代码和配置项文件，执行编译任务；
（3）拉取基础镜像，将编译好的应用包打入生成最新的应用镜像，推送到镜像仓库；
（4）根据当前应用及所属环境定制化生成docker-compose.yml文件，基于这个文件执行rancher-compose命令，将应用镜像部署到预发环境（发布生产前的测试环境，相关配置、服务依赖关系和生产环境一致）。
（5）预发环境测试通过后将应用镜像部署至线上环境，测试结果通知后端测试同学。
监控管理
通过zabbix 自动注册（AutoRegistration），Grafana通过调用zabbix的API接口进行监控指标的统一展示。
日志管理
容器在运行时会在只读层之上创建读写层，所有对应用程序的写操作都在这层进行。当容器重启后，读写层中的数据（包含日志）也会一并被清除。虽然可以通过将容器中日志目录挂载到宿主机解决此类问题，但当容器在多个宿主机间频繁漂移时，每个宿主机上都会有留存应用名的部分日志，增加了开发同学查看、排查问题的难度。
#docker# #rancher#
追加内容
2018-01-29 16:07:01
在最好的时候创建用户喜欢的高质量应用程序并不是件容易的事情。更何况，要怎样做才能更快地创建用户喜欢的高质量应用程序并且能够不断改进它们呢？这就是需要引入持续集成和持续交付（CI / CD）的地方。
持续集成（CI）
什么是持续集成？
那么，持续集成（CI）究竟是什么呢？它是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。
持续集成有什么好处？
我们不能低估CI的好处。因为团队里的人都在同一个产品上进行实时工作，所以在软件开发过程中使用CI时，你可以期望实现更快的速度、更好的稳定性和更强的可靠性。并且在开发过程的早期，开发人员能够发现和解决任何编码问题，使它们在成为下游主要问题之前得到纠正。这样可以降低错误代码导致的长期开发（和业务）的成本。
持续集成对于QA测试花费的时间也有很大的影响。通过CI，开发人员不断审查和编辑以前的代码，能够检查到许多小的错误，这些错误在QA里通常发现的晚一些。这使得测试人员不仅可以专注研究代码和关注更加紧迫的问题，而且能够同时测试更多的场景。
对开发团队来说，使用CI的另一个好处是可以提高编码能力。由于持续发展的自然灵活性，这使得开发人员能够快速、轻松地对代码进行更改，却不会产生运行回归风险。
持续交付（CD）
什么是持续交付？
持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。
持续交付有什么好处？
实施持续交付的主要好处是能够加快应用程序的上市时间。使用CD的公司能大大增加他们的应用程序发行频率。在没有使用CD之前，应用程序发布的频率通常是几个月一次。然而现在使用CD，你可以一个星期发布一次、甚至每天发布多次应用。在竞争激烈的行业中，速度的提高将会使你处于主要优势。
持续不断的软件版本发布也会根据用户对应用程序的反馈，允许开发团队对其进行微调。这个用户反馈为开发人员提供了所需要的洞察力，并且它优先考虑了用户实际需要的功能请求。同样重要的是，对用户实际上没有用到的应用程序功能，它允许开发人员对其进行优先级排序。
CD的另一个好处是它能保证每个发行版本的风险较低。当使用CD方法发布时，开发团队也会更有信心，因为在整个开发生命周期中，所有内容都经过了多次测试。
任何不考虑转向CI / CD的公司都或将被那些使用CI / CD方法的竞争对手远远地甩在后面。那么，如何转向CI / CD？当您准备转向持续集成／持续交付（CI / CD）时，需要考量及决定的相关流程有很多。下文将带您了解这些主要流程。
转向CI/CD的重要流程
1、分支和合并
你需要组织及考虑的一个主要流程就是你的分支和合并。分支就是开发人员可以在代码的平行部分工作的地方——从一个中央代码库分支出来。分支的好处在于，它允许在不破坏中心代码基础的情况下，在软件构建的不同方面同时进行工作。显然，合并即意味着分支合并到核心代码库。
通过各种版本控制系统，许多开发人员对分支和合并已经很熟悉了。然而，根据您的构建的特别要求，您所分支的内容也有很多不同的策略。有些开发人员将通过维护、功能或团队来进行发布的分支。
您可能会对某种策略非常狂热，但“绝对正确”的分支和合并策略是不存在的，只存在“对您的构建而言正确”的方式与策略。这需要检查您当前的分支和合并策略，并根据您的目标和情况决定需要更改哪些内容。
2、构建自动化
构建自动化意味着您可以自动编译软件构建。持续集成服务器的核心是构建自动化服务器，其工作是在触发或定时的基础上编译和链接源代码。您选择的持续集成服务器将成为您的CI/CD环境的支柱。
在查看构建自动化过程时，了解市场上各种可用选项的功能是非常有帮助的。开源公司Jenkins现在在CI/CD部署中占绝对优势，这通常是一个好的开始。或者至少，在比较其他解决方案时把它作为基准。作为一个开源代码系统，您可能仍需构建一些实用程序,以使构建自动化完全适合您的情况。
3、测试自动化
测试自动化对于CI/CD能否按预期工作至关重要。如果没有自动化测试，CI/CD将很快无法实现快速交付的目标。我们的总体建议是尽可能自动化。这意味着您需要检查您需要执行的各种测试，并决定在您的环境中可以安全地自动进行哪些测试。
建立测试自动化环境可能需要新的技能。然而，这是战略需求，将会提高交付速度，减少错误。至少，您应该自动化代码审查、单元测试、集成测试和系统测试。
4、部署自动化
关于持续交付和持续部署之间的区别，仍然存在一些混淆。简而言之，持续交付意味着持续推出发布就绪代码，而持续部署则意味着持续给用户部署该软件。
无论你在看什么“CD”，对那些不习惯的人来说，这似乎是一个巨大的飞跃。为了让您的组织有信心将软件部署到最终用户，需要一个严密的测试自动化基础设施。
我们的建议是，最好进入流程定义，以实现零接触持续部署的总体目标。虽然领先的持续集成系统通常会考虑自己的持续交付系统，但您可以比现成的参数更进一步。真正的敏捷性需要构建一个基础设施、写好代码，吸引用户使用。
选择开源且完整的CI/CD的工具
真正实现CI／CD并非易事，pipeline搭建工作复杂，平滑升级难以保障，服务宕机难以避免……选择一个完整的CI/CD工具，将大大助力于CI/CD在企业里落地并最终带来生产运维效率的提升。Rancher Labs新近发布的CI/CD工具Rancher Pipeline，就拥有极简的操作体验，强大的功能整合，并且完全开源。
同时支持多源码管理：在单一环境中同时拉取、使用和管理托管在GitHub和GitLab的代码；
一键部署，完全可视化的pipeline配置，拖拽方式的pipeline搭建；
阶段式和阶梯式pipeline，可自由扩展的步骤系统；
灵活的流程控制：不同的代码分支可以自动匹配不同的CI流程，从而支持较为复杂的流程控制
支持多种触发方式：计划任务的触发、来自GitHub / GitLab的webhook触发、手动触发，以及通过定制化的开发，实现更多种触发方式的支持
良好集成的审批系统：审批系统已与Rancher用户管理系统集成，且用户可以在任意阶段插入断点，自由地对任意阶段进行审批
灵活的pipeline启停机制：任一环节出错，整个进度可以立即停止，而问题解决之后又可以重新运行
持续集成（CI）
什么是持续集成？
那么，持续集成（CI）究竟是什么呢？它是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。
持续集成有什么好处？
我们不能低估CI的好处。因为团队里的人都在同一个产品上进行实时工作，所以在软件开发过程中使用CI时，你可以期望实现更快的速度、更好的稳定性和更强的可靠性。并且在开发过程的早期，开发人员能够发现和解决任何编码问题，使它们在成为下游主要问题之前得到纠正。这样可以降低错误代码导致的长期开发（和业务）的成本。
持续集成对于QA测试花费的时间也有很大的影响。通过CI，开发人员不断审查和编辑以前的代码，能够检查到许多小的错误，这些错误在QA里通常发现的晚一些。这使得测试人员不仅可以专注研究代码和关注更加紧迫的问题，而且能够同时测试更多的场景。
对开发团队来说，使用CI的另一个好处是可以提高编码能力。由于持续发展的自然灵活性，这使得开发人员能够快速、轻松地对代码进行更改，却不会产生运行回归风险。
持续交付（CD）
什么是持续交付？
持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。
持续交付有什么好处？
实施持续交付的主要好处是能够加快应用程序的上市时间。使用CD的公司能大大增加他们的应用程序发行频率。在没有使用CD之前，应用程序发布的频率通常是几个月一次。然而现在使用CD，你可以一个星期发布一次、甚至每天发布多次应用。在竞争激烈的行业中，速度的提高将会使你处于主要优势。
持续不断的软件版本发布也会根据用户对应用程序的反馈，允许开发团队对其进行微调。这个用户反馈为开发人员提供了所需要的洞察力，并且它优先考虑了用户实际需要的功能请求。同样重要的是，对用户实际上没有用到的应用程序功能，它允许开发人员对其进行优先级排序。
CD的另一个好处是它能保证每个发行版本的风险较低。当使用CD方法发布时，开发团队也会更有信心，因为在整个开发生命周期中，所有内容都经过了多次测试。
任何不考虑转向CI / CD的公司都或将被那些使用CI / CD方法的竞争对手远远地甩在后面。那么，如何转向CI / CD？当您准备转向持续集成／持续交付（CI / CD）时，需要考量及决定的相关流程有很多。下文将带您了解这些主要流程。
转向CI/CD的重要流程
1、分支和合并
你需要组织及考虑的一个主要流程就是你的分支和合并。分支就是开发人员可以在代码的平行部分工作的地方——从一个中央代码库分支出来。分支的好处在于，它允许在不破坏中心代码基础的情况下，在软件构建的不同方面同时进行工作。显然，合并即意味着分支合并到核心代码库。
通过各种版本控制系统，许多开发人员对分支和合并已经很熟悉了。然而，根据您的构建的特别要求，您所分支的内容也有很多不同的策略。有些开发人员将通过维护、功能或团队来进行发布的分支。
您可能会对某种策略非常狂热，但“绝对正确”的分支和合并策略是不存在的，只存在“对您的构建而言正确”的方式与策略。这需要检查您当前的分支和合并策略，并根据您的目标和情况决定需要更改哪些内容。
2、构建自动化
构建自动化意味着您可以自动编译软件构建。持续集成服务器的核心是构建自动化服务器，其工作是在触发或定时的基础上编译和链接源代码。您选择的持续集成服务器将成为您的CI/CD环境的支柱。
在查看构建自动化过程时，了解市场上各种可用选项的功能是非常有帮助的。开源公司Jenkins现在在CI/CD部署中占绝对优势，这通常是一个好的开始。或者至少，在比较其他解决方案时把它作为基准。作为一个开源代码系统，您可能仍需构建一些实用程序,以使构建自动化完全适合您的情况。
3、测试自动化
测试自动化对于CI/CD能否按预期工作至关重要。如果没有自动化测试，CI/CD将很快无法实现快速交付的目标。我们的总体建议是尽可能自动化。这意味着您需要检查您需要执行的各种测试，并决定在您的环境中可以安全地自动进行哪些测试。
建立测试自动化环境可能需要新的技能。然而，这是战略需求，将会提高交付速度，减少错误。至少，您应该自动化代码审查、单元测试、集成测试和系统测试。
4、部署自动化
关于持续交付和持续部署之间的区别，仍然存在一些混淆。简而言之，持续交付意味着持续推出发布就绪代码，而持续部署则意味着持续给用户部署该软件。
无论你在看什么“CD”，对那些不习惯的人来说，这似乎是一个巨大的飞跃。为了让您的组织有信心将软件部署到最终用户，需要一个严密的测试自动化基础设施。
我们的建议是，最好进入流程定义，以实现零接触持续部署的总体目标。虽然领先的持续集成系统通常会考虑自己的持续交付系统，但您可以比现成的参数更进一步。真正的敏捷性需要构建一个基础设施、写好代码，吸引用户使用。
选择开源且完整的CI/CD的工具
真正实现CI／CD并非易事，pipeline搭建工作复杂，平滑升级难以保障，服务宕机难以避免……选择一个完整的CI/CD工具，将大大助力于CI/CD在企业里落地并最终带来生产运维效率的提升。Rancher Labs新近发布的CI/CD工具Rancher Pipeline，就拥有极简的操作体验，强大的功能整合，并且完全开源。
同时支持多源码管理：在单一环境中同时拉取、使用和管理托管在GitHub和GitLab的代码；
一键部署，完全可视化的pipeline配置，拖拽方式的pipeline搭建；
阶段式和阶梯式pipeline，可自由扩展的步骤系统；
灵活的流程控制：不同的代码分支可以自动匹配不同的CI流程，从而支持较为复杂的流程控制
支持多种触发方式：计划任务的触发、来自GitHub / GitLab的webhook触发、手动触发，以及通过定制化的开发，实现更多种触发方式的支持
良好集成的审批系统：审批系统已与Rancher用户管理系统集成，且用户可以在任意阶段插入断点，自由地对任意阶段进行审批
灵活的pipeline启停机制：任一环节出错，整个进度可以立即停止，而问题解决之后又可以重新运行
评论（1）
-
2018-01-29 15:14:04 回复
评论请先登录
最近热帖
- 基于 Harbor 搭建 Docker 私有镜像仓库 710704
- PPS代理节点池 272244
- PPS代理节点池② 181574
- PPS代理节点池③ 149595
- 订阅池记录 128332
- V2ray免费账号 12126
- WEB代理地址 3524
- 全栈开发笔记 3097
- GITHUB项目 2342
- 百度的无刷新搜索之PJAX 2285