spring cloud config
4.2.0
Spring Cloud Config Server oferece os seguintes benefícios:
API baseada em recursos HTTP para configuração externa (pares nome-valor ou conteúdo YAML equivalente)
Criptografar e descriptografar valores de propriedade (simétricos ou assimétricos)
Incorporável facilmente em um aplicativo Spring Boot usando @EnableConfigServer
Especificamente para aplicações Spring, o Spring Cloud Config Client permite:
Vincule-se ao Config Server e inicialize o Spring Environment com fontes de propriedades remotas.
Criptografar e descriptografar valores de propriedade (simétricos ou assimétricos).
@RefreshScope para Spring @Beans que deseja ser reinicializado quando a configuração for alterada.
Use endpoints de gerenciamento:
/env para atualizar Environment e religar @ConfigurationProperties e níveis de log.
/refresh para atualizar os beans @RefreshScope .
/restart para reiniciar o contexto Spring (desabilitado por padrão).
/pause e /resume para chamar os métodos Lifecycle ( stop() e start() no ApplicationContext ).
Contexto do aplicativo Bootstrap: um contexto pai para o aplicativo principal que pode ser treinado para fazer qualquer coisa (por padrão, ele se vincula ao Config Server e descriptografa os valores das propriedades).
Você pode encontrar um exemplo de aplicativo aqui. É um aplicativo Spring Boot, então você pode executá-lo usando os mecanismos usuais (por exemplo, mvn spring-boot:run ). Quando executado, ele procura o servidor de configuração em http://localhost:8888 (um padrão configurável), para que você também possa executar o servidor para ver tudo funcionando junto.
A amostra possui um caso de teste em que o servidor de configuração também é iniciado na mesma JVM (com uma porta diferente) e o teste afirma que uma propriedade de ambiente do repositório de configuração git está presente. Para alterar a localização do servidor de configuração, você pode definir spring.cloud.config.uri em bootstrap.yml (ou nas propriedades do sistema e outros locais).
O caso de teste possui um método main() que executa o servidor da mesma maneira (observe os logs de sua porta), para que você possa executar todo o sistema em um processo e brincar com ele (por exemplo, você pode executar o main() em seu IDE). O método main() usa target/config para o diretório de trabalho do repositório git, para que você possa fazer alterações locais lá e vê-las refletidas no aplicativo em execução. O exemplo a seguir mostra uma sessão de ajustes no caso de teste:
$ curl localhost:8080/env/sample meu teste $ vi target/config/mytest.properties .. altere o valor de "amostra", opcionalmente confirme $ curl -X POST localhost:8080/atualização ["amostra"] $ curl localhost:8080/env/sample amostraValor
O endpoint de atualização informa que a propriedade "sample" foi alterada.
Para construir o código-fonte você precisará instalar o JDK 17.
Spring Cloud usa Maven para a maioria das atividades relacionadas à construção, e você deve conseguir decolar rapidamente clonando o projeto no qual está interessado e digitando
$ ./mvnw instalar
Observação | Você também pode instalar o Maven (>=3.3.3) e executar o comando mvn no lugar de ./mvnw nos exemplos abaixo. Se você fizer isso, também poderá precisar adicionar -P spring se suas configurações locais do Maven não contiverem declarações de repositório para artefatos de pré-lançamento do Spring. |
Observação | Esteja ciente de que pode ser necessário aumentar a quantidade de memória disponível para o Maven definindo uma variável de ambiente MAVEN_OPTS com um valor como -Xmx512m -XX:MaxPermSize=128m . Tentamos cobrir isso na configuração .mvn , portanto, se você achar que precisa fazer isso para que uma compilação seja bem-sucedida, crie um ticket para que as configurações sejam adicionadas ao controle de origem. |
Os projetos que exigem middleware (ou seja, Redis) para teste geralmente exigem que uma instância local do [Docker](https://www.docker.com/get-started) esteja instalada e em execução.
O módulo spring-cloud-build tem um perfil "docs" e, se você ativá-lo, ele tentará construir fontes asciidoc usando Antora em modules/ROOT/ .
Como parte desse processo, ele irá procurar por docs/src/main/asciidoc/README.adoc e processá-lo carregando todas as inclusões, mas não analisando ou renderizando-o, apenas copiando-o para ${main.basedir} (o padrão é ${basedir} , ou seja, a raiz do projeto). Se houver alguma alteração no README, ele aparecerá após a construção do Maven como um arquivo modificado no local correto. Apenas confirme e empurre a mudança.
Se você não tiver uma preferência de IDE, recomendamos usar Spring Tools Suite ou Eclipse ao trabalhar com o código. Usamos o plugin m2eclipse eclipse para suporte maven. Outros IDEs e ferramentas também devem funcionar sem problemas, desde que usem o Maven 3.3.3 ou superior.
Os projetos Spring Cloud exigem que o perfil Maven 'spring' seja ativado para resolver o marco do Spring e os repositórios de snapshots. Use seu IDE preferido para definir esse perfil como ativo ou você poderá enfrentar erros de compilação.
Recomendamos o plugin m2eclipse eclipse ao trabalhar com o eclipse. Se você ainda não possui o m2eclipse instalado, ele está disponível no "mercado Eclipse".
Observação | Versões mais antigas do m2e não suportam o Maven 3.3, portanto, depois que os projetos forem importados para o Eclipse, você também precisará informar ao m2Eclipse para usar o perfil correto para os projetos. Se você encontrar muitos erros diferentes relacionados aos POMs nos projetos, verifique se possui uma instalação atualizada. Se você não conseguir atualizar o m2e, adicione o perfil "spring" ao seu settings.xml . Alternativamente, você pode copiar as configurações do repositório do perfil "spring" do pom pai para o seu settings.xml . |
Se preferir não usar m2eclipse você pode gerar metadados do projeto Eclipse usando o seguinte comando:
$ ./mvnw eclipse:eclipse
Os projetos Eclipse gerados podem ser importados selecionando import existing projects no menu file .
Se você receber uma exceção devido ao "tamanho de chave ilegal" e estiver usando o JDK da Sun, será necessário instalar os arquivos de política de jurisdição de força ilimitada do Java Cryptography Extension (JCE). Consulte os links a seguir para obter mais informações:
Java 6JCE
Java 7JCE
Java 8JCE
Extraia os arquivos JCE na pasta JDK/jre/lib/security para qualquer versão do JRE/JDK x64/x86 que você usar.
Spring Cloud é lançado sob a licença não restritiva Apache 2.0 e segue um processo de desenvolvimento muito padrão do Github, usando o rastreador do Github para problemas e mesclando solicitações pull no principal. Se você quiser contribuir, mesmo que seja algo trivial, não hesite, mas siga as orientações abaixo.
Antes de aceitarmos um patch não trivial ou uma solicitação pull, precisaremos que você assine o Contrato de Licença de Colaborador. Assinar o acordo do contribuidor não concede a ninguém direitos de commit no repositório principal, mas significa que podemos aceitar suas contribuições, e você receberá um crédito de autor se o fizermos. Contribuidores ativos podem ser convidados a ingressar na equipe principal e ter a capacidade de mesclar solicitações pull.
Este projeto segue o código de conduta do Contributor Covenant. Ao participar, espera-se que você cumpra este código. Por favor, relate comportamento inaceitável para [email protected].
Nada disso é essencial para uma solicitação pull, mas todos ajudarão. Eles também podem ser adicionados após a solicitação pull original, mas antes de uma mesclagem.
Use as convenções de formato de código do Spring Framework. Se você usar o Eclipse, poderá importar as configurações do formatador usando o arquivo eclipse-code-formatter.xml do projeto Spring Cloud Build. Se estiver usando o IntelliJ, você pode usar o plug-in Eclipse Code Formatter para importar o mesmo arquivo.
Certifique-se de que todos os novos arquivos .java tenham um comentário simples da classe Javadoc com pelo menos uma tag @author identificando você e, de preferência, pelo menos um parágrafo sobre a finalidade da classe.
Adicione o comentário do cabeçalho da licença ASF a todos os novos arquivos .java (copie dos arquivos existentes no projeto)
Adicione-se como @author aos arquivos .java que você modifica substancialmente (mais do que alterações cosméticas).
Adicione alguns Javadocs e, se você alterar o namespace, alguns elementos do documento XSD.
Alguns testes unitários também ajudariam muito — alguém tem que fazer isso.
Se ninguém mais estiver usando seu branch, faça o rebase dele no main atual (ou outro branch de destino no projeto principal).
Ao escrever uma mensagem de commit, siga estas convenções. Se você estiver corrigindo um problema existente, adicione Fixes gh-XXXX no final da mensagem de commit (onde XXXX é o número do problema).
Spring Cloud Build vem com um conjunto de regras de estilo de verificação. Você pode encontrá-los no módulo spring-cloud-build-tools . Os arquivos mais notáveis do módulo são:
└── src ├── estilo de verificação │ └── checkstyle-suppressions.xml (3) └── principal └── recursos ├── checkstyle-header.txt (2) └── estilo de verificação.xml (1)
Regras de estilo de verificação padrão
Configuração do cabeçalho do arquivo
Regras de supressão padrão
As regras de estilo de verificação estão desativadas por padrão . Para adicionar checkstyle ao seu projeto basta definir as seguintes propriedades e plugins.
<propriedades>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
<maven-checkstyle-plugin.failsOnViolation>verdadeiro
</maven-checkstyle-plugin.failsOnViolation> (2)
<maven-checkstyle-plugin.includeTestSourceDirectory>verdadeiro
</maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</propriedades>
<construir>
<plug-ins>
<plug-in> (4)
<groupId>io.spring.javaformat</groupId>
<artifactId>spring-javaformat-maven-plugin</artifactId>
</plugin>
<plug-in> (5)
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
</plugins>
<relatório>
<plug-ins>
<plug-in> (5)
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
</plugins>
</relatório>
</build>Falha na compilação com base em erros de Checkstyle
Falha na compilação com base em violações do Checkstyle
Checkstyle analisa também as fontes de teste
Adicione o plugin Spring Java Format que irá reformatar seu código para passar a maioria das regras de formatação Checkstyle
Adicione o plugin checkstyle às suas fases de construção e relatório
Se você precisar suprimir algumas regras (por exemplo, o comprimento da linha precisa ser maior), basta definir um arquivo em ${project.root}/src/checkstyle/checkstyle-suppressions.xml com suas supressões. Exemplo:
<?xml versão="1.0"?> <!DOCTYPE supressões PUBLIC "-// Rastreamento de filhotes // Supressões de DTD 1.1 // EN" "https://www.puppycrawl.com/dtds/suppressions_1_1.dtd"> <supressões> <suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/> <suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/> </supressões>
É aconselhável copiar ${spring-cloud-build.rootFolder}/.editorconfig e ${spring-cloud-build.rootFolder}/.springformat para o seu projeto. Dessa forma, algumas regras de formatação padrão serão aplicadas. Você pode fazer isso executando este script:
$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformatPara configurar o Intellij você deve importar nossas convenções de codificação, perfis de inspeção e configurar o plugin checkstyle. Os arquivos a seguir podem ser encontrados no projeto Spring Cloud Build.
└── src
├── estilo de verificação
│ └── checkstyle-suppressions.xml (3)
└── principal
└── recursos
├── checkstyle-header.txt (2)
├── estilo de verificação.xml (1)
└── inteligência
├── Intellij_Project_Defaults.xml (4)
└── Intellij_Spring_Boot_Java_Conventions.xml (5)Regras de estilo de verificação padrão
Configuração do cabeçalho do arquivo
Regras de supressão padrão
Padrões de projeto para Intellij que aplicam a maioria das regras Checkstyle
Convenções de estilo de projeto para Intellij que aplicam a maioria das regras do Checkstyle
Vá para File → Settings → Editor → Code style . Clique no ícone ao lado da seção Scheme . Lá, clique no valor Import Scheme e escolha a opção Intellij IDEA code style XML . Importe o arquivo spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml .
Vá para File → Settings → Editor → Inspections . Clique no ícone ao lado da seção Profile . Lá, clique em Import Profile e importe o arquivo spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml .
Para que o Intellij funcione com Checkstyle, você deve instalar o plugin Checkstyle . É aconselhável instalar também o Assertions2Assertj para converter automaticamente as asserções JUnit
Vá para File → Settings → Other settings → Checkstyle . Clique no ícone + na seção Configuration file . Lá, você terá que definir de onde as regras de checkstyle devem ser escolhidas. Na imagem acima, escolhemos as regras do repositório clonado do Spring Cloud Build. No entanto, você pode apontar para o repositório GitHub do Spring Cloud Build (por exemplo, para checkstyle.xml : https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml ). Precisamos fornecer as seguintes variáveis:
checkstyle.header.file - aponte-o para o arquivo Spring Cloud Build, spring-cloud-build-tools/src/main/resources/checkstyle-header.txt em seu repositório clonado ou por meio do https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt URL.
checkstyle.suppressions.file - supressões padrão. Aponte-o para o arquivo spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml Spring Cloud Build em seu repositório clonado ou por meio de https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml URL.
checkstyle.additional.suppressions.file - esta variável corresponde às supressões em seu projeto local. Por exemplo, você está trabalhando em spring-cloud-contract . Em seguida, aponte para a pasta project-root/src/checkstyle/checkstyle-suppressions.xml . Um exemplo de spring-cloud-contract seria: /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml .
Importante | Lembre-se de definir o Scan Scope como All sources pois aplicamos regras de estilo de verificação para fontes de produção e de teste. |
Spring Cloud Build traz basepom:duplicate-finder-maven-plugin , que permite sinalizar classes e recursos duplicados e conflitantes no caminho de classe java.
O localizador de duplicatas está habilitado por padrão e será executado na fase verify da sua construção do Maven, mas só terá efeito no seu projeto se você adicionar o duplicate-finder-maven-plugin à seção build do pom.xml do projeto.
< build >
< plugins >
< plugin >
< groupId >org.basepom.maven</ groupId >
< artifactId >duplicate-finder-maven-plugin</ artifactId >
</ plugin >
</ plugins >
</ build >Para outras propriedades, definimos padrões conforme listado na documentação do plugin.
Você pode substituí-los facilmente, mas definindo o valor da propriedade selecionada prefixada com duplicate-finder-maven-plugin . Por exemplo, defina duplicate-finder-maven-plugin.skip como true para ignorar a verificação de duplicatas em sua compilação.
Se você precisar adicionar ignoredClassPatterns ou ignoredResourcePatterns à sua configuração, certifique-se de adicioná-los na seção de configuração do plugin do seu projeto:
< 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 >
