一、GitLab简介

GitLab 社区版（Community Edition，简称 CE）是 GitLab 提供的免费开源版本。与企业版（Enterprise Edition，简称 EE）相比，社区版主要针对个人和小型团队，提供核心的代码仓库管理、代码审查、持续集成/持续部署（CI/CD）等功能。

1、主要特点

版本控制：基于 Git，提供强大的版本控制功能。
代码审查：支持合并请求（Merge Request），以及代码审查功能。
持续集成和持续部署（CI/CD）：内置 GitLab CI/CD，无需额外服务。
项目管理：提供问题追踪（Issue Tracking）、看板等项目管理工具。
文档管理：支持 Wiki，以及其他文档管理功能。
开放源代码：社区版是完全开源的，可以自由地进行定制和二次开发。

2、安装

GitLab CE 可以在 Linux 上通过多种方式安装，包括使用包管理器，Docker 容器，或者从源代码编译。

A. 使用包管理器（Ubuntu）

bash
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo yum install -y gitlab-ce

B. Linux部署 (此处先省略，后面着重介绍部署步骤)

C. 使用 Docker (需要内存 4GB+)

注意端口是否已被占用

bash
docker run --detach \
  --hostname gitlab.example.com \
  --publish 443:443 --publish 80:80 --publish 2322:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab \
  --volume /srv/gitlab/logs:/var/log/gitlab \
  --volume /srv/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ce:latest

3. 重置容器的 root 密码

完整的操作步骤如下：

A. 进入正在运行的 GitLab 容器:

运行以下命令以进入正在运行的 GitLab 容器：

bash
docker exec -it gitlab /bin/bash

B. 在容器内重置 root 密码:

在容器内执行以下命令来重置 root 密码：

bash
gitlab-rake gitlab:password:reset

它会要求你输入新的密码。输入后，系统会打印出新密码。

C. 使用新密码登录 GitLab

使用这个新密码登录 GitLab 网页端。之后，你可以在个人设置中再次修改密码。

通过这种方式，你可以安全地为 GitLab 实例设置一个新的 root 密码，而不需要查看日志。这是官方推荐的密码重置流程。

3、适用场景

小型到中型项目：对于小型到中型的开发项目，社区版通常已足够。
教育和个人用途：社区版是学习 DevOps 和 Git 的好选择。
开源项目：社区版支持公开项目，适用于开源社群。

4、集成到 IT 环境

对于一个以 Java 和企业级微服务架构为基础的项目，GitLab 社区版可以提供代码版本管理，以及 CI/CD 流程。这样，每当有代码更改时，GitLab 可以自动触发构建和测试任务，确保代码质量。此外，通过 API 或 Webhook，GitLab 还可以与其他 IT 系统（如 Jira、Kubernetes 等）进行集成，形成一个完整的 DevOps 工作流。

解决方案设计、物理网络蓝图、系统集成接口定义和部署环境蓝图等都可以基于 GitLab 的各种功能来进行详细规划和实施。

二、部署步骤介绍

在Linux上部署GitLab，不采用Docker的方式，通常是通过下载和安装包来完成。以下是具体的步骤：

1. 系统准备

确保你的系统满足GitLab的硬件要求（4G），并且系统是最新更新的。

2. 安装必要的依赖

安装Postfix以发送通知邮件（或者你可以稍后配置其他的SMTP服务）。
```
bash
sudo yum install -y postfix
```

3. 添加GitLab包仓库

下载并安装GitLab的仓库设置包：

bash
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

4. 安装GitLab

通过包管理器安装GitLab包：
```
bash
sudo yum install -y gitlab-ce
```

5. 配置GitLab

编辑/etc/gitlab/gitlab.rb文件来配置GitLab，例如设置外部URL等。

bash
vim /etc/gitlab/gitlab.rb
# 修改external_url 'https://gitlab.example.com'
# 查找：/external_url

配置SMTP (可选):

如果您想通过SMTP服务器发送邮件，您需要配置SMTP设置。下面是一个示例配置：

bash
   gitlab_rails['smtp_address'] = "smtp.qq.com"
   gitlab_rails['smtp_port'] = 587
   gitlab_rails['smtp_user_name'] = "xxxxxxxxx@qq.com"  # 用你的QQ邮箱地址替换
   gitlab_rails['smtp_password'] = "brxl*******gfha"  # 用你的SMTP授权码替换
   gitlab_rails['smtp_domain'] = "qq.com"
   gitlab_rails['smtp_authentication'] = "login"
   gitlab_rails['smtp_enable_starttls_auto'] = true
   gitlab_rails['gitlab_email_from'] = 'xxxxxxxxx@qq.com'  # 用你的QQ邮箱地址替换

6. 重新配置GitLab

运行下面的命令应用你的配置更改：
```
bash
sudo gitlab-ctl reconfigure
```

其他操作

1、停止：sudo gitlab-ctl stop

2、启动：sudo gitlab-ctl start

3、查看状态：sudo gitlab-ctl status

7. 访问和配置你的GitLab实例


从您提供的输出中，看起来GitLab已成功配置，并且默认的管理员账户（用户名：**root**）已被创建。但是，出于安全考虑，系统没有在标准输出（STDOUT）中显示初始的root密码。相反，它已将初始密码存储在`/etc/gitlab/initial_root_password`文件中。这个文件会在24小时后的第一次重新配置运行时被清理。

下面是如何获取初始root密码和登录到GitLab的步骤：

获取初始root密码:
- 使用以下命令查看/etc/gitlab/initial_root_password文件中的密码：
```
bash
sudo cat /etc/gitlab/initial_root_password
```

登录到GitLab:
- 在Web浏览器中打开您的GitLab实例的URL。
- 如果是做了Nginx Proxy Manager管理的话，需要指定一下IP:port
- 在登录页面上，使用用户名root和刚刚获取的密码登录。

重置root密码 (强烈推荐):
- 出于安全考虑，强烈建议您在登录后立即重置root密码。您可以按照GitLab的重置密码文档中的指示进行操作。
清理初始密码文件 (可选):
- 如果您已成功登录并重置了root密码，您可以选择手动删除/etc/gitlab/initial_root_password文件，以确保不会保留任何敏感信息：
```
bash
sudo rm /etc/gitlab/initial_root_password
```

通过这些步骤，应该能够获取初始的root密码，登录到您的GitLab实例，并重置root密码以增加安全性。

8. 创建备份策略

配置定期备份，以保护你的数据。

9. 设置监控和报警

考虑设置监控和报警，以确保你的GitLab实例运行正常，及时发现和解决问题。

是的，您可以将GitLab设置为中文。GitLab支持多种语言，包括简体中文。以下是如何将GitLab界面语言设置为中文的步骤：

10. 更改语言

登录到GitLab:
- 使用您的用户名和密码登录到您的GitLab实例。
访问个人设置:
- 在页面的右上角，点击您的头像或初始字母图标，然后从下拉菜单中选择“Settings”（设置）。
更改语言设置:
- 在左侧的导航菜单中，点击“Preferences”（偏好设置）。
- 在“Localization”（本地化）区域，找到“Language”（语言）下拉菜单。
- 从“Language”下拉菜单中选择“简体中文”。
- 滚动到页面底部并点击“Save changes”（保存更改）按钮。
确认更改:
- 保存设置后，您的GitLab界面应该会立即更新为中文。

11. 导入第三方仓库

根据从不同源获取的信息，下面是在GitLab中启用项目导入选项的步骤：

管理员访问:
- 登录到GitLab，您需要具有管理员访问级别。在左侧边栏中，选择搜索或转到Admin Area（管理员区域）。

导航到设置，启用导入源/导出:
- 在管理员区域中，选择Settings > General（设置 > 通用）。展开Import and export settings（导入和导出设置）部分，滚动到Project export（项目导出）、Import sources（导入源）选项，选择Enabled（启用）复选框，你可以启用希望允许的导入源，例如Repo by URL, GitHub, Bitbucket等，然后选择Save changes（保存更改）。

应用程序设置 ( 如果适用 ) :
- 对于某些GitLab版本，您可能需要导航到/admin/application_settings，并在Import sources下启用项目导入选项。
验证设置: 返回到GitLab的主页面，尝试导入项目以确保您的设置已正确应用。

12. 设置时区

北京时间是UTC+8时区。这意味着北京时间比协调世界时（UTC）快8小时。例如，如果UTC的时间是12:00（中午），那么北京时间将是20:00（晚上8点）。在中国，全国都统一使用北京时间，无论是东部还是西部地区。

三、同级别大版本内更新

查看版本号：

sh
cd /opt/gitlab/embedded/service/gitlab-rails
cat VERSION
rpm -q gitlab-ce

同级别的大版本内，也可以通过包管理，进行例行升级

https://docs.gitlab.com/16.10/ee/update/

升级手册
备份与恢复手册

sh
sudo yum install gitlab-ce

当从版本 16.5.0 直接升级到 16.10.3时

GitLab的升级脚本检测到需要先升级到 16.7.x 版本, 然后才能继续升级到 16.10.3。

这是由于GitLab的升级路径限制, 不允许跨越多个次要版本号直接升级。

sh
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for gitlab_gitlab-ce
gitlab-ce-16.10.3-ce.0.el7.x86_64.rpm                                                                                                                                                                  | 1.0 GB  00:02:12     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
gitlab preinstall: It seems you are upgrading from 16.5 to 16.10.
gitlab preinstall: It is required to upgrade to the latest 16.7.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
error: %pre(gitlab-ce-16.10.3-ce.0.el7.x86_64) scriptlet failed, exit status 1
Error in PREIN scriptlet in rpm package gitlab-ce-16.10.3-ce.0.el7.x86_64
  Verifying  : gitlab-ce-16.10.3-ce.0.el7.x86_64                                                                                                                                                                          1/2 
gitlab-ce-16.5.0-ce.0.el7.x86_64 was supposed to be removed but is not!
  Verifying  : gitlab-ce-16.5.0-ce.0.el7.x86_64                                                                                                                                                                           2/2 

Failed:
  gitlab-ce.x86_64 0:16.5.0-ce.0.el7                                                                            gitlab-ce.x86_64 0:16.10.3-ce.0.el7                                                                           

Complete!

(一) GitLab 升级指南：从 16.5.0 到 16.10.3

1. 备份前，先检查运行状态

执行以下命令以准备升级：

sh
sudo gitlab-ctl status
systemctl status gitlab-runsvdir.service

2. 创建备份

bash
# 停止相关数据连接服务,如果使用的话  
gitlab-ctl stop unicorn
gitlab-ctl stop puma
gitlab-ctl stop sidekiq

# 备份gitlab数据目录  
gitlab-rake gitlab:backup:create

提示

根据输出日志,备份操作现在已经成功完成了。

日志显示备份文件名为 1713423032_2024_04_18_16.5.0。这个备份包含了GitLab实例的大部分数据,包括:

数据库 Git仓库数据 CI构建数据上传的附件等但是,需要注意的是,GitLab的配置文件 gitlab.rb 和密钥文件 gitlab-secrets.json 并未包含在备份中。日志有如下提示:

sh
2024-04-18 06:50:38 UTC -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.

因此,如果将来需要从这个备份还原GitLab实例,你还需要手动备份这两个配置文件。

备份文件默认存储在 /var/opt/gitlab/backups 目录下。你可以将该备份文件复制到其他位置作为额外的备份。

总的来说,现在你已经成功创建了一个GitLab的数据备份,便于未来出现问题时进行还原。不过请记得也备份配置文件,以确保还原后能正常运行。

3. 升级到 16.7.x 版本

bash
# 停止所有gitlab服务
sudo gitlab-ctl stop

# 安装16.7版本
sudo yum install -y gitlab-ce-16.7.7

中间版本更新完成

重新配置并启动（注：重新配置若更新时自动配置了，则不需要执行）

sh
sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

再次查看版本号：

sh
cd /opt/gitlab/embedded/service/gitlab-rails
cat VERSION
rpm -q gitlab-ce

4. 从 16.7.x 升级到 16.10.3

同样的，继续执行以下命令以完成升级，步骤与升级中间版本相同：

bash
# 停止相关连接服务
gitlab-ctl stop unicorn  
gitlab-ctl stop puma
gitlab-ctl stop sidekiq

# 停止所有gitlab服务  
sudo gitlab-ctl stop

# 安装16.10.3
sudo yum install -y gitlab-ce-16.10.3

# 重新配置并启动（注：重新配置若更新时自动配置了，则不需要执行）
sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

提示

在从16.7.x升级到16.10.3的过程中,您无需再次创建备份。原因如下:

已有备份可用在第一步从16.5.0升级到16.7.x时,您已经创建了一个名为1713423032_2024_04_18_16.5.0的完整数据备份。只要这个备份文件存在且完整,就可以在升级过程中作为回滚点使用。

文档建议 GitLab官方的升级文档中,对于次要版本之间的升级(如16.7.x到16.10.x),并没有明确要求必须重新创建备份。创建备份主要是为了应对从一个主版本升级到另一个不兼容的主版本时(如16.x到17.x)的风险。

在线升级 GitLab的次要版本升级通常是一个在线的无中断的过程。在升级过程中,服务会短暂停止但数据不会被修改,因此不需要完整备份作为还原点。

效率考虑创建备份是一个耗时的过程,为了升级效率,中间每个小版本都重新备份是不必要的开销。

因此,根据最佳实践,只需要在主要版本升级前创建一次完整备份即可,作为升级过程中的保险。在后续的次要版本升级中,如果您对现有备份和系统状态有足够的信心,可以跳过备份步骤直接进行升级。

但是,如果您对现有系统或备份的完整性和可靠性有任何疑虑,重新创建一次新的备份也是可以的,这样可以最大程度地降低风险

再次查看版本号：

sh
cd /opt/gitlab/embedded/service/gitlab-rails
cat VERSION
rpm -q gitlab-ce

注意事项

如果使用了 HTTPS，需要在重新配置后重新运行一次 gitlab-ctl renew-le-certs。
升级后建议检查一下GitLab状态 sudo gitlab-ctl status。
如遇其他错误，请参考升级向导 GitLab 升级文档。按照这个分两步的升级路径，您应该可以成功将 GitLab 从 16.5.0 升级到 16.10.3 版本了。

(二) 在安装或升级 GitLab CE 后的后续步骤

1. 重新配置 GitLab（注：重新配置若更新时自动配置了，则不需要执行）

安装或升级 GitLab CE 后，首先需要重新配置 GitLab。运行以下命令来启动此过程：

bash
sudo gitlab-ctl reconfigure

这个命令会根据新安装的软件包自动重新配置 GitLab，包括应用新的设置、更新数据库结构等。

2. 检查 GitLab 状态

配置完成后，使用以下命令检查 GitLab 各个组件的状态，确保它们都处于运行中：

bash
sudo gitlab-ctl status

这将显示如 Redis、Nginx、Unicorn 等组件的运行状态。

3. 浏览器访问

GitLab 应该会自动启动 web 服务，你可以用浏览器访问对应的 URL（例如 http://gitlab.example.com）查看 GitLab 的登录页面。

4. 登录并修改密码（如有必要）

使用默认的 root 用户和更新后的新密码（可在 /etc/gitlab/initial_root_password 查看）登录到 GitLab 实例。为了安全起见，建议修改默认的 root 密码。

5. 执行其他配置（可选）

根据实际需求，你可能还需要进行其他配置，比如设置域名/HTTPS、配置邮件服务器等，请参考 GitLab 官方文档进行操作。

6. 升级检查和清理

最后，你可以输入以下命令检查是否还有可用的软件包升级，并进行清理：

bash
sudo yum update
sudo yum clean all

如有新版本的升级包，可以选择继续升级。同时也可以清理过期的包和缓存。按照上述步骤操作，你就能顺利地在升级后继续使用最新版本的 GitLab。

四、 GitLab 内存调优

在内存受限的环境中运行极狐GitLab

在启用所有功能的情况下运行时，极狐GitLab需要大量内存。有一些用例，例如在不需要所有功能的较小安装上运行极狐GitLab。例如：

运行极狐GitLab供个人使用或非常小的团队使用。
使用云提供商上的小实例来节省成本。
使用资源受限的设备，如 Raspberry PI。

通过一些调整，GitLab可以在比最低要求中描述的规格低得多的规格下舒适地运行。

受限环境的最低要求

可以运行极狐GitLab的最低预期规格是：

基于Linux的系统（最好基于Debian或基于RedHat）
4个ARM7/ARM64 CPU内核或1个AMD64架构CPU内核
最低2GB RAM + 1GB SWAP，最佳为2.5GB RAM + 1GB SWAP
20GB可用存储空间
具有良好随机I/O性能且具有优先顺序的存储：SSD, eMMC, HDD, 高性能A1-type SD卡

存储尤其重要，因为在受限环境中，我们预计会发生一定量的内存交换，这会给使用过的磁盘带来更大的压力。

1. 配置Swap

在安装极狐GitLab之前，您需要配置swap。Swap是磁盘上的专用空间，在物理RAM已满时使用。当Linux系统耗尽RAM时，非活动页面将从RAM移动到交换空间。建议的swap配置为可用内存的50%左右。

如何配置Swap

Ubuntu 20.04

bash
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

CentOS 7

bash
sudo dd if=/dev/zero of=/swapfile bs=1024 count=1048576
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

2. 验证系统的性能

有许多工具可以让您验证基于Linux的系统的性能，例如 sbc-bench，它可以用作一种验证系统性能是否足以在受限环境中运行极狐GitLab的方法。

这些系统提供足够的性能来运行极狐GitLab 的小型安装：

3. 禁用监控以节省资源

在 /etc/gitlab/gitlab.rb 中禁用监控：

ruby
prometheus_monitoring['enable'] = false

4. 优化GitLab的配置（根据实际情况调整）

减少Puma工作进程数量：
```
ruby
puma['worker_processes'] = 0
```

降低Sidekiq的并发请求数：
```
ruby
sidekiq['max_concurrency'] = 10
```

优化Gitaly配置：

ruby
gitaly['configuration'] = {
    concurrency: [
      {'rpc' => "/gitaly.SmartHTTPService/PostReceivePack", 'max_per_repo' => 3},
      {'rpc' => "/gitaly.SSHService/SSHUploadPack", 'max_per_repo' => 3}
    ],
    cgroups: {
        repositories: {'count' => 2},
        mountpoint: '/sys/fs/cgroup',
        hierarchy_root: 'gitaly',
        memory_bytes: 500000,
        cpu_shares: 512,
    }
}
gitaly['env'] = {'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'}

5. 重载配置

进行所有这些更改后，重新配置极狐GitLab以使用新设置：

bash
sudo gitlab-ctl reconfigure

6. 性能结果

配置完成后，您可以预期以下内存使用情况：


              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.7Gi       151Mi        31Mi       132Mi       102Mi
Swap:         1.0Gi       153Mi       870Mi

五、 GitLab CI/CD 流水线

1. runner注册、环境变量配置、

2.开放上传文件最大限制

一般流水线部署会出现上传报错：

一般来说修改如图这个配置即可：

这是防止流水线打包若未采用流水线自身缓存时，会上传jar包，过大时会报错

若修改后重试未生效可以尝试修改gitlab.rb配置文件

sh
cd /etc/gitlab/ && vim gitlab.rb

添加配置：gitlab自身的限制，nginx上传的限制两个都需要调整

rb
gitlab_rails['env'] = {
  'GITLAB_MAX_ARTIFACTS_SIZE' => '0'
  'MALLOC_CONF' => 'dirty_decay_ms:30000,muzzy_decay_ms:30000'
}
nginx['client_max_body_size'] = '0' # 0 表示无限制，或者您可以设置一个更高的限制，如 '100m'（100 MB）。

然后保存:wq，重载 gitlab 配置

sh
sudo gitlab-ctl reconfigure

3.支持并行的deploy任务

核心目标是将jar包分发到三台不同的目标服务器上

3.1 修改GitLab Runner配置

首先找到 gitlab 的并发配置文件（root下）：
```
sh
cd /etc/gitlab-runner && vim config.toml
```

在 gitlab 服务器上，修改配置让其支持 3个任务 并发执行，修改网络超时时间为 3倍 artifact_download_timeout 设置的 30分钟

toml
concurrent = 3
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "local-system-runner"
  url = "https://example.com"
  id = 3
  token = "glrt-Syxxxxxxxxxxxxx4rjkP"
  token_obtained_at = 2024-05-04T17:56:30Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.network]
    artifact_download_timeout = 1800

重启 GitLab Runner：修改完配置文件后，重启 GitLab Runner 以应用更改。

sh
sudo gitlab-runner restart

验证并行执行:

创建和启动 CI Pipeline 在 GitLab 项目中创建新的 Pipeline，即重新触发启动一条流水线，观察三个作业是否都处于同一阶段且在运行；这可以在 GitLab 的 Pipeline 界面中，观察三个作业是否是同时运行的，例子，如下所示。

示例：

流水线的并发deploy示例：

yml
stages:
  - deploy

.deploy_template: &deploy_template
  stage: deploy
  environment: production
  script:
    - echo "Deploying application..."
    - sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "mv /home/ctm/evn/java_run/*.jar /home/ctm/evn/java_run/bak/$(date +%Y%m%d%H%M%S).jar"
    - sshpass -p "$SSH_PASSWORD" scp -o StrictHostKeyChecking=no target/*.jar ctm@${SERVER_IP}:/home/ctm/evn/java_run/
    - sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "sh /home/ctm/evn/java_run/restart.sh"
    - echo "Application successfully deployed on ${SERVER_IP}."
  only:
    - main

deploy-job-1:
  <<: *deploy_template
  variables:
    SERVER_IP: "111.xxx.xxx.23"

deploy-job-2:
  <<: *deploy_template
  variables:
    SERVER_IP: "139.xxx.xxx.18"

deploy-job-3:
  <<: *deploy_template
  variables:
    SERVER_IP: "49.xxx.xxx.6"

执行的 restart.sh 文件示例

sh
#!/bin/bash

# 设置脚本所需的绝对路径
work_dir="/home/ctm/evn/java_run"
java_home="/home/ctm/evn/jdk/jdk1.8.0_201/bin/java"

# 杀掉现有的Java进程
pkill -9 -f 'java.*system-0.0.1-SNAPSHOT.jar'

# 等待一段时间确保进程已经被杀死
sleep 5

# 检查进程是否被成功杀死，如果没有，则输出提示信息
if pgrep -f 'java.*system-0.0.1-SNAPSHOT.jar' > /dev/null; then
    echo "Failed to kill the process. Please check manually."
    exit 1
fi

# 获取当前时间戳，格式为yyyymmddhhmmss
timestamp=$(date +"%Y%m%d%H%M%S")

# 将现有的nohup.out文件重命名，添加时间戳作为后缀
mkdir -p "$work_dir/bak"
mv "$work_dir/nohup.out" "$work_dir/bak/nohup.out.$timestamp"

# 重新启动服务
cd "$work_dir"
nohup $java_home -noverify -Xmx512m -Xms512m -jar "$work_dir/system-0.0.1-SNAPSHOT.jar" --spring.profiles.active=uat1 > nohup.out 2>&1 &

3.2 流水线完整示例：

针对各个环节还可以自定义依赖项，也就是先后顺序，比如我还要加入验证环节verify要在deploy结束后进行，而test需要在build之后进行，但deploy不用等待test，而是直接等待build，那么我们可以通过添加needs参数配置来实现，如下所示：

yml
unit-test-job:   # 单元测试阶段 - 后续测试内容自行添加
  stage: test
  script:
    - echo "Running unit tests... This will take about 5 seconds."
    - sleep 5
    - echo "Code coverage is 90%"
  cache: # 2、采用缓存形式 （提升效率，无jar包上传下载的网络通讯消耗）
    key: "${CI_COMMIT_REF_SLUG}-build"      # 采用build阶段的缓存，读取编译后的jar包，key也为主${key}-build 保持一致
    paths:
      - .m2/repository
      - target/
  needs:
    - build-job
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

3.3 配置示例：

yml
cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - .m2/repository  # 使用相对路径定义 Maven 缓存位置

variables:
  MAVEN_HOME: "/home/ctm/evn/apache-maven-3.9.6"
  JAVA_HOME: "/home/ctm/evn/jdk/jdk1.8.0_201"
  PATH: "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$MAVEN_HOME/bin:$JAVA_HOME/bin"
  MAVEN_CLI_OPTS: "-s .maven/settings.xml --batch-mode -Dmaven.repo.local=/home/ctm/maven_nexus"
  GIT_TRACE: "true"
  GIT_CURL_VERBOSE: "true"
  GIT_DEPTH: "0"

before_script:
  - echo "JAVA_HOME=$JAVA_HOME"
  - echo $PATH
  - which java
  - which mvn
  - which mkdir
  - mkdir -p .maven
  - echo "$MAVEN_SETTINGS_XML" > .maven/settings.xml
  - mkdir -p /home/ctm/maven_nexus

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling the code..."
    - mvn $MAVEN_CLI_OPTS clean install -DskipTests
  cache:
    key: "${CI_COMMIT_REF_SLUG}-build"
    paths:
      - .m2/repository
      - target/
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 hour  # 根据需要设置适当的过期时间
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

#unit-test-job:   # 单元测试阶段
#  stage: test
#  script:
#    - echo "Running unit tests... This will take about 10 seconds."
#    - sleep 10
#    - echo "Code coverage is 90%"
#  rules:
#    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
#    - if: '$CI_RUN == "true"'
#
#lint-test-job:   # 代码静态检查阶段
#  stage: test
#  script:
#    - echo "Linting code... This will take about 10 seconds."
#    - sleep 10
#    - echo "No lint issues found."
#  rules:
#    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
#    - if: '$CI_RUN == "true"'

## 用户密码的方式
.deploy_template: &deploy_template
  stage: deploy
  environment: production
  script:
    - echo "Deploying application..."
    - |
      sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "mv /home/ctm/evn/java_run/*.jar /home/ctm/evn/java_run/bak/system-0.0.1-BAK-$(date +%Y%m%d%H%M%S).jar" ||
      {
        echo "WARNING: Failed to move JAR files to backup directory."
      }
    - echo "Backup completed or failed with a warning."
    - |
      sshpass -p "$SSH_PASSWORD" scp -o StrictHostKeyChecking=no target/*.jar ctm@${SERVER_IP}:/home/ctm/evn/java_run/ &&
      echo "New JAR file uploaded successfully." ||
      {
        echo "ERROR: Failed to upload new JAR file."
      }
    - |
      sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "sh /home/ctm/evn/java_run/restart.sh" &&
      echo "Application restarted successfully." ||
      {
        echo "ERROR: Failed to restart application."
      }
    - echo "Application successfully deployed on ${SERVER_IP}."
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

deploy-job-1:
  <<: *deploy_template
  variables:
    SERVER_IP: "111.xxx.xxx.23"

deploy-job-2:
  <<: *deploy_template
  variables:
    SERVER_IP: "139.xxx.xxx.18"

deploy-job-3:
  <<: *deploy_template
  variables:
    SERVER_IP: "49.xxx.xxx.6"

3.4 共享缓存示例（节省构件上传下载时间 - 共享runner则不能采用，会导致混乱）

此配置我仅留给main分支代码使用隔离开避免混乱

yml
cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - .m2/repository  # 使用相对路径定义 Maven 缓存位置
    - target/         # 确保.jar文件也被缓存

variables:
  MAVEN_HOME: "/home/ctm/evn/apache-maven-3.9.6"
  JAVA_HOME: "/home/ctm/evn/jdk/jdk1.8.0_201"
  PATH: "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$MAVEN_HOME/bin:$JAVA_HOME/bin"
  MAVEN_CLI_OPTS: "-s .maven/settings.xml --batch-mode -Dmaven.repo.local=/home/ctm/maven_nexus"
  GIT_TRACE: "true"
  GIT_CURL_VERBOSE: "true"
  GIT_DEPTH: "0"

before_script:
  - echo "JAVA_HOME=$JAVA_HOME"
  - echo $PATH
  - which java
  - which mvn
  - which mkdir
  - mkdir -p .maven
  - echo "$MAVEN_SETTINGS_XML" > .maven/settings.xml
  - mkdir -p /home/ctm/maven_nexus

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling the code..."
    - mvn $MAVEN_CLI_OPTS clean install -DskipTests
    - echo "Listing compiled artifacts..."
    - pwd && ls -l target/  # 列出 target 目录中的文件以确认构件
  cache:
    key: "${CI_COMMIT_REF_SLUG}-main-build"    # 输出编译后的jar作为缓存，key为主${key}-build
    paths:
      - .m2/repository
      - target/
#  artifacts:       # 启用流水线生成的构建包作为流水线输出 - 标准流程
#    paths:
#      - target/*.jar
#    expire_in: 1 hour  # 根据需要设置适当的过期时间
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

unit-test-job:   # 单元测试阶段 - 后续测试内容自行添加
  stage: test
  script:
    - echo "Running unit tests... This will take about 5 seconds."
    - sleep 5
    - echo "Code coverage is 90%"
  cache: # 2、采用缓存形式 （提升效率，无jar包上传下载的网络通讯消耗）
    key: "${CI_COMMIT_REF_SLUG}-main-build"      # 采用build阶段的缓存，读取编译后的jar包，key也为主${key}-build 保持一致
    paths:
      - .m2/repository
      - target/
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

lint-test-job:   # 代码静态检查阶段 - 后续测试内容自行添加
  stage: test
  script:
    - echo "Linting code... This will take about 5 seconds."
    - sleep 5
    - echo "No lint issues found."
  cache: # 2、采用缓存形式 （提升效率，无jar包上传下载的网络通讯消耗）
    key: "${CI_COMMIT_REF_SLUG}-main-build"      # 采用build阶段的缓存，读取编译后的jar包，key也为主${key}-build 保持一致
    paths:
      - .m2/repository
      - target/
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

## 用户密码的方式
.deploy_template: &deploy_template
  stage: deploy
  environment: production
  script:
#    - echo "Listing downloaded artifacts..."       # 1、采用上传下载构件形式 - 标准流程
    - echo "Checking for the existence of JAR file in the cache..."     # 2、采用缓存形式 （提升效率，无jar包上传下载的网络通讯消耗）
    - pwd && ls -l target/      # 列出 下载下来的构件
    - echo "Deploying application..."
    - |
      sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "mv /home/ctm/evn/java_run/*.jar /home/ctm/evn/java_run/bak/system-0.0.1-BAK-$(date +%Y%m%d%H%M%S).jar" ||
      {
        echo "WARNING: Failed to move JAR files to backup directory."
      }
    - echo "Backup completed or failed with a warning."
    - |
      sshpass -p "$SSH_PASSWORD" scp -o StrictHostKeyChecking=no target/*.jar ctm@${SERVER_IP}:/home/ctm/evn/java_run/ &&
      echo "New JAR file uploaded successfully." ||
      {
        echo "ERROR: Failed to upload new JAR file."
      }
    - |
      sshpass -p "$SSH_PASSWORD" ssh -o StrictHostKeyChecking=no ctm@${SERVER_IP} "sh /home/ctm/evn/java_run/restart.sh" &&
      echo "Application restarted successfully." ||
      {
        echo "ERROR: Failed to restart application."
      }
    - echo "Application successfully deployed on ${SERVER_IP}."
  cache:                                    # 2、采用缓存形式 （提升效率，无jar包上传下载的网络通讯消耗）
    key: "${CI_COMMIT_REF_SLUG}-main-build"      # 采用build阶段的缓存，读取编译后的jar包，key也为主${key}-build 保持一致
    paths:
      - .m2/repository
      - target/
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 当提交发生在 main 分支上时，流水线才执行
    - if: '$CI_RUN == "true"'

deploy-job-1:
  <<: *deploy_template
  variables:
    SERVER_IP: "111.xxx.xxx.23"

deploy-job-2:
  <<: *deploy_template
  variables:
    SERVER_IP: "139.xxx.xxx.18"

deploy-job-3:
  <<: *deploy_template
  variables:
    SERVER_IP: "49.xxx.xxx.6"

目录

一、GitLab简介

1、主要特点

2、安装

A. 使用包管理器（Ubuntu）

B. Linux部署 (此处先省略，后面着重介绍部署步骤)

C. 使用 Docker (需要内存 4GB+)

3. 重置容器的 root 密码

A. 进入正在运行的 GitLab 容器:

B. 在容器内重置 root 密码:

C. 使用新密码登录 GitLab

3、适用场景

4、集成到 IT 环境

二、部署步骤介绍

1. 系统准备

2. 安装必要的依赖

3. 添加GitLab包仓库

4. 安装GitLab

5. 配置GitLab

6. 重新配置GitLab

7. 访问和配置你的GitLab实例

8. 创建备份策略

9. 设置监控和报警

10. 更改语言

11. 导入第三方仓库

12. 设置时区

三、 同级别大版本内更新

(一) GitLab 升级指南：从 16.5.0 到 16.10.3

1. 备份前，先检查运行状态

2. 创建备份

3. 升级到 16.7.x 版本

4. 从 16.7.x 升级到 16.10.3

(二) 在安装或升级 GitLab CE 后的后续步骤

1. 重新配置 GitLab（注：重新配置若更新时自动配置了，则不需要执行）

2. 检查 GitLab 状态

3. 浏览器访问

4. 登录并修改密码（如有必要）

5. 执行其他配置（可选）

6. 升级检查和清理

四、 GitLab 内存调优

受限环境的最低要求

1. 配置Swap

2. 验证系统的性能

3. 禁用监控以节省资源

4. 优化GitLab的配置（根据实际情况调整）

5. 重载配置

6. 性能结果

五、 GitLab CI/CD 流水线

1. runner注册、环境变量配置、

2.开放上传文件最大限制

3.支持并行的deploy任务

3.1 修改GitLab Runner配置

3.2 流水线完整示例：

3.3 配置示例：

3.4 共享缓存示例（节省构件上传下载时间 - 共享runner则不能采用，会导致混乱）

三、同级别大版本内更新