linux搭建的gitlab服务器会在重启之后消失吗

linux搭建的gitlab服务器会在重启之后消失

1、由于在Windows Vista之后的版本默认并没有提供Telnet功能。如果需要使用Telnet就必须打开此项功能。以Windows 7为例，首先打开控制面板。

2、然后在控制面板中打开“程序和功能”。

3、再在左上角点击“打开或关闭Windows功能”。

4、在“打开或关闭Windows功能”对话框中勾选“Telnet客户端”，点击确定，系统会自动安装。到此Windows终端的工作已经完成。

5、Linux服务器开启Telnet服务

许多Linux系统在默认情况下是不安装Telnet服务的，如果需要使用就必须安装此项服务。安装的方法有很多，小编在这里只介绍yum安装Telnet服务，它的优点是能够自动检查安装包的依赖文件不用人为干预，当然前提是系统必须联网。在提示符下输入“yum install -y telnet-server”命令安装Telnet服务。最后出现Complete，代表安装完成。

dockergitlab服务器挂了准确来说应该是今天升级了阿里云的ECS内存之后重启实例，结果发现所有跟docker相关的东西都坏掉了。docker启动不了，所有镜像都查不到。我们的gitlab是用的docker，所以必须要把这个给弄好。

查看docker相关的文件和镜像容器都在，所以猜测数据可能没受到损坏。具体修复过程分为以下几个阶段：

1、这是由于重启了服务器造成的，所以有可能再重启一次情况会回复，但是重启后结果还是不行。

2、启动docker 的时候执行service docker start指令，显示数据如下图：

docker start/running,process 。这条指令并没有说明docker已经运行，因为我查询所有进程的时候根本没有docker，具体原因可以百度下。

3、找大神帮忙，加入了几个docker群，其中在docker分享群2中几位大神纷纷出来指点。

其中一位说service 只是相当于一个快捷方式，这样启动不了就去docker下直接手动启动。可是我找了半天没找到在哪启动。第二位朋友说dockerd指令，这个是手动启动docker的，可是执行后还是不行，(/dockerd也失败)

提示信息里说可能没有安装docker。可是我重启服务器之前运行了将近半年都是OK的，但是我不排除重启后docker完全损坏，不被识别的可能。

使用uname -a查看内核版本，看看是不是不支持docker。按照他的解释是，他之前遇到过，重启服务器之后内核更新了，导致不支持docker所以这也是一种可能。

查看docker版本：

我这里是162的客户端，

linux内核313

确认了我的服务器内核是支持docker的，所以把这个可能排除。

其中杭州的以为朋友注意到，我上边的错误提示里有一句缺少dockersock文件。所以建议我在相应的目录下简历dockersock。上边提示信息的完整路径是/var/run/dockersock。

按照上边说的建立后，再执行出现以下信息：

这时候注意后边那条提示，shutting down，看到这之后大神给出一条指令sudo apt-get install apparmor，说执行完之后就没问题了。

执行完之后果断docker可以起来了



在top中查询：



消失已久的docker终于出来了，而且docker下以前建立的容器都还在，手动起一下就好。

感谢各位大神的帮助，我的docker又复活了。总之不熟悉这个的朋友最好还是慎用，或者有人指点也好，省的不知道出问题之后该找谁。

一、环境准备

1gitlab所在的服务器A（centos7，19216811）

2备份服务器B（centos7，19216812）

3gitlab本地备份目录设置为/var/opt/gitlab/backups/log，本篇也是以此展开

gitlab已经配置了本地备份。如果没有配置，可以参考 http://wwwcnblogscom/straycats/p/7671204html 。

二、通过密钥配对取消scp传输密码的限制

手动备份数据费时费力。最好的方法就是通过脚本实现远程自动备份。但远程无论是通过SSH登陆，还是通过scp拷贝文件都需要输入密码。

为了克服这个问题，首先需要实现不需要密码的SSH登陆，这样就可以使用 rsync，scp，rexec等命令来做的远程备份了。

21 生成密钥对

假设A，B两服务器，现在需要在A机上用root登陆B机，而不需要输入密码。那我们可按照下面的步骤来做：

1）在gitlab服务器A上生成rsa证书

1、生成的过程中提示输入密钥对保存位置，直接回车，接受默认值就行了。

2、因为之前已经有/root/ssh/id_rsa 文件存在，因此提示你是否覆盖，输入y表示覆盖

3、接着会提示输入一个密码，直接回车，让它空着。当然，也可以输入一个密码。

4、接着输入确认密码，输入完之后，回车密钥对就生成完了。

这样，在/root/ssh下生成id_rsa 和 id_rsapub 两个文件，其中公共密钥保存在 /root/ssh/id_rsapub，私有密钥保存在/root/ssh/id_rsa。

2）在gitlab服务器A上cp生成rsa公钥证书

在/root/ssh下复制备份一份id_rsapub 命名为 id_rsapubA，以便拷贝到远程服务器B。

22 生成rsa公钥证书上传到备份服务器B

先在服务器B上创建目录/root/ssh。

使用scp命令进行远程复制，将服务器A生成的id_rsapubA拷贝到服务器B的/root/ssh目录下。

此时使用scp命令需要输入密码，当把下面的“23 密钥配对”执行后，以后gitlab服务器A使用scp命令复制文件到备份服务器B的话，就不需要输入密码了。

23 密钥配对

1）创建authorized_keys文件

在备份服务器B的/root/ssh下创建authorized_keys文件。

2）将id_rsapubA文件内容追加到authorized_keys 文件中

通过 cat 命令 把id_rsapubA 追写到 authorized_keys 文件中。

3）修改authorized_keys文件的权限

authorized_keys文件的权限很重要，如果设置为777，那么登录的时候，还是需要提供密码的。

4）测试上传文件是否还要输入密码

不放心的话，立刻测试下gitlab服务器A使用scp命令复制文件到备份服务器B是否还要输入密码。

发现在23之前，由于没有设置ssh证书授权认证时，上传需要输入密码；23操作完后，由于授权认证，已经不需要输入密码了。

三、定时将备份文件传到备份服务器

31 创建远程备份脚本

在gitlab服务器A上 ，在/root目录下创建定期备份脚本auto_backup_to_remotesh。

添加下面的内容，并wq保存。

32 修改远程备份脚本auto_backup_to_remotesh的权限

要能让系统执行 auto_backup_to_remotesh ，必须修改该脚本的权限。

33 创建日志存放目录

34 测试远程备份脚本的功能是否可用

现在为了验证脚本是否可以正常运行，我们需要手动执行脚本。

在gitlab服务器A上执行find命令，看是否能够正常查找出我们要scp到远程服务器的Gitlab备份文件。

手动执行脚本auto_backup_to_remotesh，看是否能够正常上传

等待1-2分钟左右，查看备份服务器B的目录/root/gitlab_backup下是否有服务器A传过来的备份文件。

在备份服务器B上能找到服务器A传过来的备份文件，说明远程备份脚本的功能OK。

如果每次上传都通过人工运行脚本的方式，人工的消耗太大，接着配置定时执行该脚本。

35 添加定时计划

定时备份的思路建立在手动的基础上，通过crontab添加定时计划就可以解决这个问题。

一般添加定时计划可以有2种方式：

1使用命令crontab -e，将定时任务添加后保存。

2将定时任务添加到/etc/crontab文件中。

我这里采取第一种，使用crontab -e。

结合我之前对公司gitlab本地备份的设计，故设计在备份完10分钟后上传，故分别在每天12:10、19:10进行备份，故添加下面的内容，wq保存。

重启crontab

四、定时删除备份服务器上的备份文件

每个Gitlab备份文件都很大。因此每天备份两次，过不了多久的话，备份服务器B上的磁盘空间可能就会被Gitlab备份文件占用完。

故需要定期清理备份文件，参考备份服务器的空间，暂定保留14天的备份文件。

41 创建删除过期备份文件的脚本

设计备份服务器B的/root/gitlab_backup作为接收远程上传备份文件的目录， 故在备份服务器B上 ，先创建该目录。

创建删除过期备份文件的脚本auto_remove_old_backupsh。

添加下面的内容，并wq保存。

42 修改auto_remove_old_backupsh脚本的权限

43 添加定时计划

定时备份的思路建立在手动的基础上，通过crontab添加定时计划就可以解决这个问题。

一般添加定时计划可以有2种方式：

1使用命令crontab -e，将定时任务添加后保存。

2将定时任务添加到/etc/crontab文件中。

我这里采取第一种，使用crontab -e。

设计凌晨0点执行删除过期备份文件的脚本，故添加下面的内容，wq保存。

重启crontab

可以。

gitlab上可以上传文本材料，上传文本材料把文件复制到要上传的本地git目录中，进入本地git文件所在目录，将要上传文件加入索引中，将要上传的文件提交到本地仓库，文件同步到GitLab服务器上就上传好了。

GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。安装方法是参考GitLab在GitHub上的Wiki页面。Gitlab是被广泛使用的基于git的开源代码管理平台,基于RubyonRails构建,主要针对软件开发过程中产生的代码和文档进行管理。

目录

一、CICD简介

二、CICD实践过程

三、含泪踩坑

四、 历史 文章指路

一、CICD简介

1、CICD定义

2、DevOps定义

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

DevOps的基础核心是CICD。

CICD的基础核心是自动化。

二、CICD实践过程

1、起因

在我之前的团队，因为要切换全新业务线，需要为新业务搭建一套全新的环境，所有东西从0开始。

原先只是用于部署测试环境，后面决定一起部署生产环境，这个过程中我还造成了一个严重生产环境问题，好在当时的生产环境还未正式使用，未造成严重影响。

在当时挺害怕也挺有压力的，但是后面项目完整落地，平稳运行，我还是挺有成就感的，接下来我将整个项目过程完整的分享出来。

2、技术栈选型

首先进行技术栈选型，我们选择的是Jenkins，Jenkins当属业内持续集成老大哥，有着非常丰富的插件，也可以选择gitlab集成的CICD，因为我们还有其它的测试脚本需要集成，所以Jenkins对于我们来说是最优的选择；

Ansible是批量运维工具，通过编写yaml脚本，可以方便实现批量管理多台机器，并且Ansible是比较轻量级应用，很容易上手；

shell脚本可以用于执行一系列命令。

其它的就结合团队项目情况进行搭建。

3、Jenkins应用部署实现流程

首先来梳理下整个项目的实现流程，主要分为Jenkins主节点和应用服务器，是一对多的关系。

Jenkins主节点的主要负责项目部署前的工作，主要包含拉取代码，前端打包，后端打包，快照版检测，将压缩包和部署脚本发送到目标机器（即应用服务器），远程调用目标机器上的部署脚本进行代码替换。

应用服务器部署脚本执行过程有：解压压缩包，停止服务，覆盖代码，拉取disconf，应用目录分组赋权，重启服务，检查服务是否有进程，查看启动日志，删除/tmp目录下旧压缩包。

Jenkins应用部署流程图

4、任务计划

41、搭建环境

Jenkins

指路Jenkins系列如何搭建Jenkins环境。

Ansible

Git

GitLab

因为这个我没有实践成功的教程，所以在这里就不贴啦~

Nodejs

Maven

JDK

Nginx

2、编写前置脚本

3、编写应用部署脚本

4、Jenkins配置

指路Jenkins系列如何构建Jenkins Job。

新增Job，主要用于拉取代码，执行Maven编译，执行app_buildsh，将压缩包通过ssh发送到目标机器，远程调用目标机器的deploysh。

三、含泪踩坑

踩坑1

问题描述：在错误的路径拉取配置，原因是未成功解压压缩包。

解决方案：校验压缩包是否解压成功解压成功，并且在cd到正确的路径后添加&&（&&表示上一条命令执行成功再执行下一条命令）才进行拉取配置。

踩坑2

问题描述：项目没有正常停止，导致无法重新启动。

解决方案：虽然执行kill -9，但是未找到根本原因，因此加了一个检测机制，如果检测没有正常停止服务，则退出程序。

踩坑3

问题描述：生产部署脚本拉取了开发环境的的jdbc配置，原因是生产部署脚本写错了开发环境disconf的域名，当时我同时在搞开发生产环境的脚本，开发和生产是两套不同的脚本，一时混乱写错了，吓得一批，好在当时生产环境还没投产使用。

解决方案：为了避免后续这种情况的发生，而且是必须避免的，我们通过环境名称来判断走开发还是生产域名，这样就能保证脚本一致性了。

在这个项目实际遇到的问题远不止上面这几个，在这个实践过程中，我对整个应用部署流程有了更深的理解，平时方方面面的学习终于集中化起来进行实践了。

我习惯将学到的知识和遇到的问题记录起来，在写这篇文章的过程回过头来看，五味杂陈，原来我都经历了这些哈哈哈

踩过的坑终究使我更加强大，带你见证呱呱本呱成长为参天大呱~

搞测试，不迷路

呱呱大王本呱带你飞！