前言最近一直在折腾自建gitlab，在此记录一下，供大家参考。整个构建过程基于DockerSwarm（近期有将微服务移植到Kubernetes的计划，但一直不顺利，暂时沿用老方案）。主题图片与主题无关，请无视...1.快速启动配置的一般原则是先可用再优化。只需一条命令即可启动gitlab：sudodockerrun--detach\--hostnamegitlab.yuclk.com\--publish443:443--publish80:80--publish22:22\--namegitlab\--总是重启\--volume/mnt/nas/gitlab/config:/etc/gitlab\--volume/mnt/nas/gitlab/logs:/var/log/gitlab\--volume/mnt/nas/gitlab/data:/var/opt/gitlab\gitlab/gitlab-ce:latest然后在功能上，离配置邮箱只差一步。通过dockerexec-it进入容器，修改/etc/gitlab/gitlab.rb，添加如下配置：**'gitlab_rails['smtp_domain']='smtp.qq.com'gitlab_rails['smtp_authentication']='login'gitlab_rails['smtp_enable_starttls_auto']=truegitlab_rails['smtp_tls']=truegitlab_rails['smtp_openssl_verify_mode']='peer'#如果您的SMTP服务器不喜欢默认的“发件人：gitlab@localhost”，您可以使用此设置更改“发件人”。gitlab_rails['gitlab_email_from']='gitlab@youclk.com'#gitlab_rails['gitlab_email_reply_to']='noreply@youclk.com'然后使用如下命令使配置生效：gitlab-ctlreconfiguregitlab-ctlrestart最后就可以进入gitlab控制台进行测试和发送邮件了：gitlab-railsconsoleNotify.test_email('destination_email@address.com','MessageSubject','MessageBody').deliver_now还有两种配置方式，例如：sudodockerrun\--envGITLAB_OMNIBUS_CONFIG="external_url'http://my.domain.com/';gitlab_rails['lfs_enabled']=true;"sudodockerrun-eGITLAB_CDN_HOST=gitlab.youclk.com上面只是简写例子，我个人不推荐后两者，虽然环境变量设置的自由度更高，但是配置太多了，我还是喜欢替换或者挂载配置文件。经过上面的配置，整个gitlab的基本功能都具备了（以后有空再折腾一下CI/CD）。2.聚集到swarm这一步只需要准备两个编排文件，proxy：version:'3.5'services:proxy:image:vfarcic/docker-flow-proxy:18.04.06-12ports:-80:80networks:-代理环境：-LISTENER_ADDRESS=swarm-listener:18.04.06-12-MODE=swarmsecrets:-dfp_users_monitoringdeploy:labels:-com.df.notify=true-com.df.port=8080-com.df.serviceDomain=localhost-com.df.reqPathSearchReplace=/alive,/v1/docker-flow-proxy/pingrestart_policy:条件：任何max_attempts:3update_config:delay:5sorder:start-firstswarm-listener:image:vfarcic/docker-flow-swarm-listener:18.04.12-7网络：-代理卷：-/var/run/docker.sock:/var/run/docker.sock环境：-DF_NOTIFY_CREATE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/重新配置-DF_NOTIFY_REMOVE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/removedeploy:放置：约束：[node.role==manager]restart_policy：条件：任何max_attempts：3update_config：延迟：5s命令：start-firstnetworks：代理：外部：truesecrets：dfp_users_monitoring：外部：truegitlab：版本：'3.5'服务：gitlab：图像：gitlab/gitlab-ce主机名：gitlab.youclk.com网络：-代理-youclk端口：-2289:22卷：-/mnt/nas/gitlab/config:/etc/gitlab-/mnt/nas/gitlab/logs:/var/log/gitlab-/mnt/nas/gitlab/data:/var/opt/gitlabdeploy:mode:replicatedlabels:-com.df.notify=true-com.df.port=80-com.df.serviceDomain=gitlab.youclk.comrestart_policy:condition:anymax_attempts:3update_config:delay:5sorder:start-firstnetworks:proxy:external:trueyouclk:external:true然后依次启动即可，例：#create基础设施回声“youclk：****”|dockersecretcreatedfp_users_monitoring-dockernetworkcreate--driveroverlayproxydockernetworkcreate--driveroverlayyouclk#startupdockerstackdeploy-csrc/docker-compose-proxy.ymlproxydockerstackdeploy-csrc/docker-复制代码compose-gitlab.yml对gitlab的第一步进行了优化，如果不想太麻烦可以到这里结束，对服务的可用性不会有太大的影响。3.缓存和数据库分离。不知道为什么gitlab不提供更干净版本的镜像，官方推荐的omnibus安装方式，反正我不喜欢把数据库和缓存整合成一个镜像，期待是建个子镜像，去掉nginx、postgreSQL、redis。经过一番痛心的测试，还是要说，浪费了很多时间，但没有顺利达到目的，还是很遗憾。最后，postgreSQL和redis只能按照官方推荐在配置文件中禁用。首先准备一个db布局文件：version:'3.5'services:redis:image:redisnetworks:-proxy-youclkports:-6379:6379deploy:restart_policy:condition:anymax_attempts:3update_config:delay:5sorder:start-第一个postgresql:image:postgresnetworks:-proxy-youclkports:-5432:5432volumes:-/mnt/nas/db/postgresql:/var/lib/postgresql-$PWD/src/postgresql.conf:/etc/postgresql/postgresql.confdeploy:labels:-com.df.notify=true-com.df.port=5432restart_policy:condition:anymax_attempts:3update_config:delay:5sorder:start-firstnetworks:代理：外部：trueyouclk:external:true注意postgreSQL默认是禁用远程连接的，需要修改/etc/postgresql/postgresql.conf，反正是给内网用的，只要允许所有iplisten_addresses='*'即可，获取配置文件的方式:dockerrun-i--rmpostgrescat/usr/share/postgresql/postgresql.conf.sample>my-postgres.conf和我编排文件中的例子一样，挂载即可postgreSQL默认的用户名、密码和初始数据库都是postgres。可以通过设置环境变量更改默认配置：environment:-POSTGRES_PASSWORD=mysecretpassword-POSTGRES_USER=myuser-POSTGRES_DB=mydb最后修改gitlab的配置文件：#redisredis['enable']=false#RedisviaTCPgitlab_rails['redis_host']='redis'gitlab_rails['redis_port']=6379#禁用内置的Postgrespostgresql['enable']=false#填写数据库的连接细节.ymlgitlab_rails['db_adapter']='postgresql'gitlab_rails['db_encoding']='utf8'gitlab_rails['db_host']='postgresql'gitlab_rails['db_port']=5432gitlab_rails['db_username']='postgres'gitlab_rails['db_password']='postgres'gitlab_rails['db_database']='postgres'第二步优化结束，启动命令：cpgitlab.rb/mnt/nas/gitlab/config/gitlab.rbdockerstackdeploy-csrc/docker-compose-gitlab.ymlgitlab4。启用S??SL如果你的情况完全符合官方文档推荐的场景，很简单：external_url"https://gitlab.youclk.com"nginx['redirect_http_to_https']=truemkdir-p/etc/gitlab/sslchmod700/etc/gitlab/sslcpgitlab.youclk.com.keygitlab.youclk.com.crt/etc/gitlab/ssl/但一般来说，微服务中的证书、负载均衡、网关等属于外围基础设施，不会与应用挂钩。这个案例比较简单，因为根本不需要配置5.强迫症的救赎上一节提到在现在的微服务环境下启用SSL不需要任何配置，那我为什么要写这节呢？没脑子？好吧，就是脑残，而且是加上强迫症的脑残。先放一张图：什么是杀强迫症，你看得懂吗？或许我这辈子都不会用HTTP克隆代码了，但是弟弟就是受不了这个提醒，想想就头皮发麻，就像被万匹草泥马碾过一样。这个小毛病，让我吃不好，睡不好，胖了好几斤。我必须解决它。那么，不知道当时的状态是不是已经到了地狱的边缘。我的第一个想法是从源码中找到这个提示的逻辑，强行改成HTTPS（失败）；注入一段js修改提示（有修改延迟，还是受不了）；修改nginx的配置文件（成功）。最后的解决方案是先把external_url设置为https（这个绕不过去），然后因为只有http做负载均衡，所以先代理到https，再返回http（或者不返回），正好抵消external_url的配置,最后修改请求头即可：proxy_set_headerX-Forwarded-Protohttps;proxy_set_headerX-Forwarded-Ssl开启；现在是不是舒服多了……上面的测试花了将近一天的时间，就为了这么个玩意儿子，不过不管怎么样，总算是有结果了，总算稍微放心了。但是，你以为就这样结束了吗？这不，当我重新访问参考文档时，我发现了这样一个提示：#其他捆绑组件（Registry、Pages等）对代理SSL使用类似的策略。使用https://设置特定组件的*_external_url并在nginx[...]配置前加上组件名称。例如，对于注册表使用以下配置：://gitlab.youclk.com'nginx['listen_port']=80nginx['listen_https']=false效果是完全一致的，这时候就像是被万千泥马碾压来回一样。怎么没把参考文件拉到底，搞了个天大的笑话，血淋淋的教训！我的公众号《捷义》
