这是一个创建于 1280 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们有一个产品采用脚手架 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 一把梭
|
 |
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