最后更新2022/04/12
google的课程没搞明白，好多重复，也无所谓了，可能更适合我这种看书学习不求甚解的人——一遍一遍深入嘛，每看一遍相关的内容，做一遍笔记，自然就了解得更多，可能也解决了相应的问题。由于大部分都已经重复过，这里只记录一些以前忘记的，重要的，有意思的东西。
有四种方式可以访问GCP，gui console；shell；API（SDK，Library，RESTful API）；最后是cloud mobile api，就是手机上用的东东。
shell里执行的命令其实也是API的一部分，例如常用的gcloud，gutil命令以及bq(bigquery); Library则支持大部分脚本语言，python，ruby，java，php，go，node.js等；
storage bucket的名字要全局unique的，就是不仅仅自己项目，和它人项目，全局的都要unique，这个么，也算合理，毕竟大家都在一个url里，中间没有项目信息分层，算是一种安全设定（隐藏了project信息），但同样也有了其它的不安全，不过由于有缺省不可访问的用户限制，未授权也没法访问，就是知道有这个名字，也没什么重要的。
cloud shell存在于一个新建的vm里，缺省5G home空间，并且永久保存（为此用户？），如果一小时不操作此vm，自动回收，但/home会保留，而别的环境变量、全局设置等等任何不在/home下的东西都没了。
在cloud shell里还可以上传、下载文件，直接保存在/home下，命令要通过菜单里面的三竖点找到。
由于cloud shell重开，一切非/home的东西都消失，所以如果想保留什么环境变量，需要编辑.profile，把参数保存到里面。由于cloud shell是独立的vm，也不受project的限制，因此可以通过环境变量更改与之关联的project。不更改也没关系，只是使用命令时要指定project，否则就会用缺省的。
gcp marketplace提供了打包好的模板，可以快速安装、实现，它利用google的deployment manager组件完成，估计是terraform写的模板。
正常来说，部署好之后，通过给定的外网地址，登录就可以了，但我遇到了好多次cloud web访问失败、中断，等各种问题，最后解决方案就是没啥方案：刷新，重来等等，很头痛。cloud就这个？！当然，有各种原因，例如当前的学习账号刷新了两次，实验做得不对，后台维护，需要等等任务真正完成，总之，你是不知道啥地方出问题的，没啥方案，重来是唯一的方案。这大概是我不喜欢云的最根本原因吧。
vpc network
有三种类型：default、auto mode，custom mode
- default用于project，缺省的，每个region一个subnet，设置了基本的firewall rule，这个算是预定义吧，每个project初始就定义好了这个default的vpc，以及它的一堆subnet。按照规则，每个region有一个subnet，跨越这个region的所有zone。
- auto mode是有别于default但其实还是default的，预设置的network，在创建计算引擎之类的东西时自动使用auto mode的网络。还是每region一个subnet，一般是20位掩码，可以扩展到16位。
- custom mode和auto mode几乎相同，区别是自己设定IP subnet，只要不和其它default和auto mode的网络冲突即可
subnet可以在同一个region内跨zone，可以扩大，但不能缩小，而且由于subnet太大对网络性能没什么好处，如非必须，subnet还是越小越好。subnet扩大的时候仅可与临近的可用子网网段合并（付合CIDR），如果相邻的子网被使用，且不能与之统一，那就不能扩展了。
vm的IP都是dhcp获得的，租期为24小时，IP地址通过vm name注册到本网络DNS，同时，会有external（internet）IP地址映射过去，当然，你可以不设外部IP，这样就Internet就访问就不能直接联通此VM。即使有外部IP，vm自身也不知道外部IP是什么，这是通过地址映射（NAT）完成的。外部IP可以来自pool，可以固定，也可以由你自己提供（BYOIP, bring your own IP), BYOIP复杂一些，需要到BGP之类的网关服务做修改，具体不在这里考虑如何实现。
每个VM的内部FQDN是这样的（不知道那个c是啥意思，customer？），对应的hostname，zone，project-id需要按照对应的情况自动设置：
[hostname].[zone].c.[project-id].internal
网络数据传输收费
数据传输是要钱的！（真实）IP地址是要钱的！有如下标准：
-
流入数据，免费
-
流出数据，zone内部，免费
-
流出数据，访问google产品（youtube，map什么的），免费
-
流出数据，另一种GCP的服务（跨区region），免费
-
流出数据，跨zone，1GB 1分钱（$）
-
流出数据，zone内部，但访问外部IP，1GB 1分钱（$）
-
流出数据，跨区（region），但同属EMEA（美洲大陆），1GB 1分钱（$）
-
流出数据，跨区（region），洲际，费用另有详细，各处不同
-
静态IP地址（分配了，但没使用），1分钱/小时（$）
-
静态或者动态IP，使用了，4厘/小时($)，为啥使用的比分配了不用还便宜？大概是希望不要占着IP地址吧？！
-
用于抢占任务（其实是插空，有空闲时启动，并非抢夺正运行的）的vm的静态或者动态IP，2厘/小时($）
-
转发规则用的静态或者动态IP，免费（为什么呢？应该是可以根据端口共享，也就是别人可以借用这个IP）
一个VPC可能（其实不是可能，就是有，每个region/zone都会给一个subnet）有很多个subnet，但它们之间路由是通的而且subnet也可以跨越的。反而在两个vpc，即使属于同一zone，也是不通的。
创建subnet时，如果没有选择Private Google Access on，则通过此subnet无法访问google的service，包括bucket等任何google服务。当然，如果此vm可以访问internet，则没问题，google service可以透过internet进行访问。
当vm没有外部IP，还要访问外部时，可以采用对其网络做NAT路由的方式，就是对应得内部网络建一个cloud NAT，则使用此内部网的vm就可以通过路由访问外部了。
通过cloud shell访问某个vm，如果它没有external IP，直接访问是不行的，需要做个tunnel，命令如下：
gcloud compute ssh vm-name --zone us-central1-c --tunnel-through-iap
当然，另一个前提条件是通过cloud shell的internal IP到此vm的防火墙是OK的。路由呢？路由缺省就自动在创建vm的subnet时就设置了。
VM Lifecycle，这张图很好，赞。
有关storage的信息比较简单，4种storage，persistent disk，persistent ssd，local ssd，memory disk，各有优缺点。首先这些disk都与boot disk无关（也不能做boot disk），然后就是性能。persistent ssd和local ssd相比，local ssd最多8个375G，共3T，可靠性差一些，延迟更少。memory disk 则是可能丢数据。大概是这样吧，没啥特别的说法。
