docker安装GitLab支持http,https

docker安装GitLab机器配置：机器Centos7.4192.168.0.87Docker-20.10.7192.168.0.87gitlab-runner192.168.0.87gitlab-ce192.168.0.87官网：https://about.gitlab.com/install/官方安装文档：https://docs.gitlab.com/omnibus/index.html拉

starsky20

4409人浏览 · 2021-07-22 11:22:57

starsky20 · 2021-07-22 11:22:57 发布

docker安装GitLab支持http,https

docker安装GitLab支持http,https
Springboot项目Gitlab使用

docker安装GitLab支持http,https

机器配置：
在这里插入图片描述

官网：https://about.gitlab.com/install/
官方安装文档：https://docs.gitlab.com/omnibus/index.html

由于项目需求，最近研究了一下gitlab持续集成相关资料，虽然网上资料很多，大多都是以前的旧版本，很多文档编写的不全，错误百出，好多估计没有验证，本文是根据gitlab官网及网络一些参考资料，安装现有公司实际环境搭建详细记录具体操作步骤，在安装过程中发现官网也有很多问题，官网文档没有及时更新，有些配置不全，导致问题很多，下面主要介绍gitlab支持http,https,ssh等协议相关具体安装步骤和配置及安装过程问题总结，希望对有需要使用到的朋友提供一定的帮助，也欢迎大家一起交流学习wx: hai1057718341,

注意：需要使用到gitlab的朋友建议安装最新版 gitlab-ce:14.2.1, 该版本中对https配置不能自动生成nginx配置对https支持问题已经解决。

拉取镜像

官网镜像地址：
https://hub.docker.com/r/gitlab/gitlab-ce/tags?page=1&ordering=last_updated
在这里插入图片描述
查找GitLab镜像：docker search gitlab

拉取gitlab docker镜像： docker pull gitlab/gitlab-ce:latest

查看本地镜像： docker images;

创建挂载目录

mkdir -p /home/data/gitlab/{data,logs,conf}
chmod 777 -R /home/data/gitlab/

在这里插入图片描述

启动容器

sudo docker run --hostname 192.168.0.87 -p 8443:443 -p 8880:80 -p 4222:22 \
-v /home/data/gitlab/conf:/etc/gitlab \
-v /home/data/gitlab/logs:/var/log/gitlab \
-v /home/data/gitlab/data:/var/opt/gitlab \
-v /etc/localtime:/etc/localtime \
-dit --name gitlab --restart always \
--privileged=true gitlab/gitlab-ce:latest

命令解释：
-i 以交互模式运行容器，通常与 -t 同时使用命令解释：
-t 为容器重新分配一个伪输入终端，通常与 -i 同时使用
-d 后台运行容器，并返回容器ID
-p 8880:80 将容器内80端口映射至宿主8880端口，这是访问gitlab的端口
-p 4222:22 将容器内22端口映射至宿主机4222端口，这是访问ssh的端口
-v /home/data/gitlab/conf:/etc/gitlab 将容器/etc/gitlab目录挂载到宿主机目录下，若宿主机内此目录不存在将会自动创建,其他目录同理
–restart always 容器自启动
–privileged=true 让容器获取宿主机root权限，否则，宿主机无权限创建/home/data/gitlab/conf/gitlab.rb等配置文件.
–name gitlab-test 设置容器名称为gitlab-test
gitlab/gitlab-ce 镜像的名称，这里也可以写镜像ID
在这里插入图片描述
gitlab启动时间比较长，需要等待几分钟，否则访问浏览器会提示502错误。

查看启动日志：docker logs gitlab
在这里插入图片描述
从日志中可以看到服务启动完成，初始化用户是root，密码在/etc/gitlab/initial_root_password文件中。

查看版本：
docker exec -it gitlab /bin/bash
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
在这里插入图片描述
最新gitlab版本是14.0.5

重置超级管理员账号密码

参考文档：https://blog.csdn.net/A___LEi/article/details/110476531
由于 root 账户用的很少，所以我们容易忘记它的密码，但不代表它不重要，类似 linux 的 root 账户；一旦我们忘记了 root 账号的密码，我们需要知道重置的方法，方法如下
1、进入 GitLab 容器内,查看修改命令使用方法，由于不同版本有差异，所以这里先查看适用方法，在操作命令
gitlab-rails console --help
gitlab-rails console -e production
在这里插入图片描述
出现以上情况，说明该命令可以使用了。

2、开始重置gitlab管理员用户密码

root@fd0f9d13f61f:/# gitlab-rails console -e production
--------------------------------------------------------------------------------
 Ruby:         ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
 GitLab:       14.0.5 (25fc1060aff) FOSS
 GitLab Shell: 13.19.0
 PostgreSQL:   12.6
--------------------------------------------------------------------------------
Loading production environment (Rails 6.1.3.2)
#此 user 则表示 root 用户
irb(main):001:0> user=User.where(id:1).first
=> #<User id:1 @root>
#修改密码
irb(main):002:0> user.password='ds.123abc'
=> "ds.123abc"
#修改确认密码
irb(main):003:0> user.password_confirmation='ds.123abc'
=> "ds.123abc"
#保存密码
irb(main):004:0> user.save!
Enqueued ActionMailer::MailDeliveryJob (Job ID: 882a0f99-bdc5-47f2-ba46-2309ed2948d0) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", {:args=>[#<GlobalID:0x00007fe1897e41f0 @uri=#<URI::GID gid://gitlab/User/1>>]}
=> true
irb(main):005:0>
#退出控制台
irb(main):005:0> exit
root@fd0f9d13f61f:/#

在这里插入图片描述

查看用户账号密码

进入gitlab容器，执行vi /etc/gitlab/initial_root_password 查看密码。
docker exec -it gitlab bash
vi /etc/gitlab/initial_root_password

[root@localhost gitlab]# 
[root@localhost gitlab]# docker exec -it gitlab bash
root@192:/# 
root@192:/# vi /etc/gitlab/initial_root_password
# WARNING: This value is valid only in the following conditions
#          1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `g
#          2. Password hasn't been changed manually, either via UI or via command line.
#          If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password
Password: bvC0xIKN7M+i+b76XHRVYcQsBA/NHJq80TJMPdaj20M=
# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.

以上日志可以看到，用户密码设置有两种方式：
1、我们可以通过启动服务时设置参数GITLAB_ROOT_PASSWORD，初始化root用户密码。
2、通过在/etc/gitlab/gitlab.rb文件中设置属性gitlab_rails[‘initial_root_password’]，初始化root用户密码。
在这里插入图片描述

配置ssh检出项目

1、修改配置文件
按上面的方式，gitlab容器运行没问题，但在gitlab上创建项目的时候，生成项目的URL访问地址是按容器的hostname来生成的，也就是容器的id。作为gitlab服务器，我们需要一个固定的URL访问地址，于是需要配置gitlab.rb（宿主机路径：/home/data/gitlab/conf/gitlab.rb）

查看宿主机gitlab.rb配置文件：
ls /home/data/gitlab/conf/
在这里插入图片描述
进入到gitlab容器内部：
docker exec -it gitlab /bin/bash
编辑gitlab.rb配置文件，添加如下内容：

vi /etc/gitlab/gitlab.rb 
#配置http协议所使用的访问地址,即gitlab访问地址，可以写域名。如果端口不写的话默认为80端口
external_url='http://192.168.0.87:8880‘
# ssh主机ip
gitlab_rails['gitlab_ssh_host']='192.168.0.87'
# ssh连接端口
gitlab_rails['gitlab_shell_ssh_port']=4222

在这里插入图片描述
修改完成后，重置配置文件，在容器中执行：gitlab-ctl reconfigure
然后查看gitlab项目地址：

配置http检出项目

进入容器内部，修改域名配置gitlab.yml：
root@1f1c3e10eb43:/#
root@1f1c3e10eb43:/#

vi /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.
production: &base
  #
  # 1. GitLab app settings
  # ==========================
  ## GitLab settings
  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: 192.168.0.87  
    port: 8880
    https: false

    # The maximum time puma can spend on the request. This needs to be smaller than the worker timeout.
    # Default is 95% of the worker timeout
    max_request_duration_seconds: 57

修改改完成之后在容器内部执行重启gitlab: gitlab-ctl restart重启gitlab就完成了。
注意: 此时不能再重新配置(gitlab-ctl reconfigure), 否则将会改变刚修改的gitlab.yml文件，主要是gitlab.yml配置是根据gitlab.rb文件生成，如果重新加载配置，则导致修改的文件被还原，文件被还原有以下几种情况：
1、执行命令docker start gitlab 或者docker restart gitlab
2、在docker容器中执行重新加载配置：gitlab-ctl reconfigure
3、docker重启，systemctl start docker 或者systemctl restart docker
目前文件还原还没有找到具体解决办法，通过官网验证测试都不能解决，待深入研究。

查看gitlab项目，地址已经改变
在这里插入图片描述

登录测试

浏览器访问：http://192.168.0.87:8880/
输入用户名root, 密码为上面设置管理员密码ds.123abc
在这里插入图片描述

配置https访问gitlab并检出项目

官网：https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https

创建自签名的证书

证书生成参考文档：https://www.cnblogs.com/xieshuang/p/8488458.html
将下面的内容保存为create.sh 脚步，然后shell运行,按照提示输入即可
脚步内容如下：

vim create.sh
#!/bin/sh
# create self-signed server certificate:
read -p "Enter your hostname or IP : " DOMAIN
echo "Create server key..."
openssl genrsa -des3 -out $DOMAIN.key 2048
echo "Create server certificate signing request..."
SUBJECT="/C=US/ST=Mars/L=iTranswarp/O=iTranswarp/OU=iTranswarp/CN=$DOMAIN"
openssl req -new -subj $SUBJECT -key $DOMAIN.key -out $DOMAIN.csr
echo "Remove password..."
mv $DOMAIN.key $DOMAIN.origin.key
openssl rsa -in $DOMAIN.origin.key -out $DOMAIN.key
echo "Sign SSL certificate..."
openssl x509 -req -days 3650 -in $DOMAIN.csr -signkey $DOMAIN.key -out $DOMAIN.crt
echo "TODO:"
echo "rename filename......"
mv $DOMAIN.crt server.crt
mv $DOMAIN.csr server.csr
mv $DOMAIN.key server.key
mv $DOMAIN.origin.key server.origin.key
echo "mv file ssl dir......"
mkdir ssl
mv create.sh server.crt  server.csr server.key server.origin.key ssl/
chmod 777 -R ssl/*
echo "Copy $DOMAIN.crt to /home/data/gitlab/config/ssl/$DOMAIN.crt"
echo "Copy $DOMAIN.key to /home/data/gitlab/config/ssl/$DOMAIN.key"
echo "Add nginx configuration in /home/data/gitlab/config/gitlab.rb"

我在当前/root目录下创建脚本create.sh,并将上面脚本内容复制到里面,然后通过sh create.s执行，执行过程要求输入域名或者ip地址，输入密码，至少需要4位，执行完成后生成如下：
在这里插入图片描述

以上这几个脚步就是我们需要的，在后面会使用到。

配置gitlab启用https

我这里将本地目录/home/data/gitlab/conf与gitlab启动容器的/etc/gitlab目录挂载，故这里需要在本地目录/home/data/gitlab/conf下创建一个ssl目录，然后将创建的证书拷贝到ssl目录下。
mkdir -p /home/data/gitlab/conf/ssl
cp /root/ssl/* /home/data/gitlab/conf/ssl/
ls /home/data/gitlab/conf/ssl/
在这里插入图片描述
1、修改配置gitlab.rb文件

根据gitlab官网介绍，修改gitlab.rb文件内容。

vim /etc/gitlab/gitlab.rb
 #13行的 http >> https
 external_url='https://192.168.0.87:8443'
 #修改nginx配置 
letsencrypt['enable'] = false
nginx['redirect_http_to_https'] =true
nginx['redirect_http_to_https_port'] = 80
nginx['ssl_certificate'] = "/etc/gitlab/ssl/server.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/server.key"
nginx['listen_port'] = 443

修改完成后，进入容器内部，让配置生效：
docker exec -it gitlab bash
在容器内执行:
gitlab-ctl reconfigure
gitlab-ctl restart

注意：这里按照官网修改完成后，重新加载配置后浏览器访问无效，经过排查分析发现external_url这里需要使用等号，否则，启动后访问无效，并且还需要修改nginx相关配置，这些官网都没有做说明，有很多缺失，网上也有很多gitlab安装资料，经过测试gitlab相关版本11,12按照官网配置https可行，我这里安装最新版14.0.5无作用。该bug在官网提出有一段时间了，一直没有解决，后续升级版本中可能修改该问题，具体还需要下面修改nginx相关配置才可以。

2、修改配置nginx.conf文件
进入/home/data/gitlab/data/nginx/conf目录或者进入容器内部//var/opt/gitlab//data/nginx/conf目录，由于nginx.conf中引入gitlab-http.conf，故这里需要修改gitlab-http.conf配置，我这里通过复制该文件为gitlab-https.conf, 然后修改gitlab-https.conf，主要是gitlab在执行docker restart gitlab或者重启docker服务时，配置会重新初始化，导致配置好的信息被覆盖，故这里通过复制文件重命名，后面就算是重启服务也不影响修改内容。
在这里插入图片描述
修改源文件gitlab-http.conf 中端口为80.

修改gitlab-https.conf 文件内容，增加https认证相关内容。

具体内容如下：
vim gitlab-https.conf 
server {
  listen *:443;
  server_name 192.168.0.87;
  server_tokens off; ## Don't show the nginx version number, a security best practice

  ## Increase this if you want to upload large attachments
  ## Or if you want to accept large git objects over http
  client_max_body_size 0;
  
## 以下为ssl相关配置
  ssl on;
#指定公钥pem或者crt文件路径，这里.crt使用以上脚步生成的秘钥
  ssl_certificate /etc/gitlab/ssl/server.crt;
#指定key文件路径，这里key使用以上脚步生成的秘钥可以
  ssl_certificate_key /etc/gitlab/ssl/server.key;
#指定session cache大小
  ssl_session_cache    shared:SSL:1m;
#指定ssl协议
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#指定ssl算法
  ssl_ciphers  HIGH:!aNULL:!MD5;
#优先采取服务器算法
  ssl_prefer_server_ciphers  on;

  ## Real IP Module Config
  ## http://nginx.org/en/docs/http/ngx_http_realip_module.html

  ## HSTS Config
  ## https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
  add_header Strict-Transport-Security "max-age=31536000";

  # Rails sets a default policy of strict-origin-when-cross-origin, so
  # hide that and just send the one we've configured for nginx
  proxy_hide_header Referrer-Policy;
  add_header Referrer-Policy strict-origin-when-cross-origin;

  ## Individual nginx logs for this GitLab vhost
  access_log  /var/log/gitlab/nginx/gitlab_access.log gitlab_access;
  error_log   /var/log/gitlab/nginx/gitlab_error.log;

  if ($http_host = "") {
    set $http_host_with_default "192.168.0.87";
  }

  if ($http_host != "") {
    set $http_host_with_default $http_host;
  }

  gzip on;
  gzip_static on;
  gzip_comp_level 2;
  gzip_http_version 1.1;
  gzip_vary on;
  gzip_disable "msie6";
  gzip_min_length 250;
  gzip_proxied no-cache no-store private expired auth;
  gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;

  ## https://github.com/gitlabhq/gitlabhq/issues/694
  ## Some requests take more than 30 seconds.
  proxy_read_timeout      3600;
  proxy_connect_timeout   300;
  proxy_redirect          off;
  proxy_intercept_errors on;
  proxy_http_version 1.1;

  proxy_set_header Host $http_host_with_default;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  proxy_set_header X-Forwarded-Proto https;
  proxy_set_header X-Forwarded-Ssl on;

  location ~ (/api/v\d/jobs/\d+/artifacts$|\.git/git-receive-pack$|\.git/gitlab-lfs/objects|\.git/info/lfs/objects/batch$) {
    proxy_cache off;
    proxy_pass http://gitlab-workhorse;
    proxy_request_buffering off;
  }

  location /-/grafana/ {
    proxy_pass http://localhost:3000/;
  }


  # health checks configuration
  include /var/opt/gitlab/nginx/conf/gitlab-health.conf;

  location / {
    proxy_cache off;
    proxy_pass  http://gitlab-workhorse;
  }

  location /assets {
    add_header X-Content-Type-Options nosniff;
    proxy_cache gitlab;
    proxy_pass  http://gitlab-workhorse;
  }

  error_page 404 /404-custom.html;
  error_page 500 /500.html;
  error_page 502 /502.html;
  location ~ ^/(404|500|502)(-custom)?\.html$ {
    root /opt/gitlab/embedded/service/gitlab-rails/public;
    internal;
  }
}

在这里插入图片描述
修改完成后，将gitlab-https.conf配置文件引入到nginx.conf文件中。

vim /home/data/gitlab/data/nginx/conf/nginx.conf
include /var/opt/gitlab/nginx/conf/gitlab-http.conf;
include /var/opt/gitlab/nginx/conf/gitlab-https.conf;

在这里插入图片描述
3、进入容器内部，重启nginx:
docker exec -it gitlab bash
gitlab-ctl restart nginx

测试https访问gitlab
浏览器访问: https://192.168.0.87:8443/

点击高级，打开链接

输入用户名，密码登录。

以上表示gitlab支持https访问。下面我们处理创建项目也支持https检出。

配置gitlab检出项目支持https访问

以上配置完成后，项目检出地址并没有修改，我们可以登录浏览器查看，项目http检出地址为：http://192.168.0.87/root/spring-demo.git，该地址是http方式，并且端口是80，如果需要支持https方式，则需要做相应修改。
在这里插入图片描述

1、修改配置文件gitlab.yml
进入/home/data/gitlab/data/gitlab-rails/etc目录。
修改配置文件gitlab.yml内容：

vim /home/data/gitlab/data/gitlab-rails/etc/gitlab.yml
  ## GitLab settings
  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: 192.168.0.87
    port: 8443
    https: true

将这里的host,port,修改和external_url配置相同的ip及端口，https设置为true.
在这里插入图片描述
2、重启服务
docker exec -it gitlab /bin/bash
gitlab-ctl restart

重启完成后，登录浏览器查看。

3、浏览器测试
浏览器访问: https://192.168.0.87:8443/
在这里插入图片描述
可以看到项目支持https了.下面我们使用idea测试通过https地址检出项目。

4、使用idea测试检出该项目
打开idea,选择VCS->Get from version controller
在这里插入图片描述

输入检出地址，选择检出到指定位置，点击clone即可。

选择yes打开项目

选择new window, 检出完成如下，

以上表示https配置成功，需要注意，如果gitlab服务重启或者docker重启，将导致gitlab相关配置被重新初始化，需要重启修改。

Gitlab服务命令

启动所有 gitlab 组件；sudo gitlab-ctl start
停止所有 gitlab 组件；sudo gitlab-ctl stop
重启所有 gitlab 组件；sudo gitlab-ctl restart
查看服务状态；sudo gitlab-ctl status
启动服务(再次加载配置)；sudo gitlab-ctl reconfigure
修改默认的配置文件；sudo vim /etc/gitlab/gitlab.rb
检查gitlab；gitlab-rake gitlab:check SANITIZE=true --trace
查看日志；sudo gitlab-ctl tail
查看版本：cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Gitlab版本升级

参考文档：
https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations
首先备份一下数据，以防万一
1、进入dokcer 容器gitlab
sudo docker exec -i -t gitlab /bin/bash
备份数据：gitlab-rake gitlab:backup:create
备份文件在 data/backups 文件夹下
2、停止全部服务： gitlab-ctl stop
3、退出容器： exit
4、停止dokcer容器gitlab： sudo docker stop gitlab
5、再删除容器： sudo docker rm gitlab
6、运行新版本gitlab容器（注意升级版本的选择）

sudo docker run -dit --name gitlab \
--hostname 192.168.0.87 -p 8443:443 -p 8880:80 -p 4222:22 \
-v /home/data/gitlab/conf:/etc/gitlab \
-v /home/data/gitlab/logs:/var/log/gitlab \
-v /home/data/gitlab/data:/var/opt/gitlab \
-v /etc/localtime:/etc/localtime \
--restart always --privileged=true \
gitlab//gitlab-ce:14.0.5-ce.0:latest

备注：只用修改gitlab版本，挂载目录中的数据不要删除

其他设置

创建项目

浏览器访问：http://192.168.0.87:8880/
输入用户名root, 密码为上面设置管理员密码ds.123abc
在这里插入图片描述
登录后如下：

导入一个项目：点击new project,如下：

这里选择模板创建项目，使用spring模板创建

填写项目名称，选择用户或者组：

创建成功如下：

设置SSH密钥

参考文档：https://blog.csdn.net/lsp84ch80/article/details/87861990
执行命令： ssh-keygen -t rsa -C ‘1057718341@qq.com’ ,都不不用输入，按回车即可
在这里插入图片描述
生成的秘钥在 /root/.ssh/目录下

查看公钥，将公钥复制到gitlab中。

设置中文

GitLab 提供了很多的设置，楼主这里偷个懒，只教大家如何设置语言（虽然楼主知道大家的英语都很棒，但我相信大家的中文更棒），当语言变成我们最擅长的中文时，相信大家都能很好的进行偏好设置了；语言设置过程如下
在这里插入图片描述
看着熟悉的中文，倍感亲切，但是要注意：此功能当初处于实验阶段，翻译尚未全部完成，也就是说语言功能尚未全部完成

取消用户注册

我们用 SVN 或 Git 的时候，账号往往不是自己注册的，而是统一分配的；而我们搭建的又是私服，不对外提供服务，所以无需注册功能，那么我们用 root 账号来关闭注册功能，很简单，流程如下
在这里插入图片描述
取消 Sign-up enabled前的复选框勾选，保存就好了
退出登录后可以发现，登录页的注册功能没了。

添加账号

管理员账号登录gitlab, 点击菜单-》选择admin-》用户-》新增用户. 在这里插入图片描述
填写用户账号、密码等信息，然后保存

保存完成，点击编辑，修改用户，设置用户登录密码。

然后保存用户，并对用户进行分组，设置项目权限。

创建分组

超级管理员用户登录，点击菜单-》选择admin->群组-》新建群组。
在这里插入图片描述

群组添加用户：

项目授权

项目授权这里有两种情况：1、项目直接授权给指定用户；2-项目授权到群组。
登录gitlab，点击项目进入内部，点击project infomation->成员(members)
邀请成员：
在这里插入图片描述

邀请群组：

选择群组、角色，点击邀请即可将群组添加到项目中，即表示该群组中的所有用户都可以访问该项目。

安装错误

Whoops, GitLab is taking too much time to respond

在这里插入图片描述
原因：
1、机器内存太小，gitlab启动运行之后相当的消耗内存，尤其是做提交更新等处理的时候，出现这个错误的时候可以查看下内存情况：free -m
2、启动未完成导致，可以稍等几分钟，通过日志查看是否有错误。

iptables: No chain/target/match by that name

[root@localhost gitlab]# systemctl stop firewalld
[root@localhost gitlab]# docker restart gitlab
Error response from daemon: Cannot restart container gitlab: driver failed programming external connectivity on endpoint gitlab (83aba17054354229ccb64d822a7f47b7c7991f7de1a4f309fdbaa3e87f1b6950): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 8880 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0: iptables: No chain/target/match by that name.
(exit status 1))
[root@localhost gitlab]#
原因：gitlab启动需要设置防火墙允许docker中网段可以访问，当关闭防火墙后，导致gitlab重启失败
解决办法：
重启防火墙: systemctl restart firewalld
重启gitlab: docker restart gitlab

ERROR: “rails console” was called with arguments [“production”] (Thor::InvocationError)

[root@localhost gitlab]# docker exec -it gitlab /bin/bash
root@fd0f9d13f61f:/# gitlab-rails console production
Traceback (most recent call last):
8: from bin/rails:4:in <main>' 7: from bin/rails:4:inrequire’
6: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/commands.rb:18:in <top (required)>' 5: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/command.rb:50:ininvoke’
4: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/command/base.rb:69:in perform' 3: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:indispatch’
2: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in invoke_command' 1: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:27:inrun’
/opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/commands/console/console_command.rb:95:in perform': (given 1, expected 0) (ArgumentError) 9: from bin/rails:4:in’
8: from bin/rails:4:in require' 7: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/commands.rb:18:in<top (required)>’
6: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/command.rb:50:in invoke' 5: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/railties-6.1.3.2/lib/rails/command/base.rb:69:inperform’
4: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:in dispatch' 3: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:ininvoke_command’
2: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:20:in run' 1: from /opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:34:inrescue in run’
/opt/gitlab/embedded/lib/ruby/gems/2.7.0/gems/thor-1.1.0/lib/thor/base.rb:525:in `handle_argument_error’: ERROR: "rails consonts [“production”] (Thor::InvocationError)
Usage: “rails console [options]”
root@fd0f9d13f61f:/#
以上是由于新版本命令修改导致，这里查看命令使用方法即可。
root@fd0f9d13f61f:/# gitlab-rails console --help
Usage:
rails console [options]
Options:
-e, [–environment=ENVIRONMENT] # Specifies the environment to run this console under (test/development/production).
-s, [–sandbox], [–no-sandbox] # Rollback database modifications on exit.
root@fd0f9d13f61f:/#
解决办法：
在这里插入图片描述
然后使用 gitlab-rails console -e production 进行修改用户账号密码

Error importing repository into root/daison-admin - No such file or directory @ rb_sysopen - [FILTERED]

以上是在创建项目时，通过导入项目方式，导致仓库未创建，可以在gitlab中创建好项目,在将项目检出到本地，将需要导入的项目放入改目录中提交即可。

There was an error running gitlab-ctl reconfigure

Running handlers:
There was an error running gitlab-ctl reconfigure:
Cannot set unsupported config value .
Running handlers complete
Chef Infra Client failed. 0 resources updated in 02 seconds
[root@localhost conf]#
主要是/etc/gitlab/gitlab.rb 配置文件编写有问题，我这里是根据官网配置配置external_url ‘xxx’ 导致错误，正确格式是external_url=‘xxx’，官网也有不靠谱的时候，如果不能解决，可以将修改的注释，一行一行的放开进行启动gitlab排查。

GitLab external URL must include a schema and FQDN, e.g. http://gitlab.example.com/

Running handlers:
There was an error running gitlab-ctl reconfigure:
GitLab external URL must include a schema and FQDN, e.g. http://gitlab.example.com/
解决办法：
进入容器内部，执行 vi /etc/gitlab/gitlab.rb 将external_url ‘xxx’ 改成 external_url= ‘xxx’
如下：
external_url='http://192.168.0.87:8880‘
修改完成后使配置文件生效，执行命令： gitlab-ctl reconfigure

Permissions 0755 for ‘/etc/gitlab/ssh_host_ed25519_key‘ are too open.

gitlab启动提示文件权限错误，主要是我们在使用挂载目录时，将gitlab目录下所有文件权限改为755，导致gitlab不能正常使用，在统一将文件的权限改为755时，发现gitlab可以正常使用，但使用ssh免密pull和push的时候，gitlab会报错：
Permissions 0755 for ‘/etc/gitlab/ssh_host_ed25519_key’ are too open.
经过查证该文件ssh_host_ed25519_key 和 ssh_host_rsa_key的权限设置过大引起的，应该配置为600。
解决办法：
使用docker命令进入容器
docker exec -it gitlab /bin/bash
查看gitlab日志
gitlab-ctl tail
3、修改文件的权限
cd /etc/gitlab/
chmod 600 ssh_host_ed25519_key
chmod 600 ssh_host_rsa_key
4、重启gitlab
gitlab-ctl stop
gitlab-ctl start

nginx: [emerg] SSL_CTX_use_certificate("/etc/nginx/conf/server.crt") failed (SSL: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small)

注意：centos版本如果是CentOS Linux release 8x 版本，私钥长度不能设置成1024位，必须2048位及以上。不然再最后启动nginx时会出错误。
解决办法：
重新生成ssl证书文件

Clone failed: Unable to access ‘https://192.168.0.87:10443/root/spring-demo.git/’: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

该错误是由于gitlab检出时，gitlab.yml配置项目地址修改支持https了，但是nginx中未修改支持https导致。
解决办法：
1、修改配置文件gitlab.yml内容：

vim /home/data/gitlab/data/gitlab-rails/etc/gitlab.yml
  ## GitLab settings
  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: 192.168.0.87
    port: 8443
    https: true

将这里的host,port,修改和external_url配置相同的ip及端口，https设置为true.

2、修改nginx.conf

具体内容如下：

vim /home/data/gitlab/data/nginx/confgitlab-http.conf 
server {
  listen *:443;
  server_name 192.168.0.87;
  server_tokens off; ## Don't show the nginx version number, a security best practice

  ## Increase this if you want to upload large attachments
  ## Or if you want to accept large git objects over http
  client_max_body_size 0;
  
## 以下为ssl相关配置
  ssl on;
#指定公钥pem或者crt文件路径，这里.crt使用以上脚步生成的秘钥
  ssl_certificate /etc/gitlab/ssl/server.crt;
#指定key文件路径，这里key使用以上脚步生成的秘钥可以
  ssl_certificate_key /etc/gitlab/ssl/server.key;
#指定session cache大小
  ssl_session_cache    shared:SSL:1m;
#指定ssl协议
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#指定ssl算法
  ssl_ciphers  HIGH:!aNULL:!MD5;
#优先采取服务器算法
  ssl_prefer_server_ciphers  on;

Springboot项目Gitlab使用

这里以IntelliJ IDEA-2019.2为例，具体idea使用方法自行百度

安装maven插件

1、下载maven插件：http://maven.apache.org/download.cgi
2、将下载的压缩包解压缩到本地。
3、通过idea配置maven插件
在这里插入图片描述
这里需要选择settings.xml和maven仓库位置。
默认xml文件位置：C:\Users\Administrator.m2
仓库位置：C:\Users\Administrator.m2\repository
这里可以不用修改，使用默认的配置，只是需要将默认位置的settings.xml文件修改成我们自己的配置即可。

4、settings.xml文件

<?xml version="1.0" encoding="UTF-8"?>

<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->

<!--
 | This is the configuration file for Maven. It can be specified at two levels:
 |
 |  1. User Level. This settings.xml file provides configuration for a single user,
 |                 and is normally provided in ${user.home}/.m2/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -s /path/to/user/settings.xml
 |
 |  2. Global Level. This settings.xml file provides configuration for all Maven
 |                 users on a machine (assuming they're all using the same Maven
 |                 installation). It's normally provided in
 |                 ${maven.conf}/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -gs /path/to/global/settings.xml
 |
 | The sections in this sample file are intended to give you a running start at
 | getting the most out of your Maven installation. Where appropriate, the default
 | values (values used when the setting is not specified) are provided.
 |
 |-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->
	<localRepository>E:\mavenrepository</localRepository>
  <!-- interactiveMode
   | This will determine whether maven prompts you when it needs input. If set to false,
   | maven will use a sensible default value, perhaps based on some other setting, for
   | the parameter in question.
   |
   | Default: true
  <interactiveMode>true</interactiveMode>
  -->

  <!-- offline
   | Determines whether maven should attempt to connect to the network when executing a build.
   | This will have an effect on artifact downloads, artifact deployment, and others.
   |
   | Default: false
  <offline>false</offline>
  -->

  <!-- pluginGroups
   | This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
   | when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
   | "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
   |-->
  <pluginGroups>
    <!-- pluginGroup
     | Specifies a further group identifier to use for plugin lookup.
    <pluginGroup>com.your.plugins</pluginGroup>
    -->
  </pluginGroups>

  <!-- proxies
   | This is a list of proxies which can be used on this machine to connect to the network.
   | Unless otherwise specified (by system property or command-line switch), the first proxy
   | specification in this list marked as active will be used.
   |-->
  <proxies>
    <!-- proxy
     | Specification for one proxy, to be used in connecting to the network.
     |
    <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>proxyuser</username>
      <password>proxypass</password>
      <host>proxy.host.net</host>
      <port>80</port>
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
    -->
  </proxies>

  <!-- servers
   | This is a list of authentication profiles, keyed by the server-id used within the system.
   | Authentication profiles can be used whenever maven must make a connection to a remote server.
   |-->
  <servers>
    <!-- server
     | Specifies the authentication information to use when connecting to a particular server, identified by
     | a unique name within the system (referred to by the 'id' attribute below).
     |
     | NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
     |       used together.
     |
    <server>
      <id>deploymentRepo</id>
      <username>repouser</username>
      <password>repopwd</password>
    </server>
    -->

    <!-- Another sample, using keys to authenticate.
    <server>
      <id>siteServer</id>
      <privateKey>/path/to/private/key</privateKey>
      <passphrase>optional; leave empty if not used.</passphrase>
    </server>
    -->
	
    <server>
      <id>docker-proxy</id>
      <username>admin</username>
      <password>admin123</password>
    </server>
	
    <server>
      <id>central</id>
      <username>test</username>
      <password>test123</password>
    </server>
    <server>
      <id>snapshots</id>
      <username>test</username>
      <password>test123</password>
    </server>
    <server>
      <id>nexus</id>
      <username>test</username>
      <password>test123</password>
    </server>
  </servers>

  <!-- mirrors
   | This is a list of mirrors to be used in downloading artifacts from remote repositories.
   |
   | It works like this: a POM may declare a repository to use in resolving certain artifacts.
   | However, this repository may have problems with heavy traffic at times, so people have mirrored
   | it to several places.
   |
   | That repository definition will have a unique id, so we can create a mirror reference for that
   | repository, to be used as an alternate download site. The mirror site will be the preferred
   | server for that repository.
   |-->
  <mirrors>
    <!-- mirror
     | Specifies a repository mirror site to use instead of a given repository. The repository that
     | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
     | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
     |
    <mirror>
      <id>mirrorId</id>
      <mirrorOf>repositoryId</mirrorOf>
      <name>Human Readable Name for this Mirror.</name>
      <url>http://my.repository.com/repo/path</url>
    </mirror>
     -->
	 <!--本地私服-->
	<mirror>
	  <id>external-repos</id>
	  <mirrorOf>external:*,!snapshots</mirrorOf>
	  <name>Nexus localHost</name>
	  <url>http://120.79.51.144:8079/repository/central/</url>
	</mirror>
	
	<!-- 阿里云仓库 -->
	<mirror>
		<id>alimaven</id>
		<mirrorOf>central</mirrorOf>        
		<name>aliyun maven</name>
		<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
	</mirror>
	
	<!-- 中央仓库1 -->
	 <mirror>
		 <id>repo1</id>
		 <mirrorOf>central</mirrorOf>
		 <name>Human Readable Name for this Mirror.</name>
		 <url>https://repo1.maven.org/maven2/</url>
	 </mirror>
 
	 <!-- 中央仓库2 -->
	 <mirror>
		 <id>repo2</id>
		 <mirrorOf>central</mirrorOf>
		 <name>Human Readable Name for this Mirror.</name>
		 <url>https://repo2.maven.org/maven2/</url>
	 </mirror>
  </mirrors>

  <!-- profiles
   | This is a list of profiles which can be activated in a variety of ways, and which can modify
   | the build process. Profiles provided in the settings.xml are intended to provide local machine-
   | specific paths and repository locations which allow the build to work in the local environment.
   |
   | For example, if you have an integration testing plugin - like cactus - that needs to know where
   | your Tomcat instance is installed, you can provide a variable here such that the variable is
   | dereferenced during the build process to configure the cactus plugin.
   |
   | As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles
   | section of this document (settings.xml) - will be discussed later. Another way essentially
   | relies on the detection of a system property, either matching a particular value for the property,
   | or merely testing its existence. Profiles can also be activated by JDK version prefix, where a
   | value of '1.4' might activate a profile when the build is executed on a JDK version of '1.4.2_07'.
   | Finally, the list of active profiles can be specified directly from the command line.
   |
   | NOTE: For profiles defined in the settings.xml, you are restricted to specifying only artifact
   |       repositories, plugin repositories, and free-form properties to be used as configuration
   |       variables for plugins in the POM.
   |
   |-->
  <profiles>
    <!-- profile
     | Specifies a set of introductions to the build process, to be activated using one or more of the
     | mechanisms described above. For inheritance purposes, and to activate profiles via <activatedProfiles/>
     | or the command line, profiles have to have an ID that is unique.
     |
     | An encouraged best practice for profile identification is to use a consistent naming convention
     | for profiles, such as 'env-dev', 'env-test', 'env-production', 'user-jdcasey', 'user-brett', etc.
     | This will make it more intuitive to understand what the set of introduced profiles is attempting
     | to accomplish, particularly when you only have a list of profile id's for debug.
     |
     | This profile example uses the JDK version to trigger activation, and provides a JDK-specific repo.
    <profile>
      <id>jdk-1.4</id>

      <activation>
        <jdk>1.4</jdk>
      </activation>

      <repositories>
        <repository>
          <id>jdk14</id>
          <name>Repository for JDK 1.4 builds</name>
          <url>http://www.myhost.com/maven/jdk14</url>
          <layout>default</layout>
          <snapshotPolicy>always</snapshotPolicy>
        </repository>
      </repositories>
    </profile>
    -->

    <!--
     | Here is another profile, activated by the system property 'target-env' with a value of 'dev',
     | which provides a specific path to the Tomcat instance. To use this, your plugin configuration
     | might hypothetically look like:
     |
     | ...
     | <plugin>
     |   <groupId>org.myco.myplugins</groupId>
     |   <artifactId>myplugin</artifactId>
     |
     |   <configuration>
     |     <tomcatLocation>${tomcatPath}</tomcatLocation>
     |   </configuration>
     | </plugin>
     | ...
     |
     | NOTE: If you just wanted to inject this configuration whenever someone set 'target-env' to
     |       anything, you could just leave off the <value/> inside the activation-property.
     |
    <profile>
      <id>env-dev</id>

      <activation>
        <property>
          <name>target-env</name>
          <value>dev</value>
        </property>
      </activation>

      <properties>
        <tomcatPath>/path/to/tomcat/instance</tomcatPath>
      </properties>
    </profile>
    -->

      <profile>
        <id>nexus</id>
        <repositories>
          <repository>
            <id>central</id>
            <name>release</name>
            <url>http://120.79.51.144:8079/repository/releases/</url>
            <snapshots>
              <enabled>false</enabled>
            </snapshots>
          </repository>
          <repository>
            <id>snapshots</id>
            <name>snapshots</name>
            <url>http://120.79.51.144:8079/repository/snapshots/</url>
          </repository>
        </repositories>
        <pluginRepositories>
          <pluginRepository>
            <id>central</id>
            <name>release</name>
            <url>http://120.79.51.144:8079/repository/releases/</url>
            <snapshots>
              <enabled>false</enabled>
            </snapshots>
          </pluginRepository>
          <pluginRepository>
            <id>snapshots</id>
            <name>snapshots</name>
            <url>http://120.79.51.144:8079/repository/snapshots/</url>
          </pluginRepository>
        </pluginRepositories>
      </profile>
  </profiles>

  <activeProfiles>
    <activeProfile>nexus</activeProfile>
  </activeProfiles>
  
  <!-- activeProfiles
   | List of profiles that are active for all builds.
   |
  <activeProfiles>
    <activeProfile>alwaysActiveProfile</activeProfile>
    <activeProfile>anotherAlwaysActiveProfile</activeProfile>
  </activeProfiles>
  -->
</settings>

安装Git插件

1、下载git gui：https://git-scm.com/downloads
2、下载后直接安装即可。安装完成如下：
在这里插入图片描述
3、在idea中配置git插件，选择git安装位置，点击test测试，如果提示成功，则表示git配置成功，然后保持配置即可，如下图：

使用Git检出项目

参考文档：https://blog.csdn.net/weixin_40816738/article/details/90052533

通过idea检出项目

打开idea->VCS->Get from Version Control
在这里插入图片描述
选择URL地址，项目位置，点击确定。这里的URL是gitlab中项目地址；例如，我这里检出spring-demo2项目,地址为http://192.168.0.87:8880/root/spring-demo2.git

检出如下图：

录入登录Gitlab登录账号、密码，点击登录

点击确定，打开项目
在这里插入图片描述
选择new Window打开一个新的窗口

检出完成如下：

更新：
选中项目->右键-》git->repository->pull，拉去gitlab仓库项目，更新本地项目。更新项目时需要注意，可能本地修改的文件与服务器冲突，需要自行对比进行将项目文件合并。

在这里插入图片描述
选择项目环境，我这里只有master，所以就选中master，如果有多个分支，根据自己需求选择分支更新即可。

提交：
选择项目-》右键-》git->commit directory或者add，add是表示现在一个文件，就是仓库中还没有该文件，这时就需要选择add，先添加到仓库，然后在commit.
在这里插入图片描述
选择需要提交的文件，填写修改内容，然后选择commit and push即可。及commit到本地仓库，然后推送到服务器。

通过git gui客户端检出项目

Windows->开始-》Git

在这里插入图片描述
这里我们选择Git GUI 通过图像话界面检出项目,如下图：

选择Clone Existing Repository.

录入gitlab项目地址，项目目录，点击clone，然后输入登录gitlab用户账号，密码。

等待检出项目，检出完成如下：

Git命令及其他操作请自行百度，这里不在介绍。

Git常用命令总结

参考文档：https://www.cnblogs.com/my–sunshine/p/7093412.html

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

云原生

所有评论(0)

查看更多评论

starsky20

@seashouwang

已为社区贡献5条内容