按照官方文档安装完成后,/home/git目录结构如下
|-- home
| |-- git
| |-- .ssh
| |-- gitlab
| |-- gitlab-satellites
| |-- gitlab-shell
| |-- repositories
/home/git/.ssh
- ssh设定的目录. gitlab-shell管理着其中的authorized_keys
./home/git/gitlab
- GitLab核心部分/home/git/gitlab-satellites
- 可以视为临时目录,通过web ui的提交请求文件以及检出版本库都会存放在这个位置/home/git/gitlab-shell
- gitlab的核心插件组件. 包括ssh协议克隆和其他一些功能./home/git/repositories
- 原始版本库的所有项目组织的名称空间,也就是所有仓库的存储位置,所以这个目录里的数据非常重要,注意备份 这是项目的关键数据. Keep a backup
注意; gitlab-satellites 和 repositories的路径都被定义在gitlab中的 config/gitlab.yml
和 gitlab-shell. 中的config.yml
执行备份的命令时,网上看到其他人说的命令:
gitlab-rake gitlab:backup:create
这个命令根本就找不到,不知道是不是版本的原因,后来在这个目录下面找到相对应的命令:
具体的备份和恢复命令如下:
创建为所有版本库的存档,就是备份啦. 存储路径在gitlab中的 config/gitlab.yml
文件命名 [TIMESTAMP]_gitlab_backup.tar
.
1
| bundle exec rake gitlab:backup:create RAILS_ENV=production
|
类似如下:
1
| Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
- Dumping table keys... [DONE]
- Dumping table merge_requests... [DONE]
- Dumping table milestones... [DONE]
- Dumping table namespaces... [DONE]
- Dumping table notes... [DONE]
- Dumping table projects... [DONE]
- Dumping table protected_branches... [DONE]
- Dumping table schema_migrations... [DONE]
- Dumping table services... [DONE]
- Dumping table snippets... [DONE]
- Dumping table taggings... [DONE]
- Dumping table tags... [DONE]
- Dumping table users... [DONE]
- Dumping table users_projects... [DONE]
- Dumping table web_hooks... [DONE]
- Dumping table wikis... [DONE]
Dumping repositories:
- Dumping repository abcd... [DONE]
Creating backup archive: $TIMESTAMP_gitlab_backup.tar [DONE]
Deleting tmp directories...[DONE]
Deleting old backups... [SKIPPING]
|
利用备份文件恢复
1
| bundle exec rake gitlab:backup:restore RAILS_ENV=production
|
选项:
1
| BACKUP=timestamp_of_backup (required if more than one backup exists)
|
类似这样:
1
| Unpacking backup... [DONE]
Restoring database tables:
-- create_table("events", {:force=>true})
-> 0.2231s
[...]
- Loading fixture events...[DONE]
- Loading fixture issues...[DONE]
- Loading fixture keys...[SKIPPING]
- Loading fixture merge_requests...[DONE]
- Loading fixture milestones...[DONE]
- Loading fixture namespaces...[DONE]
- Loading fixture notes...[DONE]
- Loading fixture projects...[DONE]
- Loading fixture protected_branches...[SKIPPING]
- Loading fixture schema_migrations...[DONE]
- Loading fixture services...[SKIPPING]
- Loading fixture snippets...[SKIPPING]
- Loading fixture taggings...[SKIPPING]
- Loading fixture tags...[SKIPPING]
- Loading fixture users...[DONE]
- Loading fixture users_projects...[DONE]
- Loading fixture web_hooks...[SKIPPING]
- Loading fixture wikis...[SKIPPING]
Restoring repositories:
- Restoring repository abcd... [DONE]
Deleting tmp directories...[DONE]
|
由于是第一次接触这个gitlab的配置,所以中间遇到一些比较基础的问题,还是困扰了很久,现在贴出来:
1.由于gitlab的正常使用涉及到很多的东西,包括:redis、mysql、ruby、nginx和gitlab本身,
gitlab的安装本身是一个非常复杂、冗余的过程,此处略去。
2.遇到的第一个问题是访问IP的时候,报500错误。Please Contact gitlab administrator......
这是因为redis没有启动导致的,service redis start 执行成功后,就能正常的访问gitlab的web页面了
3.通过
http://192.168.1.8 访问gitlab页面的时候,发现项目的git地址不对,正确的应该是
git@192.168.1.8:behavior/BehavioralData.git 但是 在项目主界面看到的却是一个莫名巧妙的IP:
git@192.168.0.6:behavior/BehavioralData.git
这是因为在config/gitlab.yml文件中的host属性 被设置为了 192.168.0.6,将这个属性改为 192.18.1.8即可。
4.然后,又碰到了另外的问题。
以上的问题,解决后,发现不能从gitlab拉取项目,这时发现 其实还是在gitlab-shell文件家中config.yml文件中还有一个属性被设为 192.168.0.6了 这同样需要修改为 192.168.1.8
5.最后 碰到了最重要、最常见、最基本的问题。
发现往gitlab上提交修改的时候,老是提示 Access Denied
通常只要提示 Access Denied或者Make Sure You have the rights之类的信息时,基本上就能确定原因是:
你提交的操作过程中,客户端跟gitlab服务器之间验证ssh key的时候 不一致导致的。
首先,在sourcetree中生成ssh的公钥和私钥,把公钥内容复制添加到gitlab服务器中的ssh keys中,私钥文件保存在本地。
然后,就是sourcetree启动的时候,其实还启动了另外一个守护进程Pageant
右键点击,双击之,进入这个界面:
再将刚才生成并保存到本地的私钥文件,添加到这个列表中即可。