大家好，我是秋意零。
昨天，一个学弟在容器部署GitLab后访问Runner时出现500的问题。根据500状态码情况是后端有误，这种情况一般需要查看对应日志进行排查，下面是处理/排查过程。
1）GitLab日志目录/文件介绍
根日志目录：
/var/log/gitlab/：这是GitLab日志文件的默认存放目录，包含了多个组件的日志。
主要日志文件：
/var/log/gitlab/gitlab-rails/production.log：记录了GitLab Rails应用的运行日志，包括每一次HTTP请求的详细信息，如请求的URL、处理时间、响应状态等。/var/log/gitlab/gitlab-rails/production_json.log：这个文件可能记录了JSON格式的HTTP请求日志，特别是通过API进行的操作，方便机器解析和分析。/var/log/gitlab/nginx/*：Nginx的访问日志和错误日志，用于监控HTTP(S)请求的处理情况，以及Nginx层面的错误信息。/var/log/gitlab/sidekiq/*：Sidekiq作业队列日志，记录后台任务的执行情况，对于监控异步处理任务的状态很重要。/var/log/gitlab/gitlab-shell/*：GitLab Shell组件的日志，它处理Git命令请求，如push、pull等，对于Git操作的错误追踪很有帮助。
其他日志和目录：
/var/log/gitlab/gitlab-workhorse/*：GitLab Workhorse日志，这是一个中间件，用于处理上传、下载和其他特殊类型的请求。/var/log/gitlab/redis/*：如果使用内置Redis，相关的日志文件会存放在此。/var/log/gitlab/puma/*：如果GitLab使用Puma作为应用服务器，Puma的日志会存放于此。/var/log/gitlab/geo/*：对于使用GitLab Geo特性（地理复制）的环境，这里会有相关日志。
备份和配置：
/var/opt/gitlab/backups/：备份文件的生成目录。/etc/gitlab/gitlab.rb：GitLab的主配置文件。
2）找到记录请求报错的日志文件
根据上述的文件介绍，可以判定/var/log/gitlab/gitlab-rails/production.log（请求URL、响应状态），报错信息在该文件。如图：
小技巧：tail -f 监控该文件，然后去浏览器再次访问，就会出现该错误
# 进入GitLab容器执行，或外部挂载目录
tail -f /var/log/gitlab/gitlab-rails/production.log
具体的错误源头在于处理页面渲染时的ActionView::Template::Error，这通常意味着视图层在准备数据展示时发生了问题。
Actionview::Template::Error
breadcrumb title('Runners')
这些错误提示表明在尝试解密与“Runners”页面相关的某种令牌(token)时发生错误，可能是用于认证或安全目的的令牌。具体来说，aes256_gcm_decrypt函数调用失败，这涉及到AES-256-GCM加密算法的解密过程，说明在解密该令牌时出现了问题，导致无法正确完成页面渲染流程。
lib/gitlab/crypto/helper.rb:28:in `aes256_gcm_decrypt`
app/models/concerns/token_authenticatable/strategies/encryption_helper.rb:18:in `decrypt_token`
...
3）解决方法
# 官方说明，在操作后可能会将配置文件恢复为默认配置，建议操作前备份
~] gitlab-rails console
> ApplicationSetting.first.delete
> ApplicationSetting.first
=> nill
# 执行后重载配置文件，再次访问Runner页面问题解决
~] gitlab-ctl reconfigure
4）出现该问题原因
没有做持久化挂载配置文件，所以需要将下列配置做持久化存储，以后也就不会出现该问题了
/etc/gitlab # 配置文件目录
/var/log/gitlab # 日志文件目录
/var/opt/gitlab # 数据文件目录
参考
https://blog.csdn.net/kaikai0720/article/details/127737009
https://blog.csdn.net/qq_40583885/article/details/110949426