Config服务端连接Git配置的技巧

Config:服务端连接Git配置，代码如下所示：

1、导入依赖

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
    </dependency>
</dependencies>

2、编写配置文件

server:
  port: 3344
spring:
  application:
    name: Git-config-3344
  #连接远程仓库
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/xiao-yunshan/gittest.git

3、编写启动类

@SpringBootApplication
@EnableConfigServer
public class Git_3344 {
    public static void main(String[] args) {
        SpringApplication.run(Git_3344.class,args);
    }
}

4、启动访问

http://localhost:3344/application-dev.yml

到此这篇关于Config服务端连接Git配置的技巧的文章就介绍到这了,更多相关Config服务端连接Git配置内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • 详解spring cloud config整合gitlab搭建分布式的配置中心

    在前面的博客中,我们都是将配置文件放在各自的服务中,但是这样做有一个缺点,一旦配置修改了,那么我们就必须停机,然后修改配置文件后再进行上线,服务少的话,这样做还无可厚非,但是如果是成百上千的服务了,这个时候,就需要用到分布式的配置管理了.而spring cloud config正是用来解决这个问题而生的.下面就结合gitlab来实现分布式配置中心的搭建.spring cloud config配置中心由server端和client端组成, 前提:在gitlab中的工程下新建一个配置文件config

  • 详解Spring Cloud Config采用Git存储时两种常用的配置策略

    由于Spring Cloud Config默认采用了Git存储,相信很多团队在使用Spring Cloud的配置中心时也会采用这样的策略.即便大家都使用了Git存储,可能还有各种不同的配置方式,本文就来介绍一下两种常用的配置策略. 第一种:多个项目公用一个Git仓库,用不同的目录区分项目 主要的配置项如下: spring.cloud.config.server.git.uri=https://github.com/dyc87112/config-repo.git spring.cloud.con

  • 解决SpringCloud Config结合github无法读取配置的问题

    解决SpringCloud Config结合github无法读取配置的问题

    前言 配置中心存放文件在github是读取过程,可能你会出现读取不到配置信息.本次笔者将这一过程进行详细介绍. 准备 父工程 由于笔者是使用聚合工程,所以这次也是把相关的工程创建说明写上.当然你也可以完全创建两个独立的工程来引用. 创建父工程时直接只有一个pom文件,以下是这个文件的依赖信息 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache

  • gitlab实践教程使用git config进行相关的配置操作

    gitlab实践教程使用git config进行相关的配置操作

    这篇文章根据实际碰到的一个问题来介绍一下git配置相关的内容. 命令: git config 使用git config进行相关的配置操作 配置文件 git在整体上,配置文件分为三级,结合优先级相关信息如下 简单来说,优先级别离仓库越近越高,所以 项目级别 > 用户级别 > 系统级别.相同的设定同时出现时,优先级别高的会覆盖上层的配置. 配置检查 使用git config 不同的参数可以对如上三个不同的级别进行相关设定的检查 因为相同的设定有可能会产生覆盖,使用git config -l会列出g

  • Config服务端连接Git配置的技巧

    Config:服务端连接Git配置,代码如下所示: 1.导入依赖 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springf

  • Springcloud中的Nacos Config服务配置流程分析

    目录 简介 nacos config快速开始 依赖引入 配置nacos config 启动测试 配置动态更新配置 简介 前边写过几个微服务,订单微服务,商品微服务,账户微服务,库存微服务,每个微服务都去配置自己的配置文件,每个微服务一个yml配置文件,这样如果微服务足够多,对于配置文件的管理就很麻烦,如果配置文件变动需要更改,则需要我们一个一个的去改.例如开发环境,测试环境,生产环境等等,而且配置文件无法实时更新.我们修改了配置文件之后,必须重新启动微服务才能使配置生效.配置中心就可以解决配置问

  • git克隆远程仓库的指定分支方法(附常用git配置命令)

    一.普通克隆方式: git clone <远程仓库地址> 这种克隆方式默认是克隆master主分支,而且通过命令 git branch --list 能看到克隆后在本地也只有这一个分支,如果再通过新建分支再拉取指定分支,甚至可能还需要解决冲突,太繁琐. 二.克隆远程指定分支 那么,如何快速有效的直接克隆远程指定分支? 只需要一条命令: git clone -b <指定分支名> <远程仓库地址> 会自动在克隆该分支在本地,同样克隆后本地只有这一个分支. 附:常用git配置

  • 解决spring-cloud-config 多服务共享公共配置的问题

    问题描述 我们公司的项目是基于SpringCloud开发的微服务,用到了Spring-Cloud-Config作为微服务统一的配置中心,可以将散落在各个服务的配置进行统一配置管理. 虽然配置中心将各个应用的配置文件进行了统一管理, 但是涉及到的一些公共配置,比如数据库连接,redis连接,ftp连接等,依然还散落在各个应用的配置文件中,并没有抽取,我们需要根据环境的不同,而动态修改它们,非常难以维护.导致每次涉及修改这些公共配置,就非常老火. 所以想到了利用公共文件方法,现在在这里简单阐述一下如

  • JetBrains IntelliJ IDEA 配置优化技巧

    JetBrains IntelliJ IDEA 配置优化技巧

    本教程基于 JetBrains IntelliJ IDEA 2018.3.6 编写,高版本未经测试,或有不兼容,请见谅! JetBrains IntelliJ IDEA 分为两个版本:旗舰版(Ultimate)和社区版(Community).旗舰版收费(30天免费使用时间,功能齐全):社区版(永久免费,功能简陋). 1.目录结构解释 bin:容器,执行文件和启动参数等 help:快捷键文档和其他帮助文档 jre64:64 位 Java 运行环境 lib:IDEA 依赖的类库 license:各个

  • Git配置用户签名方式及原因说明

    目录 1.为什么要创建用户签名 2.为什么要在Git中配置这些信息 3.创建用户签名的方式 4.总结 1.为什么要创建用户签名 作为版本控制系统的客户端,每台客户机对版本库的所有提交操作,都需要注明操作者的身份.所以客户机首先需要进行自我身份的注册,即创建用户.Git要求“用户名和Email"这两样信息是必不可少的. 也就是说再让Git干活之前,必须得做一个最小配置,要把参与项目开发的工作人员的user.name以及user.email进行设置. 配置签名的作用:只是区分不同开发人员的身份. 2

  • Git配置用户签名方式的拓展示例实现全面讲解

    Git配置用户签名方式的拓展示例实现全面讲解

    目录 1.配置Git签名 (1)语法 (2)配置系统用户签名 (3)配置全局用户签名 (4)配置本地用户签名 2.查看三个配置文件的用户签名 (1)语法 (2)查看项目/仓库级别的配置文件信息(local) (3)查看用户/全局级别的配置文件信息(global) (4)查看系统级别的配置文件信息(system) (5)查看当前系统中Git的所有配置信息 3.总结 1.配置Git签名 (1)语法 $ git config 配置文件作用域 user.name '用户名' $ git config 配

  • go使用consul实现服务发现及配置共享实现详解

    go使用consul实现服务发现及配置共享实现详解

    目录 使用consul四大特性 通过docker安装consul 实现代码 运行结果 使用consul四大特性 1. 服务发现:利用服务注册,服务发现功能来实现服务治理. 2. 健康检查:利用consul注册的检查检查函数或脚本来判断服务是否健康,若服务不存在则从注册中心移除该服务,减少故障服务请求. 3. k/v数据存储:存储kv数据,可以作为服务配置中心来使用. 4. 多数据中心:可以建立多个consul集群通过inter网络进行互联,进一步保证数据可用性. 通过docker安装consul

  • Git配置别名简化操作命令方式详解

    目录 引言 一.配置别名 1.命令行配置别名 2.通过配置文件配置别名 二.常用别名配置 引言 Git 中有些操作命令比较长,单词多,不容易记忆.例如把一个dev开发分支合并到master分支,就需要敲:git merge --no-ff -m "提交合并" dev 这么长的命令.如果git命令不熟练的话很容易就敲错,这个问题就可以通过配置别名来简化git命令. 一.配置别名 Git配置别名通常有两种方式: 命令行配置 修改config文件 1.命令行配置别名 git config -

随机推荐