这是一个创建于 1624 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们有一个产品采用脚手架 full-stack-fastapi-postgresql 开发，在内部部署的时候都是用 gitlab + gitlab runner + docker swarm 部署。现在有需求要部署到客户内网，一下子傻眼了，难道要在客户内容搭建一套 gitlab ci 环境 然后把代码推送到客户的gitlab 来进行部署么？
 | 1 zlink 2021-06-21 10:08:18 +08:00 vpn ？ |
 | 2 youyi1996 2021-06-21 10:09:46 +08:00 都上 docker 了为啥不导出镜像拷贝到客户那边？ |
 | 3 killva4624 2021-06-21 10:12:58 +08:00 - 客户端内网服务器如果可以连接外网，可以考虑做一套或者找现成的轮子，实现自动轮询最新配置+自动变更（比如 Azure IoT ）; |
| 4 killva4624 2021-06-21 10:14:37 +08:00 - 如果客户端不能连接外网，那就找客户要一个连接外网的内网的服务器做中转，从这个服务器上连接 CI 和客户内网的部署环节，比如 Rundeck |
 | 5 Actrace 2021-06-21 10:20:20 +08:00 @killva4624 ，有点腿裤子放屁的感觉。 |
 | 6 liuxu 2021-06-21 10:21:29 +08:00 不用，这个方案我搞过，gitlab runner 有个 shell 模式，runner 在服务器内网安装，原理其实是 runner 定时每秒请求 gitlab 获取 event 执行 ci，只要内网有机器能访问到 gitlab 就行 |
 | 8 jackleeforce3615 OP @zlink 这个估计悬，可能还得升级公司基础设施（ VPN 网速不够） @youyi1996 感谢回复，这样镜像导出来好像没办法用 `docker swarm` 部署。 @killva4624 感谢回复，你说的这两个方案 我消化理解一下。 |
| 9 jackleeforce3615 OP @wengych 是 我们内网部署的时候有一台 `artifactory `，`gitlab-ci.yaml` 里面执行脚本把镜像 push 到 `artifactory`上面。然后执行 docker-swarm 命令拉取镜像部署。 现在看来感觉这个 registry 要放到外网。 |
| 10 jackleeforce3615 OP @liuxu 你的意思是在客户内网安装 `runner`， 只要客户内网 `runner ` 可以访问到我公司的 `gitlab` 就可以是把？ |
| 11 jackleeforce3615 OP 回复怎么不能支持 markdown . |
| 12 liuxu 2021-06-21 10:33:18 +08:00 |
 | 13 securityCoding 2021-06-21 10:42:35 +08:00 我们上了 k8s+helm ,helm 防火墙开放白名单 流程标准化后没那么累 |
 | 14 defunct9 2021-06-21 10:53:45 +08:00 开 ssh，让我上去看看。（刚弄完一套 gitlab + 2 处 git + harbor + argocd，网络一样复杂，穿越了 3 个机房） |
 | 15 pelloz 2021-06-21 10:54:35 +08:00 我问一下，客户服务器没有 k8s 或者 docker 的环境，也没有相应的运维资源去支持，你们都是怎么解决私有化部署的？ |
 | 17 clf 2021-06-21 11:02:00 +08:00 runner 在内网就行了，runner 开权限连 gitlab 就 OK 。runner 就是实际打包的机器。 镜像要不要推送到镜像仓库看你们需求。 |
| 18 killva4624 2021-06-21 11:07:26 +08:00 @Actrace 去年刚做过一个类似的场景，国内某大型企业，内网准入极其苛刻，前期研发手动 VPN 变更，后期为了大规模部署真是绞尽脑汁…… |
 | 19 ljhrot 2021-06-21 11:16:14 +08:00 建议放弃在内网折腾 CI/CD 的想法，大规模服务可以尝试使用 ansible 部署，就是包括基础环境和服务应用，做稳定版本的部署和升级就行了 |
 | 20 wengych 2021-06-21 11:18:48 +08:00  1 代码交付还是二进制交付，代码交付可以做 repo mirror，然后客户方面内网部署一套独立的 gitlab 和 cicd 如果是二进制交付，做一个白名单入口把 repository 开放给客户，客户主机可以用 puppet/ansible 之类的工具做配置管理。 |
 | 21 ghwolf007 2021-06-21 11:31:05 +08:00 内网完全物理隔离的情况我碰到过，之前用过搭 gitlab 的方式 很操蛋，后面转 k8s+helm 了， 镜像导出导入，helm install 一把梭/div> |
 | 22 robinlovemaggie 2021-06-21 13:17:51 +08:00 邮寄硬盘简单粗暴无脑解决私有化部署各种的弊端 |
 | 23 miao1007 2021-06-21 13:31:16 +08:00 via iPhone 内外网应该有 dmz 才对啊 |
 | 24 qizhca 2021-06-21 15:38:28 +08:00 如果是国电那种一区二区的内网，好像没有物理接触去部署以外更好的解决方案 |
 | 25 lework1234 2021-06-21 17:16:39 +08:00 docker-compose 一把梭 |
 | 26 Rush9999 2021-06-21 18:07:17 +08:00 1 docker export -o *.tar CONTAINER |
 | 28 lfzyx 2021-06-21 22:38:32 +08:00 招个 devops 运维工程师能解决 |
 | 29 adoal 2021-06-21 23:31:02 +08:00 via iPhone 需方内外网严格隔离、需方外包给外面单位开发而不是养自研团队、CI/CD，这三项不能流畅地兼顾，至少要放弃一项 |
 | 30 julyclyde 2021-06-22 13:52:34 +08:00 用反弹的 saltsstack 、gitlab-runner 之类的 |
| 32 jackleeforce3615 OP 大家都给了很好的思路，感谢！ 实际上我们这个产品刚开发完毕，还没有客户来当小白鼠。以后可能各种网络情况的客户都会碰到吧。 根据大家的回复，我整理了一下思路： 如果是客户可以访问外网的： 1.外网部署一个 gitlab + docker-registry( artifactory ) 2.公司内网 gitlab 的项目与外网 gitlab 做成 mirror 。 3.内网代码提交触发 CI 制作镜像, 并推到外网的 docker-registry 上，同时触发外网 gitlab mirror 项目的 CI, 这个 CI 在客户侧的 gitlab runner 上面执行，拉取镜像下来部署。 如果客户不可以访问外网。估计只能导出容器或者镜像到客户侧部署了吧。 这是最操蛋也是最无奈的做法。 不过考虑到我们这个产品不止有我们自创的镜像，还依赖一些公共服务镜像，如 redis,postgresql,traefik 等等，估计得逼客户开放外网。 |
Select Language