夜法之书 • Posts by "devops" category

开源观察之到底是谁在主导开源软件生态的发展？

2023-03-24T13:21:22.000Z

前言

很多人对于开源生态误解很深，这里对开源软件生态的一些介绍和解释，使用ChatGPT辅助编写了一篇对于外行的介绍，使其可以快速了解开源生态

对话开源

使用了很多很久的开源软件，也参与了一些开源软件的发展，现在软件的选择首选的就是开源软件，对于开源软件生态算是有一个初步的了解和映像。很多外行对于开源有一些错误的认知，很早就有写一篇关于开源生态的文章了，最近使用ChatGPT辅助，很快就完成了一篇文章。

在思考是否把对话过程整理成文之后，最终决定还是保留交流对话的过程！

ChatGPT很强大，但你也得具备很多专业知识才能用好它

开源软件是什么

开源软件指的是源代码可以被公开查看、使用、修改和分发的软件。与之相对的是闭源软件，它的源代码是私有的，不公开供大众使用和修改。

开源软件的特点是：

可以被公开查看和修改：任何人都可以查看开源软件的源代码，并且可以根据自己的需要进行修改和定制。
可以被免费使用：大部分开源软件都是免费提供给用户使用的，用户不需要支付版权费用。
具有较高的安全性：由于源代码公开，开源软件的漏洞和安全问题可以被更多人发现和修复，从而提高了软件的安全性。
具有良好的社区支持：开源软件通常有一个庞大的社区支持，用户可以通过社区获得帮助、交流和分享。
可以被广泛应用和推广：由于开源软件具有免费和开放的特点，它可以被广泛应用和推广，从而提高了软件的影响力和普及率。

常见的开源软件有Linux操作系统、Apache Web服务器、MySQL数据库、Firefox浏览器、WordPress网站建设平台等等。开源软件已经成为现代软件开发中的重要组成部分，为用户和开发者带来了诸多的好处。

开源软件的优点是什么

开源软件有以下优点：

透明性：开源软件的源代码是公开的，用户可以查看代码并了解软件的实现原理，这种透明性使得用户可以更好地理解软件的功能和运行机制。
自由度：开源软件的用户可以自由地复制、分发、修改和使用软件，而且不需要支付任何费用。这种自由度使得用户可以根据自己的需要来定制软件，从而更好地满足自己的需求。
安全性：由于开源软件的源代码是公开的，任何人都可以查看代码并发现其中的漏洞和安全问题，这种开放的审查机制可以使得开源软件具有更高的安全性和稳定性。
可定制性：开源软件通常具有很好的可定制性，用户可以根据自己的需求和特定的场景对软件进行修改和定制，从而更好地满足自己的需求。
社区支持：由于开源软件的用户和开发者通常组成一个庞大的社区，这种社区可以为用户提供技术支持、问题解答、开发经验和资源共享等支持。
兼容性：开源软件通常具有更好的兼容性，因为开源软件通常遵循开放标准，不受私有标准的限制，可以更好地与其他软件和系统进行协作。

综上所述，开源软件的优点包括透明性、自由度、安全性、可定制性、社区支持和兼容性等。这些优点使得开源软件成为现代软件开发中不可或缺的一部分，为用户和开发者带来了巨大的价值和好处。

那么，开源软件有什么缺点了？

虽然开源软件具有很多优点，但也存在一些缺点，包括以下几个方面：

缺乏专业支持：开源软件通常由社区维护和支持，缺乏专业支持，这可能导致用户在使用和维护软件时遇到困难。
可能存在安全问题：虽然开源软件的源代码可以被公开审查，但这也可能导致黑客更容易找到软件中的漏洞和安全问题，因此开源软件也需要及时修复漏洞以保障安全。
兼容性问题：虽然开源软件通常遵循开放标准，但在实际应用中，与其他软件或系统的兼容性可能存在问题，这可能会导致软件无法正常工作。
学习成本较高：由于开源软件的源代码是公开的，用户可能需要具有一定的编程知识和技能才能进行定制和修改，因此需要付出一定的学习成本。
可能存在版本更新不及时的问题：由于开源软件通常由社区维护，因此可能存在版本更新不及时的问题，用户需要自己去维护和更新软件，这可能会增加用户的工作量。

综上所述，开源软件的缺点包括缺乏专业支持、安全问题、兼容性问题、学习成本较高和版本更新不及时等。对于这些缺点，用户可以通过选择专业的开源软件提供商、参与社区维护和支持、及时更新软件版本等方式来解决。

只要投入金钱，开源软件的这些问题可以解决么

投入金钱确实可以解决一些开源软件存在的问题，例如提供专业支持、加强软件安全等，但并不能完全解决所有问题。以下是一些例子：

提供专业支持：企业可以选择购买专业的开源软件支持服务，获得专业的技术支持、问题解答和定制服务，从而解决由于缺乏专业支持而导致的困难。
加强软件安全：企业可以选择购买安全软件，对开源软件进行加固和安全管理，从而提高软件的安全性。
定制和维护：企业可以选择雇佣开源软件开发人员，进行定制和维护，从而解决开源软件的兼容性和版本更新等问题。
增加社区投入：企业可以向开源社区投入资金，促进社区的发展和维护，从而帮助解决一些开源软件存在的问题。

然而，开源软件的自由性和透明性也意味着，用户可以根据自己的需求和资源选择是否投入金钱。在一些情况下，投入金钱可能并不是必要的，用户可以通过自己的努力和学习来解决开源软件存在的问题。

redhat就是一家很成功的开源软件公司，并创造了巨大的利润，redhat的商业模式是否解决了开源软件的问题

Red Hat 确实是一家非常成功的开源软件公司，它的商业模式可以说是解决了开源软件的问题之一。Red Hat 的商业模式主要是基于以下两个方面：

提供专业支持：Red Hat 提供针对企业级用户的 Linux 操作系统和其他开源软件的专业支持，包括技术支持、培训、咨询和服务等，这可以解决企业在使用和维护开源软件时遇到的困难。
付费订阅服务：Red Hat 基于其开源软件产品提供付费订阅服务，订阅用户可以获得 Red Hat 官方提供的软件更新、安全修复、新功能和技术支持等服务，这可以解决开源软件版本更新和安全性问题。

Red Hat 的商业模式的成功不仅在于它提供了专业的支持和服务，而且在于其能够让企业在同时获得开源软件的好处和商业化的优势。Red Hat 的开源软件产品在大多数情况下是免费的，但企业需要付费订阅服务才能获得更好的服务和支持，这既保证了开源软件的自由性和透明性，又能够为企业提供可靠的商业支持。

总之，Red Hat 的商业模式是非常成功的，但并不能完全解决所有开源软件存在的问题。其他开源软件公司和社区也在不断探索和创新商业模式，以解决开源软件存在的问题。

在互联网领域，几乎都是使用的开源软件，未来，开源软件会统治所有的互联网标准么？

开源软件在互联网领域确实得到了广泛的应用，成为了很多公司和组织选择的首选。然而，要说开源软件会统治所有的互联网标准，还是有一定的困难。

首先，虽然开源软件在很多领域已经达到了很高的水平，但在某些特定领域，闭源软件仍然具有更好的性能和效率。例如，在一些高性能计算领域，闭源软件仍然是不可替代的选择。

其次，开源软件也存在一些问题和限制。例如，开源软件的发展和更新速度可能会比较慢，有时候可能存在安全和兼容性问题，需要用户花费时间和精力进行自我调试和维护。

最后，由于开源软件的自由性和透明性，它们存在着无法控制的风险。如果在开源软件的代码中存在漏洞或安全问题，攻击者可以很容易地获取代码并利用其中的漏洞进行攻击。这可能会对企业和组织的安全带来潜在风险。

综上所述，虽然开源软件在互联网领域中得到了广泛应用，但是它们并不一定会成为统治所有互联网标准的唯一选择。在未来，我们可能会看到开源软件和闭源软件之间的协同发展，以提供更好的解决方案。

但是，我看到，越来越多的闭源软件公司倒闭了，或者转为开源软件模式，例如firefox，谷歌的chrome，开源软件的占比越来越高，你有什么看法

是的，确实有越来越多的闭源软件公司倒闭或者转为开源软件模式，而开源软件在互联网领域中的占比也越来越高。这是因为开源软件具有很多优势，包括透明性、自由性、灵活性、可定制性等，而这些优势正好能够满足当前互联网应用的需求。

另外，随着云计算和开放云平台的发展，开源软件也得到了更多的应用机会。云计算和开放云平台为开源软件提供了更好的部署和使用方式，同时也提高了开源软件在企业和组织中的接受度和应用价值。

最后，开源软件社区的活跃度和贡献者数量也在不断增加，这进一步促进了开源软件的发展和普及。开源软件社区的活跃度和贡献者数量越多，开源软件的功能和性能就越强大，这也让更多的企业和组织愿意选择开源软件。

综上所述，开源软件在互联网领域中的占比确实越来越高，这是因为开源软件具有很多优势，并且得到了更多的应用机会和社区支持。不过，仍然需要注意开源软件本身的一些问题和限制，并且需要根据实际情况选择最适合自己的软件解决方案。

开源软件是由谁主导的？

开源软件的开发和推广通常是由开源社区和贡献者主导的。这些社区由一群热爱技术和开源理念的人组成，他们相信共享和协作的力量，致力于开发和维护开源软件项目。

开源社区是由志愿者、爱好者、开发者和公司等组成的多方参与的群体，其成员之间通过互相交流和合作来推动软件的开发和改进。开源社区通常拥有完善的组织结构和开发流程，例如开发者的代码提交、审查和合并流程、用户的反馈和贡献流程等，这些流程可以帮助开发者更好地协作、沟通和共同推进软件的发展。

除了开源社区，一些公司也在开源软件的发展中扮演了重要的角色。这些公司可以是开源软件的赞助者、贡献者或用户，也可以是基于开源软件构建自己产品和服务的企业。一些知名的开源软件公司，例如Red Hat、Canonical、MongoDB等，不仅为开源社区提供了财务和技术上的支持，同时也为企业用户提供了开源软件的商业服务和支持，从而帮助开源软件在企业中得到更广泛的应用。

总之，开源软件的开发和推广主要由开源社区和贡献者主导，同时得到了一些公司的支持和参与。这种多方参与的开发模式可以使得开源软件具有更广泛的用户和应用范围，也可以让软件得到更多人的参与和贡献，从而推动软件的不断发展和完善。

有人或者组织能够独裁控制开源软件走向么？例如只支持某个操作系统，或者不准某些企业或国家使用

在开源软件的开发和推广过程中，由于开放的自由性和民主性，很难有人或组织能够完全独裁控制开源软件的走向和应用范围。这是因为开源软件是基于开放源代码的共享和协作模式，其代码和文档等资源都是公开的，并且可以被其他人自由地使用、修改和再分发。

开源软件通常采用自由软件许可证进行授权，这些许可证保障了用户的自由，例如选择软件的使用、复制、修改和再分发等。这些自由是在法律框架下保护的，因此，无论是个人、企业还是国家，都可以使用和参与开源软件的开发和推广。

开源软件的发展和应用也是一个开放和民主的过程，任何人都可以参与到开源社区中，提交代码、提出建议和反馈、进行讨论等等，从而共同推动软件的发展和改进。在开源社区中，没有人或组织能够完全控制软件的走向和应用范围，而是基于开放和民主的原则，通过共同协作和讨论来制定和决定软件的发展方向和应用范围。

因此，开源软件的开放性和民主性是其成功的关键之一，也是其能够避免独裁控制的重要保障。

你对谷歌禁止华为使用android，导致华为开发鸿蒙操作系统有什么看法

谷歌决定禁止向华为提供Android许可证，导致华为无法获得最新的Android更新和支持。这一决定是由于华为与美国政府的关系引起的，谷歌也只是在执行美国政府的规定。这对华为造成了一定的影响，需要花费更多的时间和资源开发自己的操作系统。

从另一个角度来看，这也提醒了人们开源软件的优势，即开放的自由性和可控性。由于Android的源代码是公开的，华为可以根据自身需求自主开发和修改操作系统，降低了对其他公司的依赖和控制。这也促使华为加快了自主操作系统鸿蒙的研发和推广，增强了技术自主性和可控性。

总的来说，谷歌禁止华为使用Android虽然给华为带来了一定的困扰，但也加快了自主操作系统的研发和推广，体现了开源软件的优势和技术自主性的重要性。

我看到现实生活中，谁掌握了金钱，谁有大量的工程师开发人员，谁就有能力创建分支，或者主导开源软件的走向，对么？

在某种程度上，金钱和人力资源的掌控确实可以对开源软件的走向产生一定的影响。但是，开源软件的社区是由广泛的利益相关方组成的，不仅包括了公司和组织，也包括了个人用户和开发者。在这个社区中，每个人都有权利和能力发表自己的意见和建议，参与到开源软件的开发和讨论中。

因此，即使某些公司或组织拥有更多的资源和影响力，但是也需要考虑到广泛的利益相关方的需求和利益。如果一个公司或组织试图独断地掌控开源软件的走向，可能会面临社区成员的反对和抵制。此外，开源软件的代码是公开的，任何人都可以自由地复制、修改和分支，因此即使某个公司或组织试图掌控某个开源软件，也无法完全控制其走向。

因此，开源软件的发展是由整个社区共同推动和影响的，任何单一的利益相关方都无法完全控制其走向。

你对oracle收购mysql后，mysql的创始人出走，创建mariadb，有什么看法

Oracle收购MySQL后，MySQL的创始人Michael Widenius确实离开了Oracle，随后创建了MariaDB这个分支，这也是开源软件的一种特点，任何人都可以基于原有代码分支出去创建一个新的项目，这样可以实现更加个性化的需求和自由度。

从MariaDB的角度来看，他们希望继续发展MySQL所代表的关系数据库的优点，并且希望推出一些新的功能和特性，以此吸引更多的用户。同时，MariaDB也注重开源社区的参与和贡献，这一点和MySQL的开源文化类似。在开源软件的世界里，分支和创新是非常普遍的现象，而这些分支往往会针对特定的用户需求，从而推出更加优秀的解决方案。

总的来说，Oracle收购MySQL后，MySQL的创始人离开创建MariaDB，也展现了开源软件的另外一种特点，即开源社区的自由度和创新性，任何人都可以基于原有代码进行修改和分支，从而创建出更适合自己需求的解决方案。

我看到，越来越多的大公司采用开源的模式开发软件，谁不做开源，谁就会被业界淘汰，这种说法对么

在当前的软件开发领域，开源软件确实已经变得越来越普遍，越来越多的大公司也开始采用开源的模式进行软件开发，这是因为开源软件具有很多优点，比如可以节约成本、提高软件质量、增加开发效率等等。因此，采用开源的模式来开发软件的公司和项目越来越多，这也是一种趋势。

然而，不能简单地说谁不做开源就会被业界淘汰。闭源软件也有其存在的合理性，比如有些公司需要保护商业机密或是保持技术优势等等，因此不会选择开源软件。此外，对于某些领域或特定的应用场景，闭源软件可能会更为适合。

总之，开源软件的普及是一个趋势，但是不能简单地说谁不做开源就会被业界淘汰，应该根据具体情况来选择采用开源还是闭源的方式。

你了解v2ray, v2fly, xray之间的关系么，这对于了解开源软件的分裂和发展是一个很好地观察对象

是的，我了解v2ray、v2fly和xray之间的关系。这三个项目都是开源的代理软件，都基于v2ray核心代码开发而来，但是它们之间又有一些不同之处。

v2ray是最早的一个项目，由一个叫做"逆向太阳"的开发者发起，并得到了很多社区贡献者的支持。后来，由于一些开发方面的分歧，v2ray的主要开发者"逆向太阳"和其他核心开发者决裂，最终导致了v2ray项目的分裂。

v2fly是在v2ray分裂后成立的一个新项目，由一些原来的v2ray社区贡献者和其他开发者组成的团队共同开发，旨在继续推进v2ray的发展。与v2ray不同的是，v2fly更加注重用户体验，提供了更加友好的界面和更多的功能。

xray是最近出现的一个项目，也是基于v2ray核心代码开发而来，但是它在性能方面进行了很大的优化，并增加了一些新的功能。与v2ray和v2fly不同的是，xray由一个商业公司进行开发和支持。

这三个项目之间的关系反映了开源软件的分裂和发展的一般规律。在开源社区中，由于人员变动、技术分歧、商业利益等因素的影响，很容易出现项目分裂的情况，而且分裂后的项目往往会根据各自的方向和目标进行不同的发展。但是，这些项目之间也会有合作和交流，共同推进整个领域的发展。

对于一些新的操作系统挑战者，只能选择开源的方式才能和闭源的微软操作系统相对抗，对么？

可以这么说。操作系统是一个非常复杂的软件系统，需要大量的研发资源和技术积累才能打造出一款稳定、安全、易用的产品。相对于成熟的闭源操作系统，新的操作系统挑战者往往面临着技术和资源上的巨大压力。选择开源的方式，可以借鉴已有的开源技术和社区资源，降低开发成本和风险，提高开发效率。同时，开源的方式也可以吸引更多的开发者和用户参与到项目中来，形成一个更加广泛的社区和生态系统，增强产品的可持续发展能力。因此，对于一些新的操作系统挑战者来说，选择开源的方式确实是一个比较明智的选择。

开源就是免费，对么？

不完全正确。开源软件和免费软件是不同的概念。开源软件是指软件源代码开放给公众，并允许公众在遵循特定协议的情况下自由使用、修改、分发和分享的软件。而免费软件是指在价格上免费提供给用户使用的软件，这并不意味着软件的源代码一定是开放的。实际上，开源软件往往是免费的，因为任何人都可以自由获取和使用源代码来构建软件。但是，也有一些开源软件提供商会提供商业版的软件，这些商业版的软件可能是收费的。因此，开源软件不一定就是免费的，而且免费软件也不一定就是开源的。

开源有哪些协议，商用使用能用那些协议的软件？

开源软件有很多种协议，其中比较常见的包括：

GNU通用公共许可证（GPL）：允许自由使用、修改、发布和再授权源代码，但只有在使用相同的许可证下发布其衍生作品。
BSD许可证：允许自由使用、修改、发布和再授权源代码，但要求在衍生作品中包含原始版权声明和许可证。
MIT许可证：允许自由使用、修改、发布和再授权源代码，但不需要在衍生作品中包含原始版权声明和许可证。
Apache许可证：允许自由使用、修改、发布和再授权源代码，但要求在衍生作品中包含原始版权声明、许可证和贡献者声明。

商用使用开源软件需要注意的是，不同的开源协议有不同的限制和要求。一些协议（如MIT许可证）对商业使用没有限制，而其他协议（如GPL许可证）可能会要求发布衍生作品的源代码，或者要求将使用的其他组件的源代码公开。因此，在商业使用开源软件之前，需要仔细阅读相关的许可证并遵守其规定。

参考&致谢

chatGPT

那些有用的Github工具介绍！Action、app、workflow等

2022-10-02T11:16:04.000Z

Github Actoins 是 GitHub 推出的持续集成 (Continuous integration，简称 CI) 服务，它提供了配置非常不错的虚拟服务器环境，基于它可以进行构建、测试、打包、部署项目。是CICD的强力工具！

本文介绍几个常用的极为有用的Action工具！

GitHub Actions 是什么？

大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

GitHub 做了一个官方市场，可以搜索到他人提交的 actions。另外，还有一个 awesome actions 的仓库，也可以找到不少 action。

上面说了，每个 action 就是一个独立脚本，因此可以做成代码仓库，使用userName/repoName的语法引用 action。比如，actions/setup-node就表示github.com/actions/setup-node这个仓库，它代表一个 action，作用是安装 Node.js。事实上，GitHub 官方的 actions 都放在 github.com/actions 里面。

更多 Github action 介绍

awesome-actions

Github Action 使用限制：

官方文档：使用限制、计费和管理

在复刻公共仓库时，默认情况下将禁用计划的工作流程。

在公共仓库中，当 60 天内未发生仓库活动时，将自动禁用计划的工作流程。

每个仓库只能同时支持20个 workflow 并行。
每小时可以调用1000次 GitHub API 。
每个 job 最多可以执行6个小时。
免费版的用户最大支持20个 job 并发执行，macOS 最大只支持5个。
私有仓库每月累计使用时间为2000分钟，超过后$ 0.008/分钟，公共仓库则无限制。

Github 仓库与上游自动同步

保持自己github的forks自动和上游仓库同步的

信息来源于 https://github.com/wei/pull

只同步默认分支的教程

当上游的仓库仅有一个默认分支。或者上游仓库有两个分支，我们仅需要同步他的默认分支，其他分支对内容对我们来说无关紧要。

a) 登录自己的github账号，另开网页打开 https://github.com/wei/pull

b) 点击Pull app进行安装。

c) 安装过程中会让你选择要选择那一种方式，All repositories(就是同步已经frok的仓库以及未来fork的仓库)，Only select repositories(仅选择要自己需要同步的仓库，其他fork的仓库不会被同步)，根据自己需求选择，实在不知道怎么选择，就选All repositories；点击install，完成安装。

d) 后续，如果要调整1.c中的选项，打开 https://github.com/apps/pull ，点击Configure，输入github密码进入pull的相关设置。

e) 进入后，找到Repository access，根据自己的需求，重新选择：All repositories(就是同步已经frok的仓库以及未来fork的仓库)，Only select repositories(仅选择要自己需要同步的仓库，其他fork的仓库不会被同步)，Save后保存生效。

f) Pull app作者虽然在项目中写道keeps your forks up-to-date with upstream via automated pull requests，但当上游仓库有更改时，自己的仓库会在3个小时内完成与上游的同步，3个小时是Pull app作者说的最长时间。当然也可以通过手动触发同步上游仓库，手动触发方式：https://pull.git.ci/process/你的GitHub名字/你的仓库名字 （例如：https://pull.git.ci/process/xxxxx/test ），手动触发可能会进行人机验证，验证通过后会显示Success。

同步其他分支的教程

a) 假设你fork了上游仓库后，你fork后的地址为 https://github.com/你的仓库名字/test ，首先设置完成第1部分内容，注意在1.c步骤没有设置全部同步的，要回到1.e步，确认是否设置同步了 你的仓库名字/test，如果没有,请添加上。

b) 在默认分支下添加一个文件。

c) 复制 .github/pull.yml 粘贴后看到以下页面，注意github前面的那个.别漏掉了。

d) 请在https://github.com/wei/pull\#advanced-setup-with-config 页复制代码，

注意：upstream处要修改为上游仓库作者名字。

e) 最终的示例如下，假设上游作者是zhangsan，所有的注意点都用红线圈出来了，保存后生效。

f) Pull app作者虽然在项目中写道keeps your forks up-to-date with upstream via automated pull requests，但当上游仓库有更改时，自己的仓库会在3个小时内完成与上游的同步，3个小时是Pull app作者说的最长时间。当然也可以通过手动触发同步上游仓库，手动触发方式：https://pull.git.ci/process/你的GitHub名字/你的仓库名字 （例如：https://pull.git.ci/process/xxxxx/test），手动触发可能会进行人机验证，验证通过后会显示Success。具体见1.f提供的图片。

g) 本人仅测试过forks一个仓库只有2个分支的项目，如果有多个分支，不能保证是否可行，请自行测试，或者是使用本教程第3部分高级玩法。

高级玩法

当然，作者还有其他更好的项目用于同步所有分支，例如使用 GitHub actions 进行同步。请参考原作者的项目

Github 自动合并 PR

renovate

自动合并example renovate.json

{
  "extends": ["config:base"],
  "assignees": ["17lai"],
  "separateMinorPatch": true,
  "packageRules": [
    {
      "updateTypes": ["minor", "patch"],
      "automerge": true,
      "automergeType": "branch"
    }
  ]
}

mergify

mergify
开源项目这个工具是免费使用的！

使用 Github Dependabot 自动更新依赖版本

通过将配置文件检入仓库，可启用 Dependabot 版本更新。配置文件指定存储在仓库中的清单或其他包定义文件的位置。 Dependabot 使用此信息来检查过时的软件包和应用程序。 Dependabot 确定依赖项是否有新版本，它通过查看依赖的语义版本 (semver) 来决定是否应更新该版本。对于某些软件包管理器，Dependabot 版本更新也支持供应。供应（或缓存）的依赖项是检入仓库中特定目录的依赖项，而不是在清单中引用的依赖项。即使包服务器不可用，供应的依赖项在生成时也可用。 Dependabot 版本更新可以配置为检查为新版本供应的依赖项，并在必要时更新它们。

以上内容来自 GitHub 官方文档，简单的讲 Dependabot 就是一个没有感情的依赖更新机器人，在您的项目所依赖的上游软件包或应用程序发布新版本后，它会在您的 GitHub 仓库自动创建一个 PR 来更新依赖文件，并说明依赖更新内容，用户自己选择是否 merge 该 PR，效果如下图：

开启 Dependabot

开启方式比较简单，仅需将 dependabot.yml 配置文件放入仓库的 .github 目录中即可开启。之后 Dependabot 就会自动提交 PR 来更新您项目中的依赖项了。您也可以在 GitHub 页面上进行操作，在仓库页面通过 Insights -> Dependency graph -> Dependabot -> Enable Dependabot 路径即可开启，之后就可以点击 Create config file 来创建配置文件了。

配置完成后，即可看到需要监控的依赖文件和上次检查更新的时间。

配置 dependabot.yml

文件的配置也相对较为简单的直接，version、updates、package-ecosystem 、schedule 是必填的，还可以配置 registries 来指定私有仓库地址及认证信息。下面这个是官方示例，该示例中为 npm 和 Docker 配置了依赖自动更新，同时指定其依赖文件的地址和更新频率。有意思的是，在下面这个示例中，如果 Docker 依赖项已过时很久，可能会先执行 daily 安排，直到这些依赖项达到最新状态，然后降回每周安排。更多内容，可以参考官方文档。

# Basic dependabot.yml file with
# minimum configuration for two package managers

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates every day (weekdays)
    schedule:
      interval: "daily"

  # Enable version updates for Docker
  - package-ecosystem: "docker"
    # Look for a `Dockerfile` in the `root` directory
    directory: "/"
    # Check for updates once a week
    schedule:
      interval: "weekly"

支持的包管理器

目前 Dependabot 支持很多包管理器，具体内容可以参考下表：

要用于 dependabot.yml 文件中的 YAML 值
支持的包管理器版本
是否支持私有 GitHub 仓库或注册表中的依赖项
是否支持供应的依赖项

Package manager	YAML value	Supported versions	Private repositories	Private registries	Vendoring
Bundler	`bundler`	v1, v2		✓	✓
Cargo	`cargo`	v1	✓	✓
Composer	`composer`	v1, v2	✓	✓
Docker	`docker`	v1	✓	✓
Hex	`mix`	v1		✓
elm-package	`elm`	v0.19	✓	✓
git submodule	`gitsubmodule`	N/A (no version)	✓	✓
GitHub Actions	`github-actions`	N/A (no version)	✓	✓
Go modules	`gomod`	v1	✓	✓	✓
Gradle	`gradle`	N/A (no version)	✓	✓
Maven	`maven`	N/A (no version)	✓	✓
npm	`npm`	v6, v7	✓	✓
NuGet	`nuget`	<= 4.8	✓	✓
pip	`pip`	v21.1.2		✓
pipenv	`pip`	<= 2021-05-29		✓
pip-compile	`pip`	6.1.0		✓
poetry	`pip`	v1		✓
Terraform	`terraform`	>= 0.13, <= 1.0	✓	✓
yarn	`npm`	v1	✓	✓

更多内容可以参考官方文档。

Gitlab 镜像 Github

这个功能需要 gitlab ee 版本，CE版本是不支持镜像的

个人用户可以参考破解Gitlab EE
企业用户去付费买授权

Github 仓库备份

最优秀的资源，大多只在短时间内出现！

平时多备份你重要的仓库，以及你使用的仓库的重要上下游仓库！

github-backup Githb

github-backup Dockerhub

githubback:
  image: lnxd/github-backup
  container_name: "githubback"
  hostname: githubback
  # ports:
    # - "80:80"
  volumes:
    - "${USERDIR}/githubback/data:/home/docker/backups:rw"
  env_file:
    - .env
  environment:
    - HTTP_PROXY=http://[ip]:[port]
    - HTTPS_PROXY=http://[ip]:[port]
  restart: always

自动翻译

实例 GitHub Action https://github.com/walinejs/waline/blob/main/.github/workflows/issue-translator.yml

源码 https://github.com/lizheming/issues-translate-action 基于 https://github.com/dromara/issues-translate-action

后记

github action 太多强大，这里仅仅只能介绍一点点，有太多好东西了，太多宝藏值得去挖掘！

这就是开源的力量！在被大公司白嫖的同时，创造了无与伦比的社区生态！

参考&致谢

系列教程

全部文章RSS订阅

自建全套开源Devops开发系统

2022-05-09T05:00:25.000Z

国内的Devops云平台动辄封号，删库，屏蔽，还多次发生数据泄密，项目被云平台克隆事件，国内云平台devops已死！数据安全没法保证，自建私有Devops平台才靠谱。这里采用开源项目建立一个完善的低成本Devops系统，基本运行良好！

目标：单节点，以最低成本，最低消耗，使用开源软件实现一个可用的DevOps！满足中小企业的研发、测试、运维需求。并对后续如何扩展本套DevOps系统做了项目，成本，路线升级规划，可以一直扩展到业界最前沿最大系统。

整套系统已经跑起来很长时间了！单节点Nas服务器，32G内存，共运行了约80个Docker，优化到平均负载10以下。

Devops框架图解

下面系统大多可以做负载平衡，多节点备份，可以扩展为一个高可用，大中央平台。

珍爱生命，使用Docker！

开源云平台生死连问

珍爱生命，不建议使用国内云平台。

什么是大教堂？

什么是集市？

什么是信任链？

什么是开源生态？

为什么要做开源生态？

怎么做开源生态？

开源生态的土壤肥力维护如何做？

这些问题没想明白，没想到如何做的是没法做开源的。

国内平台连种子嫩芽都要收割，到处收费，动辄删库，屏蔽，封号，注定做不了开源生态。

`Consul`自动负载均衡

基于服务自动发现和注册的负载均衡，负载均衡的方式没有变，只是多了一些外围组件，当然这些组件对 Client 是不可见的，client 依然只能看到 Nginx 入口，访问方式也没变化。

`Github`仓库备份

最优秀的资源，大多只在短时间内出现！

平时多备份你重要的仓库，以及你使用的仓库的重要上下游仓库！

github-backup Githb

github-backup Dockerhub

githubback:
  image: lnxd/github-backup
  container_name: "githubback"
  hostname: githubback
  # ports:
    # - "80:80"
  volumes:
    - "${USERDIR}/githubback/data:/home/docker/backups:rw"
  env_file:
    - .env
  environment:
    - HTTP_PROXY=http://[ip]:[port]
    - HTTPS_PROXY=http://[ip]:[port]
  restart: always

配置要求

个人Nas配置

cpu j4125 4 核 14nm 2.00 GHz ~2.70 GHz

SSD sata 接口的读写 500MB/S

32G DDR4. 2x16G 双通道

上图中介绍的系统都是上面配置的单服务器中可以运行的。

如何以最低的配置，最少的内存运行起来最多的功能才是本文的追求，花费更多金钱去满足极少数情况的高压力是钱多的没处花。

8G内存的nas 就可以运行 gitea + drone ，zentao 想用就用
gitlab 要跑起来至少要2核 8G 内存，jenkins 也是内存 cpu 占用大户。大于 16G 内存时考虑上这个
4核 32G 内存的nas，图片中介绍的可以全都跑起来！

可靠性

ELK集群监控对于单服务器来说完全多余，netdata监控也不错，portainer就够用了，以后为了节约资源，portainer说不定也会被干掉，大多数时候命令行监控就够了。少于200节点K8S就是多余的。

数据安全

云平台把数据交给别人，赌别人的道德不会私自偷拿你的数据？真是想多了。

某垄断社交平台内部有专门的团队分析客户的数据，看有什么有价值的没有，是很多年前就爆出来的消息。

自建DevOps成本其实相当的低！

整套系统可以从少到多，从小到大，慢慢优化，扩展的。硬件成本也是随着需求变化而变化的，随着业务扩展而增加成本，一开始单节点单服务器就可以满足要求了，后面业务增加慢慢扩展为集群，k8s 等。

数据，代码是公司核心资产与竞争力的公司，上云赌别人的人品就是找死。你注册账户的时候，就同意了，无论别人随意删除你的数据，或者窃取你的数据都是不用付任何责任的，再说，整个系统数据都在别人手上，你要维权也没有证据。

备份

UPS电源，防止意外断电
rsync 备份，对于大多数人，已经够用了
文件系统快照
离线每日，或者每周冷备份
大系统，多台服务器的时候可以用多节点集群备灾。nginx,harbor，gitlab，elasticsearch等都可以使用集群

扩展性

上面说的都可以单服务器搞定。多台服务器的时候可以用多节点集群备灾。nginx,harbor，gitlab，elasticsearch等都可以使用集群。

多于200节点，大于3台服务器以后考虑上K8S。ELK监控之类的这时候可以上了。蓝鲸智云标准运维这时候也可以考虑了。

再次扩大的时候可以考虑Proxmox VE（PVE） + ceph

更大的系统，或者对外提供云平台服务的时候可以考虑上OpenStack

项目介绍

ELK

消耗资源很多，至少上百节点以上再考虑上这个

portainer -> netdata -> ELK，zabbix

cacti

zabbix

ansible

CMDB

PVE

Proxmox VE（PVE）

CEPH

OpenStack

其它项目

大家还有啥好项目建议？

onedev

onedev 是替代Gitlab的极佳候补，看文档介绍，潜力无限！

smartdns

一个本地DNS服务器，获取最快的网站IP，获得最佳上网体验。

awesome-selfhosted

这里你能找到各种各样的自建 Docker 服务

私有Git服务器整理

ruby系：GitLab。这个没什么好说的，说到私有git服务器第一反应必然是这个，似乎也是目前已知的开源git服务器中体量最大的，功能齐全，界面美观。
golang系：Gogs、gitea、forgejo。这仨一脉相传，简单概括来说，就是先有的gogs，然后一群贡献者嫌gogs更新慢、不加新功能，然后fork出了gitea；然后gitea搞了几年之后开公司了，codeberg担心gitea搞收费，就又从gitea代码fork出了一个forgejo自己开发。
Java系：gitbucket、GitBlit、OneDev。这三家都是个搞个的，其中OneDev比较新，界面做的也比较现代化。

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

Git介绍以及分支模型图解

2022-04-19T12:07:16.000Z

不废话，直接上图。

由 Drawio 绘制

GIT架构

GIT的架构，可以分为几个部分：

本地工作区(working directory)
暂存区(stage area, 又称为索引区, index)、
本地仓库(local repository)、
远程仓库副本
远程仓库(remote repository)。

工作区(working directory) 简言之就是你工作的区域。对于git而言，就是的本地工作目录。工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。

暂存区(stage area, 又称为索引区index) 是git中一个非常重要的概念。是我们把修改提交版本库前的一个过渡阶段。查看GIT自带帮助手册的时候，通常以index来表示暂存区。在工作目录下有一个.git的目录，里面有个index文件，存储着关于暂存区的内容。git add命令将工作区内容添加到暂存区。

本地仓库(local repository) 版本控制系统的仓库，存在于本地。当执行git commit命令后，会将暂存区内容提交到仓库之中。在工作区下面有.git的目录，这个目录下的内容不属于工作区，里面便是仓库的数据信息，暂存区相关内容也在其中。

远程版本库(remote repository) 与本地仓库概念基本一致，不同之处在于一个存在远程，可用于远程协作，一个却是存在于本地。通过push/pull可实现本地与远程的交互；

远程仓库副本 可以理解为存在于本地的远程仓库缓存。如需更新，可通过git fetch/pull命令获取远程仓库内容。使用fech获取时，并未合并到本地仓库，此时可使用git merge实现远程仓库副本与本地仓库的合并。

`.git`介绍

.git目录下各个文件中所存放的内容信息：

HEAD 当前所在位置，其实就是工作区的在版本库中的那个提交点，最终会指向一个40位的HASH值；
config 当前版本库的专有配置文件，如使用命令git config user.name poloxue便会记录在此文件；
description 被gitweb (Github的原型)用来显示对repo的描述。
hooks git有可自动运行在 git 任有意义阶段的脚本hooks, 如commit/release/pull/push等状态之前或者之后。个人思考的一个用处，如pre-push可以用来强制进行代码检查。
index 存放暂存区(stage area)的相关信息；
info/exclue 可以做到和.gitignore相同的事情，用于排除不要包含进版本库的文件。区别就是，此文件不会被共享。
refs/heads 目录下有关于本地仓库的所有分支；
refs/remote 目录下有关于远程仓库的所有分支；
object 目录下存放的就是实际的数据文件

Commitizen

Commitizen——标准化的Git commit工具

Commitizen 分为两部分，脚手架（cz-cli）和规范（Adapters）

脚手架可以帮助我们初始化和构建 Commitizen，而规范是开发者可以自定义的内容

官方默认提供的规范是 cz-conventional-changelog

同时，官方也提供了一些优秀的第三方规范，例如你肯定想要的表情包commit规范：cz-emoji-conventional

本文也将提供这两种规范的安装和使用方式

安装

一条命令搞定

npm install -g commitizen

这就安装成功了，而且是全局安装，以后再用就不用重复安装了

当然，安装成功的只是一个脚手架，现在还不能使用

创建 package.json

Commitizen 基于 nodejs，想要使用的话，在你的项目中自然需要一个 package.json

如果已经存在了那最好，没有的话，例如是一个 java 项目，那么你可以在项目根目录执行以下命令

npm init

当然，如果不是 nodejs 的项目，你肯定不需要将这些文件也上传到 git

你可以在 .gitignore 文件中加入下面几句来忽略这些文件

package-lock.json
package.json
node_modules/

初始化

这一步就可以选择我们需要的规范了

windows

commitizen init 规范名称 --save-dev --save-exact

linux

commitizen init 规范名称 --yarn --dev --exact

commitizen 脚手架会自动帮我们导入规范的依赖并进行下载，所以你只要注意不要写错规范名称就好了

关于这些名称，可以参考这里推荐的规范

例如你想使用默认的规范

那么可以这样写：

commitizen init cz-conventional-changelog --save-dev --save-exact

而如果你想使用带表情包的，就这样写：

commitizen init cz-emoji-conventional --save-dev --save-exact

使用

使用的方式很简单，将你原本要输入的 git commit 命令替换为 git cz 即可

当你的控制台出现这样的界面，你可以使用方向键的 ↑ 和 ↓ 来移动光标选择这次 commit 的 type

按回车 enter 进行选择

常用的 type 有：

英文	含义
feat	新特性，新功能
fix	修bug
docs	更新文档
style	修改代码风格、代码格式（不影响代码运行的变动）
refactor	重构代码（既不是新增功能，也不是修改bug，可以理解为觉得原本写太烂了，重新写了一遍）
perf	优化性能、优化体验
test	测试
chore	构建过程或者辅助工具的变动
revert	回滚版本
merge	代码合并
sync	同步主线或分支

随后，根据提示输入相关信息即可

例如

scope 作用域，也就是这次变动影响的范围，例如数据层，控制层，或者单单某个类
subject / description 描述，cz 将描述分为简短描述和详细描述，使用几下就清楚了

除此以外，cz 还会提示你这次变动是否与某个 issue 有关等等

变更规范

上面是在初始化时选择的规范，如果在后期我们想要变更该怎么做？

首先，脚手架只有在初始化才能帮我们自动管理依赖

后期想要变动，就得手动下载依赖了

例如初始化时用的是官方默认的规范

那么这时候你的package.json里面会有这样一段代码

"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"
    }
}

我们如果想要换成有表情包的规范形式 cz-emoji-conventional

首先需要下载依赖，当然是要在项目根目录执行：

npm i cz-emoji-conventional

然后修改上面 package.json 中的配置

"config": {
    "commitizen": {
        "path": "node_modules/cz-emoji-conventional"
    }
}

到这里，规范就修改完成了

全局安装

上面所讲的安装方式仅适用于项目内，也就是每一个项目都会创建node_modules并安装依赖。

如果需要在电脑上任意地方都能用 git cz 命令，需要进行全局安装：

脚手架 npm install -g commitizen
选择一个规范，参考上文：npm install -g cz-emoji-conventional
在用户目录下创建文件 .czrc

Windows：C:\user\用户名

Linux: /home
编辑 .czrc 文件，写入规范名称：
```
{
    "path": "cz-emoji-conventional"
}
```

参考

Git 教程

Git book

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

三万字无坑搭建基于Docker+K8S+GitLab/SVN+Jenkins+Harbor持续集成交付环境

2022-04-16T10:49:57.000Z

最近在 K8S 1.18.2 版本的集群上搭建DevOps环境，期间遇到了各种坑。目前，搭建环境的过程中出现的各种坑均已被填平，特此记录，并分享给大家！

文章和搭建环境所需要的yml文件已收录到：https://github.com/sunshinelyz/technology-binghe 和 https://gitee.com/binghe001/technology-binghe 。如果文件对你有点帮助，别忘记给个Star哦！

服务器规划

IP	主机名	节点	操作系统
192.168.175.101	binghe101	K8S Master	CentOS 8.0.1905
192.168.175.102	binghe102	K8S Worker	CentOS 8.0.1905
192.168.175.103	binghe103	K8S Worker	CentOS 8.0.1905

安装环境版本

软件名称	软件版本	说明
Docker	19.03.8	提供容器环境
docker-compose	1.25.5	定义和运行由多个容器组成的应用
K8S	1.8.12	是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。
GitLab	12.1.6	代码仓库（与SVN安装一个即可）
Harbor	1.10.2	私有镜像仓库
Jenkins	2.89.3	持续集成交付
SVN	1.10.2	代码仓库（与GitLab安装一个即可）
JDK	1.8.0_202	Java运行基础环境
maven	3.6.3	构建项目的基础插件

服务器免密码登录

在各服务器执行如下命令。

ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

将binghe102和binghe103服务器上的id_rsa.pub文件复制到binghe101服务器。

[root@binghe102 ~]# scp .ssh/id_rsa.pub binghe101:/root/.ssh/102
[root@binghe103 ~]# scp .ssh/id_rsa.pub binghe101:/root/.ssh/103

在binghe101服务器上执行如下命令。

cat ~/.ssh/102 >> ~/.ssh/authorized_keys
cat ~/.ssh/103 >> ~/.ssh/authorized_keys

然后将authorized_keys文件分别复制到binghe102、binghe103服务器。

[root@binghe101 ~]# scp .ssh/authorized_keys binghe102:/root/.ssh/authorized_keys
[root@binghe101 ~]# scp .ssh/authorized_keys binghe103:/root/.ssh/authorized_keys

删除binghe101节点上~/.ssh下的102和103文件。

rm ~/.ssh/102
rm ~/.ssh/103

安装JDK

需要在每台服务器上安装JDK环境。到Oracle官方下载JDK，我这里下的JDK版本为1.8.0_202，下载后解压并配置系统环境变量。

tar -zxvf jdk1.8.0_212.tar.gz
mv jdk1.8.0_212 /usr/local

接下来，配置系统环境变量。

配置项内容如下所示。

JAVA_HOME=/usr/local/jdk1.8.0_212
CLASS_PATH=.:$JAVA_HOME/lib
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASS_PATH PATH

接下来执行如下命令使系统环境变量生效。

安装Maven

到Apache官方下载Maven，我这里下载的Maven版本为3.6.3。下载后直接解压并配置系统环境变量。

tar -zxvf apache-maven-3.6.3-bin.tar.gz
mv apache-maven-3.6.3-bin /usr/local

接下来，就是配置系统环境变量。

配置项内容如下所示。

JAVA_HOME=/usr/local/jdk1.8.0_212
MAVEN_HOME=/usr/local/apache-maven-3.6.3-bin
CLASS_PATH=.:$JAVA_HOME/lib
PATH=$MAVEN_HOME/bin:$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASS_PATH MAVEN_HOME PATH

接下来执行如下命令使系统环境变量生效。

接下来，修改Maven的配置文件，如下所示。

<localRepository>/home/repository</localRepository>

将Maven下载的Jar包存储到/home/repository目录下。

安装Docker环境

本文档基于Docker 19.03.8 版本搭建Docker环境。

在所有服务器上创建install_docker.sh脚本，脚本内容如下所示。

export REGISTRY_MIRROR=https://registry.cn-hangzhou.aliyuncs.com
dnf install yum*
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
dnf install https://mirrors.aliyun.com/docker-ce/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.13-3.1.el7.x86_64.rpm
yum install -y docker-ce-19.03.8 docker-ce-cli-19.03.8
systemctl enable docker.service
systemctl start docker.service
docker version

在每台服务器上为install_docker.sh脚本赋予可执行权限，并执行脚本即可。

安装docker-compose

注意：在每台服务器上安装docker-compose

1.下载docker-compose文件

curl -L https://github.com/docker/compose/releases/download/1.25.5/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

2.为docker-compose文件赋予可执行权限

chmod a+x /usr/local/bin/docker-compose

3.查看docker-compose版本

[root@binghe ~]# docker-compose version
docker-compose version 1.25.5, build 8a1c60f6
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

安装K8S集群环境

本文档基于K8S 1.8.12版本来搭建K8S集群

安装K8S基础环境

在所有服务器上创建install_k8s.sh脚本文件，脚本文件的内容如下所示。

#配置阿里云镜像加速器
mkdir -p /etc/docker
tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"]
}
EOF
systemctl daemon-reload
systemctl restart docker

#安装nfs-utils
yum install -y nfs-utils
yum install -y wget

#启动nfs-server
systemctl start nfs-server
systemctl enable nfs-server

#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

#关闭SeLinux
setenforce 0
sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config

# 关闭 swap
swapoff -a
yes | cp /etc/fstab /etc/fstab_bak
cat /etc/fstab_bak |grep -v swap > /etc/fstab

#修改 /etc/sysctl.conf
# 如果有配置，则修改
sed -i "s#^net.ipv4.ip_forward.*#net.ipv4.ip_forward=1#g"  /etc/sysctl.conf
sed -i "s#^net.bridge.bridge-nf-call-ip6tables.*#net.bridge.bridge-nf-call-ip6tables=1#g"  /etc/sysctl.conf
sed -i "s#^net.bridge.bridge-nf-call-iptables.*#net.bridge.bridge-nf-call-iptables=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.all.disable_ipv6.*#net.ipv6.conf.all.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.default.disable_ipv6.*#net.ipv6.conf.default.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.lo.disable_ipv6.*#net.ipv6.conf.lo.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.all.forwarding.*#net.ipv6.conf.all.forwarding=1#g"  /etc/sysctl.conf
# 可能没有，追加
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-ip6tables = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.lo.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 1"  >> /etc/sysctl.conf
# 执行命令以应用
sysctl -p

# 配置K8S的yum源
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
       http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

# 卸载旧版本K8S
yum remove -y kubelet kubeadm kubectl

# 安装kubelet、kubeadm、kubectl，这里我安装的是1.18.2版本，你也可以安装1.17.2版本
yum install -y kubelet-1.18.2 kubeadm-1.18.2 kubectl-1.18.2

# 修改docker Cgroup Driver为systemd
# # 将/usr/lib/systemd/system/docker.service文件中的这一行 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
# # 修改为 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd
# 如果不修改，在添加 worker 节点时可能会碰到如下错误
# [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". 
# Please follow the guide at https://kubernetes.io/docs/setup/cri/
sed -i "s#^ExecStart=/usr/bin/dockerd.*#ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd#g" /usr/lib/systemd/system/docker.service

# 设置 docker 镜像，提高 docker 镜像下载速度和稳定性
# 如果访问 https://hub.docker.io 速度非常稳定，亦可以跳过这个步骤
# curl -sSL https://kuboard.cn/install-script/set_mirror.sh | sh -s ${REGISTRY_MIRROR}

# 重启 docker，并启动 kubelet
systemctl daemon-reload
systemctl restart docker
systemctl enable kubelet && systemctl start kubelet

docker version

在每台服务器上为install_k8s.sh脚本赋予可执行权限，并执行脚本即可。

初始化Master节点

只在binghe101服务器上执行的操作。

1.初始化Master节点的网络环境

注意：下面的命令需要在命令行手动执行。

# 只在 master 节点执行
# export 命令只在当前 shell 会话中有效，开启新的 shell 窗口后，如果要继续安装过程，请重新执行此处的 export 命令
export MASTER_IP=192.168.175.101
# 替换 k8s.master 为 您想要的 dnsName
export APISERVER_NAME=k8s.master
# Kubernetes 容器组所在的网段，该网段安装完成后，由 kubernetes 创建，事先并不存在于物理网络中
export POD_SUBNET=172.18.0.1/16
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

2.初始化Master节点

在binghe101服务器上创建init_master.sh脚本文件，文件内容如下所示。

#!/bin/bash
# 脚本出错时终止执行
set -e

if [ ${#POD_SUBNET} -eq 0 ] || [ ${#APISERVER_NAME} -eq 0 ]; then
  echo -e "\033[31;1m请确保您已经设置了环境变量 POD_SUBNET 和 APISERVER_NAME \033[0m"
  echo 当前POD_SUBNET=$POD_SUBNET
  echo 当前APISERVER_NAME=$APISERVER_NAME
  exit 1
fi


# 查看完整配置选项 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
rm -f ./kubeadm-config.yaml
cat <<EOF > ./kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.18.2
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
controlPlaneEndpoint: "${APISERVER_NAME}:6443"
networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "${POD_SUBNET}"
  dnsDomain: "cluster.local"
EOF

# kubeadm init
# 根据服务器网速的情况，您需要等候 3 - 10 分钟
kubeadm init --config=kubeadm-config.yaml --upload-certs

# 配置 kubectl
rm -rf /root/.kube/
mkdir /root/.kube/
cp -i /etc/kubernetes/admin.conf /root/.kube/config

# 安装 calico 网络插件
# 参考文档 https://docs.projectcalico.org/v3.13/getting-started/kubernetes/self-managed-onprem/onpremises
echo "安装calico-3.13.1"
rm -f calico-3.13.1.yaml
wget https://kuboard.cn/install-script/calico/calico-3.13.1.yaml
kubectl apply -f calico-3.13.1.yaml

赋予init_master.sh脚本文件可执行权限并执行脚本。

3.查看Master节点的初始化结果

（1）确保所有容器组处于Running状态

# 执行如下命令，等待 3-10 分钟，直到所有的容器组处于 Running 状态
watch kubectl get pod -n kube-system -o wide

具体执行如下所示。

[root@binghe101 ~]# watch kubectl get pod -n kube-system -o wide
Every 2.0s: kubectl get pod -n kube-system -o wide                                                                                                                          binghe101: Sun May 10 11:01:32 2020

NAME                                       READY   STATUS    RESTARTS   AGE    IP                NODE        NOMINATED NODE   READINESS GATES          
calico-kube-controllers-5b8b769fcd-5dtlp   1/1     Running   0          118s   172.18.203.66     binghe101   <none>           <none>          
calico-node-fnv8g                          1/1     Running   0          118s   192.168.175.101   binghe101   <none>           <none>          
coredns-546565776c-27t7h                   1/1     Running   0          2m1s   172.18.203.67     binghe101   <none>           <none>          
coredns-546565776c-hjb8z                   1/1     Running   0          2m1s   172.18.203.65     binghe101   <none>           <none>          
etcd-binghe101                             1/1     Running   0          2m7s   192.168.175.101   binghe101   <none>           <none>          
kube-apiserver-binghe101                   1/1     Running   0          2m7s   192.168.175.101   binghe101   <none>           <none>          
kube-controller-manager-binghe101          1/1     Running   0          2m7s   192.168.175.101   binghe101   <none>           <none>          
kube-proxy-dvgsr                           1/1     Running   0          2m1s   192.168.175.101   binghe101   <none>           <none>          
kube-scheduler-binghe101                   1/1     Running   0          2m7s   192.168.175.101   binghe101   <none>           <none>

（2）查看 Master 节点初始化结果

kubectl get nodes -o wide

具体执行如下所示。

[root@binghe101 ~]# kubectl get nodes -o wide
NAME        STATUS   ROLES    AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION         CONTAINER-RUNTIME
binghe101   Ready    master   3m28s   v1.18.2   192.168.175.101   <none>        CentOS Linux 8 (Core)   4.18.0-80.el8.x86_64   docker://19.3.8

初始化Worker节点

1.获取join命令参数

在Master节点（binghe101服务器）上执行如下命令获取join命令参数。

kubeadm token create --print-join-command

具体执行如下所示。

[root@binghe101 ~]# kubeadm token create --print-join-command
W0510 11:04:34.828126   56132 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

其中，有如下一行输出。

kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

这行代码就是获取到的join命令。

注意：join命令中的token的有效时间为 2 个小时，2小时内，可以使用此 token 初始化任意数量的 worker 节点。

2.初始化Worker节点

针对所有的 worker 节点执行，在这里，就是在binghe102服务器和binghe103服务器上执行。

在命令分别手动执行如下命令。

# 只在 worker 节点执行
# 192.168.175.101 为 master 节点的内网 IP
export MASTER_IP=192.168.175.101
# 替换 k8s.master 为初始化 master 节点时所使用的 APISERVER_NAME
export APISERVER_NAME=k8s.master
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

# 替换为 master 节点上 kubeadm token create 命令输出的join
kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

具体执行如下所示。

[root@binghe102 ~]# export MASTER_IP=192.168.175.101
[root@binghe102 ~]# export APISERVER_NAME=k8s.master
[root@binghe102 ~]# echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts
[root@binghe102 ~]# kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d 
W0510 11:08:27.709263   42795 join.go:346] [preflight] WARNING: JoinControlPane.controlPlane settings will be ignored when control-plane flag is not set.
[preflight] Running pre-flight checks
        [WARNING FileExisting-tc]: tc not found in system path
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

根据输出结果可以看出，Worker节点加入了K8S集群。

注意：kubeadm join…就是master 节点上 kubeadm token create 命令输出的join。

3.查看初始化结果

在Master节点（binghe101服务器）执行如下命令查看初始化结果。

kubectl get nodes -o wide

具体执行如下所示。

[root@binghe101 ~]# kubectl get nodes
NAME        STATUS   ROLES    AGE     VERSION
binghe101   Ready    master   20m     v1.18.2
binghe102   Ready    <none>   2m46s   v1.18.2
binghe103   Ready    <none>   2m46s   v1.18.2

注意：kubectl get nodes命令后面加上-o wide参数可以输出更多的信息。

重启K8S集群引起的问题

1.Worker节点故障不能启动

Master 节点的 IP 地址发生变化，导致 worker 节点不能启动。需要重新安装K8S集群，并确保所有节点都有固定的内网 IP 地址。

2.Pod崩溃或不能正常访问

重启服务器后使用如下命令查看Pod的运行状态。

kubectl get pods --all-namespaces

发现很多 Pod 不在 Running 状态，此时，需要使用如下命令删除运行不正常的Pod。

kubectl delete pod <pod-name> -n <pod-namespece>

注意：如果Pod 是使用 Deployment、StatefulSet 等控制器创建的，K8S 将创建新的 Pod 作为替代，重新启动的 Pod 通常能够正常工作。

K8S安装ingress-nginx

注意：在Master节点（binghe101服务器上执行）

1.创建ingress-nginx命名空间

创建ingress-nginx-namespace.yaml文件，文件内容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    name: ingress-nginx

执行如下命令创建ingress-nginx命名空间。

kubectl apply -f ingress-nginx-namespace.yaml

2.安装ingress controller

创建ingress-nginx-mandatory.yaml文件，文件内容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: default-http-backend
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: default-http-backend
        app.kubernetes.io/part-of: ingress-nginx
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: default-http-backend
          
          
          
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64:1.5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: 10m
              memory: 20Mi
            requests:
              cpu: 10m
              memory: 20Mi

---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
spec:
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      
      
      
      
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

---

执行如下命令安装ingress controller。

kubectl apply -f ingress-nginx-mandatory.yaml

3.安装K8S SVC：ingress-nginx

主要是用来用于暴露pod：nginx-ingress-controller。

创建service-nodeport.yaml文件，文件内容如下所示。

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
      nodePort: 30080
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
      nodePort: 30443
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

执行如下命令安装。

kubectl apply -f service-nodeport.yaml

4.访问K8S SVC：ingress-nginx

查看ingress-nginx命名空间的部署情况，如下所示。

[root@binghe101 k8s]# kubectl get pod -n ingress-nginx
NAME                                        READY   STATUS    RESTARTS   AGE
default-http-backend-796ddcd9b-vfmgn        1/1     Running   1          10h
nginx-ingress-controller-58985cc996-87754   1/1     Running   2          10h

在命令行服务器命令行输入如下命令查看ingress-nginx的端口映射情况。

kubectl get svc -n ingress-nginx

具体如下所示。

[root@binghe101 k8s]# kubectl get svc -n ingress-nginx 
NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                      AGE
default-http-backend   ClusterIP   10.96.247.2   <none>        80/TCP                       7m3s
ingress-nginx          NodePort    10.96.40.6    <none>        80:30080/TCP,443:30443/TCP   4m35s

所以，可以通过Master节点（binghe101服务器）的IP地址和30080端口号来访问ingress-nginx，如下所示。

[root@binghe101 k8s]# curl 192.168.175.101:30080       
default backend - 404

也可以在浏览器打开http://192.168.175.101:30080 来访问ingress-nginx，如下所示。

K8S安装gitlab代码仓库

注意：在Master节点（binghe101服务器上执行）

1.创建k8s-ops命名空间

创建k8s-ops-namespace.yaml文件，文件内容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: k8s-ops
  labels:
    name: k8s-ops

执行如下命令创建命名空间。

kubectl apply -f k8s-ops-namespace.yaml

2.安装gitlab-redis

创建gitlab-redis.yaml文件，文件的内容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: k8s-ops
  labels:
    name: redis
spec:
  selector:
    matchLabels:
      name: redis
  template:
    metadata:
      name: redis
      labels:
        name: redis
    spec:
      containers:
      - name: redis
        image: sameersbn/redis
        imagePullPolicy: IfNotPresent
        ports:
        - name: redis
          containerPort: 6379
        volumeMounts:
        - mountPath: /var/lib/redis
          name: data
        livenessProbe:
          exec:
            command:
            - redis-cli
            - ping
          initialDelaySeconds: 30
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - redis-cli
            - ping
          initialDelaySeconds: 10
          timeoutSeconds: 5
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/redis

---
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: k8s-ops
  labels:
    name: redis
spec:
  ports:
    - name: redis
      port: 6379
      targetPort: redis
  selector:
    name: redis

首先，在命令行执行如下命令创建/data1/docker/xinsrv/redis目录。

mkdir -p /data1/docker/xinsrv/redis

执行如下命令安装gitlab-redis。

kubectl apply -f gitlab-redis.yaml

3.安装gitlab-postgresql

创建gitlab-postgresql.yaml，文件内容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgresql
  namespace: k8s-ops
  labels:
    name: postgresql
spec:
  selector:
    matchLabels:
      name: postgresql
  template:
    metadata:
      name: postgresql
      labels:
        name: postgresql
    spec:
      containers:
      - name: postgresql
        image: sameersbn/postgresql
        imagePullPolicy: IfNotPresent
        env:
        - name: DB_USER
          value: gitlab
        - name: DB_PASS
          value: passw0rd
        - name: DB_NAME
          value: gitlab_production
        - name: DB_EXTENSION
          value: pg_trgm
        ports:
        - name: postgres
          containerPort: 5432
        volumeMounts:
        - mountPath: /var/lib/postgresql
          name: data
        livenessProbe:
          exec:
            command:
            - pg_isready
            - -h
            - localhost
            - -U
            - postgres
          initialDelaySeconds: 30
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - pg_isready
            - -h
            - localhost
            - -U
            - postgres
          initialDelaySeconds: 5
          timeoutSeconds: 1
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/postgresql
---
apiVersion: v1
kind: Service
metadata:
  name: postgresql
  namespace: k8s-ops
  labels:
    name: postgresql
spec:
  ports:
    - name: postgres
      port: 5432
      targetPort: postgres
  selector:
    name: postgresql

首先，执行如下命令创建/data1/docker/xinsrv/postgresql目录。

mkdir -p /data1/docker/xinsrv/postgresql

接下来，安装gitlab-postgresql，如下所示。

kubectl apply -f gitlab-postgresql.yaml

4.安装gitlab

（1）配置用户名和密码

首先，在命令行使用base64编码为用户名和密码进行转码，本示例中，使用的用户名为admin，密码为admin.1231

转码情况如下所示。

[root@binghe101 k8s]# echo -n 'admin' | base64 
YWRtaW4=
[root@binghe101 k8s]# echo -n 'admin.1231' | base64 
YWRtaW4uMTIzMQ==

转码后的用户名为：YWRtaW4= 密码为：YWRtaW4uMTIzMQ==

也可以对base64编码后的字符串解码，例如，对密码字符串解码，如下所示。

[root@binghe101 k8s]# echo 'YWRtaW4uMTIzMQ==' | base64 --decode 
admin.1231

接下来，创建secret-gitlab.yaml文件，主要是用户来配置GitLab的用户名和密码，文件内容如下所示。

apiVersion: v1
kind: Secret
metadata:
  namespace: k8s-ops
  name: git-user-pass
type: Opaque
data:
  username: YWRtaW4=
  password: YWRtaW4uMTIzMQ==

执行配置文件的内容，如下所示。

kubectl create -f ./secret-gitlab.yaml

（2）安装GitLab

创建gitlab.yaml文件，文件的内容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab
  namespace: k8s-ops
  labels:
    name: gitlab
spec:
  selector:
    matchLabels:
      name: gitlab
  template:
    metadata:
      name: gitlab
      labels:
        name: gitlab
    spec:
      containers:
      - name: gitlab
        image: sameersbn/gitlab:12.1.6
        imagePullPolicy: IfNotPresent
        env:
        - name: TZ
          value: Asia/Shanghai
        - name: GITLAB_TIMEZONE
          value: Beijing
        - name: GITLAB_SECRETS_DB_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_SECRETS_SECRET_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_SECRETS_OTP_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: git-user-pass
              key: password
        - name: GITLAB_ROOT_EMAIL
          value: 12345678@qq.com
        - name: GITLAB_HOST
          value: gitlab.binghe.com
        - name: GITLAB_PORT
          value: "80"
        - name: GITLAB_SSH_PORT
          value: "30022"
        - name: GITLAB_NOTIFY_ON_BROKEN_BUILDS
          value: "true"
        - name: GITLAB_NOTIFY_PUSHER
          value: "false"
        - name: GITLAB_BACKUP_SCHEDULE
          value: daily
        - name: GITLAB_BACKUP_TIME
          value: 01:00
        - name: DB_TYPE
          value: postgres
        - name: DB_HOST
          value: postgresql
        - name: DB_PORT
          value: "5432"
        - name: DB_USER
          value: gitlab
        - name: DB_PASS
          value: passw0rd
        - name: DB_NAME
          value: gitlab_production
        - name: REDIS_HOST
          value: redis
        - name: REDIS_PORT
          value: "6379"
        ports:
        - name: http
          containerPort: 80
        - name: ssh
          containerPort: 22
        volumeMounts:
        - mountPath: /home/git/data
          name: data
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 180
          timeoutSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 1
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/gitlab
---
apiVersion: v1
kind: Service
metadata:
  name: gitlab
  namespace: k8s-ops
  labels:
    name: gitlab
spec:
  ports:
    - name: http
      port: 80
      nodePort: 30088
    - name: ssh
      port: 22
      targetPort: ssh
      nodePort: 30022
  type: NodePort
  selector:
    name: gitlab

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gitlab
  namespace: k8s-ops
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: gitlab.binghe.com
    http:
      paths:
      - backend:
          serviceName: gitlab
          servicePort: http

注意：在配置GitLab时，监听主机时，不能使用IP地址，需要使用主机名或者域名，上述配置中，我使用的是gitlab.binghe.com主机名。

在命令行执行如下命令创建/data1/docker/xinsrv/gitlab目录。

mkdir -p /data1/docker/xinsrv/gitlab

安装GitLab，如下所示。

kubectl apply -f gitlab.yaml

5.安装完成

查看k8s-ops命名空间部署情况，如下所示。

[root@binghe101 k8s]# kubectl get pod -n k8s-ops
NAME                          READY   STATUS    RESTARTS   AGE
gitlab-7b459db47c-5vk6t       0/1     Running   0          11s
postgresql-79567459d7-x52vx   1/1     Running   0          30m
redis-67f4cdc96c-h5ckz        1/1     Running   1          10h

也可以使用如下命令查看。

[root@binghe101 k8s]# kubectl get pod --namespace=k8s-ops
NAME                          READY   STATUS    RESTARTS   AGE
gitlab-7b459db47c-5vk6t       0/1     Running   0          36s
postgresql-79567459d7-x52vx   1/1     Running   0          30m
redis-67f4cdc96c-h5ckz        1/1     Running   1          10h

二者效果一样。

接下来，查看GitLab的端口映射，如下所示。

[root@binghe101 k8s]# kubectl get svc -n k8s-ops
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                     AGE
gitlab       NodePort    10.96.153.100   <none>        80:30088/TCP,22:30022/TCP   2m42s
postgresql   ClusterIP   10.96.203.119   <none>        5432/TCP                    32m
redis        ClusterIP   10.96.107.150   <none>        6379/TCP                    10h

此时，可以看到，可以通过Master节点（binghe101）的主机名gitlab.binghe.com和端口30088就能够访问GitLab。由于我这里使用的是虚拟机来搭建相关的环境，在本机访问虚拟机映射的gitlab.binghe.com时，需要配置本机的hosts文件，在本机的hosts文件中加入如下配置项。

192.168.175.101 gitlab.binghe.com

注意：在Windows操作系统中，hosts文件所在的目录如下。

C:\Windows\System32\drivers\etc

接下来，就可以在浏览器中通过链接：http://gitlab.binghe.com:30088 来访问GitLab了，如下所示。

此时，可以通过用户名root和密码admin.1231来登录GitLab了。

注意：这里的用户名是root而不是admin，因为root是GitLab默认的超级用户。

登录后的界面如下所示。

到此，K8S安装gitlab完成。

安装Harbor私有仓库

注意：这里将Harbor私有仓库安装在Master节点（binghe101服务器）上，实际生产环境中建议安装在其他服务器。

1.下载Harbor的离线安装版本

wget https://github.com/goharbor/harbor/releases/download/v1.10.2/harbor-offline-installer-v1.10.2.tgz

2.解压Harbor的安装包

tar -zxvf harbor-offline-installer-v1.10.2.tgz

解压成功后，会在服务器当前目录生成一个harbor目录。

3.配置Harbor

注意：这里，我将Harbor的端口修改成了1180，如果不修改Harbor的端口，默认的端口是80。

（1）修改harbor.yml文件

修改的配置项如下所示。

hostname: 192.168.175.101
http:
  port: 1180
harbor_admin_password: binghe123
###并把https注释掉，不然在安装的时候会报错：ERROR:root:Error: The protocol is https but attribute ssl_cert is not set
#https:
  #port: 443
  #certificate: /your/certificate/path
  #private_key: /your/private/key/path

（2）修改daemon.json文件

修改/etc/docker/daemon.json文件，没有的话就创建，在/etc/docker/daemon.json文件中添加如下内容。

[root@binghe~]# cat /etc/docker/daemon.json
{
  "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.175.101:1180"]
}

也可以在服务器上使用 ip addr 命令查看本机所有的IP地址段，将其配置到/etc/docker/daemon.json文件中。这里，我配置后的文件内容如下所示。

{
    "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"],
    "insecure-registries":["192.168.175.0/16","172.17.0.0/16", "172.18.0.0/16", "172.16.29.0/16", "192.168.175.101:1180"]
}

4.安装并启动harbor

配置完成后，输入如下命令即可安装并启动Harbor

[root@binghe harbor]# ./install.sh

5.登录Harbor并添加账户

安装成功后，在浏览器地址栏输入http://192.168.175.101:1180打开链接，如下图所示。

输入用户名admin和密码binghe123，登录系统，如下图所示

接下来，我们选择用户管理，添加一个管理员账户，为后续打包Docker镜像和上传Docker镜像做准备。添加账户的步骤如下所示。

此处填写的密码为Binghe123。

点击确定后，如下所示。

此时，账户binghe还不是管理员，此时选中binghe账户，点击“设置为管理员”。

此时，binghe账户就被设置为管理员了。到此，Harbor的安装就完成了。

6.修改Harbor端口

如果安装Harbor后，大家需要修改Harbor的端口，可以按照如下步骤修改Harbor的端口，这里，我以将80端口修改为1180端口为例

（1）修改harbor.yml文件

修改的配置项如下所示。

hostname: 192.168.175.101
http:
  port: 1180
harbor_admin_password: binghe123
###并把https注释掉，不然在安装的时候会报错：ERROR:root:Error: The protocol is https but attribute ssl_cert is not set
#https:
  #port: 443
  #certificate: /your/certificate/path
  #private_key: /your/private/key/path

（2）修改docker-compose.yml文件

修改的配置项如下所示。

（3）修改config.yml文件

cd common/config/registry
vim config.yml

修改的配置项如下所示。

realm: http://192.168.175.101:1180/service/token

（4）重启Docker

systemctl daemon-reload
systemctl restart docker.service

（5）重启Harbor

[root@binghe harbor]# docker-compose down
Stopping harbor-log ... done
Removing nginx             ... done
Removing harbor-portal     ... done
Removing harbor-jobservice ... done
Removing harbor-core       ... done
Removing redis             ... done
Removing registry          ... done
Removing registryctl       ... done
Removing harbor-db         ... done
Removing harbor-log        ... done
Removing network harbor_harbor
 
[root@binghe harbor]# ./prepare
prepare base dir is set to /mnt/harbor
Clearing the configuration file: /config/log/logrotate.conf
Clearing the configuration file: /config/nginx/nginx.conf
Clearing the configuration file: /config/core/env
Clearing the configuration file: /config/core/app.conf
Clearing the configuration file: /config/registry/root.crt
Clearing the configuration file: /config/registry/config.yml
Clearing the configuration file: /config/registryctl/env
Clearing the configuration file: /config/registryctl/config.yml
Clearing the configuration file: /config/db/env
Clearing the configuration file: /config/jobservice/env
Clearing the configuration file: /config/jobservice/config.yml
Generated configuration file: /config/log/logrotate.conf
Generated configuration file: /config/nginx/nginx.conf
Generated configuration file: /config/core/env
Generated configuration file: /config/core/app.conf
Generated configuration file: /config/registry/config.yml
Generated configuration file: /config/registryctl/env
Generated configuration file: /config/db/env
Generated configuration file: /config/jobservice/env
Generated configuration file: /config/jobservice/config.yml
loaded secret from file: /secret/keys/secretkey
Generated configuration file: /compose_location/docker-compose.yml
Clean up the input dir
 
[root@binghe harbor]# docker-compose up -d
Creating network "harbor_harbor" with the default driver
Creating harbor-log ... done
Creating harbor-db   ... done
Creating redis       ... done
Creating registry    ... done
Creating registryctl ... done
Creating harbor-core ... done
Creating harbor-jobservice ... done
Creating harbor-portal     ... done
Creating nginx             ... done
 
[root@binghe harbor]# docker ps -a
CONTAINER ID        IMAGE                                               COMMAND                  CREATED             STATUS                             PORTS

安装Jenkins（一般的做法）

1.安装nfs（之前安装过的话，可以省略此步）

使用 nfs 最大的问题就是写权限，可以使用 kubernetes 的 securityContext/runAsUser 指定 jenkins 容器中运行 jenkins 的用户 uid，以此来指定 nfs 目录的权限，让 jenkins 容器可写；也可以不限制，让所有用户都可以写。这里为了简单，就让所有用户可写了。

如果之前已经安装过nfs，则这一步可以省略。找一台主机，安装 nfs，这里，我以在Master节点（binghe101服务器）上安装nfs为例。

在命令行输入如下命令安装并启动nfs。

yum install nfs-utils -y
systemctl start nfs-server
systemctl enable nfs-server

2.创建nfs共享目录

在Master节点（binghe101服务器）上创建 /opt/nfs/jenkins-data目录作为nfs的共享目录，如下所示。

mkdir -p /opt/nfs/jenkins-data

接下来，编辑/etc/exports文件，如下所示。

在/etc/exports文件文件中添加如下一行配置。

/opt/nfs/jenkins-data 192.168.175.0/24(rw,all_squash)

这里的 ip 使用 kubernetes node 节点的 ip 范围，后面的 all_squash 选项会将所有访问的用户都映射成 nfsnobody 用户，不管你是什么用户访问，最终都会压缩成 nfsnobody，所以只要将 /opt/nfs/jenkins-data 的属主改为 nfsnobody，那么无论什么用户来访问都具有写权限。

这个选项在很多机器上由于用户 uid 不规范导致启动进程的用户不同，但是同时要对一个共享目录具有写权限时很有效。

接下来，为 /opt/nfs/jenkins-data目录授权，并重新加载nfs，如下所示。

chown -R 1000 /opt/nfs/jenkins-data/
systemctl reload nfs-server

在K8S集群中任意一个节点上使用如下命令进行验证：

如果能够看到 /opt/nfs/jenkins-data 就表示 ok 了。

具体如下所示。

[root@binghe101 ~]# showmount -e 192.168.175.101
Export list for 192.168.175.101:
/opt/nfs/jenkins-data 192.168.175.0/24

[root@binghe102 ~]# showmount -e 192.168.175.101
Export list for 192.168.175.101:
/opt/nfs/jenkins-data 192.168.175.0/24

3.创建PV

Jenkins 其实只要加载对应的目录就可以读取之前的数据，但是由于 deployment 无法定义存储卷，因此我们只能使用 StatefulSet。

首先创建 pv，pv 是给 StatefulSet 使用的，每次 StatefulSet 启动都会通过 volumeClaimTemplates 这个模板去创建 pvc，因此必须得有 pv，才能供 pvc 绑定。

创建jenkins-pv.yaml文件，文件内容如下所示。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins
spec:
  nfs:
    path: /opt/nfs/jenkins-data
    server: 192.168.175.101
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 1Ti

我这里给了 1T存储空间，可以根据实际配置。

执行如下命令创建pv。

kubectl apply -f jenkins-pv.yaml

4.创建serviceAccount

创建service account，因为 jenkins 后面需要能够动态创建 slave，因此它必须具备一些权限。

创建jenkins-service-account.yaml文件，文件内容如下所示。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: jenkins
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: jenkins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: jenkins
subjects:
  - kind: ServiceAccount
    name: jenkins

上述配置中，创建了一个 RoleBinding 和一个 ServiceAccount，并且将 RoleBinding 的权限绑定到这个用户上。所以，jenkins 容器必须使用这个 ServiceAccount 运行才行，不然 RoleBinding 的权限它将不具备。

RoleBinding 的权限很容易就看懂了，因为 jenkins 需要创建和删除 slave，所以才需要上面这些权限。至于 secrets 权限，则是 https 证书。

执行如下命令创建serviceAccount。

kubectl apply -f jenkins-service-account.yaml

5.安装Jenkins

创建jenkins-statefulset.yaml文件，文件内容如下所示。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: jenkins
  labels:
    name: jenkins
spec:
  selector:
    matchLabels:
      name: jenkins
  serviceName: jenkins
  replicas: 1
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      name: jenkins
      labels:
        name: jenkins
    spec:
      terminationGracePeriodSeconds: 10
      serviceAccountName: jenkins
      containers:
        - name: jenkins
          image: docker.io/jenkins/jenkins:lts
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
            - containerPort: 32100
          resources:
            limits:
              cpu: 4
              memory: 4Gi
            requests:
              cpu: 4
              memory: 4Gi
          env:
            - name: LIMITS_MEMORY
              valueFrom:
                resourceFieldRef:
                  resource: limits.memory
                  divisor: 1Mi
            - name: JAVA_OPTS
              
              value: -Xmx$(LIMITS_MEMORY)m -XshowSettings:vm -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85
          volumeMounts:
            - name: jenkins-home
              mountPath: /var/jenkins_home
          livenessProbe:
            httpGet:
              path: /login
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 5
            failureThreshold: 12 
          readinessProbe:
            httpGet:
              path: /login
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 5
            failureThreshold: 12 
  
  volumeClaimTemplates:
    - metadata:
        name: jenkins-home
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Ti

jenkins 部署时需要注意它的副本数，你的副本数有多少就要有多少个 pv，同样，存储会有多倍消耗。这里我只使用了一个副本，因此前面也只创建了一个 pv。

使用如下命令安装Jenkins。

kubectl apply -f jenkins-statefulset.yaml

6.创建Service

创建jenkins-service.yaml文件，文件内容如下所示。

apiVersion: v1
kind: Service
metadata:
  name: jenkins
spec:
  
  selector:
    name: jenkins
  
  
  ports:
    - name: http
      port: 80
      nodePort: 31888
      targetPort: 8080
      protocol: TCP
    - name: jenkins-agent
      port: 32100
      nodePort: 32100
      targetPort: 32100
      protocol: TCP
  type: NodePort

使用如下命令安装Service。

kubectl apply -f jenkins-service.yaml

7.安装 ingress

jenkins 的 web 界面需要从集群外访问，这里我们选择的是使用 ingress。创建jenkins-ingress.yaml文件，文件内容如下所示。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins
spec:
  rules:
    - http:
        paths:
          - path: /
            backend:
              serviceName: jenkins
              servicePort: 31888
      host: jekins.binghe.com

这里，需要注意的是host必须配置为域名或者主机名，否则会报错，如下所示。

The Ingress "jenkins" is invalid: spec.rules[0].host: Invalid value: "192.168.175.101": must be a DNS name, not an IP address

使用如下命令安装ingress。

kubectl apply -f jenkins-ingress.yaml

最后，由于我这里使用的是虚拟机来搭建相关的环境，在本机访问虚拟机映射的jekins.binghe.com时，需要配置本机的hosts文件，在本机的hosts文件中加入如下配置项。

192.168.175.101 jekins.binghe.com

注意：在Windows操作系统中，hosts文件所在的目录如下。

C:\Windows\System32\drivers\etc

接下来，就可以在浏览器中通过链接：http://jekins.binghe.com:31888 来访问Jekins了。

物理机安装SVN

这里，以在Master节点（binghe101服务器）上安装SVN为例。

1.使用yum安装SVN

在命令行执行如下命令安装SVN。

yum -y install subversion

2.创建SVN库

依次执行如下命令。

#创建/data/svn
mkdir -p /data/svn 
#初始化svn
svnserve -d -r /data/svn
#创建代码仓库
svnadmin create /data/svn/test

3.配置SVN

mkdir /data/svn/conf
cp /data/svn/test/conf/* /data/svn/conf/
cd /data/svn/conf/
[root@binghe101 conf]# ll
总用量 20
-rw-r--r-- 1 root root 1080 5月  12 02:17 authz
-rw-r--r-- 1 root root  885 5月  12 02:17 hooks-env.tmpl
-rw-r--r-- 1 root root  309 5月  12 02:17 passwd
-rw-r--r-- 1 root root 4375 5月  12 02:17 svnserve.conf

配置authz文件，

配置后的内容如下所示。

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
SuperAdmin = admin
binghe = admin,binghe

# [/foo/bar]
# harry = rw
# &joe = r
# * =

# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

[test:/]
@SuperAdmin=rw
@binghe=rw

配置passwd文件

配置后的内容如下所示。

[users]
# harry = harryssecret
# sally = sallyssecret
admin = admin123
binghe = binghe123

配置 svnserve.conf

配置后的文件如下所示。

### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository.  (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)

### Visit http://subversion.apache.org/ for more information.

[general]
### The anon-access and auth-access options control access to the
### repository for unauthenticated (a.k.a. anonymous) users and
### authenticated users, respectively.
### Valid values are "write", "read", and "none".
### Setting the value to "none" prohibits both reading and writing;
### "read" allows read-only access, and "write" allows complete 
### read/write access to the repository.
### The sample settings below are the defaults and specify that anonymous
### users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
anon-access = none
auth-access = write
### The password-db option controls the location of the password
### database file.  Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
password-db = /data/svn/conf/passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control.  Unless you specify a path
### starting with a /, the file's location is relative to the
### directory containing this file.  The specified path may be a
### repository relative URL (^/) or an absolute file:// URL to a text
### file in a Subversion repository.  If you don't specify an authz-db,
### no path-based access control is done.
### Uncomment the line below to use the default authorization file.
authz-db = /data/svn/conf/authz
### The groups-db option controls the location of the file with the
### group definitions and allows maintaining groups separately from the
### authorization rules.  The groups-db file is of the same format as the
### authz-db file and should contain a single [groups] section with the
### group definitions.  If the option is enabled, the authz-db file cannot
### contain a [groups] section.  Unless you specify a path starting with
### a /, the file's location is relative to the directory containing this
### file.  The specified path may be a repository relative URL (^/) or an
### absolute file:// URL to a text file in a Subversion repository.
### This option is not being used by default.
# groups-db = groups
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa.  The default realm
### is repository's uuid.
realm = svn
### The force-username-case option causes svnserve to case-normalize
### usernames before comparing them against the authorization rules in the
### authz-db file configured above.  Valid values are "upper" (to upper-
### case the usernames), "lower" (to lowercase the usernames), and
### "none" (to compare usernames as-is without case conversion, which
### is the default behavior).
# force-username-case = none
### The hooks-env options specifies a path to the hook script environment 
### configuration file. This option overrides the per-repository default
### and can be used to configure the hook script environment for multiple 
### repositories in a single file, if an absolute path is specified.
### Unless you specify an absolute path, the file's location is relative
### to the directory containing this file.
# hooks-env = hooks-env

[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### Enabling this option requires svnserve to have been built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
# use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256

接下来，将/data/svn/conf目录下的svnserve.conf文件复制到/data/svn/test/conf/目录下。如下所示。

[root@binghe101 conf]# cp /data/svn/conf/svnserve.conf /data/svn/test/conf/
cp：是否覆盖'/data/svn/test/conf/svnserve.conf'？ y

4.启动SVN服务

（1）创建svnserve.service服务

创建svnserve.service文件

vim /usr/lib/systemd/system/svnserve.service

文件的内容如下所示。

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target
Documentation=man:svnserve(8)

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/svnserve
#ExecStart=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid $OPTIONS
ExecStart=/usr/bin/svnserve --daemon $OPTIONS
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

接下来执行如下命令使配置生效。

命令执行成功后，修改 /etc/sysconfig/svnserve 文件。

vim /etc/sysconfig/svnserve

修改后的文件内容如下所示。

# OPTIONS is used to pass command-line arguments to svnserve.
# 
# Specify the repository location in -r parameter:
OPTIONS="-r /data/svn"

（2）启动SVN

首先查看SVN状态，如下所示。

[root@itence10 conf]# systemctl status svnserve.service
● svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:svnserve(8)

可以看到，此时SVN并没有启动，接下来，需要启动SVN。

systemctl start svnserve.service

设置SVN服务开机自启动。

systemctl enable svnserve.service

接下来，就可以下载安装TortoiseSVN，输入链接svn://192.168.0.10/test 并输入用户名binghe，密码binghe123来连接SVN了。

物理机安装Jenkins

注意：安装Jenkins之前需要安装JDK和Maven，我这里同样将Jenkins安装在Master节点（binghe101服务器）。

1.启用Jenkins库

运行以下命令以下载repo文件并导入GPG密钥：

wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

2.安装Jenkins

执行如下命令安装Jenkis。

接下来，修改Jenkins默认端口，如下所示。

vim /etc/sysconfig/jenkins

修改后的两项配置如下所示。

JENKINS_JAVA_CMD="/usr/local/jdk1.8.0_212/bin/java"
JENKINS_PORT="18080"

此时，已经将Jenkins的端口由8080修改为18080

3.启动Jenkins

在命令行输入如下命令启动Jenkins。

配置Jenkins开机自启动。

查看Jenkins的运行状态。

[root@itence10 ~]# systemctl status jenkins
● jenkins.service - LSB: Jenkins Automation Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins; generated)
   Active: active (running) since Tue 2020-05-12 04:33:40 EDT; 28s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 71 (limit: 26213)
   Memory: 550.8M

说明，Jenkins启动成功。

配置Jenkins运行环境

1.登录Jenkins

首次安装后，需要配置Jenkins的运行环境。首先，在浏览器地址栏访问链接http://192.168.0.10:18080，打开Jenkins界面。

根据提示使用如下命令到服务器上找密码值，如下所示。

[root@binghe101 ~]# cat /var/lib/jenkins/secrets/initialAdminPassword
71af861c2ab948a1b6efc9f7dde90776

将密码71af861c2ab948a1b6efc9f7dde90776复制到文本框，点击继续。会跳转到自定义Jenkins页面，如下所示。

这里，可以直接选择“安装推荐的插件”。之后会跳转到一个安装插件的页面，如下所示。

此步骤可能有下载失败的情况，可直接忽略。

2.安装插件

需要安装的插件

Kubernetes Cli Plugin：该插件可直接在Jenkins中使用kubernetes命令行进行操作。
Kubernetes plugin：使用kubernetes则需要安装该插件
Kubernetes Continuous Deploy Plugin：kubernetes部署插件，可根据需要使用

还有更多的插件可供选择，可点击系统管理->管理插件进行管理和添加，安装相应的Docker插件、SSH插件、Maven插件。其他的插件可以根据需要进行安装。如下图所示。

3.配置Jenkins

（1）配置JDK和Maven

在Global Tool Configuration中配置JDK和Maven，如下所示，打开Global Tool Configuration界面。

接下来就开始配置JDK和Maven了。

由于我在服务器上将Maven安装在/usr/local/maven-3.6.3目录下，所以，需要在“Maven 配置”中进行配置，如下图所示。

接下来，配置JDK，如下所示。

注意：不要勾选“Install automatically”

接下来，配置Maven，如下所示。

注意：不要勾选“Install automatically”

（2）配置SSH

进入Jenkins的Configure System界面配置SSH，如下所示。

找到 SSH remote hosts 进行配置。

配置完成后，点击Check connection按钮，会显示 Successfull connection。如下所示。

至此，Jenkins的基本配置就完成了。

Jenkins发布Docker项目到K8s集群

1.调整SpringBoot项目的配置

实现，SpringBoot项目中启动类所在的模块的pom.xml需要引入打包成Docker镜像的配置，如下所示。

  <properties>
        <docker.repostory>192.168.0.10:1180</docker.repostory>
        <docker.registry.name>test</docker.registry.name>
        <docker.image.tag>1.0.0</docker.image.tag>
        <docker.maven.plugin.version>1.4.10</docker.maven.plugin.version>
  </properties>

<build>
        <finalName>test-starter</finalName>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            
            
            
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>dockerfile-maven-plugin</artifactId>
                <version>${docker.maven.plugin.version}</version>
                <executions>
                    <execution>
                    <id>default</id>
                    <goals>
                        
                        <goal>build</goal>
                        <goal>push</goal>
                    </goals>
                    </execution>
                </executions>
                <configuration>
                    <contextDirectory>${project.basedir}</contextDirectory>
                    
                    <useMavenSettingsForAuth>useMavenSettingsForAuth>true</useMavenSettingsForAuth>
                    <repository>${docker.repostory}/${docker.registry.name}/${project.artifactId}</repository>
                    <tag>${docker.image.tag}</tag>
                    <buildArgs>
                        <JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
                    </buildArgs>
                </configuration>
            </plugin>

        </plugins>
        
        <resources>
            
            <resource>
                <directory>src/main/resources</directory>
                <targetPath>${project.build.directory}/classes</targetPath>
                <includes>
                    <include>**/*</include>
                </includes>
                <filtering>true</filtering>
            </resource>
        </resources>
    </build>

接下来，在SpringBoot启动类所在模块的根目录创建Dockerfile，内容示例如下所示。

#添加依赖环境，前提是将Java8的Docker镜像从官方镜像仓库pull下来，然后上传到自己的Harbor私有仓库中
FROM 192.168.0.10:1180/library/java:8
#指定镜像制作作者
MAINTAINER binghe
#运行目录
VOLUME /tmp
#将本地的文件拷贝到容器
ADD target/*jar app.jar
#启动容器后自动执行的命令
ENTRYPOINT [ "java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/app.jar" ]

根据实际情况，自行修改。

注意：FROM 192.168.0.10:1180/library/java:8的前提是执行如下命令。

docker pull java:8
docker tag java:8 192.168.0.10:1180/library/java:8
docker login 192.168.0.10:1180
docker push 192.168.0.10:1180/library/java:8

在SpringBoot启动类所在模块的根目录创建yaml文件，录入叫做test.yaml文件，内容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-starter
  labels:
    app: test-starter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-starter
  template:
    metadata:
      labels:
        app: test-starter
    spec:
      containers:
      - name: test-starter
        image: 192.168.0.10:1180/test/test-starter:1.0.0
        ports:
        - containerPort: 8088
      nodeSelector:
        clustertype: node12

---
apiVersion: v1
kind: Service
metadata:
  name: test-starter
  labels:
    app: test-starter
spec:
  ports:
    - name: http
      port: 8088
      nodePort: 30001
  type: NodePort
  selector:
    app: test-starter

2.Jenkins配置发布项目

将项目上传到SVN代码库，例如地址为svn://192.168.0.10/test

接下来，在Jenkins中配置自动发布。步骤如下所示。

点击新建Item。

在描述文本框中输入描述信息，如下所示。

接下来，配置SVN信息。

注意：配置GitLab的步骤与SVN相同，不再赘述。

定位到Jenkins的“构建模块”，使用Execute Shell来构建发布项目到K8S集群。

执行的命令依次如下所示。

#删除本地原有的镜像,不会影响Harbor仓库中的镜像
docker rmi 192.168.0.10:1180/test/test-starter:1.0.0
#使用Maven编译、构建Docker镜像，执行完成后本地Docker容器中会重新构建镜像文件
/usr/local/maven-3.6.3/bin/mvn -f ./pom.xml clean install -Dmaven.test.skip=true
#登录 Harbor仓库
docker login 192.168.0.10:1180 -u binghe -p Binghe123
#上传镜像到Harbor仓库
docker push 192.168.0.10:1180/test/test-starter:1.0.0
#停止并删除K8S集群中运行的
/usr/bin/kubectl delete -f test.yaml
#将Docker镜像重新发布到K8S集群
/usr/bin/kubectl apply -f test.yaml

编辑整理冰河团队 From

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

DevOps系列---【Jenkinsfile+Dockerfile+nginx+vue】

2022-04-15T10:49:37.000Z

1.前提：一台装好的jenkins

参考:https://www.cnblogs.com/hujunwei/p/13176994.html

2.编写Dockerfile，放在项目根目录下

FROM nginx
#修改名字、版本、作者
LABEL name="home-finance-web-dev" version="1.0.0" author="hjw"
COPY dist/ /usr/share/nginx/html/
COPY nginx/nginx-dev.conf /etc/nginx/nginx.conf
EXPOSE 80

3.编写Jenkinsfile，放在项目根目录下

//流水线脚本
pipeline {
    agent any
    environment {
        WS = "${WORKSPACE}"
        TOPIC = "测试"
        TITLE = "标题"
        CONTENT = "具体内容"
    }

    //定义流水线的加工流程
    stages {
        stage('环境检查') {
            steps{
                sh 'printenv'
                echo "正在检测基本信息"
                sh 'git --version'
                sh 'docker version'
            }
        }

        stage('编译') {
            //jenkins不配置任何环境的情况下可以兼容任何场景
            agent {
                docker { image 'node:14.17.6-alpine3.13' }
            }
            steps{
                sh 'node -v'
                sh 'npm -v'
                sh 'pwd && ls -alh'
                sh 'echo "默认的项目目录:${WS}"'
                //注意:cd ${WS} && npm不能分开写，也不能直接用${WORKSPACE}
                sh 'cd ${WS}/fast-ui && npm config set registry=https://registry.npm.taobao.org && npm install -g cnpm --registry=https://registry.npm.taobao.org && cnpm install && cnpm run build'
            }
        }

        stage('生成镜像') {
            steps{
                sh 'pwd && ls -alh'
                echo '生成镜像'
                sh 'docker version'
                sh "echo 默认的项目目录:${WS}"
                sh 'cd ${WS}/fast-ui && docker build -t home-finance-web .'
            }
        }

        stage('部署') {
            steps{
                echo '部署....'
                sh 'pwd && ls -alh'
                sh 'pwd && ls -alh'
                sh 'docker rm -f home-finance-web'
                sh 'docker run -d -p 8081:80 --restart=always --name home-finance-web home-finance-web'
            }
        }
    }
}

4.编写nginx-dev.conf,放在项目根目录下的nginx目录下

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    # include /etc/nginx/conf.d/*.conf;

    server {
        listen       80;
        server_name  101.43.159.8; # 服务器地址或绑定域名

        #charset koi8-r;
        #access_log  /var/log/nginx/host.access.log  main;

        # =========================================================
        # ================== ↓↓↓↓↓↓ start ↓↓↓↓↓↓ ==================
        # =========================================================

        location / {
            root   /usr/share/nginx/html;
            #try_files $uri $uri/ @router;
            index  index.html index.htm;
            try_files $uri $uri/ /index.html; # 解决页面刷新 404 问题
            #proxy_pass http://zhengqingya.gitee.io; # 代理的ip地址和端口号
            #proxy_connect_timeout 600; #代理的连接超时时间（单位：毫秒）
            #proxy_read_timeout 600; #代理的读取资源超时时间（单位：毫秒）
        }

        # =========================================================
        # ================== ↑↑↑↑↑↑ end ↑↑↑↑↑↑ ==================
        # =========================================================

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }

    }
}

编辑整理 hujunwei

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

项目开发管理工具推荐

2022-04-15T10:48:59.000Z

软件开发是复杂的创造性的劳动，需要依赖大量工具才能完成，因此想要提高软件开发的效率和质量，离不开强大、高效、易用、维护成本低的工具，下面我根据自己的经验，推荐一些好用的工具。

即时通讯

更推荐自建开源替代。

即时通讯和会议系统是项目开发过程中必不可少的，尤其是远程办公时，会议系统更是不可或缺。企业微信拥有和微信一致的沟通体验，简单易用。企业微信可随时随地发起和参与音视频会议，支持300人同时参会，并为主持人提供了管理功能。发言时还可演示文档或电脑屏幕，支持实时标注演示内容。

官方网站：https://work.weixin.qq.com/

项目管理

目前主流的项目管理通常采用敏捷开发的模式，因此项目管理工具也要选择支持敏捷开发模式的工具，不建议使用禅道这样的重流程的工具，不适合敏捷团队，这里我推荐Taiga，它设计简洁，操作简单，充分体现了敏捷开发的理念。

官方网站：https://taiga.io

在线体验：https://tree.taiga.io

体验版服务器在国外，访问可能会有点慢。

代码托管

前几年使用的比较多是SVN，近几年基本都使用GIT了，开源项目大都使用Github，虽然免费，但国内访问不稳定，速度慢，因此国内的公司基本都会自己搭建，我先后为公司搭建过两个托管平台，一个是Gitlab，一个是Gitea，Gitlab功能比较全面，但对硬件资源要求比较高，而且性能一般。所以推荐使用另一个开源的git托管平台——Gitea。

官方网站：https://gitea.io

在线体验：https://gitea.com

持续交付

最知名、使用最广泛的开源的持续集成、交付平台当属Jenkins，主要的优势在于有大量免费的插件可以使用，但实际使用发现，很多插件质量很差，配置项很多，真正想要落地，其实需要自己编写shell脚本。这里我推荐基于docker技术的一款现代化的持续交付平台DroneCI，它使用简单，可以和主流的Git代码托管平台无缝对接，并且不需要编写代码就可以满足大多数持续构建、交付的需求。

官方网站：https://drone.io

在线体验：https://cloud.drone.io

体验版服务器在国外，访问可能会有点慢。

制品库(本地仓库)

Maven 仓库是项目中依赖的第三方库，这个库所在的位置叫做仓库。Maven 仓库能帮助我们管理构件（主要是JAR），它就是放置所有JAR文件（WAR，ZIP，POM等等）的地方。

后来，除了Maven仓库，还有npm、nuget、pypi、docker等仓库也需要本地仓库。

市面上可选的通用的本地仓库有：nexus、ARTIFACTORY，ARTIFACTORY是收费的，nexus是免费的，同时nexus以其易用性和可靠性，成为目前市场上最主流的本地仓库。

官方网站：https://www.sonatype.com/product-nexus-repository

文件存储

在公司中，文件分享是一个很常用的功能，不同于云盘，他对性能和安全性没有那么高的要求，简单易用才是大家最关心的，这里推荐chfs，chfs是一个免费的、HTTP协议的文件共享服务器，使用浏览器可以快速访问。与其他常用文件共享方式（如FTP，飞秋，网盘，自己建站）相比，具有使用简单，适用场景更多的优点，在个人使用以及共享给他人的场景中非常方便快捷。

官方网站：http://iscute.cn/chfs

绘图(流程图、UML、思维导图)

draw.io 是一个强大简洁的在线的绘图网站，支持流程图，UML图，架构图，原型图等。支持Github，Google Drive, One drive等网盘同步，并且永久免费。如果觉得使用Web版不方便，draw.io 也提供了多平台的离线桌面版可供下载。

在线版：https://www.draw.io

本地部署版：https://github.com/jgraph/drawio/releases/latest

PC 安装版：https://github.com/jgraph/drawio-desktop/releases/latest

接口管理

维护不同工具之间数据一致性非常困难、低效。并且这里不仅仅是工作量的问题，更大的问题是多个系统之间数据不一致，导致协作低效、频繁出问题，开发测试人员痛苦不堪。

Apifox 是接口管理、开发、测试全流程集成工具，定位 Postman + Swagger + Mock + JMeter。通过一套系统、一份数据，解决多个系统之间的数据同步问题。只要定义好接口文档，接口调试、数据 Mock、接口测试就可以直接使用，无需再次定义；接口文档和接口开发调试使用同一个工具，接口调试完成后即可保证和接口文档定义完全一致。高效、及时、准确！

官方网站：https://www.apifox.cn

安全测试

在今天，网站的安全是容易被忽视的，黑客具备广泛的攻击手段，例如SQL注入，XSS，文件包含，目录遍历，参数篡改，认证攻击等，虽然你配置了正确的防火墙和WAF，但是这些安全防御软件仍然存在策略性的绕过。因此，需要您定期的扫描你的web应用，但是手动检测你所有的web应用是否存在安全漏洞比较复杂和费时，所以您需要一款自动化的web漏洞扫描工具来检测您的web应用是否存在安全漏洞。

Acunetix Web Vulnerability Scanner（简称AWVS）是一款知名的Web网络漏洞扫描工具，它通过网络爬虫测试你的网站安全，检测流行安全漏洞。

官方网站：https://www.acunetix.com

性能测试

Locust是一个用于可扩展的，分布式的，性能测试的，开源的，用Python编写框架/工具，它非常容易使用，也非常好学。

它的主要思想就是模拟一群用户将访问你的网站。每个用户的行为由你编写的python代码定义，同时可以从Web界面中实时观察到用户的行为。

Locust完全是事件驱动的，因此在单台机器上能够支持几千并发用户访问。

与其它许多基于事件的应用相比，Locust并不使用回调，而是使用gevent，而gevent是基于协程的，可以用同步的方式来编写异步执行的代码。

官方网站：https://www.locust.io

代码静态分析平台

SonarQube 是一款用于代码质量管理的开源工具，它主要用于管理源代码的质量。通过插件形式，可以支持众多计算机语言，比如 java, C#, go，C/C++, PL/SQL, Cobol, JavaScrip, Groovy 等。sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具来检测你的代码，帮助你发现代码的漏洞，Bug，异味等信息。

Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar

官方网站：https://www.sonarqube.org

系列教程

全部文章RSS订阅

Devops系列

Devops 分类 RSS 订阅

Gitlab的安装及使用教程完全版

2021-08-02T08:25:00.000Z

1. Gitlab概述

1.1 GitLab介绍

GitLab是利用Ruby on Rails一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。

GitLab能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。

它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找

1.2 Gitlab服务构成

Nginx：静态web服务器。

gitlab-shell：用于处理Git命令和修改authorized keys列表。

gitlab-workhorse: 轻量级的反向代理服务器。

logrotate：日志文件管理工具。

postgresql：数据库。

redis：缓存数据库。

sidekiq：用于在后台执行队列任务（异步执行）。

unicorn：An HTTP server for Rack applications，GitLab Rails应用是托管在这个服务器上面的。

1.3 Gitlab工作流程

1.4 GitLab Shell

GitLab Shell有两个作用：为GitLab处理Git命令、修改authorized keys列表

当通过SSH访问GitLab Server时，GitLab Shell会：

限制执行预定义好的Git命令（git push，git pull，git annex）
调用GitLab Rails API检查权限
执行pre-receive钩子（在企业版中叫做Git钩子）
执行用户请求的动作，处理GitLab的post-receive动作
处理自定义的post-receive动作

当通过http(s)访问GitLab Server时，工作流程取决于你是从Git仓库拉取(pull)代码还是向git仓库推送(push)代码：

如果是从Git仓库拉取(pull)代码，GitLab Rails应用会全权负责处理用户鉴权和执行Git命令的工作

如果是向Git仓库推送(push)代码，GitLab Rails应用既不会进行用户鉴权也不会执行Git命令，它会把以下工作交由GitLab Shell进行处理：

调用GitLab Rails API 检查权限
执行pre-receive钩子（在GitLab企业版中叫做Git钩子）
执行你请求的动作
处理GitLab的post-receive动作
处理自定义的post-receive动作

1.5 GitLab Workhorse

GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求，比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用，即反向代理给后端的unicorn。

2. Gitlab的安装部署

Gitlab要求服务器内存2G以上

2.1 方式一:下载gitlab-ce的rpm包

将对应版本的gitlab-ce下载到本地后，直接yum安装即可

# 要先将这个rpm包下载到本地
yum install -y gitlab-ce-13.6.1-ce.0.el7.x86_64.rpm

2.2 方式二:配置yum源

在 /etc/yum.repos.d/ 下新建 gitlab-ce.repo，写入如下内容：

[gitlab-ce]
name=gitlab-ce
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
Repo_gpgcheck=0
Enabled=1
Gpgkey=https://packages.gitlab.com/gpg.key

然后创建cache，再直接安装gitlab-ce

yum makecache  # 这一步会创建大量的数据
 
# 直接安装最新版
yum install -y gitlab-ce
 
# 如果要安装指定的版本，在后面填上版本号即可
yum install -y  gitlab-ce-13.6.1
 
# 如果安装时出现gpgkey验证错误，只需在安装时明确指明不进行gpgkey验证
yum install gitlab-ce -y --nogpgcheck

2.2.1. 单服务启动模式

docker run -d --name gitlab --hostname gitlab.example.com \
-e GITLAB_OMNIBUS_CONFIG="
    external_url 'https://gitlab.example.com'
    gitlab_rails['gitlab_shell_ssh_port'] = 22
    nginx['redirect_http_to_https'] = true
    nginx['ssl_dhparam'] = '/etc/gitlab/ssl/dhparam.pem'
    nginx['ssl_certificate'] = '/etc/gitlab/ssl/domain.crt'
    nginx['ssl_certificate_key'] = '/etc/gitlab/ssl/domain.key'
    nginx['custom_gitlab_server_config'] = 'location ^~ /.well-known {\n alias /var/opt/gitlab/letsencrypt/.well-known;\n}\n'
    high_availability['mountpoint'] = ['/etc/gitlab', '/var/log/gitlab' '/var/opt/gitlab'  # 严格限定gitlab服务启动前，指定文件系统挂完毕
" \
-p 22:22 -p 80:80 -p 443:443 \
-v /srv/gitlab/config:/etc/gitlab \
-v /srv/gitlab/logs:/var/log/gitlab \
-v /srv/gitlab/data:/var/opt/gitlab \
-v /etc/certs:/etc/gitlab/ssl \
--restart=always gitlab/gitlab-ce:latest

2.2.1. Compose服务编排模式(推荐方式)

docker pull gitlab/gitlab-ce:latest
 
############################ 多行命令开始 ##########################
cat > docker-compose.yaml <<EOF
version: '2'
 
services:
 
  Gitlab:
    image: 'gitlab/gitlab-ce:latest'
    container_name: 'gitlab'
    hostname: 'gitlab.example.com'
    restart: always
    ports:
      - '22:22'
      - '80:80'
      - '443:443'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        external_url 'https://gitlab.example.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 22
        nginx['redirect_http_to_https'] = true
        nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparam.pem"
        nginx['ssl_certificate'] = "/etc/gitlab/ssl/domain.crt"
        nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/domain.key"
        nginx['custom_gitlab_server_config'] = "location ^~ /.well-known {\n alias /var/opt/gitlab/letsencrypt/.well-known;\n}\n"
        high_availability['mountpoint'] = ["/etc/gitlab", "/var/log/gitlab", "/var/opt/gitlab"]  # 严格限定gitlab服务启动前，指定文件系统挂完毕
    volumes:
      - /srv/gitlab/config:/etc/gitlab
      - /srv/gitlab/logs:/var/log/gitlab
      - /srv/gitlab/data:/var/opt/gitlab
      - /etc/certs:/etc/gitlab/ssl
EOF
############################ 多行命令结束 ##########################
 
# 启动服务
docker-compose -f docker-compose.yaml up -d

2.3 gitlab的配置

配置文件位置 /etc/gitlab/gitlab.rb

[root@centos7 test]# vim /etc/gitlab/gitlab.rb
 
[root@centos7 test]# grep "^[a-Z]" /etc/gitlab/gitlab.rb
 
external_url 'http://10.0.0.51'  # 这里一定要加上http://
 
# 配置邮件服务
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.qq.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = "hgzerowzh@qq.com"  # 自己的qq邮箱账号
gitlab_rails['smtp_password'] = "xxx"  # 开通smtp时返回的授权码
gitlab_rails['smtp_domain'] = "qq.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['gitlab_email_from'] = "hgzerowzh@qq.com"  # 指定发送邮件的邮箱地址
user["git_user_email"] = "shit@qq.com"   # 指定接收邮件的邮箱地址

修改好配置文件后，要使用 gitlab-ctl reconfigure 命令重载一下配置文件，否则不生效。

gitlab-ctl reconfigure # 重载配置文件
gitlab-ctl restart

测试邮件服务器

gitlab-rails console
Notify.test_email('rollinghell@foxmail.com','testbiaoti','testzhegnwen1').deliver_now

[root@test102 ~]# gitlab-rails console
--------------------------------------------------------------------------------
 GitLab:       12.5.0 (1f0ab8978ef)
GitLab Shell: 10.2.0
 PostgreSQL:   10.9
--------------------------------------------------------------------------------
Loading production environment (Rails 5.2.3)
irb(main):001:0> Notify.test_email('andycrusoe@gmail.com','test','test').deliver_now
Notify#test_email: processed outbound mail in 1.4ms
Sent mail to anliven@126.com (73.0ms)
Date: Wed, 27 Nov 2019 15:12:58 +0800
From: GitLab <gitlab@192.168.16.102>
Reply-To: GitLab <noreply@192.168.16.102>
To: anliven@126.com
Message-ID: <5dde21fa612d4_3a1b3fcb38fcf9c0651b@test102.mail>
Subject: test
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
X-Auto-Response-Suppress: All
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><p>test</p></body></html>
=> #<Mail::Message:70141649239780, Multipart: false, Headers: <Date: Wed, 27 Nov 2019 15:12:58 +0800>, <From: GitLab <gitlab@192.168.16.102>>, <Reply-To: GitLab <noreply@192.168.16.102>>, <To: anliven@126.com>, <Message-ID: <5dde21fa612d4_3a1b3fcb38fcf9c0651b@test102.mail>>, <Subject: test>, <Mime-Version: 1.0>, <Content-Type: text/html; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>, <Auto-Submitted: auto-generated>, <X-Auto-Response-Suppress: All>>
irb(main):002:0>
irb(main):003:0> exit
[root@test102 ~]#

配置gitlab代理

Setting custom environment variables | GitLab

Log system | GitLab

gitaly['env'] = {
    "http_proxy" => "http://USERNAME:PASSWORD@example.com:8080",
    "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
}

也可以使用单独模块代理

# Needed for proxying Git clones
gitaly['env'] = {
    "http_proxy" => "http://USERNAME:PASSWORD@example.com:8080",
    "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
}

gitlab_workhorse['env'] = {
    "http_proxy" => "http://USERNAME:PASSWORD@example.com:8080",
    "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
}

gitlab_pages['env'] = {
    "http_proxy" => "http://USERNAME:PASSWORD@example.com:8080",
    "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
}

# If you use the docker registry
registry['env'] = {
    "http_proxy" => "http://USERNAME:PASSWORD@example.com:8080",
    "https_proxy" => "http://USERNAME:PASSWORD@example.com:8080"
}

应用生效 gitlab-ctl reconfigure

2.4 Gitlab常用命令

gitlab-ctl start         # 启动所有 gitlab 组件
gitlab-ctl stop          # 停止所有 gitlab 组件
gitlab-ctl restart       # 重启所有 gitlab 组件
gitlab-ctl status        # 查看服务状态
 
gitlab-ctl reconfigure   # 启动服务
gitlab-ctl show-config   # 验证配置文件
 
gitlab-ctl tail          # 查看日志
 
gitlab-rake gitlab:check SANITIZE=true --trace    # 检查gitlab
 
vim /etc/gitlab/gitlab.rb # 修改默认的配置文件

2.5 gitlab-ctl常用命令介绍

命令	说明
check-config	检查在gitlab中是否有任何配置。在指定版本中删除的rb
deploy-page	安装部署页面
diff-config	将用户配置与包可用配置进行比较
remove-accounts	删除所有用户和组
upgrade	升级
service-list	查看所有服务
once	如果GitLab服务停止了就启动服务，如果已启动就不做任何操作
restart	重启GitLab服务
start	如果GitLab服务停止了就启动服务，如果已启动就重启服务
stop	停止GitLab服务
status	查看GitLab服务状态
reconfigure	重新配置GitLab并启动

3. Gitlab的使用

Gitlab安装好后，设置密码，管理账户为root

3.1 创建Group

填上组名即可，这里组名为java

3.2 创建User

创建四个User：pm、dev1、dev2、dev3

3.3 添加User到Group中并授权

3.4 创建Project并配置SSH

3.5 在项目中添加成员

3.6 将本地文件推送到Gitlab

# 将app01项目克隆下来
git clone git@10.0.0.51:java/app01.git
 
# 初始化配置
git config --global user.name "hgzero"
git config --global user.email "hgzero@qq.com"
 
# 在app01目录下新建一些文件
 
# 推送到gitlab
git add .
git commit -m "first edition"
git push origin master

4. 制定开发计划

4.1 创建开发计划

项目：app01
版本：v1.0

4.2 创建里程碑Milestones

用pm账号登录gitlab后操作（先要在admin中设置pm账号的密码）
要根据开发计划来创建Milestones

4.3 根据开发计划创建issue

创建4个issue，分派给dev1和dev2这两个开发人员

4.4 开发者登录账号查看分派的任务

然后开发dev1登录gitlab，就能看到任务已经分配过来了

4.5 开发流程

公司里的开发开始任务

# 1. 先从仓库把项目拉下来
git clone git@10.0.0.51:java/app01.git
cd app01/
 
# 2.先创建一个自己的分支，然后进行开发
git checkout -b index   # 创建一个叫index的分支，并切换到这个分支
git status
 
# 3. 开始开发首页
echo "<h1>welcome to this app</h1>" > index.html  # 假设就开发了一个index页面
 
# 4. 开发完成后，把项目传到仓库
git add .
git commit -m "index"
# 如果写成 git commit -m "close #2" ，则表示merge请求允许且merge成功之后，自动删除编号为#2的issue
 
# 传到index分支
git push origin index

4.6 合并分支

1）开发dev1发送合并分支请求给pm

2）pm收到开发的Merge请求后进行处理

使用pm登录，就可以看到pm已经收到了合并请求merge request

3）开发dev1确认任务完成

退出pm账户，登入dev1账户：

或者点进去后，在侧边栏进行标识Done，然后已经完成的issue，可以将其Close

这个时候Milestones的进度已经往前进了一些了：

4.7 开发其他功能

然后其他开发者或者自己再次进行开发时，先要把刚刚更新后的内容（master主干）拉回来，然后再进行开发

git checkout master # 切换到master
git pull # 从远端仓库拉取数据
# 然后再进行其他操作

5. Gitlab备份恢复

5.1 备份gitlab

1）修改配置文件

/etc/gitlab/gitlab.rb

# 备份保存的位置，这里是默认位置，可修改成指定的位置
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
 
# 设置备份保存的时间，超过此时间的日志将会被新覆盖
gitlab_rails['backup_keep_time'] = 604800  # 这里是默认设置，保存7天
 
# 特别注意：
#     如果自定义了备份保存位置，则要修改备份目录的权限，比如：
#     chown -R git.git /data/backup/gitlab

配置完成后要重启以使配置生效

# 重读配置文件
gitlab-ctl reconfigure
 
# 重启gitlab
gitlab-ctl restart

2）设置定时任务

# 每天凌晨2点定时创建备份
# 将一下内容写入到定时任务中 crontab -e
0 2 * * * /usr/bin/gitlab-rake gitlab:backup:create
 
# 备份策略建议：
#     本地保留3到7天，在异地备份永久保存

3）备份时间的识别

# 备份后的文件类似这样的形式：1494170842_gitlab_backup.tar，可以根据前面的时间戳确认备份生成的时间
 
data  -d  @1494170842

5.2 恢复gitlab

1）停止停止相关数据连接,数据写入服务

# 停止数据写入服务
gitlab-ctl stop puma
gitlab-ctl stop sidekiq

2）进行数据恢复并重启

# 进行恢复
gitlab-rake gitlab:backup:restore BACKUP=1627839447_2021_08_01_14.1.1-ee  # 这个时间戳就是刚刚备份的文件前面的时间戳
 
# 重启
gitlab-ctl restart

6. gitlab邮件通知配置

vim /etc/gitlab/gitlab.rb

gitlab_rails['time_zone'] = 'Asia/Shanghai'
 
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = 'example@163.com' # 填写发件人的邮箱地址
gitlab_rails['gitlab_email_display_name'] = 'gitlab'
 
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.163.com"  # smtp服务器的地址,如网易的地址
gitlab_rails['smtp_port'] = 25                 # 要注意如果使用了SSL/TLS的话,端口可能不是25
gitlab_rails['smtp_user_name'] = "smtp用户名"
gitlab_rails['smtp_password'] = "smtp用户密码"
gitlab_rails['smtp_domain'] = "163.com"
gitlab_rails['smtp_authentication'] = "login"

启用邮件功能
Gitlab 的 Compose 配置 GITLAB_OMNIBUS_CONFIG 节点下增加如下几行：

########## 邮件服务配置 ##########
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.exmail.qq.com"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_tls'] = true
gitlab_rails['smtp_user_name'] = "账号"
gitlab_rails['smtp_password'] = "密码"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true 
gitlab_rails['gitlab_email_from'] = "发件人邮箱"

7. 使用SourceTree进行项目开发

7.1 项目拉取

先把项目克隆下来

如果ssh的方式克隆失败，可能是因为SSH Key没找到，可以在这里添加

7.2 创建分支进行功能开发

1）新建立一个叫“pay”的分支

2）进行功能开发

7.3 提交项目

1）开发pay功能完成后进行提交

可以看到SourceTree中已经有“未提交的更改”

2）添加“用户信息”

** 3）进行提交**

注释也可以写成 close #3 ，作用是提交完成后关闭3号issue

7.4 推送到仓库

然后就可以在gitlab上进行发送merge请求了，后面就可以进行其他操作了

7.5 项目上线

1）当所有工作完成之后，就可以进行上线了

2）打标签

上线先打个标签

** 3）删除无用分支**

然后删除已经合并到主干中的不必要的分支，如index、pay等
最后一定要注意时间一定要同步，不然会错乱

8. Gitlab调优

gitlab对内存资源的消耗比较厉害其中尤以 sidekiq队列及 unicorn服务两个组件对内存消耗最多可以再容器启动时对相关参数进行微调：

unicorn['worker_processes'] = 1
unicorn['worker_memory_limit_min'] = "300 * 1 << 20"
unicorn['worker_memory_limit_max'] = "400 * 1 << 20"
unicorn['worker_timeout'] = 15
sidekiq['concurrency'] = 10
sidekiq_cluster['enable'] = false
sidekiq_cluster['ha'] = false
redis['maxclients'] = "100"
nginx['worker_processes'] = 2
nginx['worker_connections'] = 512
nginx['keepalive_timeout'] = 300
nginx['cache_max_size'] = '200m'
mattermost['enable'] = false
mattermost_nginx['enable'] = false
gitlab_pages['enable'] = false
pages_nginx['enable'] = false
postgresql['shared_buffers'] = "256MB"
postgresql['max_connections'] = 30
postgresql['work_mem'] = "8MB"
postgresql['maintenance_work_mem'] = "16MB"
postgresql['effective_cache_size'] = "1MB"
postgresql['checkpoint_timeout'] = "5min"
postgresql['checkpoint_warning'] = "30s"

配置调整后需要重载一下

docker exec gitlab gitlab-ctl reconfigure
docker-compose down
docker-compose up -d

9. Gitlab 启用 ContainerRegistry

ContainerRegistry是Gitlab内置的Docker Registry集成组件
集成后每个项目可获得私有的 Docker 镜像存储空间
ContainerRegistry 可以复用 Gitlab 域名或者独立域名
这里配置为复用域名（此时ContainerRegistry 将复用 Gitlab 的 TLS 证书）

docker-compose.yaml中Gitlab服务的 GITLAB_OMNIBUS_CONFIG 节点下增加如下配置：

registry_external_url "https://gitlab.example.com:4567"  # ContainerRegistry的外部访问地址
registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/domain.crt"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/domain.key"
gitlab_rails['registry_host'] = "gitlab.example.com"
gitlab_rails['registry_port'] = "4567"
gitlab_rails['registry_api_url'] = "http://localhost:5000"
gitlab_rails['gitlab_default_projects_features_builds'] = false
gitlab_rails['gitlab_default_projects_features_container_registry'] = false

端口开放增加 - 4567:4567
服务重启 docker-compose restart Gitlab

ContainerRegistry 集成后可以通过 Gitlab 账户登录： docker login gitlab.example.com:4567

日常维护命令

# Gitlab维护
docker exec gitlab gitlab-ctl status  # gitlab各组件服务状态
docker exec gitlab gitlab-ctl start/restart/stop [组件名]  # gitlab所有组件的统一控制（其中Unicorn组件重启完成前GitLab会报502）
docker exec gitlab gitlab-ctl tail [/var/log/gitlab下的某子目录]  # 实时查看日志
 
docker exec gitlab update-permissions  # 修复gitlab版本升级后出现的权限问题
docker exec gitlab gitlab-ctl reconfigure  # 重载配置
docker exec -t gitlab gitlab-rake gitlab:backup:create  # 创建备份
 
# ContainerRegistry维护
docker exec gitlab gitlab-ctl registry-garbage-collect  # 垃圾回收，清理废弃layer（registry停机）

Import Repository(Repo By Url)

# 账号密码若存在特殊字符则需要url编码
https://username:password@host:port/group/project.git

10. GitLab重置用户名密码

打开终端，访问：

gitlab-rails console

输入：

user = User.where(id: 1).first
user.password='123456'
user.password_confirmation = '123456'
user.save! #注意加上 “！”

然后退出命令行即可。

quit

 gitlab-rails console production 命令 开始初始化密码
# 在irb(main):001:0> 后面通过 u=User.where(id:1).first 来查找与切换账号（User.all 可以查看所有用户）
# 通过u.password='12345678'设置密码为12345678(这里的密码看自己喜欢)：
# 通过u.password_confirmation='12345678' 再次确认密码
# 通过 u.save!进行保存

11. HTTPS SSL 支持

nginx反向代理方式
- 注意docker 内部没有ca支持，需要手动添加
域名提供商提供的免费证书
- 这种证书直接用，如果是自签名证书，需要添加自己的ca root证书到服务器

12. Gitlab恢复数据出现must be owner of解决方法

按正常Gitlab备份数据gitlab-rake gitlab:backup:create

ERROR: must be owner of extension plpgsql
ERROR: must be owner of schema public
ERROR: schema “public” already exists
ERROR: must be owner of schema public
ERROR: must be owner of extension plpgsql
WARNING: no privileges could be revoked for “public”
WARNING: no privileges could be revoked for “public”
WARNING: no privileges were granted for “public”
WARNING: no privileges were granted for “public”

解决方法：

1. 修改postgresql配置

cd /var/opt/gitlab/postgresql/data
$ vi /var/opt/gitlab/postgresql/data/postgresql.conf
listen_addresses = '*'

找到listen_addresses = ” 改为listen_addresses = ‘*’

修改 /var/opt/gitlab/postgresql/data/pg_hba.conf
在这个文件最后面加入

$ vi /var/opt/gitlab/postgresql/data/pg_hba.conf
local   all         all                               trust
host    all         all                               127.0.0.1/32 trust
host    all         all                               ::1/128 trust    #ipv6 可以不配置

2. 重启gitlab生效

gitlab-ctl restart

3. 修改gitlab账号为超级用户

进入postgresql命令行

cd /opt/gitlab/embedded/bin
su gitlab-psql
./psql -h 127.0.0.1 gitlabhq_production

查看账户权限

\du

执行修改gitlab用户为超级权限

ALTER USER gitlab WITH SUPERUSER;

退出

\q

4. 从1462989681编号备份中恢复

gitlab-rake gitlab:backup:restore BACKUP=1462989681

这样Gitlab恢复数据就不会再报must be owner of extension plpgsql错误。

4. 重启gitlab

gitlab-ctl restart

13. Gitlab Pages

官方文档：https://docs.gitlab.com/ee/user/project/pages/ 。

Gitlab Pages 使用 GitLab Pages daemon 服务，它是用 GO 语言实现的简单 HTTP 服务，并且可以监听外部 IP 地址以及为自定义域名和自定义证书提供支持。它通过 SNI 支持动态证书并且默认通过 HTTP2 协议发送页面。最后推荐你去看官方文档 README 以便全面了解它的工作原理。

启用 Pages

打开 gitlab.rb：

sudo vim /etc/gitlab/gitlab.rb

修改 Pages 配置：

# Pages 服务地址
pages_external_url "http://git.17lai.io"
# 启用 pages
gitlab_pages['enable'] = true
# fails to start in Docker
gitlab_pages['inplace_chroot'] = true

让 Gitlab 使用当前配置：

sudo gitlab-ctl reconfigure

# stdout
> gitlab Reconfigured!

如果没有域名怎么办呢？可以参考 Linux智能DNS服务搭建之Bind服务。

使用 Pages

官方的案例库：https://gitlab.com/pages

用户文档

一般有两种类型的Pages可以创建

对于用户（username.example.io）或组（groupname.example.io）
对于Project（username.example.io/projectname 或 groupname.example.io/projectname ）

在GitLab中，usernames或groupnames是唯一的，我们经常把他们称为namespaces。在一个GitLab实例中只能有一个namespace。

下面是Gitlab Pages类型、Project Name和 website URL对照表：

GitLab Pages前提条件：

简而言之，这是上传web站点到GitLab Pages需要的：

Gitlab Pages使用的域名（向管理员询问）。
创建一个Project。
仓库的根目录放一个.gitlab-ci.yml，其中有个叫做pages的job。
设置一个GitLab Runner构建web站点。

部署简单的 html 项目

我们在自己的 gitlab 上面创建一个测试项目：plain-html
把项目拉取到本地：

# 换成你自己的仓库地址
git clone git@git.17lai.io:pages/plain-html.git

在项目中新建 public 目录，然后添加 index.html 、 style.css 文件:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="generator" content="GitLab Pages">
    <title>Plain HTML site using GitLab Pages</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <div class="navbar">
      <a href="https://pages.gitlab.io/plain-html/">Plain HTML Example</a>
      <a href="https://gitlab.com/pages/plain-html/">Repository</a>
      <a href="https://gitlab.com/pages/">Other Examples</a>
    </div>

    <h1>Hello World!</h1>

    <p>
      This is a simple plain-HTML website on GitLab Pages, without any fancy static site generator.
    </p>
  </body>
</html>

body {
  font-family: sans-serif;
  margin: auto;
  max-width: 1280px;
}

.navbar {
  background-color: #313236;
  border-radius: 2px;
  max-width: 800px;
}

.navbar a {
  color: #aaa;
  display: inline-block;
  font-size: 15px;
  padding: 10px;
  text-decoration: none;
}

.navbar a:hover {
  color: #ffffff;
}

在项目根目录添加 .gitlab-ci.yml 文件：

# This file is a template, and might need editing before it works on your project.
# Full project: https://gitlab.com/pages/plain-html
pages:
  tags:
    - html
  stage: deploy
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  only:
    - master

提交代码：

git add .
git commit -m"feat(pages):  开启 pages 服务"
git push

最后我们回到 gitlab 服务，在 plain-html 仓库中的 Settings / pages 页面可以看到已经有对应的服务地址了：

gitlab 服务的域名跟 pages 的不要使用同一个，防止 XSS 攻击。

管理员文档：https://docs.gitlab.com/ce/administration/pages/
用户文档：https://docs.gitlab.com/ce/user/project/pages/index.html
gitlab pages：https://pages.gitlab.io/

Container Registry

官方文档：https://docs.gitlab.com/ee/user/packages/container_registry/

本节修改中

开启 Container Registry

修改gitlab配置文件： vim /etc/gitlab/gitlab.rb

//外部访问地址，此处被nginx代理，暴露给外部访问
registry_external_url 'http://xxx.com'
//启用
gitlab_rails['registry_enabled'] = true
//registry 服务ip
gitlab_rails['registry_host'] = "172.29.1.70"
//registry 服务真正端口
gitlab_rails['registry_port'] = "5000"

这里需要注意的是，registry_external_url是外部访问的url，如docker需要pull和push，都是访问该路径。然后，刷新配置，重启：

gitlab-ctl reconfigure
gitlab-ctl restart

访问Docker

# docker login https://xxx.com -u root -p xxx
Login Succeeded

默认需要SSL，请使用反向代理

官方文档有说明，如果启用了双重验证（Two-Factor Authentication）则不应该输入密码，而是token：

docker login xxx.com -u <username> -p <token>

CI

GitLab Continuous Integration (GitLab CI/CD)

CI: Continuous Integration：持续集成。

CD: Coninuous delivery and deployment：持续交付和部署。

Gitlab CI/CD 是以可持续方法论进行软件开发的内建工具（continuous integration service ）。

在使用 Gitlab CI 之前，我们需要先了解几个概念：

Stage

阶段：通俗的讲就是步骤（把一件事分解成多个步骤来完成）。从最上面的图中可以看到在 CI 中可能会有：Build、Unit Test 、Integration Tests 等多个阶段。

Job

任务：就是我们在每个阶段具体要做的事情，而一个阶段可能会有多个任务。

Pipelines

一条流水线（ pipeline）就是一组在各个阶段执行的任务。在同一阶段的多个任务是可以并行的（如果 Runner 足够多的话），当全部的任务都执行成功之后流水线将会进入下一个阶段。反之，如果其中有一个任务失败，流水线的下一个阶段将不再执行。

Runners

在 Gitlab CI 中，Runner 负责运行定义在 .gitlab-ci.yml 中的代码。Runner 为三种：Shared Runners、Group Runners、Specific Runners，分别表示全局共用 Runner、组共用 Runner、单个项目指定的 Runner。

.gitlab-ci.yml

Gitlab CI 的配置文件，该文件声明了流水线的结构和顺序，以任务为最小单元。

文件中允许定义的元素：

image：docker 镜像，当 Gitlab-Runner 的类型为 docker 时，会根据该属性指定的镜像为脚本执行容器。
services: 指定另一个 docker 镜像，主要用于提供服务层的能力，比如 mysql 。
before_script：任务执行前的钩子事件，比如一个 node 项目，我们可以在这里安装依赖。
after_script：任务执行后的钩子事件，当所有的任务都执行完毕之后被调用，不管任务是否执行成功。
stages：定义流水线中的阶段，默认的为 build 、test、deploy。如果我们要在任务中指定其他的 stage，则需要使用该属性先申明。
cache：需要缓存的文件，比如 node 项目可以把 node_modules 缓存起来。提示：可以定义在 .gitlab-ci.yml 顶级表示项目级别的，也可以申明在单个任务中。
variables：变量，同样可以在顶级或者单个任务中申明。
pages：内置的一个任务，用于上传任务执行的结果到 Gitlab Pages。
include：合并其他的 .gitlab-ci.yml 文件配置。
在单个任务中申明的元素：
1. script：需要执行的脚本。
2. stage：标识该任务所属的阶段。
3. tags：为任务打上标签，用于选择特定的 Runner。
4. only：用于表明何时创建该任务。
5. except：用于表明何时不创建该任务。
6. when：用于表明何时运行该任务。
7. allow_failure：允许失败，该任务失败时不会影响整个流水线的结果。
8. artifacts：任务执行的结果，比如执行 打包任务 后的产出资源。
9. dependencies：依赖的其他任务。
10. retry：当任务失败时最多重试的次数。
11. coverage：指定如何从任务结果中提取代码覆盖率。
12. parallel：允许并行的任务实例个数。

请注意版本问题，每个属性对版本的要求并不一致，具体的可以点击属性查看官方文档。

使用 Gitlab CI

使用 Gitlab CI 服务的两种方式： 1. Auto DevOps 2. 手动配置 CI/CD

Auto DevOps

Auto DevOps 是 Gitlab 11.0 推出的新功能，它提供了预定义的 CI/CD 配置，允许我们自动检测、构建、测试、发布以及监控应用。

暂未使用，待补充。

手动配置 CI/CD

手动配置主要就 2 个步骤，配置 .gitlab-ci.yml 文件，添加 Gitlab Runner 运行该文件。

下面，我们看看如何配置 Gitlab Runner：

Gitlab Runner

Gitlab Runner 是一个开源项目，用来运行 .gitlab-ci.yml 中定义的任务并把结果返给 Gitlab。

安装

官方文档：https://docs.gitlab.com/runner/install/linux-repository.html

首先，添加离线仓库：

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

然后，安装最新版本：

sudo apt-get install gitlab-runner

注册

官方文档：https://docs.gitlab.com/runner/register/index.html

首先，我们进入要配置 Runner 的 Gitlab 仓库，在 Settings -> CI / CD 页面展开 Runners 配置面板可以看到已经分配的 Runner 以及注册 Runner 需要的参数：

然后，我们使用 Gitlab-Runner 命名开始注册：

gitlab-runner register

执行完会该命令，终端会有交互，要求我们输入以下参数：

gitlab-ci coordinator url ：gitlab 服务地址
gitlab-ci token：上图中的 token
description：描述信息
tags：标签，对应 .gitlab-ci.yml 任务中配置的 tags，只有 tags 匹配的任务才会被该 Runner 执行。
executor：执行器，即任务脚本执行的环境

如果使用 docker 执行，则需要事先安装 Docker 环境。

参数填写完毕之后，一个 Runner 便被注册成功了：

我们回到 gitlab 仓库页面，然后刷新便可以看到 _fzBq4PN 这个 Runner 已经被注册到该项目：

我们可以点击 编辑图标 对该 Runner 进行修改。我比较喜欢把 Run untagged jobs 选项勾上，这样就不用每个任务都添加对应的 tags 了（因为现在涉及到的都是一些简单的流程）。

总结

首先，CI/CD 是一种软件开发流程，Gitlab CI/CD 是 Gitlab 为实现该流程而提供的一个内置工具（服务）。其次，我们有 Auto DevOps 与 手动配置 两种方式使用，本文讲解的主要是 手动配置 方式。

加速Gitlab Runner

gitlab runner构建镜像每次RUN 安装依赖包，都远程下载?可以缓存加速吗？可以的！

在将GitLab Runner注册到GitLab page上，让GitLab page可以和你的Runner通信时，有一步是填写使用的executor

输入Runner的executor：
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:

如果你选择Docker作为Runner的executor，你还要选择默认的docker image来运行job(当然，你也可以在.gitlab-ci.yml里指明你需要用的image),这句话就跟文章使用gitlab-runner往k8s上发送curl命令实现pod中容器使用的镜像版本更新，地址：开头讲述的那样，不过.gitlab-ci.yml里指明的image优先级高。

注册完成后你可以在/etc/gitlab-runner里发现 config.toml文件，该文件是Runner的配置文件

接下来就牵涉到一个重要的话题 —— Executor

Shell Executor
以宿主机作为Runner的所有jobs的执行器。Runner将会从远程仓库pull你的工程，工程的目录为：/builds。如果你使用了cache，那么cache将会存在/cache/。但是，它需要将构建所需的所有依赖手动安装到安装了Runner的同一台计算机上，比如使用到的git,jdk,maven,docekr等
Docker Executor
所有jobs的执行环境为指定的docker image所生成的container，每个job都会生成一个container并且在job结束后立即销毁。这个说的就是config.toml文件和.gitlab-ci.yml中指定的image
Docker executor默认将所有的builds存储在/builds/(这里的路径是container里的路径，Runner配置文件config.toml里的build_dir字段可以重新指明build的目录，默认对应于宿主机的目录是在宿主机的docker volume下：/var/lib/docker/volumes//_data/)，默认将所有的caches存储在container里的/cache目录(config.toml里的cache_dir字段可以重新指明cache的目录)，注意build_dir和cache_dir指向的均是container里的目录，要想将container里的数据持久化，需要用到volumes字段，这个字段的使用和docker volume的使用是类似的，只需在config.toml的[runner.docker]部分添加volumes = [“/cache”, “:rw”]即可实现container里/cache目录数据的永久保存以及将host目录挂载到相应的container目录并具有读写的功能。比如：

# 仅作展示，未显示完整
[runners.docker]
  image = "jdd.io/jre:1.8.275"
  volumes = ["/cache","/run/docker.sock:/run/docker.sock"]

当你使用docker 或 docker+machine executors时，你可以通过设置pull_policy来决定Runner如何pull docker image。pull_policy有三种值：

always —— Runner始终从远程pull docker image。
if-not-present —— Runner会首先检查本地是否有该image，如果有则用本地的，如果没有则从远程拉取。
never —— Runner始终使用本地的image。

注意：这一步就是本文开头提到的，使用本地镜像，不用再从dockerhub上拉取了

# 仅作展示，未显示完整
[runners.docker]
  image = "jdd.io/jre:1.8.275"
  pull_policy="if-not-present" # 添加这个选项就可以了
  volumes = ["/cache","/run/docker.sock:/run/docker.sock"]

当你使用docker, docker+machine 或 kubernetes作为executor时，GitLab Runner将会使用特定的container来处理Git、artifacts 和cache 操作。

权限管理

以管理员的身份登入gitlab，点击Settings，然后选择Members，可以通过输入名字选择要分配权限的小组成员，然后分配角色，选择权限有效时间，点击Add to Project就把人员拉近到项目中。

GitLab的角色有以下四种：

Guest：可以创建issue、发表评论，不能读写版本库
Reporter：可以克隆代码，不能提交，可以赋予测试、产品经理此权限
Developer：可以克隆代码、开发、提交、push，可以赋予开发人员此权限
MainMaster：可以创建项目、添加tag、保护分支、添加项目成员、编辑项目，一般GitLab管理员或者CTO才有此权限

访问权限 - Visibility Level：

这个是在建立项目时就需要选定的，主要用于决定哪些人可以访问此项目，包含3种

Private - 私有，只有属于该项目成员才有原先查看
Internal - 内部，用个Gitlab账号的人都可以clone
Public - 公开，任何人可以clone

性能优化

为GitLab EE Docker版本配置以减少CPU占用，需要同时从容器资源分配和GitLab内部服务调优两个层面入手。关键在于理解：gitlab.rb是GitLab服务自身的配置文件，而docker-compose参数是控制容器运行时资源上限的约束。两者需协同配置，缺一不可。

以下是完整的配置方法与操作教程。

核心原则：分层优化策略

CPU占用过高通常由两方面导致：一是分配给Docker容器的物理资源（CPU核心数）不足，导致资源竞争；二是GitLab内部服务（如Unicorn、Sidekiq、PostgreSQL）的默认配置不适合当前硬件规模，造成进程过多或计算资源浪费。因此，优化应遵循以下步骤：
1.容器层：通过docker-compose.yml的deploy.resources.limits参数，为容器设定合理的CPU和内存使用上限，防止其无节制地消耗宿主机资源。
2.应用层：进入容器内部，修改/etc/gitlab/gitlab.rb文件，对GitLab的各个高消耗组件进行精细化调优，减少不必要的进程和内存开销，从而间接降低CPU负载。

Docker-Compose层面：限制容器资源

在您的docker-compose.yml文件中，必须为GitLab服务定义资源限制。这是控制CPU占用的第一道防线。

version: '3.8'
services:
gitlab:
image: gitlab/gitlab-ee:latest
container_name: gitlab
restart: unless-stopped
hostname: 'gitlab.yourdomain.com'
# --- 核心资源限制配置开始 ---
deploy:
resources:
limits:
cpus: '4.0'# 关键：将容器使用的CPU核心数限制在4核。请根据您宿主机总核心数调整（例如8核主机分配4核）。
memory: 8G# 关键：限制容器最大内存为8GB。充足的内存可以减少Swap使用，避免因内存交换导致CPU飙升。
reservations:
memory: 4G# 为容器预留4GB内存，确保其启动和基本运行。
# --- 核心资源限制配置结束 ---
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.yourdomain.com'
# 其他gitlab.rb配置也可通过此处注入，但复杂配置建议在容器内修改文件。
ports:
- "80:80"
- "443:443"
- "2222:22"
volumes:
- './config:/etc/gitlab'
- './logs:/var/log/gitlab'
- './data:/var/opt/gitlab'

配置说明：

cpus: '4.0'：此设置直接限制了该容器最多只能使用相当于4个CPU核心的计算能力。如果宿主机是8核，这意味着一半的资源被划定给GitLab，防止它占用全部CPU。
memory: 8G：内存限制同样重要。根据经验，对于中小团队（50人以下），8GB内存是一个推荐的起点。内存不足会触发系统使用Swap，导致磁盘I/O增加，进而引发CPU等待和负载升高。
修改后，执行 docker-compose down 然后 docker-compose up -d 使配置生效。

GitLab应用层面：优化 `/etc/gitlab/gitlab.rb`

这是降低CPU占用的关键步骤。您需要进入容器内部修改配置文件，并应用配置。

1.进入容器并编辑配置文件：

# 进入正在运行的GitLab容器
docker exec -it gitlab /bin/bash

# 备份原始配置文件
cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak

# 使用vim编辑配置文件（容器内通常已安装）
vim /etc/gitlab/gitlab.rb

2.添加或修改以下核心优化参数：在gitlab.rb文件中找到相应位置，取消注释并修改为以下值。这些设置旨在减少并发进程数和后台任务负载，特别适用于资源有限的环境。

### 1. 优化Unicorn (GitLab Rails应用服务器)
# 减少工作进程数量。默认值可能过高。对于2-4核CPU的容器，设为2是一个安全的起点。
unicorn['worker_processes'] = 2
# 可选：设置每个工作进程的内存限制，防止单个进程失控。
unicorn['worker_memory_limit_min'] = "200 * 1 << 20" # 200MB
unicorn['worker_memory_limit_max'] = "300 * 1 << 20" # 300MB

### 2. 优化Sidekiq (后台作业处理器)
# 降低并发线程数。默认值可能为25，这对于小型部署过高。
sidekiq['concurrency'] = 10

### 3. 优化PostgreSQL (数据库)
# 减少共享缓冲区大小。在容器内存有限的情况下，过大的设置会挤占其他进程内存。
postgresql['shared_buffers'] = "256MB"
# 减少最大工作进程数。
postgresql['max_worker_processes'] = 4

### 4. 关闭非必需的服务（强力降低CPU/内存开销）
# 禁用Prometheus监控、节点导出器（除非您需要详细的容器级监控）
prometheus['enable'] = false
prometheus_monitoring['enable'] = false
node_exporter['enable'] = false
redis_exporter['enable'] = false
postgres_exporter['enable'] = false
gitlab_exporter['enable'] = false

# 如果不需要，可以禁用Elasticsearch搜索（这是一个资源消耗大户）
# elasticsearch['enable'] = false

参数原理：

unicorn['worker_processes']：每个Unicorn进程都会处理HTTP请求。进程数越多，并发能力越强，但CPU和内存开销也线性增长。将其从默认值（如4）降低到2，可以立即减少CPU占用。
sidekiq['concurrency']：控制后台任务（如发送邮件、处理CI流水线）的并行度。降低此值可以减少数据库连接数和CPU竞争。
postgresql['shared_buffers']：是数据库缓存。在内存受限的容器中，设置过大（如按物理内存25%计算的几个GB）会导致内存紧张，触发系统交换和CPU高负载。将其设置为一个较小的固定值（如256MB）更安全。
关闭监控组件：对于私有化部署的小型团队，内置的Prometheus及其一系列exporter会持续消耗约10-15%的CPU和数百MB内存。禁用它们是立竿见影的减负方法。

3.应用配置并重启服务：

# 在容器内执行，使新的gitlab.rb配置生效
gitlab-ctl reconfigure
# 重启GitLab服务
gitlab-ctl restart
# 退出容器
exit

验证优化效果与监控

完成上述配置后，需要进行验证。

1.观察容器资源使用：

# 在宿主机上执行，查看容器的CPU和内存使用率
docker stats gitlab

您应该看到CPU %和MEM USAGE被限制在您设定的limits附近。

2.检查GitLab内部状态：

docker exec gitlab gitlab-ctl status

确保所有服务（如unicorn，sidekiq，postgresql）都处于run状态。

3.进行压力测试（可选）：尝试进行一些Git操作（如git clone、git push）并访问Web界面，观察响应速度是否可接受。您可以使用top或htop命令在宿主机上观察整体CPU负载是否已下降。

总结与进阶建议

配置位置关系：docker-compose的limits是天花板，设定了容器能使用的资源最大值；gitlab.rb的调优是在这个天花板下，安排各个服务如何更高效、更节省地使用这些资源。两者必须配合使用。
循序渐进：性能调优是一个迭代过程。建议每次只修改1-2个参数，观察效果后再进行下一步调整。
监控先行：如果条件允许，在调优前建立简单的监控（如使用docker stats日志），以便量化调优效果。
备份配置：在修改gitlab.rb和docker-compose.yml前，务必进行备份，以便在出现问题时快速回滚。

通过上述容器层与应用层的双重配置，您可以有效控制GitLab EE Docker版本的CPU占用率，在保证核心功能可用的前提下，实现服务器资源的合理利用。

参考链接：

系列教程

全部文章RSS订阅

Gitlab 使用系列

Gitlab RSS 分类订阅

Devops系列

Devops 分类 RSS 订阅

项目管理系列

AI 分类 RSS 订阅

Gitlab的安装及使用

2021-07-09T08:25:00.000Z

Gitlab概述

1.1 GitLab介绍

GitLab是利用Ruby on Rails一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。

它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找

1.2 Gitlab服务构成

Nginx：静态web服务器。
gitlab-shell：用于处理Git命令和修改authorized keys列表。
gitlab-workhorse: 轻量级的反向代理服务器。
logrotate：日志文件管理工具。
postgresql：数据库。
redis：缓存数据库。
sidekiq：用于在后台执行队列任务（异步执行）。
unicorn：An HTTP server for Rack applications，GitLab Rails应用是托管在这个服务器上面的。

1.3 Gitlab工作流程

1.4 GitLab Shell

GitLab Shell有两个作用：为GitLab处理Git命令、修改authorized keys列表

当通过SSH访问GitLab Server时，GitLab Shell会：

限制执行预定义好的Git命令（git push，git pull，git annex）
调用GitLab Rails API检查权限
执行pre-receive钩子（在企业版中叫做Git钩子）
执行用户请求的动作，处理GitLab的post-receive动作
处理自定义的post-receive动作

当通过http(s)访问GitLab Server时，工作流程取决于你是从Git仓库拉取(pull)代码还是向git仓库推送(push)代码：

如果是从Git仓库拉取(pull)代码，GitLab Rails应用会全权负责处理用户鉴权和执行Git命令的工作

如果是向Git仓库推送(push)代码，GitLab Rails应用既不会进行用户鉴权也不会执行Git命令，它会把以下工作交由GitLab Shell进行处理：

调用GitLab Rails API 检查权限
执行pre-receive钩子（在GitLab企业版中叫做Git钩子）
执行你请求的动作
处理GitLab的post-receive动作
处理自定义的post-receive动作

1.5 GitLab Workhorse

Gitlab的安装部署

Gitlab要求服务器内存2G以上

2.1 方式一:下载gitlab-ce的rpm包

将对应版本的gitlab-ce下载到本地后，直接yum安装即可

要先将这个rpm包下载到本地

yum install -y gitlab-ce-13.6.1-ce.0.el7.x86_64.rpm

2.2 方式二:配置yum源

在 /etc/yum.repos.d/ 下新建 gitlab-ce.repo，写入如下内容：

[gitlab-ce]
name=gitlab-ce
baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/ Repo_gpgcheck=0
Enabled=1 Gpgkey=https://packages.gitlab.com/gpg.key

然后创建cache，再直接安装gitlab-ce

yum makecache # 这一步会创建大量的数据

直接安装最新版

yum install -y gitlab-ce # 如果要安装指定的版本，在后面填上版本号即可
yum install -y  gitlab-ce-13.6.1

如果安装时出现gpgkey验证错误，只需在安装时明确指明不进行gpgkey验证

yum install gitlab-ce -y --nogpgcheck

2.3 gitlab的配置

配置文件位置 /etc/gitlab/gitlab.rb

[root@centos7 test]# vim /etc/gitlab/gitlab.rb
[root@centos7 test]# grep "^[a-Z]" /etc/gitlab/gitlab.rb
external_url 'http://10.0.0.51'  # 这里一定要加上http://

配置邮件服务

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.qq.com" gitlab_rails['smtp_port'] = 25 gitlab_rails['smtp_user_name'] = "hgzerowzh@qq.com"  # 自己的qq邮箱账号
gitlab_rails['smtp_password'] = "xxx"  # 开通smtp时返回的授权码
gitlab_rails['smtp_domain'] = "qq.com" gitlab_rails['smtp_authentication'] = "login" gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['gitlab_email_from'] = "hgzerowzh@qq.com"  # 指定发送邮件的邮箱地址
user["git_user_email"] = "shit@qq.com"   # 指定接收邮件的邮箱地址

修改好配置文件后，要使用 gitlab-ctl reconfigure 命令重载一下配置文件，否则不生效。

gitlab-ctl reconfigure # 重载配置文件

2.4 Gitlab常用命令

gitlab-ctl start         # 启动所有 gitlab 组件
gitlab-ctl stop          # 停止所有 gitlab 组件
gitlab-ctl restart       # 重启所有 gitlab 组件
gitlab-ctl status        # 查看服务状态
gitlab-ctl reconfigure   # 启动服务
gitlab-ctl show-config   # 验证配置文件
gitlab-ctl tail          # 查看日志
gitlab-rake gitlab:check SANITIZE=true --trace    # 检查gitlab
vim /etc/gitlab/gitlab.rb # 修改默认的配置文件

Gitlab的使用

Gitlab安装好后，设置密码，管理账户为root

3.1 创建Group

填上组名即可，这里组名为java

3.2 创建User

创建四个User：pm、dev1、dev2、dev3

3.3 添加User到Group中并授权

3.4 创建Project并配置SSH

3.5 在项目中添加成员

3.6 将本地文件推送到Gitlab

将app01项目克隆下来

git clone git@10.0.0.51:java/app01.git # 初始化配置
git config --global user.name "hgzero" git config --global user.email "hgzero@qq.com"

在app01目录下新建一些文件

推送到gitlab

git add .
git commit -m "first edition" git push origin master

制定开发计划

4.1 创建开发计划

项目：app01
版本：v1.0

4.2 创建里程碑Milestones

用pm账号登录gitlab后操作（先要在admin中设置pm账号的密码）
要根据开发计划来创建Milestones

4.3 根据开发计划创建issue

创建4个issue，分派给dev1和dev2这两个开发人员

4.4 开发者登录账号查看分派的任务

然后开发dev1登录gitlab，就能看到任务已经分配过来了

4.5 开发流程

公司里的开发开始任务

1. 先从仓库把项目拉下来

git clone git@10.0.0.51:java/app01.git
cd app01/

2.先创建一个自己的分支，然后进行开发

git checkout -b index   # 创建一个叫index的分支，并切换到这个分支
git status # 3. 开始开发首页
echo "<h1>welcome to this app</h1>" > index.html  # 假设就开发了一个index页面

4. 开发完成后，把项目传到仓库

git add .
git commit -m "index"

如果写成 git commit -m “close #2” ，则表示merge请求允许且merge成功之后，自动删除编号为#2的issue

传到index分支

git push origin index

4.6 合并分支

1）开发dev1发送合并分支请求给pm

2）pm收到开发的Merge请求后进行处理

使用pm登录，就可以看到pm已经收到了合并请求merge request

3）开发dev1确认任务完成

退出pm账户，登入dev1账户：

或者点进去后，在侧边栏进行标识Done，然后已经完成的issue，可以将其Close

这个时候Milestones的进度已经往前进了一些了：

4.7 开发其他功能

然后其他开发者或者自己再次进行开发时，先要把刚刚更新后的内容（master主干）拉回来，然后再进行开发

git checkout master  # 切换到master
git pull             # 从远端仓库拉取数据

然后再进行其他操作

Gitlab备份恢复

5.1 备份gitlab

1）修改配置文件

/etc/gitlab/gitlab.rb

备份保存的位置，这里是默认位置，可修改成指定的位置

gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

设置备份保存的时间，超过此时间的日志将会被新覆盖

gitlab_rails['backup_keep_time'] = 604800  # 这里是默认设置，保存7天

特别注意： # 如果自定义了备份保存位置，则要修改备份目录的权限，比如： # chown -R git.git /data/backup/gitlab

配置完成后要重启以使配置生效

重读配置文件

gitlab-ctl reconfigure # 重启gitlab
gitlab-ctl restart

2）设置定时任务

每天凌晨2点定时创建备份 # 将一下内容写入到定时任务中 crontab -e

0 2 * * * /usr/bin/gitlab-rake gitlab:backup:create # 备份策略建议： # 本地保留3到7天，在异地备份永久保存

3）备份时间的识别

备份后的文件类似这样的形式：1494170842_gitlab_backup.tar，可以根据前面的时间戳确认备份生成的时间

data -d  @1494170842

5.2 恢复gitlab

1）停止数据写入服务

停止数据写入服务

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq

2）进行数据恢复并重启

进行恢复

gitlab-rake gitlab:backup:restore BACKUP=1494170842  # 这个时间戳就是刚刚备份的文件前面的时间戳

重启

gitlab-ctl restart

gitlab邮件通知配置

vim /etc/gitlab/gitlab.rb

gitlab_rails['time_zone'] = 'Asia/Shanghai' gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = 'example@163.com' # 填写发件人的邮箱地址
gitlab_rails['gitlab_email_display_name'] = 'gitlab' gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.163.com"  # smtp服务器的地址,如网易的地址
gitlab_rails['smtp_port'] = 25                 # 要注意如果使用了SSL/TLS的话,端口可能不是25
gitlab_rails['smtp_user_name'] = "smtp用户名" gitlab_rails['smtp_password'] = "smtp用户密码" gitlab_rails['smtp_domain'] = "163.com" gitlab_rails['smtp_authentication'] = "login"

使用SourceTree进行项目开发

7.1 项目拉取

先把项目克隆下来

如果ssh的方式克隆失败，可能是因为SSH Key没找到，可以在这里添加

7.2 创建分支进行功能开发

1）新建立一个叫“pay”的分支

2）进行功能开发

7.3 提交项目

1）开发pay功能完成后进行提交

可以看到SourceTree中已经有“未提交的更改”

2）添加“用户信息”

** 3）进行提交**

注释也可以写成 close #3 ，作用是提交完成后关闭3号issue

7.4 推送到仓库

然后就可以在gitlab上进行发送merge请求了，后面就可以进行其他操作了

7.5 项目上线

1）当所有工作完成之后，就可以进行上线了

2）打标签

上线先打个标签

** 3）删除无用分支**

然后删除已经合并到主干中的不必要的分支，如index、pay等
最后一定要注意时间一定要同步，不然会错乱

参考

Praywu

系列教程

全部文章RSS订阅

Gitlab 使用系列

Gitlab RSS 分类订阅

Devops系列

Devops 分类 RSS 订阅

项目管理系列

AI 分类 RSS 订阅

夜法之书 • Posts by "devops" category

开源观察之到底是谁在主导开源软件生态的发展？

前言

对话开源

参考&致谢

那些有用的Github工具介绍！Action、app、workflow等

GitHub Actions 是什么？

Github Action 使用限制：

Github 仓库与上游自动同步

只同步默认分支的教程

同步其他分支的教程

高级玩法

Github 自动合并 PR

renovate

mergify

使用 Github Dependabot 自动更新依赖版本

开启 Dependabot

配置 dependabot.yml

支持的包管理器

Gitlab 镜像 Github

Github 仓库备份

自动翻译

后记

参考&致谢

系列教程

Devops系列

Gitbook使用系列

Gitlab 使用系列

自建全套开源Devops开发系统

Devops框架图解

开源云平台生死连问

Consul自动负载均衡

Github仓库备份

配置要求

可靠性

数据安全

备份

扩展性

项目介绍

ELK

cacti

zabbix

ansible

CMDB

PVE

CEPH

OpenStack

其它项目

onedev

smartdns

awesome-selfhosted

私有Git服务器整理

系列教程

Devops系列

相关文档

Git介绍以及分支模型图解

GIT架构

.git介绍

Commitizen

安装

创建 package.json

初始化

使用

变更规范

全局安装

参考

系列教程

Devops系列

三万字无坑搭建基于Docker+K8S+GitLab/SVN+Jenkins+Harbor持续集成交付环境

服务器规划

安装环境版本

服务器免密码登录

安装JDK

安装Maven

安装Docker环境

安装docker-compose

2.为docker-compose文件赋予可执行权限

3.查看docker-compose版本

安装K8S集群环境

安装K8S基础环境

`Consul`自动负载均衡

`Github`仓库备份

`.git`介绍