spring cloud config herunterladen – spring cloud config Quellcode herunterladen

spring cloud config

JAVA-Quellcode

4.2.0

Herunterladen

Merkmale

Spring Cloud-Konfigurationsserver

Spring Cloud Config Server bietet die folgenden Vorteile:

HTTP-ressourcenbasierte API für externe Konfiguration (Name-Wert-Paare oder gleichwertiger YAML-Inhalt)
Eigenschaftswerte verschlüsseln und entschlüsseln (symmetrisch oder asymmetrisch)
Einfache Einbettung in eine Spring Boot-Anwendung mit @EnableConfigServer

Spring Cloud-Konfigurationsclient

Speziell für Spring-Anwendungen ermöglicht Ihnen der Spring Cloud Config Client:

Binden Sie an den Konfigurationsserver und initialisieren Sie Spring Environment mit Remote-Eigenschaftsquellen.
Eigenschaftswerte verschlüsseln und entschlüsseln (symmetrisch oder asymmetrisch).
@RefreshScope für Spring @Beans , die bei Konfigurationsänderungen neu initialisiert werden möchten.
Verwenden Sie Verwaltungsendpunkte:
- /env zum Aktualisieren Environment und zum erneuten Binden von @ConfigurationProperties und Protokollebenen.
- /refresh zum Aktualisieren der @RefreshScope Beans.
- /restart zum Neustarten des Spring-Kontexts (standardmäßig deaktiviert).
- /pause und /resume zum Aufrufen der Lifecycle -Methoden ( stop() und start() im ApplicationContext ).
Bootstrap-Anwendungskontext: ein übergeordneter Kontext für die Hauptanwendung, der für alles trainiert werden kann (standardmäßig bindet er an den Konfigurationsserver und entschlüsselt Eigenschaftswerte).

Schnellstart

Beispielanwendung

Eine Beispielanwendung finden Sie hier. Da es sich um eine Spring Boot-Anwendung handelt, können Sie sie mit den üblichen Mechanismen ausführen (z. B. mvn spring-boot:run ). Wenn es ausgeführt wird, sucht es nach dem Konfigurationsserver unter http://localhost:8888 (ein konfigurierbarer Standardwert), sodass Sie den Server auch ausführen können, um zu sehen, wie alles zusammenarbeitet.

Das Beispiel enthält einen Testfall, bei dem der Konfigurationsserver auch in derselben JVM (mit einem anderen Port) gestartet wird und der Test bestätigt, dass eine Umgebungseigenschaft aus dem Git-Konfigurations-Repo vorhanden ist. Um den Speicherort des Konfigurationsservers zu ändern, können Sie spring.cloud.config.uri in bootstrap.yml (oder in den Systemeigenschaften und an anderen Stellen) festlegen.

Der Testfall verfügt über eine main() Methode, die den Server auf die gleiche Weise ausführt (beobachten Sie die Protokolle auf seinen Port), sodass Sie das gesamte System in einem Prozess ausführen und damit spielen können (Sie können beispielsweise die main() -Methode in Ihrer IDE). Die main() Methode verwendet target/config für das Arbeitsverzeichnis des Git-Repositorys, sodass Sie dort lokale Änderungen vornehmen und diese in der laufenden App sehen können. Das folgende Beispiel zeigt eine Sitzung, in der am Testfall herumgebastelt wird:

 $ curl localhost:8080/env/sample
mytest
$ vi target/config/mytest.properties
.. Wert von „sample“ ändern, optional festschreiben
$ curl -X POST localhost:8080/refresh
["Probe"]
$ curl localhost:8080/env/sample
Beispielwert

Der Aktualisierungsendpunkt meldet, dass sich die Eigenschaft „sample“ geändert hat.

Gebäude

Grundlegendes Kompilieren und Testen

Um die Quelle zu erstellen, müssen Sie JDK 17 installieren.

Spring Cloud verwendet Maven für die meisten Build-bezogenen Aktivitäten, und Sie sollten in der Lage sein, recht schnell loszulegen, indem Sie das Projekt, an dem Sie interessiert sind, klonen und eingeben

 $ ./mvnw installieren

Notiz

Sie können Maven (>=3.3.3) auch selbst installieren und in den folgenden Beispielen den Befehl mvn anstelle von ./mvnw ausführen. Wenn Sie dies tun, müssen Sie möglicherweise auch -P spring hinzufügen, wenn Ihre lokalen Maven-Einstellungen keine Repository-Deklarationen für Spring-Vorabversionsartefakte enthalten.

Notiz

Beachten Sie, dass Sie möglicherweise den für Maven verfügbaren Speicher erhöhen müssen, indem Sie eine MAVEN_OPTS Umgebungsvariable mit einem Wert wie -Xmx512m -XX:MaxPermSize=128m festlegen. Wir versuchen, dies in der .mvn -Konfiguration abzudecken. Wenn Sie also feststellen, dass dies für einen erfolgreichen Build erforderlich ist, erstellen Sie bitte ein Ticket, damit die Einstellungen zur Quellcodeverwaltung hinzugefügt werden.

Die Projekte, die Middleware (z. B. Redis) zum Testen erfordern, erfordern im Allgemeinen, dass eine lokale Instanz von [Docker] (https://www.docker.com/get-started) installiert ist und ausgeführt wird.

Dokumentation

Das Spring-Cloud-Build-Modul verfügt über ein „docs“-Profil. Wenn Sie dieses aktivieren, wird versucht, Asciidoc-Quellen mit Antora aus modules/ROOT/ zu erstellen.

Als Teil dieses Prozesses sucht es nach einem docs/src/main/asciidoc/README.adoc und verarbeitet es, indem es alle Includes lädt, es aber nicht analysiert oder rendert, sondern es einfach nach ${main.basedir} kopiert (standardmäßig). ${basedir} , also das Stammverzeichnis des Projekts). Wenn es Änderungen in der README-Datei gibt, wird diese nach einem Maven-Build als geänderte Datei an der richtigen Stelle angezeigt. Commitieren Sie es einfach und treiben Sie die Änderung voran.

Arbeiten mit dem Code

Wenn Sie keine IDE-Präferenz haben, empfehlen wir Ihnen, bei der Arbeit mit dem Code Spring Tools Suite oder Eclipse zu verwenden. Wir verwenden das Eclipse-Plugin m2eclipse für die Maven-Unterstützung. Andere IDEs und Tools sollten ebenfalls problemlos funktionieren, solange sie Maven 3.3.3 oder höher verwenden.

Aktivieren Sie das Spring Maven-Profil

Für Spring Cloud-Projekte muss das „Spring“-Maven-Profil aktiviert werden, um die Spring-Meilenstein- und Snapshot-Repositorys aufzulösen. Verwenden Sie Ihre bevorzugte IDE, um dieses Profil als aktiv festzulegen. Andernfalls kann es zu Buildfehlern kommen.

Importieren in Eclipse mit m2eclipse

Für die Arbeit mit Eclipse empfehlen wir das Eclipse-Plugin m2eclipse. Wenn Sie m2eclipse noch nicht installiert haben, ist es auf dem „Eclipse-Marktplatz“ verfügbar.

Notiz

Ältere Versionen von m2e unterstützen Maven 3.3 nicht, daher müssen Sie nach dem Import der Projekte in Eclipse auch m2eclipse anweisen, das richtige Profil für die Projekte zu verwenden. Wenn Sie viele verschiedene Fehler im Zusammenhang mit den POMs in den Projekten sehen, überprüfen Sie, ob Ihre Installation auf dem neuesten Stand ist. Wenn Sie m2e nicht aktualisieren können, fügen Sie das Profil „Spring“ zu Ihrer settings.xml hinzu. Alternativ können Sie die Repository-Einstellungen aus dem „Spring“-Profil des übergeordneten POM in Ihre settings.xml kopieren.

Importieren in Eclipse ohne m2eclipse

Wenn Sie m2eclipse lieber nicht verwenden möchten, können Sie Eclipse-Projektmetadaten mit dem folgenden Befehl generieren:

 $ ./mvnw Eclipse:Eclipse

Die generierten Eclipse-Projekte können importiert werden, indem Sie im file import existing projects auswählen.

JCE

Wenn Sie eine Ausnahme wegen „Ungültige Schlüsselgröße“ erhalten und das JDK von Sun verwenden, müssen Sie die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installieren. Weitere Informationen finden Sie unter den folgenden Links:

Java 6 JCE

Java 7 JCE

Java 8 JCE

Extrahieren Sie die JCE-Dateien in den Ordner JDK/jre/lib/security für die von Ihnen verwendete Version von JRE/JDK x64/x86.

Mitwirken

Spring Cloud wird unter der nicht restriktiven Apache 2.0-Lizenz veröffentlicht und folgt einem sehr standardmäßigen Github-Entwicklungsprozess, bei dem Github-Tracker für Probleme verwendet und Pull-Anfragen in Main zusammengeführt werden. Wenn Sie auch nur etwas Triviales beitragen möchten, zögern Sie bitte nicht, sondern befolgen Sie die nachstehenden Richtlinien.

Unterzeichnen Sie die Mitwirkenden-Lizenzvereinbarung

Bevor wir eine nicht triviale Patch- oder Pull-Anfrage annehmen, müssen Sie die Lizenzvereinbarung für Mitwirkende unterzeichnen. Die Unterzeichnung der Mitwirkendenvereinbarung gewährt niemandem Rechte am Hauptrepository, bedeutet aber, dass wir Ihre Beiträge annehmen können und Sie in diesem Fall eine Urheberangabe erhalten. Aktive Mitwirkende werden möglicherweise gebeten, dem Kernteam beizutreten, und erhalten die Möglichkeit, Pull-Anfragen zusammenzuführen.

Verhaltenskodex

Dieses Projekt hält sich an den Verhaltenskodex des Contributor Covenant. Durch Ihre Teilnahme wird von Ihnen erwartet, dass Sie diesen Kodex einhalten. Bitte melden Sie inakzeptables Verhalten an [email protected].

Kodexkonventionen und Housekeeping

Nichts davon ist für eine Pull-Anfrage unbedingt erforderlich, aber sie werden alle hilfreich sein. Sie können auch nach der ursprünglichen Pull-Anfrage, aber vor einer Zusammenführung hinzugefügt werden.

Verwenden Sie die Codeformatkonventionen des Spring Framework. Wenn Sie Eclipse verwenden, können Sie Formatierungseinstellungen mithilfe der Datei eclipse-code-formatter.xml aus dem Spring Cloud Build-Projekt importieren. Wenn Sie IntelliJ verwenden, können Sie das Eclipse Code Formatter Plugin verwenden, um dieselbe Datei zu importieren.
Stellen Sie sicher, dass alle neuen .java -Dateien einen einfachen Javadoc-Klassenkommentar mit mindestens einem @author -Tag zur Identifizierung Ihrer Person und vorzugsweise mindestens einem Absatz darüber haben, wofür die Klasse gedacht ist.
Fügen Sie den ASF-Lizenz-Header-Kommentar zu allen neuen .java Dateien hinzu (kopieren Sie ihn aus vorhandenen Dateien im Projekt).
Fügen Sie sich selbst als @author zu den .java-Dateien hinzu, die Sie erheblich ändern (mehr als nur kosmetische Änderungen).
Fügen Sie einige Javadocs und, wenn Sie den Namespace ändern, einige XSD-Dokumentelemente hinzu.
Ein paar Unit-Tests würden auch sehr helfen – jemand muss es tun.
Wenn niemand sonst Ihren Zweig verwendet, stellen Sie ihn bitte auf den aktuellen Hauptzweig (oder einen anderen Zielzweig im Hauptprojekt) um.
Befolgen Sie beim Schreiben einer Commit-Nachricht bitte diese Konventionen. Wenn Sie ein bestehendes Problem beheben, fügen Sie bitte Fixes gh-XXXX am Ende der Commit-Nachricht hinzu (wobei XXXX die Problemnummer ist).

Karostil

Spring Cloud Build enthält eine Reihe von Checkstyle-Regeln. Sie finden sie im Modul spring-cloud-build-tools . Die bemerkenswertesten Dateien unter dem Modul sind:

spring-cloud-build-tools/

 └── src
   ├── Karostil
   │ └── checkstyle-suppressions.xml (3)
   └── Haupt
   └── Ressourcen
   ├── checkstyle-header.txt (2)
   └── checkstyle.xml (1)

Standard-Checkstyle-Regeln
Datei-Header-Setup
Standardunterdrückungsregeln

Checkstyle-Konfiguration

Checkstyle-Regeln sind standardmäßig deaktiviert . Um Ihrem Projekt Checkstyle hinzuzufügen, definieren Sie einfach die folgenden Eigenschaften und Plugins.

pom.xml

 <Eigenschaften>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
        <maven-checkstyle-plugin.failsOnViolation>true
        </maven-checkstyle-plugin.failsOnViolation> (2)
        <maven-checkstyle-plugin.includeTestSourceDirectory>true
        </maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</properties>

<Build>
        <Plugins>
            <plugin> (4)
                <groupId>io.spring.javaformat</groupId>
                <artifactId>spring-javaformat-maven-plugin</artifactId>
            </plugin>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>

    <Berichterstattung>
        <Plugins>
            <plugin> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>
</build>

Der Build schlägt aufgrund von Checkstyle-Fehlern fehl
Der Build schlägt aufgrund von Checkstyle-Verstößen fehl
Checkstyle analysiert auch die Testquellen
Fügen Sie das Spring Java Format-Plugin hinzu, das Ihren Code neu formatiert, um die meisten Checkstyle-Formatierungsregeln zu erfüllen
Fügen Sie das Checkstyle-Plugin zu Ihren Build- und Berichtsphasen hinzu

Wenn Sie einige Regeln unterdrücken müssen (z. B. muss die Zeilenlänge länger sein), dann reicht es aus, wenn Sie unter ${project.root}/src/checkstyle/checkstyle-suppressions.xml eine Datei mit Ihren Unterdrückungen definieren. Beispiel:

projectRoot/src/checkstyle/checkstyle-suppresions.xml

 <?xml version="1.0"?>
<!DOCTYPE unterdrückt PUBLIC
		"-//Puppy Crawl//DTD Suppressions 1.1//EN"
		„https://www.puppycrawl.com/dtds/suppressions_1_1.dtd“>
<Unterdrückungen>
	<suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/>
	<suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/>
</suppressions>

Es empfiehlt sich ${spring-cloud-build.rootFolder}/.editorconfig und ${spring-cloud-build.rootFolder}/.springformat in Ihr Projekt zu kopieren. Auf diese Weise werden einige Standardformatierungsregeln angewendet. Sie können dies tun, indem Sie dieses Skript ausführen:

$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformat

IDE-Setup

Intellij-IDEE

Um Intellij einzurichten, sollten Sie unsere Codierungskonventionen und Inspektionsprofile importieren und das Checkstyle-Plugin einrichten. Die folgenden Dateien finden Sie im Spring Cloud Build-Projekt.

spring-cloud-build-tools/

 └── src
   ├── Karostil
   │ └── checkstyle-suppressions.xml (3)
   └── Haupt
   └── Ressourcen
   ├── checkstyle-header.txt (2)
   ├── checkstyle.xml (1)
   └── intellij
     ├── Intellij_Project_Defaults.xml (4)
     └── Intellij_Spring_Boot_Java_Conventions.xml (5)

Standard-Checkstyle-Regeln
Datei-Header-Setup
Standardunterdrückungsregeln
Projektstandards für Intellij, die die meisten Checkstyle-Regeln anwenden
Projektstilkonventionen für Intellij, die die meisten Checkstyle-Regeln anwenden

Abbildung 1. Codestil

Gehen Sie zu File → Settings → Editor → Code style . Klicken Sie dort auf das Symbol neben dem Abschnitt Scheme . Klicken Sie dort auf den Wert Import Scheme und wählen Sie die Option Intellij IDEA code style XML aus. Importieren Sie die Datei spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml .

Abbildung 2. Inspektionsprofile

Gehen Sie zu File → Settings → Editor → Inspections . Klicken Sie dort auf das Symbol neben dem Abschnitt Profile . Klicken Sie dort auf das Import Profile und importieren Sie die Datei spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml .

Karostil

Damit Intellij mit Checkstyle funktioniert, müssen Sie das Checkstyle Plugin installieren. Es empfiehlt sich, auch Assertions2Assertj zu installieren, um die JUnit-Assertionen automatisch zu konvertieren

Gehen Sie zu File → Settings → Other settings → Checkstyle . Klicken Sie dort im Abschnitt Configuration file auf das + -Symbol. Dort müssen Sie definieren, woher die Checkstyle-Regeln ausgewählt werden sollen. Im Bild oben haben wir die Regeln aus dem geklonten Spring Cloud Build-Repository ausgewählt. Sie können jedoch auf das GitHub-Repository von Spring Cloud Build verweisen (z. B. für checkstyle.xml : https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml ). Wir müssen die folgenden Variablen bereitstellen:

checkstyle.header.file – verweisen Sie bitte auf die Datei spring-cloud-build-tools/src/main/resources/checkstyle-header.txt von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt URL.
checkstyle.suppressions.file – Standardunterdrückungen. Bitte verweisen Sie auf die Datei spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml von Spring Cloud Build, entweder in Ihrem geklonten Repository oder über https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml URL.
checkstyle.additional.suppressions.file – diese Variable entspricht Unterdrückungen in Ihrem lokalen Projekt. Sie arbeiten beispielsweise an spring-cloud-contract . Zeigen Sie dann auf den Ordner project-root/src/checkstyle/checkstyle-suppressions.xml . Ein Beispiel für spring-cloud-contract wäre: /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml .

Wichtig

Denken Sie daran, den Scan Scope auf All sources festzulegen, da wir Checkstyle-Regeln für Produktions- und Testquellen anwenden.

Duplikat-Finder

Spring Cloud Build bringt das basepom:duplicate-finder-maven-plugin mit, das die Kennzeichnung doppelter und widersprüchlicher Klassen und Ressourcen im Java-Klassenpfad ermöglicht.

Doppelte Finder-Konfiguration

Der Duplikat-Finder ist standardmäßig aktiviert und wird in der verify Ihres Maven-Builds ausgeführt. Er wird jedoch nur dann in Ihrem Projekt wirksam, wenn Sie das duplicate-finder-maven-plugin zum build Abschnitt der pom.xml des Projekts hinzufügen.

pom.xml

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
        </ plugin >
    </ plugins >
</ build >

Für andere Eigenschaften haben wir die in der Plugin-Dokumentation aufgeführten Standardwerte festgelegt.

Sie können sie leicht überschreiben, indem Sie den Wert der ausgewählten Eigenschaft mit dem Präfix duplicate-finder-maven-plugin festlegen. Setzen Sie beispielsweise duplicate-finder-maven-plugin.skip auf true um die Duplikatprüfung in Ihrem Build zu überspringen.

Wenn Sie ignoredClassPatterns oder ignoredResourcePatterns zu Ihrem Setup hinzufügen müssen, stellen Sie sicher, dass Sie diese im Abschnitt „Plugin-Konfiguration“ Ihres Projekts hinzufügen:

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
            < configuration >
                < ignoredClassPatterns >
                    < ignoredClassPattern >org.joda.time.base.BaseDateTime</ ignoredClassPattern >
                    < ignoredClassPattern >.*module-info</ ignoredClassPattern >
                </ ignoredClassPatterns >
                < ignoredResourcePatterns >
                    < ignoredResourcePattern >changelog.txt</ ignoredResourcePattern >
                </ ignoredResourcePatterns >
            </ configuration >
        </ plugin >
    </ plugins >
</ build >