摘要：
要实现一台服务器上多个网站的自动化部署和管理,可以使用一些常见的工具和技术,如:对于一台服务器上的多个网站,备份和恢复是非常重要的。常见的备份方式有:恢复时,只需要将备份的数据和文... 要实现一台服务器上多个网站的自动化部署和管理,可以使用一些常见的工具和技术,如:
对于一台服务器上的多个网站,备份和恢复是非常重要的。常见的备份方式有:
恢复时,只需要将备份的数据和文件恢复到服务器即可。对于容器部署,可以直接从镜像启动容器。图解 Jenkins Pipeline 的前端自动化部署，用上后真香！
本文将图解并详细阐述如何通过Jenkins Pipeline来实现前端自动化部署，强调了Pipeline相较于自由风格项目的灵活性和高级自动化能力。 以下是部署流程的步骤：首先，选择Jenkins Pipeline任务以实现更高效的自动化流程，相较于自由风格项目，Pipeline提供了更高级的构建能力。 ### Pipeline核心脚本#### 获取 Git 代码分支使用gitParameter插件获取Git仓库的分支，部署时选择分支。 默认选择develop分支。 #### Git环境变量与获取Git分支代码关键代码通过Git插件获取选定的Git分支。 #### 拷贝依赖包考虑到node_modules不会上传到Git仓库，需要在Linux服务器上预先安装依赖包，然后手动压缩并拷贝到Jenkins服务器的passjava目录。 部署时，从passjava目录将node_modules压缩包拷贝并解压到当前工作目录。 #### 编译代码使用npm run build xx命令编译前端代码，并压缩编译后的dist目录。 #### 备份代码将web服务器上多个前端项目移动到备份目录web-bak。 #### 上传代码将编译后的代码包上传到web服务器。 #### 更新代码解压dist压缩包，将多个前端工程（如passjavabase, passjava-channel, project-contract）拷贝到passjava-web-micro目录。 #### 清理代码执行命令查找并删除web服务器上超过7天未修改的目录，以确保服务器空间整洁。 #### 邮件通知具体步骤见之前的邮件通知教程。 ### 总结通过使用Jenkins Pipeline进行前端自动化部署，团队可以实现高效管理与部署前端应用程序，降低人为错误和手动操作的风险，显著提升开发和部署效率。 此方法通过图解和代码展示，涵盖了从分支获取到代码更新的完整流程，有助于优化部署流程，特别是在支持选择部署不同前端模块方面。
Gitlab-CI 自动部署Kubernetes
通过将基于docker的自动部署方式迁移至Kubernetes，本文详细介绍了一系列的步骤与实践，以实现对系统的自动部署与管理。 首先，我们介绍如何在本地安装和使用kubectl工具进行远程管理Kubernetes集群，包括在Windows系统上下载kubectl的二进制文件，复制k8s-master机器上的config文件至本地，并通过kubectl命令进行集群操作，以验证其可行性。 接着，通过使用Docker镜像构建kubectl，具体步骤包括进入部署了GitLab和GitLab Runner的服务器，下载并测试bitnami/kubectl镜像。 随后，从k8s-master集群中拉取kubectl配置文件，并使用Docker命令运行kubectl，搭建基于kubectl的自动化部署环境。 自动化构建阶段，我们阐述了通过Docker打包镜像并推送至私有镜像服务器，以及利用kubectl在Kubernetes上创建deployment并将镜像部署至集群的过程。 实现自动化构建的关键步骤包括创建一个副本数量为3的deployment，保存为文件，并在文件中进行相应调整，将本地机器配置好的配置文件映射至GitLab Runner容器，确保kubectl能够正确访问集群配置。 在测试阶段，我们展示了如何通过kubectl查看pod状态，监控pod变化，以及在主程序（）中更新输出内容。 通过GitLab的自动构建功能，实现对代码的实时监控和部署，新pod的创建替代了旧pod，且IP地址发生相应变化，验证了自动化部署的正确性。 最后，通过Curl连接新创建的pod，获取更改后的信息，整个流程顺利结束。
gitlab-ci&gitlab-runner完整自动化部署过程
GitLab CI & GitLab Runner 是一套用于自动化部署的工具，简化项目部署操作，强调自动化流程。 只需要在终端输入命令即可更新仓库代码并直接发布到线上环境。 在部署过程中，首先需要确保本地环境的配置，如免密码登录服务端。 自动化部署不需要人工干预，将打包的 dist 文件夹通过 scp 复制到服务器上的指定路径（如 nginx 的指定目录），即可实现直接访问。 在部署前，需要确保目标服务器已安装好 nginx。 通过 vim 编辑 文件并进行相应的配置调整，如路径转发和文件夹复制。 确保 nginx 服务重启（执行 nginx -s reload）以应用新配置。 为了实现免密码登陆，使用 ssh-keygen 创建 SSH 密钥对，通常在与 GitLab Runner 相同的服务器上操作。 执行 scp 命令将 dist 文件夹复制到服务器上的 nginx 指定路径，如 `/opt/project/web/`。 在 GitLab 仓库中创建一个项目，用于存放自动化脚本。 这一步可以在线下环境中进行，确保配置正确。 随后，基于 Docker 安装 GitLab Runner，执行特定的启动命令并创建配置文件。 确保在容器内正确配置环境，以满足开发需求，如 Java、 或其他特定技术栈。 通过容器内运行的脚本注册 GitLab Runner，并获取 Token。 将 Runner 注册到 GitLab 仓库中，完成配置。 编写自动化部署脚本，通常在项目根目录下完成。 将脚本与 GitLab 仓库关联，每次提交代码或更新时，脚本将自动执行，无需手动打包和上传。 进行语法检测以确保脚本正确无误。 配置文件中定义了多个参数，如 job、stages、image、services、variables 等，用于指定部署流程的各个阶段，包括编译、打包和部署。 配置文件中的 `only` 参数用于指定在哪个分支上执行自动化部署，通常用于 master 分支。 自动化部署流程通常包含编译、打包和部署三个阶段。 配置文件中的详细参数包括 `script`、`extends`、`image`、`services` 等，用于定义执行的命令、使用的镜像、所需的服务以及环境配置。 通过 `environment` 参数指定部署环境，使用 `coverage` 参数监控代码覆盖率，并配置 `retry` 来处理失败后的自动重试。 配置文件提供了高度的灵活性，以适应不同项目的特定需求。 GitLab CI 还提供其他功能，如依赖管理、测试执行、代码审查等，进一步提升自动化部署的效率和可靠性。