怒涛小站

chf007 的自留地，分享不多，想写就写

Gitlab 仓库迁移 Coding 指引

因公司决策将代码仓库从 Gitlab 换成 Coding，在此记录一下迁移过程。

  1. 针对要迁移的 Gitlab 仓库提醒涉及的团队成员及时提交和推送要保留的本地分支，本次迁移只迁移 Gitlab 服务器上现存在分支、Tag、历史记录
  2. 将要迁移的 Gitlab 仓库进行归档，此时仓库为只读状态不能提交和推送
  3. Coding 中建立一个新的空仓库，不需要初始化
  4. Coding 个人设置中添加 SSH 公钥，建议和 Gitlab 中的个人公钥保持一致
  5. 执行以下命令克隆 Gitlab 仓库裸库到本地 git clone --bare git@gitlab.xxx.com:xxx-fe/xxx-webapp.git ( 以下皆以 xxx-fe/xxx-webapp 为例，实际操作中要换成真实的仓库 )
  6. 进入 xxx-webapp.git 目录，执行 du -d 1 -h 查看仓库体积，Coding 对仓库体积大小有限制
  7. 检查仓库体积无问题后，执行 git push --mirror git@e.coding.net:yyy/tw/xxx-webapp.git 命令推送裸仓库至 Coding 建好的空仓库中 (地址 git@e.coding.net:yyy/tw/xxx-webapp.git 从建好的 Coding 仓库中获取)
  8. 刷新 Coding 仓库，检查是否推送成功，检查分支、Tag、历史提交记录是否正常，并转移至相关分组
  9. 重新从 Coding 拉取代码或更改本地仓库 git 远程地址
  10. 酌情迁移 .gitlab-ci.yml 至 Jenkinsfile (注意 Jenkinsfile 和 Jenkins 手工配置只能留一个)

Coding 公钥拉取失败提示 Permission denied(publickey)：https://help.coding.net/docs/repo/faq.html#permission-denied
Coding 的公钥配置拉取代码如果失败，按这个配置一下，说明 git 版本太新，默认不支持 RSA 密钥了，需要配置一下支持 RSA

Coding 不支持个人空间，自已有在 Gitlab 个人空间中有仓库的，自行备份处理

Coding 不支持代码片段，自已有在 Gitlab 中有代码片段的，自行备份处理

Gitlab 中有用的 issue 建议迁移到 Coding 中的任务

Gitlab 中有用的 wiki 建议迁移到 Coding 中的 wiki

有同时在搞公司项目在外面又有个人 github 项目的，切记不要误把公司代码提交到 github 上去，任何代码代码仓库（不管公司内部的还是外部的）里切记不要提交实际在用的密码密钥之类的敏感信息!!!

GitlabCodingGit
添加评论

使用 kubectl 及 kubetail 查看腾讯云 TKE 日志

腾讯云 TKE 默认自带的查看日志功能比较薄弱，日志刷新缓慢，有延迟，查看费劲。腾讯云 TKE 支持 K8S 标准协议，我们可以自已安装 kubectl，连上线上环境 K8S 集群，直接看日志分析问题(其它厂商 K8S 集群同理)。主要方法如下：

注，以下都是在 Mac 系统中操作，其它系统自行搜索解决

1. 安装 kubectl

1.1 下载 kubectl 二进制文件

1
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.8.13/bin/darwin/amd64/kubectl

会下载一个单独的二进制文件 kubectl 到下载目录 （要翻墙，其中版本号信息在路径中可以改成自已想要的）

1.2 给 kubectl 添加执行权限

1
chmod +x ./kubectl

1.3 复制到你系统的 PATH 环境变量目录中，这样你就可以在任意地方调用

1
sudo mv ./kubectl /usr/local/bin/kubectl

1.4 测试安装成功没有

1
kubectl version

会输出一些基本信息

2. 连接集群 (!!#ff0000 内容已过期，连接集群请参考 TKE 集群基本信息里的步骤!!)

2.1 选好你要操作的集群，准备好集群配置信息，主要有

  • 用户名
  • token/密码
  • 集群 CA 证书（要下载）
  • 集群外网访问地址

配置信息在这里找

tke01.png

tke02.png

2.2 设置 kubectl 全局配置信息

1
2
3
4
5
# 注意，新版 TKE，已经没有用户名密码方式登录了，要换用证书
kubectl config set-credentials see-xdb-prod-admin --username=${用户名}--password=${token/密码}
kubectl config set-cluster see-xdb-prod-cluster --server=${集群外网访问地址} --certificate-authority=${下载到本地的集群CA证书路径，例如/etc/kubernetes/cluster-ca.crt}
kubectl config set-context see-xdb-prod --cluster=see-xdb-prod-cluster --user=see-xdb-prod-admin
kubectl config use-context see-xdb-prod

以上配置信息会写入 ${HOME}/.kube/config 下，设置错了，或想切别的环境的集群，可以直接去改配置文件

其中 see-xdb-prod、see-xdb-prod-cluster、see-xdb-prod-admin 分别是本地配置的 K8S 集群的 context、cluster、credentials 的名字，可以取任何名，只要能和其它 K8S 集群的配置区分开就行，此处可替换成自已组织的名字

2.3 测试是否生效

1
kubectl get pods --all-namespaces

会输出当前部署的pod，例如

tke03.png

3. 使用 kubectl 查看日志

3.1 先列出所有 pod，找出自已想看日志的 pod，把名字记下来

1
kubectl get pods --all-namespaces

tke04.png

3.2 查看日志，例如我想看 mapi 的日志，其它例如 prisma 的日志同理

1
kubectl logs -f mapi-db74bc5ff-25brz --namespace=production

tke05.png

注意，要加命名空间名

kubectl 更多用法请查看相关文档。

3.3 kubectl 查看日志的缺点

  • 每次只能查看一个 pod 的日志，我们在线上每个应用往往要起多个 pod，例如 mapi 就起了 8 个
  • 要查看 pod 的日志，只能用 pod 全名查看，而 pod 每次部署，名字会变，不支持通配符或按 label 查看

所以推荐一个第三方的脚本工具 kubetail，用 shell 写的，支持多个 pod 同时查看，还支持不同 pod 日志颜色不同，方便区分，安装方法如下

4. 安装查看日志工具 kubetail

1
brew tap johanhaleby/kubetail && brew install kubetail

测试是否安装成功

1
kubetail

tke06.png

查看日志，例如我要查看线上环境所有 mapi 开头的 pod 日志

1
kubetail mapi -n production

tke07.png

就可以看到所有 mapi 开头的 pod 日志，各个 pod 还有颜色区别，详细用法请看 github

Kubernetes
添加评论

一种适用于中小团队的 Git 工作流

  1. 前端应用只有三种分支类型：主干分支、特性分支、发布分支。
  2. 约定 master 为主干分支，代表当前生产环境最新代码，设为保护分支，只允提 MR 合并，不允许直接推送。
  3. 开发一个需求前
    3.1. 每人从 master 分支新建自已的特性分支，命名规则 feature/YYYYMMDD-xxx，其中 YYYYMMDD 代表需求所属迭代要发布的日期，xxx 可以根据自已要做的功能特性以简短有意义的英文命名。如 feature/20201111-productBannerUpdate。
    3.2. TL、项目 Owner 或其他有权限的人，预先从 master 分支新建发布分支，命名规则 release/YYYYMMDD[-xx]，其中 YYYYMMDD 代表需求所属迭代要发布的日期。发布分支暂时设为保护分支，不允许随意合并。[-xx] 说明见 5.2。
  4. 开发完成，需要部署开发/测试各环境时
    4.1 每人推送自已的特性分支到远程 Gitlab 仓库中。
    4.2 在 Gitlab 中发起 MR 请求，源分支为自已的特性分支，目标分支为 3.2 中建好的相应迭代的发布分支。
    4.3 TL 或项目 Owner 进行简单的代码 review，检查无问题后合并代码。
    4.4 TL 或项目 Owner 在 CI 系统各环境流水线中部署相应发布分支。
  5. 需要发布生产环境时
    5.1 TL 或项目 Owner 再次确认本次迭代要上线的需求已是否合入相应发布分支中，如无问题，则在 CI 系统 UAT 或生产环境流水线中部署相应发布分支。发布成功后，将发布分支合并到 master 分支，并打 Tag。
    5.2 如果有本次迭代不需要上线的特性分支，则 TL 或项目 Owner 从 master 分支新建一个新的发布分支，命名规则为当前迭代的发布分支名末尾加上 -01，需要多次重复此步骤的就多次执行此步骤，结尾加 1 即可。确定如无问题，则在 CI 系统 UAT 或生产环境流水线中部署相应发布分支。发布成功后，将发布分支合并到 master 分支，并打 Tag。
    5.3 发布 Tag 应设为保护 Tag，不允许随意创建。
  6. 需要修复生产环境问题时
    6.1 从 master 分支或相应 Tag 新建 hotfix 分支（本质上还是特性分支），命名规则 hotfix/xxx。
    6.2 修复问题后，直接发布 hotfix 分支到相应环境验证，无问题后直接发布生产环境，生产环境发布成功后，将该 hotfix 分支合并到 master 分支，并打 Tag。
  7. 发布分支合并冲突解决策略
    7.1 有条件的应在 release 分支上解决冲突。
    7.2 如无 release 分支权限，应基于 release 分支拉一个临时分支解决冲突并合回 release 分支。注意：release 分支如有撤出发布的分支，应基于新的 release 分支重新执行该步骤（有条件的，应优先使用 7.1 的方式解决冲突）。
    7.3 不要使用 Gitlab 自带的在线解决冲突工具。
其它Tips
  • 每人在开发过程中，各自的特性分支应随时合并 master 分支上生产环境最新代码。
  • 发布分支应随时合并 master 分支上生产环境最新代码。
  • 每人的特性分支应按照需求尽量原子化，做到可单独上线或临时不需要上线时不用再手工剔除代码。
    • 原子化的颗粒度由个人把控，接到一个需求可以拆成多个分支，也可以就一个分支，只要符合上述原则就行。
    • 在实际开发中，遇到大的项目可能会出现在开发阶段有依赖其他人的代码的，例如一些公共逻辑，这些公共逻辑应由单独一个特性分支维护。每人根据具体情况，合并到自已的特性分支，或自已再维护一个临时分支，以保持自已的特性分支的纯洁性。
  • 为尽量避免合并冲突，各项目应分析代码库中多人频繁操作的文件，如路由配置文件、接口定义文件等，按模块进行拆分，避免多人同时改动同一个文件的情况出现。
  • 前期人工操作多，且瓶颈在 TL 或项目 Owner 身上，最好工具化。
  • 主要参考 AoneFlow 分支管理模型，参见 在阿里，我们如何管理代码分支？ 只适合 Web 这种生产环境只有一种最新业务形态的场景，手机 APP、私有化部署等 这种需要同时保留多个生产版本的场景并不适用。
GitlabGit
添加评论