DevOps-Gitlab命令使用、实现代码上传与下载示例、数据备份恢复、汉化与常见代码部署方式
SVN 与 CVS：
每次提交的文件都单独保存，即按照文件的提交时间区分不同的版本，保存至不同的逻辑存储区域，后期恢复的时候直接基于之前版本恢复。
Gitlab：
Gitlab 与 SVN 的数据保存方式不一样，gitlab 虽然也会在内部对数据进行逻辑划分保存，但是当后期提交的数据如果和之前提交过的数据没有变化，其就直接快照之前的文件，而不是在将文件重新上传一份在保存一遍，这样既节省了空间又加快了代码提交速度。
git常用命令
Git global setup git config --global user.name "Administrator" git config --global user.email "admin@example.com"
git remote remove origin # 移除仓库 Create a new repository git clone http://gitlab.magedu.com/mao/lmweb1.git cd lmweb1 touch README.md git add README.md //将当前目录下代码提交到本地暂存区" git commit -m "add README" //"为描述信息，将当前目录下代码提交到本地仓库" git push -u origin master //上传到远程仓库 Push an existing folder cd existing_folder git init git remote add origin http://gitlab.magedu.com/mao/lmweb1.git git add . git commit -m "Initial commit" git push -u origin master
git push -u 是 Git 中的一个常见命令，用于将本地分支推送到远程仓库，并将本地分支与远程分支关联起来。
具体含义如下：
git push: 是用于将本地分支推送到远程仓库的 Git 命令。-u或--set-upstream: 是git push命令的一个选项，用于在推送分支时设置本地分支和远程分支之间的关联。
当你在本地创建了一个新的分支并想将其推送到远程仓库时，使用 git push -u 可以实现以下功能：
- 将本地分支的修改推送到远程仓库。
- 在远程仓库中创建一个与本地分支同名的远程分支。
- 建立本地分支与远程分支之间的关联，使得以后可以使用
git push或git pull命令时自动关联到对应的远程分支。
例如，如果你在本地创建了一个名为 feature 的分支，并想将其推送到名为 origin 的远程仓库中的同名分支，你可以使用以下命令：
git push -u origin feature
通过使用 -u 参数，Git 将在推送分支的同时设置本地分支 feature 与远程分支 origin/feature 的关联。这样，以后在该分支上执行 git push 或 git pull 时，Git 将自动关联到远程分支 origin/feature。
其他
报错：error: src refspec main does not match any
git checkout -b main
移除仓库
git remote remove origin http://172.16.xx/root/xxx.git
查看仓库列表
git remote -v
Push an existing Git repository cd existing_repo git remote rename origin old-origin git remote add origin http://gitlab.magedu.com/mao/lmweb1.git git push -u origin --all git push -u origin --tags
git push -u origin --all 和 git push -u origin --tags 是用于将本地所有分支和标签推送到远程仓库的 Git 命令。
具体含义如下：
-
git push -u origin --all: 这个命令将本地所有分支推送到名为origin的远程仓库。使用-u参数设置本地分支与远程分支之间的关联。通过--all参数，所有本地分支都会被推送到远程仓库，包括新创建的分支和已存在的分支。 -
git push -u origin --tags: 这个命令将本地所有标签推送到名为origin的远程仓库。同样，使用-u参数设置本地标签与远程标签之间的关联。通过--tags参数，所有本地标签都会被推送到远程仓库。
这两个命令在首次推送本地分支或标签到远程仓库时非常有用。使用 -u 参数建立本地和远程分支/标签之间的关联，使得以后可以使用 git push 或 git pull 命令时自动关联到对应的远程分支/标签。
请注意，在执行这两个命令之前，确保已经将远程仓库 origin 添加为本地仓库的远程地址，使用命令 git remote add origin <repository_url>。
git config --global user.name “name“ #设置全局用户名 git config --global user.email xxx@xx.com #设置全局邮箱 git config --global --list #列出用户全局设置 git add index.html / . #添加指定文件、目录或当前目录下所有数据到暂存区 git commit -m “11“ #提交文件到本地仓库,""为描述信息 git status #查看工作区的状态 git push #提交代码到服务器 git pull #获取代码到本地，从远程仓库获取最新版本的代码到本地，clone为完整版 git log #查看操作日志 vim .gitignore #定义忽略文件 git reset --hard HEAD^^ #git 版本回滚， HEAD 为当前版本，加一个^为上一个，^^为上上一个版本 git reflog # #获取每次提交的 ID，可以使用--hard 根据提交的 ID 进行版本回退 git reset --hard 5ae4b06 #回退到指定 id 的版本 # git branch #查看当前所处的分支 #git checkout -b develop #创建并切换到一个新分支 #git checkout develop #切换分支
git 缓存区与工作区 等 概念
工作区：clone 的代码或者开发自己编写的代码文件所在的目录，通常是代码所在的一个服务的目录名称。
暂存区：用于存储在工作区中对代码进行修改后的文件所保存的地方，使用 git add 添加。
本地仓库：用于提交存储在工作区和暂存区中改过的文件地方，使用 git commi 提交。
远程仓库：多个开发共同协作提交代码的仓库，即 gitlab 服务器。
示例：
]# cd lmweb1/ [root@jenkins lmweb1]# ll -rw-r--r--. 1 root root 74 Dec 16 06:32 index.html [root@jenkins lmweb1]# git status # On branch master nothing to commit, working directory clean [root@jenkins lmweb1]# mkdir app1 [root@jenkins lmweb1]# cd app1/ [root@jenkins app1]# vim index.html [root@jenkins app1]# cd ..
[root@jenkins lmweb1]# git add . [root@jenkins lmweb1]# git status //可以看到缓存区有待上传文件 # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: app1/index.html [root@jenkins lmweb1]# git commit -m "this is app1" [master c6cdc3e] this is app1 1 file changed, 1 insertion(+) create mode 100644 app1/index.html
[root@jenkins lmweb1]# git status //再次查看工作区状态 # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use "git push" to publish your local commits) # nothing to commit, working directory clean
[root@jenkins lmweb1]# git push //上传到远程仓库
Username for 'http://gitlab.magedu.com': laomao Password for 'http://laomao@gitlab.magedu.com': Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 364 bytes | 0 bytes/s, done. Total 4 (delta 0), reused 0 (delta 0) To http://gitlab.magedu.com/mao/lmweb1.git 46dcbb6..c6cdc3e master -> master
.gitignore文件讲解
# 文件名称固定，用于说明
# 暂时上传到主分支
# 当文件名称被定义到gitignore，表示app3,README.md这些文件不需要上传到远程仓库，执行git push不会上传
app3
.README.md
版本回滚
git reset --hard HEAD^^ #git 版本回滚， HEAD 为当前版本，加一个^为上一个，^^为上上一个版本
git reflog # #获取每次提交的 ID，可以使用--hard 根据提交的 ID 进行版本回退
git reset --hard 5ae4b06 #回退到指定 id 的版本
分支管理
# git branch #查看当前所处的分支 # git checkout -b develop #创建并切换到一个新分支 # git checkout develop #切换分支
数据备份恢复
停止 gitlab 数据服务
# gitlab-ctl stop unicorn ok: down: unicorn: 1s, normally up # gitlab-ctl stop sidekiq ok: down: sidekiq: 0s, normally up
手动备份数据
# gitlab-rake gitlab:backup:create #在任意目录即可备份当前 gitlab 数据
# gitlab-ctl start #备份完成后启动 gitlab
查看要 恢复的文件
/var/opt/gitlab/backups/ # Gitlab 数据备份目录，需要使用命令备份的
/var/opt/gitlab/nginx/conf #nginx 配置文件
/etc/gitlab/gitlab.rb #gitlab 配置文件
/etc/gitlab/gitlab-secrets.json #key 文件
# ll /var/opt/gitlab/backups/ total 408 drwx------ 4 git root 4096 Jul 17 10:42 ./ drwxr-xr-x 20 root root 4096 Jul 17 10:11 ../ -rw------- 1 git git 92160 Jul 17 10:20 1563330030_2019_07_17_11.11.5_gitlab_backup.tar -rw------- 1 git git 92160 Jul 17 10:23 1563330216_2019_07_17_11.11.5_gitlab_backup.tar -rw------- 1 git git 92160 Jul 17 10:30 1563330647_2019_07_17_11.11.5_gitlab_backup.tar -rw------- 1 git git 92160 Jul 17 10:32 1563330751_2019_07_17_11.11.5_gitlab_backup.tar
执行恢复
# gitlab-ctl stop unicorn # gitlab-ctl stop sidekiq #恢复数据之前停止服务 # gitlab-rake gitlab:backup:restore BACKUP=备份文件名
启动服务
# gitlab-ctl start sidekiq ok: run: sidekiq: (pid 16859) 0s # gitlab-ctl start unicorn ok: run: unicorn: (pid 16882) 1s
gitlab汉化
下载语言包替换 https://gitlab.com/xhang/gitlab # gitlab-ctl stop # tar xvf gitlab-vX.Y.Z-zh.tar # cp -rp /opt/gitlab/embedded/service/gitlab-rails /opt/gitlab-rails.bak #备份源文件 # cp -rf gitlab-vX.Y.Z-zh/* /opt/gitlab/embedded/service/gitlab-rails/ #替换文件 # gitlab-ctl reconfigure # gitlab-ctl start
通过源码 汉化： ： https://gitlab.com/xhang/gitlab #汉化包地址 # gitlab-ctl stop # git clone https://gitlab.com/xhang/gitlab.git # head -1 /opt/gitlab/version-manifest.txt #查看当前 gitlab 版本 # cd gitlab # git diff v11.11.8 v11.11.8-zh > /root/v11.11.8-zh.diff # patch -f -d /opt/gitlab/embedded/service/gitlab-rails -p1 < /root/v11.9.8-zh.diff # gitlab-ctl reconfigure # gitlab-ctl start
Web 界面更改语言：
右上角的账户下拉框选 Settings 然后左侧 Preferences 设置项，然后语言选择中文
常见代码部署方式
蓝绿部署：
蓝绿部署指的是不停老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。
比如生产环境有一个域名给用户来访问，这个域名解析的IP是V1版本的IP地址，通常是VIP或防火墙映射出去的IP，后面代理了N多个业务服务器。同时给这个机器绑定多网卡，研发运维测试等通过主机hosts映射访问V2版本IP，这个V2 IP也代理了一部分业务服务器，通过临时解析就可以实现访问同一个域名，访问两套环境。
具体过程：
1、当前版本业务正常访问(V1)
2、在另外一套环境部署新代码(V2)，代码可能是增加了功能或者是修复了某些 bug
3、测试通过之后将用户请求流量切到新版本环境
4、观察一段时间，如有异常直接切换旧版本
5、下次升级，将旧版本升级到新版本(V3)
蓝绿部署适用的场景：
1、不停止老版本，额外部署一套新版本，等测试发现新版本 OK 后，删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
金丝雀发布：
金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。
金丝雀发布、灰度发布步骤组成：
1、准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器。
3、升级“金丝雀”应用（排掉原有流量并进行部署）。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度发布/金丝雀部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如 90%的用户维持使用老版本，10%的用户尝鲜新版本。
3、经常与 A/B 测试一起使用，用于测试选择多种方案。
滚动发布：
滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
A/B 测试：
A/B 测试也是同时运行两个 APP 环境，但是蓝绿部署完全是两码事，A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等，蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚，即蓝绿部署是一套正式环境环境在线，而A/B 测试是两套正式环境在线。
