gitlab

DEVOPS技术实践_01:jenkins集成平台

半腔热情 提交于 2020-05-08 03:27:35
一、准备环境 准备三台机器 角色 IP地址 用户名 密码 jenkins-master 172.25.254.130 admin meiyoumima gitlab 172.25.254.131 tseter meiyoumima jenkins-slave(Maven 172.25.254.134 N/A N/A 二、jenkins-master安装 2.1 安装Java [root@jenkins-master ~]# yum install java-1.8.0-openjdk-devel.x86_64 [root@jenkins-master ~]# vi /etc/profile export JAVA_HOME=/usr/lib/jvm/usr/lib/jvm/java- 1.8 . 0 -openjdk- 1.8 . 0.201 .b09- 2 .el7_6.x86_64 export CLASSPATH =.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/ tools.jar export PATH =$PATH:$JAVA_HOME/bin [root@jenkins-master ~]# source /etc/profile [root@jenkins-master ~]#

netlify搭建静态站+https

淺唱寂寞╮ 提交于 2020-05-07 02:13:57
转载[大雄的学习人生 - 原文地址: https://www.cnblogs.com/codernie/p/9062104.html ] 一、使用github或者gitlab登陆netlify 首先,打开netlify网站( https://app.netlify.com/ ) 然后使用github或者gitlab账号登录。 二、根据github/gitlab仓库创建网站 点击New site from Git按钮: 根据你的仓库所在平台选择,以下三选一: 选择你需要部署的仓库: 设置部署选项,包括三点: 部署分支(对应下图中 Branch to deploy): 顾名思义就是你的git仓库的分支,默认选择为master分支 打包命令(对应下图中 Build command): 就是你的打包命令,诸如 npm run build,gulp build 之类;如果本身已是静态文件,不需打包编译,这一栏则不填 打包后目录(对应下图中 Publish directory): 即执行完打包命令之后静态文件所在目录,诸如 dist,_site 之类;如果本身已是静态文件,这一栏则不填 完成之后点击途中 deploy site 按钮 三、设置域名,绑定域名 进行完第二步,我们可以看到自动化部署已经开始运行了,而且过不多久,我们的网站就已经可以利用netlify域名就行访问了,如下图:

GitHub/GitLab/Gitee中项目互拷贝后仍保留历史提交记录的方法

浪尽此生 提交于 2020-05-06 14:21:41
GitHub、GitLab、Gitee等在同一个网站中执行复制或拷贝一个已有项目到一个新项目比较简单,因为它们在每一个项目上都有一个Fork按钮,直接点击此Fork按钮即可,Fork后的新项目会保留原有项目的历史提交记录。但是如果不在同一个网站上进行此操作,如想把GitHub中的项目复制到Gitee上,又要保留历史提交记录,则需要执行一些额外命令。 如把GitHub上的Messy_Test项目( https://github.com/fengbingchun/Messy_Test )复制到Gitee上,并取项目名为Messy_Tmp,具体操作如下: 1. 对Messy_Test项目执行git log,查看历史提交记录,结果如下图所示,最近的一次提交commit id为:7726835e4a92252985cd521bb83fed9dbfb62312,分支名为master 2. 在Messy_Test项目中.git/config内容如下:注意此时[remote “origin”]的内容: 3. 在Gitee中创建一个新项目,名称为Messy_Tmp,地址为: https://gitee.com/fengbingchun/Messy_Tmp 4. 在Messy_Test项目中依次执行如下三条命令,结果如下图所示:注意此时[remote “origin”]的内容已改变: 5.

AWS之EBS卷扩容根分区

≯℡__Kan透↙ 提交于 2020-05-06 10:26:38
AWS对磁盘(EBS)的计费是根据用户划分的容量来按时计费,而不是以使用容量来计费。所以,大家可能会问,那磁盘扩容方不方便呢,答案是肯定的,在AWS上,即便扩容根分区也是非常方便的。扩容工具就是cloud-init。 扩容操作步骤如下: 1、安装cloud-init 对于ubuntu系统,安装cloud-init命令如下: # apt-get install -y cloud-init 对于CentOs系统,安装cloud-init命令如下: # yum -y install cloud-init 2、登录AWS控制台修改EBS卷大小,此处是将名为gitlab的卷从60GB扩容到100GB。 3、确认文件系统类型,ext4文件系统要用growpart和resize2fs命令;而如果是XFS文件系统,则应该用growpart和xfs_growfs。 此处应该用以下两条命令,使用growpart命令,后面接是设备名以及分区编号(中间有空隔),可以使用fdisk -l命令查看。 # growpart /dev/nvme0n1 1 # xfs_growfs /dev/nvme0n1p1 说明:nvme0n1是设备名,nvme0n1p1是对应的一个分区,p1表示主分区1 完成上述命令后,再次查看,根分区已经扩到100GB了。 若文件系统是ext4,则用下面2条命令完成扩容操作: #

Jenkins+maven+gitlab+Tomcat自动部署版本更新及回滚

China☆狼群 提交于 2020-05-06 08:05:45
该博文实现效果:结合maven+gitlab,可以使用Jenkins对不同环境(测试及线上环境)的tomcat服务器实现版本的迭代更新及版本回滚操作,部署完成后,只需点击几下,即可实现。 一、环境准备 系统 IP 主机名 运行服务 Centos7.3 192.168.171.131 Jenkins Jenkins+gitlab+Maven Centos7.3 192.168.171.134 Tomcat1 Tomcat Centos7.3 192.168.171.135 Tomcat2 Tomcat Jenkins、gitlab服务部署可参考: 部署Jenkins+Gitlab实现持续集成 Tomcat1用于测试环境,Tomcat2用于生产环境,部署可参考: Tomcat 的安装与优化 在进行真正的配置前,优先确保可以访问到以下几个页面: 1、gitlab 2、Jenkins 3、访问tomcat1 4、访问tomcat2 二、部署及配置 1、Jenkins服务器上安装JDK环境 [root@jenkins ~]# rpm -qa | grep jdk copy-jdk-configs-1.2-1.el7.noarch java-1.8.0-openjdk-headless-1.8.0.102-4.b14.el7.x86_64 java-1.8.0-openjdk-1.8.0

本地gitlab迁移并升级至docker运行并升级到12.5.9版本

…衆ロ難τιáo~ 提交于 2020-05-06 02:53:46
目的: 本地linux中gitlab11.4.3-ee.0 ----迁移并升级---->docker+ gitlab12.5.9-ee.0 升级路径: 首先使docker中的gitlab和本地linux为相同版本,然后再一步步升级至12.5.9 升级路径:11.4.3 -> 11.11.8 -> 12.0.9 -> 12.5.9 官方参考链接: 官方docker安装、升级gitlab官方文档: https://docs.gitlab.com/omnibus/docker/README.html#run-the-image 官方docker下载gitlab地址: https://hub.docker.com/r/gitlab/gitlab-ee/tags?page=1&name=11.4.3 升级参考链接 https://blog.csdn.net/bpqdwo/article/details/93204128 https://www.cnblogs.com/inxworld/p/11782545.html 环境: linux版本:CentOS Linux release 7.6.1810 (Core) docker版本:Docker version 19.03.5, build 633a0ea 老主机:IP为192.168.3.5------->gitlab为11.4.3-ee版本

解决 Windows Docker 安装 Gitlab Volume 权限问题

给你一囗甜甜゛ 提交于 2020-05-06 02:53:33
本文首发于我的个人博客, 解决 Windows Docker 安装 Gitlab Volume 权限问题 ,欢迎访问! 记录一下 Windows10 下 Docker 安装 Gitlab 的步骤。 Caution: We do not officially support running on Docker for Windows. There are known issues with volume permissions, and potentially other unknown issues. If you are trying to run on Docker for Windows, please see our getting help page for links to community resources (IRC, forum, etc) to seek help from other users. 首先, Gitlab 官方是不支持 Windows 下部署 Gitlab 镜像的,所以正常的 Gitlab 服务还是部署在 Linux 上比较好。本地部署只是用于个人开发测试环境。 问题描述 其实搭建 Gitlab 本省是一件很简单的事情,直接 pull 官方的 Gitlab 镜像开起来就可以用了。 docker run --detach \ --hostname

Linux环境使用Docker安装GitLab

房东的猫 提交于 2020-05-06 02:16:54
系统环境: CentOS 7.6 64位(同样适用于Ubuntu) 安装步骤: 1.创建文件夹 /home/docker/gitlab/etc /home/docker/gitlab/log /home/docker/gitlab/data 2.下载镜像并用外部匿名卷挂载数据 $ docker run \ --detach \ --publish 8090:8090 \ --publish 8091:22 \ --name gitlab \ --restart always \ -v /home/docker/gitlab/etc:/etc/gitlab -v /home/docker/gitlab/log:/var/log/gitlab -v /home/docker/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:12.5.0-ce.0 3.配置主机名 $ vim /home/docker/gitlab/etc/gitlab.rb external_url 'http://服务器IP:8090' gitlab_rails['gitlab_shell_ssh_port'] = 8091 4.重启gitlab $ docker restart gitlab 5.查看docker gitlab容器状态 $ docker ps 状态为

持续集成教程

﹥>﹥吖頭↗ 提交于 2020-05-05 19:32:43
持续集成教程 软件安装包 链接:https://pan.baidu.com/s/1ItDkmvoeQajIjY17J9Jw6w 提取码:o2rr 1. Devops介绍 01. 运维介绍 02. Devops是什么 03. Devops能干嘛 04. Devops如何实现 2. Git版本控制系统 01. 版本控制系统简介 02. 为什么需要版本控制系统 03. 常见版本管理工具 04. 牛逼的人不需要解释 3. Git安装 01. 系统环境准备 02. Git安装部署 03. Git初始化 4. Git常规使用 01. 创建数据-提交数据 02. Git四种状态 03. Git基础命令 04. Git分支 05. Git标签使用 5. Github使用 6. Gitlab安装 7. Gitlab使用 01. 外观配置 02. Gitlab汉化配置 03. 注册限制 04. 创建用户及组 05. 创建用户 06. 把用户添加到组 07. 创建项目 08. 推送代码到Gitlab 09. 开发推送代码到Gitlab 10. 分支保护 11. 代码合并 12. Git-gui安装 8. Gitlab备份与恢复 01. 备份 02. 恢复 9. Jenkins 01. 安装准备 02 .安装Jdk和Jenkins 03 .配置Jenkins 04. 插件安装 05. 创建项目 06.

Jenkins 中以构建 Tag 来实现版本管理

∥☆過路亽.° 提交于 2020-05-05 18:09:58
好的工具和流程能使我们事半功倍,而这个过程是不断迭代和演进的。关于这一块的内容,之前写过几篇文章: 在团队中使用GitLab中的Merge Request工作模式 敏捷下的需求和代码分支管理 不断进化的分支和需求管理 现在又有了些新的变化和改进,之所以需要改进,肯定是遇到问题了,那么就先从问题来开始今天的文章。 问题 问题分为两种: 方法论的问题 :比如团队采用主干开发,主干发布的模式,但是质量得不到保证,这时通过分析讨论决定采用采用主干开发,分支发布的模式来解决,这属于从方法论层面解决问题。 落地执行的问题 :已经知道应该采用主干开发,分支发布的模式,但在实际操作的时候,难以执行下去,这属于执行的问题。 在《不断进化的分支和需求管理》一文的最后提到会引入 release 分支和 tag,实际也这么做了,但效果并不理想,原因是执行的不严格,没有做到位,具体原因如下: 发布时是对分支进行构建发布,发布后再在 GitLab 中打上 tag,一忙起来很容易忘记; 镜像的版本也是如此。 解决思路 目的其实很简单,就是让代码的 tag 和镜像的 tag 能够一致,靠人工去做这些事情比想象的要更加困难,所以稍微转换了下思路就能实现自动化,也就可以解决这个问题。 之前提到的 release 分支只做最终的集成测试; 需要发布时就从 release 分支创建 tag,对 tag 来做发布