GitLab 10.6.3与Jenkins 2.164.3的CICD部署：非K8s环境

本文档主要介绍了如何在GitLab 10.6.3版本与Jenkins 2.164.3版本的持续集成/持续交付(CI/CD)环境下，结合Kubernetes 1.14.2进行部署，特别强调的是Jenkins被部署在Kubernetes集群之外。以下将详细介绍整个过程： 1. **GitLab环境设置**: - GitLab服务器配置在一个运行Docker的机器上，IP地址为172.28.31.20。 - 使用`docker load`命令从`.tar`包中加载GitLab CE 10.6.3镜像，确认了镜像版本为1.0.6.3-ce.05d8ab6b0691。 2. **GitLab服务安装与配置**: - 可以选择两种部署方式之一，第一种是使用`--net=host`选项，让容器共享主机网络，便于访问外部资源，如端口映射到主机的443、10085和8080。 - 或者使用第二种方式，通过`-p`参数明确指定容器的端口映射，以便在Kubernetes集群内部或外部都能访问GitLab服务。 3. **Jenkins集成**: - 文档没有详细说明Jenkins的部署，但可以推测是在Kubernetes之外单独部署的，可能通过类似的方式（如Docker）独立运行。通常，Jenkins与GitLab集成可以通过Jenkins插件如GitLab API插件来实现，这样Jenkins可以触发GitLab上的构建任务。 4. **Kubernetes环境**: - 文档提到使用Kubernetes 1.14.2版本，这表明可能存在一个Kubernetes集群作为CI/CD管道的一部分，但Jenkins不直接参与Kubernetes的管理，而是作为一个独立的工具。 5. **CICD流程**: - 由于没有具体描述CICD流程，我们可以推测这是一个典型的GitLab CI/CD场景，可能包括配置GitLab CI，编写YAML文件定义构建规则，以及通过Jenkins与GitLab的集成触发构建任务，但实际操作细节并未在文中提供。 6. **部署模式选择**: - 在Kubernetes外部部署GitLab意味着管理和运维相对独立，适用于不想完全依赖Kubernetes的场景，或者想保持服务的高可用性和扩展性，但同时又希望保持对Kubernetes集群的控制。 总结，这个文档为读者提供了一个在非Kubernetes环境中部署GitLab 10.6.3和Jenkins 2.164.3进行CI/CD的基础框架，着重强调了GitLab的独立部署，并简要提及了与Kubernetes的间接交互。对于实际操作者来说，需要根据自己的需求进一步配置GitLab CI、Jenkins集成，以及可能的安全和性能优化措施。