Linux系统 2023-07-27

Linux上CI的部署方式，解锁高效持续交付能力 (linux 部署ci)

随着软件开发的迅速发展，持续集成（Continuous Integration，CI）的概念越来越被广泛接受并应用于软件开发过程中。在Linux上部署CI，可以帮助开发者自动化构建、测试、部署和发布软件，进一步提高软件开发的效率和效果。在本文中，我们将介绍一些关于Linux上CI的部署方式，并探讨如何通过CI来解锁高效持续交付能力。

一、Linux上CI的部署方式

1.使用持续集成工具

持续集成工具是一种自动化集成开发的工具，可以通过将源代码合并到同一个代码库中，然后进行构建和测试，检查集成错误，使开发者可以更轻松地在多个平台上测试和部署代码。

目前，更流行的CI工具包括Jenkins、GitLab CI、Travis CI等。这些工具可以在Linux服务器上轻松地进行部署，提供了一个方便的流程来集成开发者的代码。

2.使用容器化技术

容器化技术一直是构建、测试和部署软件的热门解决方案。它可以使软件在不同环境下运行，无需依赖本地环境。

Docker是目前容器化技术中更受欢迎的解决方案之一。它可以在Linux服务器上运行，并且支持多种操作系统和编程语言。通过使用Docker，开发者可以轻松构建、测试和部署应用程序，同时简化了软件开发的流程和配置管理。

3.集成版本控制

版本控制使开发者能够在开发过程中更轻松地跟踪更改，并与其他开发者协作。集成版本控制（如Git）可以使开发者在不同的环境中工作，并确保所有的变更都被记录下来。

集成版本控制工具可以与CI工具配合使用，实现代码持续构建、测试和部署。GitLab是一个带有集成CI/CD functions的开源版本控制系统，可以将所有的开发过程集成到一个平台上，提供了一种自动化的CI解决方案。

4.自动化流程

自动化流程可以帮助开发者加快软件开发过程中的测试、构建和部署，尤其是在代码量庞大或需要频繁更新时，手动处理这些任务可能非常耗时，自动化流程可以借助CI工具完成这些任务，较大程度地减少人力、时间和成本。

当然，自动化流程不仅仅是指CI工具，还可以包括脚本编写、自动化测试等，这些工具都可以实现自动化流程，帮助开发者更快地部署和发布软件。

二、解锁高效持续交付能力

CI对于软件开发来说，不仅仅是自动化构建、测试和部署，更是一种思维方式和一种实践流程。通过CI实践，可以帮助开发者实现数字化转型，以更高效的方式构建和发布软件。

下面是解锁高效持续交付能力的一些重要点：

1.确保可靠的构建和测试

持续集成和持续交付是一种测试和部署软件的方法，它可以确保软件的质量和相互兼容性，并使其更容易部署、更容易运行、更容易维护。为了确保构建和测试的可靠性，在CI过程中，需要实现自动化成套的测试，并确保每个修改都经过测试，以提高软件的质量和可靠性。

2.加速部署速度

CI可以将软件开发过程中的构建、测试和部署自动化，并加速每次部署的速度，这在开发人员需要频繁部署的情况下非常重要。通过自动化部署流程，可以减少错误，提高软件的生产效率和交付速度。

3.更快的软件发布

将交付作为开发流程的一部分，可以大大缩短软件发布的周期，使开发人员能够更快地发布产品和功能。CI可以帮助开发者自动化控制和管理软件发布，并提高发布周期的可靠性和重复性。

4.提高团队的生产力

CI可以帮助团队节省时间和资源，降低成本，提高生产效率，并帮助开发者专注于更高层次的任务。通过CI的自动化流程，可以以更快的速度构建、测试和部署软件，并提高团队的整体效率。

CI已成为现代软件开发流程的核心，可以使开发者更快地构建、测试、部署和发布软件，提高软件质量并降低成本。在Linux上部署CI，可以借助流行的工具和技术，使开发者能够更容易地实现持续性开发，进一步提高软件交付的效率和产品质量。

相关问题拓展阅读：

浅谈对微服务的一些思考
Gitlab+Jenkins+Docker+Harbor+K8s集群搭建CICD平台

浅谈对微服务的一些思考

两年前，之一次真正接触微服务的概念，但也只是简单地进行了使用，当时技术栈主要是 Spring Boot,那时 Spring Cloud 也比较流行，但是由于各种原因，并没有转向这套（甚至用 zookeeper 实现了简单的服务发现），理论上来说，用了 Spring Boot 再转向 Spring Cloud 应该是很正常的事情。当时也认为 Spring Cloud 各种理念很高级，实现上也不错，也有 Netflix 等之类的大公司背书，而且和 Spring 天然集成的，使用起来还是比较方便。当时可能觉得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比简直差了一个档次，可能大家都认为 Spring Cloud 是未来。

从之一家公司离职后，去了另外一家公司，发现一个很奇怪的特点，这家公司的技术比较保守，基本还是十年前或者五六年前的技术架构困燃。记得之前看过一本书上说过，技术不与时俱进，那就相当于自取灭亡，特别是技术驱动型公司，如果一直停滞不前，那就相当于你拿几十年前的武器和别人战斗，那结果自然是必然的。为什么技术要与时俱进，不是因为有了新技术就要去使用它，而是因为新技术往往可以提高业务的运转效率，同时也可以降低成本。不过在这个公司待了两个月，还是觉得有可取的地方，之一点是对代码质量的追求，由于业务的体量和特殊性（大概是亿级），所以对代码有较高的要求；第二点是对微服务整体架构的深入，虽然这个系统没有上 Spring Cloud ,甚至 Spring Boot 都没有，还是很老的一个架构，但其中微服务的思想已经有了，比如服务的拆分，服务的水平扩展，基于 Dubbo 的一些伍尺冲服务发现和治理，整体来说已经算是不错了，但是也总在思考，感觉还是少了什么东西。

容器化和 CI/CD

后来又到了一家比较年轻活跃的公司，接触到 Docker 的大规模使用以及 CI/CD，也是在这里，形成了整个对微服务完整生命周期的理解。 Docker 其实流行也很久了，但是真正线上使用的并没有那么多，最近随着 Kubernetes（ k8s ）的流行，更多公司也开始关注起来。

首先为什么服务要容器化，之一点是不再依赖于运行环境，只要有 Docker 就可以跑起来，无论你是什么发行版的 Linux 系统，还是 Windows，Mac。这有点像 JVM，屏蔽底层的细节，一次编写，到处运行，用在容器上就是一次构建，到处运行。第二点是容器化可以更好的进行持续集成，由于之一点的缘故，部署一个服务容器将非常快捷，这更加适合目前 devops 的理念。

持续集成(Continuous Integration)简称 CI ,持续部署（Continuous Deployment)简称 CD,如果微服务不把 CI/CD 放在首位，那必然整个流程就是不流畅的。有些公司还是手动本地构建包，然后上传到服务器上跑起来，进行这样的人肉运维，人肉上线，要么考虑一下，是不是整个 CI/CD 有问题，或者根本就没有 CI/CD 。其次 CI/CD 流程要做到每次构建自动跑单元测试，集成测试，以及 API 测试，UI 测试等等，这些流程也没有自动化的话，也谈不上完整的 CI/CD。如果没有经过这些流程把包直接上传到服务器，不出问题，那应该要烧柱香，拜拜佛。

云原生应用和服务网格

云原生应用遵循 Twelve-Factor ，云原生应用是为了解决传统应用发布升级流程缓慢、架构复杂，可维护性差而提出的的一个思腔歼想，集中了微服务，devops，云等多种思想。

云原生应用应用可以跑在任意一家云服务商上，也可以实现多家服务商同时使用，同时也支持公有云和私有云的混合部署，这只是它的一个特点，更多的特点还是集中在解决传统应用面临的问题，如灰度发布，不停机发布，A/B Test, 快速回滚，服务治理等。

服务网格（Service Mesh）是一个比较新的概念，但是核心思想并不新。Spring Cloud 以框架的形式侵入到程序中来解决微服务的各种问题，理论上来说，应该是效率更高，最灵活的一种做法。但是侵入性太强，而且只能 Spring 这套，异构语言的系统玩不转。Service Mesh 从另外一个角度来解决这个问题，也就是 sidecar 和 proxy，这样虽然性能上有些损失，但是扩展性却是比较灵活的，将这些基础能力（服务发现，服务治理，熔断限流，监控等）下放到基础设施中，做到对应用程序透明，是一个不错的进步。写业务逻辑不需要再去和这些东西纠结，代码逻辑也变得十分明朗。同时这样也解决了异构语言系统的问题，无论什么语言，都是可以完美的工作在一起，简直是一个完美世界。但是但是但是 Service Mesh 由于还比较新，目前还不能进行生产环境使用，就拿目前更流行的 Istio 来说，目前只发布了 0.8 版本，还不能实际使用，估计 1.0 也不行，可能得 1.2 才推荐生产，所以现在就面临一个困境，Service Mesh 是一个好东西，但是我们却用不了，呜呼哀哉。

Spring Cloud 和 Service Mesh

首先两者解决问题的方式不一样，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，这可能会造就两者之后的命运。如果目前已经上了 Spring Cloud 或者其他的，系统已经具有基础的服务治理能力，先不要考虑 Service Mesh ，要先去考虑容器化和 CI/CD ；如果没有太多的历史负担，则是可以考虑。

总结

技术发展太快，不能停滞不前，也不能盲目追风。当年的 SSH 也只剩下了 Spring，可是有人说 Spring 只能一个季节用，但是 Service Mesh 整年都可以用，好像很有道理。最后，路漫漫而修远兮，吾将上下而求索。

Gitlab+Jenkins+Docker+Harbor+K8s集群搭建CICD平台

上帝借由各种途径使人变得孤独，好让我们可以走向自己。 ——赫尔曼·黑塞《德米安》

CI即为持续集成(Continue Integration,简称CI) ，用通俗的话讲，就是持续的整合版本库代码编译后制作应用镜像。建立有效的持续集成环境可以减少开发过程中一些不必要的问题、提高代码质量、快速迭代等,

Jenkins :基于Java开发的一种持续集成工具,用于监控持笑散续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

Bamboo : 是一个企业级商用软件,可以部署在大规模生产环境中。

CD即持续交付Continuous Delivery和持续部署Continuous Deployment，用通俗的话说，即可以持续的部署到生产环境给客户使用，这里分为两个阶段，持续交付我理解为满足上线条件兆皮的过程，但是没有上线，持续部署，即为上线应用的过程

关于 CD环境，我们使用以前搭建好的 K8s集群，K8s集群可以实现应用的健康检测，动态扩容，滚动更新等优点，关于K8s集群的搭建，小伙伴可以看看我的其他文章

拉取镜像，启动并设置开机自启

配置docker加速器

GitLab 不多介绍。一个基于Git的版本控制平台，,提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki，当然同时也提供了

切记:这里的端口要设置成80，要不push项目会提示没有报错，如果宿主机端口被占用，需要把这个端口腾出来

external_url ‘

gitlab_rails = ‘192.168.26.55’

gitlab_rails = 222

修改完配置文件之后。直接启动容器

浅谈对微服务的一些思考

Gitlab+Jenkins+Docker+Harbor+K8s集群搭建CICD平台

相关推荐