gitlab

1.安装依赖 $ yum -y install policycoreutils openssh-server openssh-clients postfix $ yum install policycoreutils-python 　　 2.设置postfix开机自启并启动 $ systemctl enable postfix $ systemctl start postfix 　　 3.下载 $ wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ce/packages/ol/7/gitlab-ce-12.0.3-ce.0.el7.x86_64.rpm/download.rpm 4.解压 $ rpm -i gitlab-ce-12.0.3-ce.0.el7.x86_64.rpm 解压完后会出现如下界面： 5.修改gitlab配置文件指定服务器ip和自定义端口 vim /etc/gitlab/gitlab.rb 6.重置并启动GitLab $ gitlab-ctl reconfigure 　　 7.访问 GitLab页面 http://服务器IP:端口 如果gitlab密码忘记了，可以执行如下步骤： （1）执行： gitlab-rails console production [root

简介： 究竟什么是云原生DevOps呢？我们认为：云原生DevOps是充分利用云原生基础设施，基于微服务/无服务架构体系和开源标准，语言和框架无关，具备持续交付和智能自运维能力，从而做到比传统DevOps更高的服务质量、更低的开发运维成本，让研发专注于业务的快速迭代。 1、什么是云原生DevOps 我们先通过一个简单的例子来了解什么是云原生DevOps，它和DevOps有什么不同。 上图是一个大排档，图中的大厨在非常努力的去切、炒、制作各种美食，并将它卖出去。从原材料的采购到加工到销售到售后，都是一两个人完成。这是非常典型的DevOps场景，团队搞定端到端的所有的事情。这种情况，当厨师水平比较高、销售能力比较强的时候，可以做到高效率、低浪费。但存在的问题是，想要规模化会很难。因为它的流程都是非标准的，需要厨师有很强的个人能力。 我们再看这张南京大排档的图，虽然名字里有大排档，但它显然不是我们上面说的大排档。我们随便走进任何一家南京大排档，都可以发现，南京大排档的厨师，可以专注在为客户提供更好的菜品上，研发试验新菜品，并通过小批量的用户来尝试和推广。无论是用户量增加或减少，都能很快的去适应。店铺扩张也可以很快。这种我们可以理解为云原生DevOps。 那究竟什么是云原生DevOps呢？我们认为：云原生DevOps是充分利用云原生基础设施，基于微服务/无服务架构体系和开源标准

培训招生 | 网络安全，那些起于平凡的荣光 “这是最好的时代，也是最坏的时代” “这是信仰的时期，也是怀疑的时期” 狄更斯似在描绘那个时代，却又讲述着每个时代，特别是，当下。 真实与虚拟，是如今的“双城”。有这样一群人，他们在真实世界中沉默平凡，但在虚拟网络中却荣耀加身，他们像独行的剑客，像入世的僧侣，用一串串代码守护着网络世界的公平和自由，在无数个不眠之夜与黑灰产、攻击者近身搏击。 拈叶飞花，网络安全既是他们的职场，也是他们的青春。 至善，愿天下摄然 自由、钻研、创新、分享，是他们信奉的黑客精神。手握屠龙之术，剑指那些技术光明背后的风险阴影，比起借此获取私利，他们选择了站在阳光下将安全威胁公之于众，让这个世界更美好。 全球首个完成VMware ESXi虚拟机逃逸，揭开云计算安全的重要战场 公开披露GitLab多个漏洞，探索基于Git版本控制服务的通用攻击面 披露因iOS APP URL Scheme和JSBridge接口导致的安全漏洞 破解索尼PS4（4.01系统）、智能微单相机、多款路由器及智能摄像头 破解主流NAS设备 一个内存破坏漏洞击溃了全线浏览器 …… 这是长亭科技一些微小的努力，也只是众多网络安全守护者们工作产出的一角。 无论是日常生活中随处可见的手机、电脑、路由器、摄像头，还是作为全面上云时代核心基础设施的虚拟化设备，凡有网络处都活跃着他们的身影

培训招生 | 网络安全，那些起于平凡的荣光 “这是最好的时代，也是最坏的时代” “这是信仰的时期，也是怀疑的时期” 狄更斯似在描绘那个时代，却又讲述着每个时代，特别是，当下。 真实与虚拟，是如今的“双城”。有这样一群人，他们在真实世界中沉默平凡，但在虚拟网络中却荣耀加身，他们像独行的剑客，像入世的僧侣，用一串串代码守护着网络世界的公平和自由，在无数个不眠之夜与黑灰产、攻击者近身搏击。 拈叶飞花，网络安全既是他们的职场，也是他们的青春。 至善，愿天下摄然 自由、钻研、创新、分享，是他们信奉的黑客精神。手握屠龙之术，剑指那些技术光明背后的风险阴影，比起借此获取私利，他们选择了站在阳光下将安全威胁公之于众，让这个世界更美好。 全球首个完成VMware ESXi虚拟机逃逸，揭开云计算安全的重要战场 公开披露GitLab多个漏洞，探索基于Git版本控制服务的通用攻击面 披露因iOS APP URL Scheme和JSBridge接口导致的安全漏洞 破解索尼PS4（4.01系统）、智能微单相机、多款路由器及智能摄像头 破解主流NAS设备 一个内存破坏漏洞击溃了全线浏览器 …… 这是长亭科技一些微小的努力，也只是众多网络安全守护者们工作产出的一角。 无论是日常生活中随处可见的手机、电脑、路由器、摄像头，还是作为全面上云时代核心基础设施的虚拟化设备，凡有网络处都活跃着他们的身影

把代码从GitHub上迁移到GitLab上，在使用一段时间过后，发现GitLab与GitHub还是有不少区别的。 先说一下相同点，二者都是基于web的Git仓库，在很大程度上GitLab是仿照GitHub来做的，它们都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。 GitHub作为开源代码库及版本控制系统，拥有超过900万的开发者用户，目前仍然是最火的开源项目托管系统。GitHub同时提供公共仓库和私有仓库，但如果要使用私有仓库，是需要付费的。 而GitLab解决了这个问题，你可以在上面创建私人的免费仓库。 GitLab让开发团队对他们的代码仓库拥有更多的控制，相比于GitHub，它有不少的特色： 允许免费设置仓库权限；允许用户选择分享一个project的部分代码；允许用户设置project的获取权限，进一步的提升安全性；可以设置获取到团队整体的改进进度；通过innersourcing让不在权限范围内的人访问不到该资源。 从代码私有性方面来看，有时公司并不希望员工获取到全部的代码，这个时候GitLab无疑是更好的选择。但对于开源项目而言，GitHub依然是代码托管的首选。 公司开始把代码从GitHub上迁移到GitLab上，在使用一段时间过后，发现GitLab与GitHub还是有不少区别的。 先说一下相同点

前端一说起刀耕火种，那肯定紧随着前端工程化这一话题。随着 react / vue / angular ， es6+ ， webpack ， babel ， typescript 以及 node 的发展，前端已经在逐渐替代过去 script 引 cdn 开发的方式了，掀起了工程化这一大浪潮。得益于工程化的发展与开源社区的良好生态，前端应用的可用性与效率得到了很大提高。 前端以前是刀耕火种，那前端应用部署在以前也是刀耕火种。那前端应用部署的发展得益于什么，随前端工程化带来的副产品？ 这只是一部分，而更重要的原因是 devops 的崛起。 为了更清晰地理解前端部署的发展史，了解部署时运维和前端（或者更广泛地说，业务开发人员）的职责划分，当每次前端部署发生改变时，可以思考两个问题 缓存，前端应用中http 的 response header 由谁来配？得益于工程化发展，可以对打包后得到带有 hash 值的文件可以做永久缓存 跨域， /api 的代理配置由谁来配？在开发环境前端可以开个小服务，启用 webpack-dev-server 配置跨域，那生产环境呢 这两个问题都是前端面试时的高频问题，但话语权是否掌握在前端手里 时间来到 React 刚刚发展起来的这一年，这时已经使用 React 开发应用，使用 webpack 来打包。但是前端部署，仍是刀耕火种 刀耕火种 一台跳板机

【回忆记录几周前】 由于在Ubuntu20中支持的gitlab9.2.5-ce0版本，因此尝试了各种方式之后最终物理安装方式没有成功。 突然想到既然没有官方的支持，何不使用docker方式部署，按照该思路一顿操作，刚开始找到资料都是介绍第三方维护的版本（很坑），尝试了多次最终才下载成功，但启动之后，使用命令行操作gitlab恢复数据，web页面报错，查阅各种文档无法解决，尝试多次只能放弃使用。（非官方维护版本，有各种坑，有些版本不能使用命令行，有些版本不能恢复数据） 最后发现官方有支持，直接使用该版本，过程非常顺利。根据物理版本的使用方式，进入docker容器内部，各种命令和物理机中使用毫无差别，顺利恢复数据。 下面记录部署流水账【粗糙莫怪】： sudo docker pull gitlab/gitlab-ce:9.2.5-ce.0 【从官方拉取最靠谱】 sudo mkdir /home/gitlab_9.2.5 sudo mkdir config logs data 【需要将备份文件修改权限】sudo docker run --detach -p 443:443 -p 80:80 -p 2222:22 --name gitlab --restart always -v /home/gitlab_9.2.5/config:/etc/gitlab -v /home/gitlab_9