软件信息网 操作系统 GitLab崩了怎么办?

GitLab崩了怎么办?

创新式的开发对于码农来说往往是一项艰巨的“修行”任务。每个GitLab用户都或多或少地认识到,源代码对于保障DevOps团队能够不间断地开展工作流程的重要性。

有人也许会问:GitLab可谓最可靠的源代码管理(SCM)工具提供平台之一。它会发生什么状况呢?作为一个开源的开放性平台,GitLab不可避免地会受到诸如:服务中断、勒索软件、以及系统宕机等各种潜在威胁。这些有的源自GitLab服务器受到攻击,有的来自GitLab数据库的自身故障。为此,您和您的团队应始终为各种灾难情况提前做好准备,即:为自己的GitLab数据建立一个强大的备份机制。同时,您也应当保证能够将默认的备份策略,集成到自己的DevSecOps流程、以及CI/CD管道中。

一、GitLab备份应该包含什么?

一旦决定了待备份的GitLab环境,我们就应该确保GitLab的备份内容包含了各种GitLab存储库和元数据。我们可以将此处的“元数据”,理解为针对各类Wiki、问题、问题注释、部署密钥、合并请求、LFS(译者注:Linux from Scratch,一种从网上直接下载源码,从头编译Linux的安装方式)、标签、Webhook、标签、里程碑、发布、操作等组件和环节的备份。只有备份好了这些,开发团队和整个公司在项目中用到的所有Git存储库数据,才能得到充分的保护。

二、备份策略的关键特性

如果您已梳理清楚了手头的工作流程,那么便可以开始制定备份策略了。为了确保工作流程的不间断,我们应该按需进行多重备份,从而不仅可以及时恢复GitLab数据,而且能够满足审计、合规、以及安全性等需求。下面便是一些值得注意的安全性要素:

  • AES加密、以及自用的各种动态与静态加密密钥;
  • 区分灵活的、长期的、以及无限期的保存需求;
  • 对旧的、未使用的存储库进行归档的可行性;
  • 通过报告和邮件通知等监控方式,来检查GitLab备份的执行情况;
  • 对勒索软件予以防护;
  • 检查灾难恢复技术是否满足恢复目标。

上面只是与完善备份策略相关的基本安全方面。如果您想制定GitLab环境的完整备份计划,则需要考虑并构建包含各种高级备份功能的替代性备份策略。

1.3-2-1备份规则

如果DevOps团队已经为某些源代码日夜奋战了许久,那么一旦出现GitLab的中断或备份失败,则会导致他们的成果覆水难收,同时也会让企业蒙受财务上的损失。对此,我向您介绍一个3-2-1的“黄金”备用规则。即:一家公司应当将3个备份副本保存在2个不同的存储实例中,并且至少有1个处于离线。因此,您需要注意备份复制的相关问题,以便它能够协助您将本机备份的副本保存到多个位置,进而实现服务的冗余和业务的连续性。

当然,如果您的DevOps备份软件具有多存储兼容性的话,则可以大幅节省花费在软件上的开销。目前,AWS S3、Backblaze B2、谷歌云存储(Google Cloud Storage)、Azure Blob Storage、GitProtect Cloud、以及其他任何与S3、本地或混合兼容的公有云,都可以提供此类兼容性。如果您不清楚的话,请询问您的备份服务提供商,以确认是否可以充分利用已有的基础设施,将代码数据、连同自己的存储空间,一并备份到不同的目的地处。

2.需无限保留的数据

保留期限也是我们在制定备份过程中,需要重点考虑的方面。对于一些非常重要的GitLab数据,您可以将其保留期限设置为5年、10年、甚至是无限期保留。如果您的代码中包含了个人隐私数据,那么其保存期限就需要满足本地的法律、法规、以及共同责任的要求。

3.对勒索软件的防护

备份GitLab数据可谓抵御勒索软件攻击的最后一道防线。因此,如果您的GitLab备份方案是针对防范勒索软件的话,它会在备份的过程中,对GitLab数据执行压缩和加密,进而保证数据在其存储状态是不可执行的。据此,即使您的备份数据被某些勒索软件所截获,也不会被轻易执行或无限量地传播。此外,在最坏的情况下,就算某些勒索软件可以加密、修改或删除已截获到的数据,您手头仍有一个备份,可方便您根据确切的时间点,恢复所需的GitLab副本,进而保证您的团队将在毫无拖延地情况下,继续开展项目。

4.给审计与合规提供监测报告

常言道:拥有信息的人正统治着世界。及时掌握任何有关GitLab备份本身、备份失败、以及备份状态的信息,可以协助DevOps团队厘清他们所碰到的问题,并能够对备份数据的可用性进行实时把控。软件项目团队往往需要通过Slack通知、数据驱动的仪表板、电子邮件通知、以及高级审计日志,来跟踪备份系统的每一项执行操作。此类信息不但能够让您的团队受益,而且可以为审计和安全认证等方面,提供详细的备份完成情况的报告。

三、恢复过程应包含哪些?

根据备份策略,对GitLab执行有效的备份,只是整个灾备计划的一部分。我们还需要规划好能够尽快恢复GitLab备份数据的策略。也就是说,灾难恢复计划应确保您的业务在服务中断/宕机、(非)故意的人为错误、以及因勒索软件攻击而造成数据丢失等可能的情况下,仍能保持业务的连续性。

下面是我们在制定恢复策略时,需要仔细考虑的方面:

  • 需要还原的数据所处时间点。
  • 存储库和选定元数据的恢复程度与数据量。
  • 用于从存储库备份数据进行恢复的GitLab帐户。
  • 是否以交叉恢复的方式,从GitLab恢复到另一个Git托管平台(如:GitHub或Bitbucket),这在工具之间进行迁移时,非常实用。
  • 恢复到本地设备的可能性。

在实践中,如果您可以将备份和恢复两项操作归并到一个应用之中的话,则可以大幅节省团队的时间。

有了恢复策略,我们在讨论面对GitLab、基础设施、以及备份方案出现故障等场景时,咱们的团队能够如何准备:

1、GitLab出现中断

虽然GitLab是一个可靠的托管服务提供平台,但是发生中断的可能性还是存在的。对此,您既可以将GitLab实例以.git文件的方式,恢复到自己的计算机上;也可以基于交叉恢复的方式,直接将GitLab的副本,恢复到另一个Git托管平台。

2、您的基础架构出现中断

基于前文提到的3-2-1备份规则,哪怕您的基础架构出现中断,您总会在2处目的地拥有着3个备份副本,而且其中1个处于离线状态。因此,您可以从任何一个时间点获得备份副本,并轻松地恢复GitLab存储库及其元数据。

3、备份方案本身出现故障

在决定使用第三方的备份方案之前,您有必要确认其已为潜在的中断做好了准备,并且可以在真正发生时,为您提供适当、可靠的数据恢复支持。例如:如果它们能够与您共享在本地应用中安装的权限,那么一旦其SaaS环境出现故障,您便可以轻松地从本地应用中,直接访问到自己的数据。

四、小结

综上所述,为了应对GitLab可能出现的中断,您既可以自行管理备份过程,也可以编写专门的GitLab备份脚本并制作快照的命令,还可以选择第三方备份软件的自动备份服务。同时,您需要实现设定好在灾难发生时,执行哪些恢复流程,让整个GitLab环境尽快可供访问,以确保团队工作的连续性。

本文来自网络,不代表软件信息网立场,转载请注明出处。软件定制开发交流:15528175269(微信同号)https://www.saasyo.com/xz/17399.html

作者: 王鹏程序员

上一篇
下一篇
联系我们

联系我们

15889726201

在线咨询: QQ交谈

邮箱: 187395037@qq.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部