在云上做了一次 ops，感觉像是在烂泥里爬行

[levelworm]

当然如果是 bare metal 上肯定也好不到哪里去。

今天尝试把一个 Docker Image 推送到 Google Cloud ，然后用 Cloud Run 跑服务，遇到了无数的问题。先是 Docker 不熟练，需要用 Nginx 服务器把 MKDocs 编译出来的静态站点显示出来，研究了半天 Dockerfile 的语法，终于用双 Docker 的方法搞定了。本地上能够用 127.0.0.1:80 来访问，第一阶段成功。

接下来是把 Docker Image 放在 Cloud Run 上跑。碰到了许多问题——首先是许可不足，搜索了一下，发现可以用 impersonate service account 的方法借服务账号的权限。第一次成功了，把 Docker Image 推送到了 Artifact Registry ，但是 Cloud Run 怎么跑也跑不出来，看 log 什么也没有。这次折腾了不少时间，后来发现，原来是自己脑残，M1 上 build 的不能在云端用，必须是 amd64 的。

重新编译了之后再次推送，老问题出了新花样，不知道什么原因总是说我没有 crendential ，折腾了老半天，只好用另外一种办法给 docker 推送的权限，这次总算搞定了。最后一步就是访问 Cloud Run 的网站，发现 Cloud Run 的 url 总是显示 403 ，原来是需要 token ，但是 Chrome 上改 header 十分麻烦，最后用 Modheader 解决了。

当然事情还没做完，之后还要研究怎么用 GitHub Action 来做 CICD ，不然如何做到动态部署呢？当然今天实在是没心思搞了，明天继续。

我的感想就是，让我们这种没做过开发的人做 Ops ，真是受罪。我从来没用过 Nginx 的人，哪里知道怎么设置？更别说还得在 Docker 里写额外的设置。我也没弄过 Cloud Run ，它是有 doc ，问题是 doc 未必能解决我的问题，最后还是 Stackoverflow 一把梭。好在本人搜索技能尚可，所有的东西都能搜到。看来搜索能力的确是我们这种挫逼的必备技能。

[Chad0000]

建议使用 Azure DevOps ，GitHub actions 局限太多。

[levelworm]

@Chad0000 1
多谢啊，可惜没这个，我们部署在 Google Cloud 上，且只能用 GitHub Action 或者 Jenkins ，后者更不熟悉了。。。

[yin1999]

可以用 Google 云的 cloud build 做 cicd ，这个简单，也能用 GitHub push 到指定分支触发，不过配置文件一开始写起来可能比较麻烦，你可以尝试先在 cloud function 里面建一个代码编译运行的实力

[yin1999]

@yin1999 接 #3 ，就是通过自动拉取仓库代码构建的实例，它会在 cloud build 里面生成一个 build 的任务，拷贝里面的 yaml 文件，依样画葫芦写一个适用于 cloud run 的，我去年是这么搞的，可以试试

[defunct9]

开 ssh ，让我来

[levelworm]

@yin1999 多谢，我倒是想用这个，但是经理建议先试试看 GA 。对我来说都是新东西，都行。。。

[AS4694lAS4808]

楼主没做过开发？那岗位是？

[calmzhu]

“让我们这种没做过开发的人做 Ops ，真是受罪”

为什么会有这种错觉,小白第一次做 Ops 就必须上帝护体 一帆风顺?

自信点,不用加限定. “让这种没做过 xx 的人做 xx ，真是受罪” 绝大多数都是正常的.

[ck65]

没经验就可以终结话题了，心里话写在日记里多好。

[xuanbg]

OP 这样的经历已经算是非常顺畅的了呀！哪有第一次就能一路顺畅毫无问题的。做过一次就会了不是。

[levelworm]

@AS4694lAS4808 7
按照做的东西来看，一半写 ETL 一半做 ops 。。。好吧 ETL 也算开发。

[levelworm]

@calmzhu 8
我觉得做过开发用过 Nginx 的人，大概能好点？

[levelworm]

@ck65 9
我忘记有这个版块了！

[xiaket]

没经验就好好学, 不要乱 stackoverflow.

[levelworm]

@xuanbg 10
多谢，就是做的真心头大，坦白地说我觉得可能一天做出来，也可能一百天也做不出来。。。纯粹是到处拼凑出来的。我其实很想在 bare metal 上从头做一遍。

[levelworm]

@xiaket 14
文档还是培训？培训就不说了，说的特别浅。文档嘛，的确找到不少，问题是文档也不会说包解决啊，只有 SO 是确定一定会有各种场景的。很多文档的链接其实也是从 SO 找到的。。。

[calmzhu]

@levelworm
第一次用都一样..

[levelworm]

@calmzhu 17
原来如此。我好希望能有个大部头的书看这些（可能是早期用 MSSQL 留下的印象，SQL Server 有很多很详细的大部头），不过好像自从入行之后，最多的是看文档和查 SO ，很多开源工具连书都没有。

[learningman]

@levelworm #18 这年头，等书印出来了 API 可能都变了，甚至整个工具都过时了，有文档不错了，前端有的工具给个 TS 类型自己看源码吧

[levelworm]

@learningman 19
看来的确不能期望太高啊。。。前几年做 Vertica 的时候，一翻书都是 15 年之前的，就弃疗了，只能看文档。这种数据库（包括 BigQuery ）的 internal 似乎也没有书。

[AS4694lAS4808]

@levelworm 怎么感觉像是 DBA+运维。。？但是运维对云原生这种东西应该很熟吧。。那 ETL 涉及到清洗分析的话，算是大数据？是的话可能确实对云原生不太了解。但是

慢慢学吧，都有这种时候，除非跑路，哈哈

[mysalt]

第一次就能让你这么顺畅的跑下去，那还要专门的 Ops 团队干啥呢。而且 Google Cloud 有专门的 DevOps 证书的，要不先考个证再上岗？

[GopherDaily]

从实际体验来说， 云确实极大的降低的了运维成本，提供了更丰富的功能，更弹性的伸缩。

但是这依然是一个非常专业的领域，主要还是面向专业客户。

[levelworm]

@AS4694lAS4808 21
也不是，目前就是一个混杂的东西，现在只能做做 做底层的梦了。实在没时间在上课之外自学。

[levelworm]

@mysalt 22
哎坛贤说的也是，这玩意的确需要经验。好在我这服务是对内的。

[linuxyz]

CI/CD 显式脚本化的好处： 把手动的不确定性和隐性时间成本给消除了。

换一种方式说就是： 强迫开发人员用自动化流水线的方式来固化所有的步骤。

[BeautifulSoap]

云服务不熟的话，建议直接用自带的 code build 来构建镜像，因为官方会有相对完善的指导

https://cloud.google.com/build/docs/build-push-docker-image?hl=zh-cn

[lscho]

docker 不会，Nginx 没用过，没做过开发，竟然最后都能让你跑起来。这还不足以说明云+ops 足够简单和方便了吗？什么叫烂泥里爬行？简直是机器人指导盲人走路了。

让你传统部署你更搞不定。

[anubu]

错误的期望管理。
外科医生不会在第一次给别人做心脏手术时就期望很顺利。当然，事实上外科医生不可能去做心脏手术。
计算机从业人员往往都有一种认知，RTFM ，我什么都能干。事实上，可是差不太多，啃啃文档，大部分的确能理解，实践环境也不难找，不用像医生在大活人身上试水。但毕竟还是分了一些职能和岗位，且不说文档质量怎么样、实践前对文档的理解怎么样，至少不应该期望很简单就配置完了，如果这么简单，它早就是一个按钮了。

[levelworm]

@lscho 28
其实好希望在 bare metal 上试一下。。。估计是比较复杂。

[levelworm]

@anubu 29
问题在于外科手术有人带，这个吧，目前没人带，所以就比较懵逼。换句话说就是纯粹碰运气了，搜到了就有了，搜不到我哪里知道这么多选项指的是什么意思。。。也许给我一个月的时间从头到尾看完文档能好些，但是还是 SO 更靠谱一些。

[levelworm]

@BeautifulSoap 27
多谢，只不过经理希望用 github action ，所以我用这个试试看。今天运气好，折腾了半天搞定了 CICD ，本来以为还需要好几天的，这几天运气都蛮好的。。。