Can spring-cloud-config be configured to have more than one config server? So that if one would fail, it would fall back to another one?
If that is possible, and the 2 severs are using filesystem instead of git, is there a sync between those, or do both have to be updated manually?
I did not find this directly in config server. But you can use discovery service as eureka and have as many config server instances as you want: http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#eureka-first-bootstrap
From docs: "To scale the Config Server up and make it highly available, you would need to have all instances of the server pointing to the same repository, so only a shared file system would work. " you can use rsync for that.
Related
I deployed a Laravel application on AWS Elasticbeanstalk.
I want to incorporate caching with Redis as my cache driver as well as Elasticsearch.
I managed to run these 2 features locally (redis on port 6379 and elasticsearch on 9200),
but now I want them to run on remote servers and I simply specify their endpoints in my .env file.
Can anyone let me know how I can obtain remote URLs for Redis and Elasticsearch?
Update:
I found out that Heruko offers the ability to create a Redis instance and thereby one can obtain a URL for Redis. I presume a similar thing is for Elasticsearch.
If this is not the right way to do so, please let me know how it works
I've been using DDev for the last six months or so. It has greatly improved my efficiency. Thanks!
I'm looking for a better way to integrate multiple sites running on separate containers. The recommended solution is to use the internal container references (e.g. ddev-projectname-web). This does not work one of my projects because the destination site relies on a matching hostname for authentication.
Scenario: SiteA communicates with SiteB via REST.
SiteA
Project-name: sitea
Hostname: sitea.ddev.site
Container reference: ddev-sitea-web
SiteB
Project-name: siteb
Hostname: siteb.ddev.site
Container reference: ddev-siteb-web
In order to authenticate with SiteB (tcp or rest), the hostname must be consistent, in this case siteb.ddev.site, so ddev-siteb-web does not work.
My current workaround is to use the SiteB hostname in REST calls from SiteA AND add internal IP to /etc/hosts on SiteA web (something like 172.1.0.1 siteb.ddev.site). I'm looking for a better solution because the hosts configuration is lost when I stop/restart SiteA and/or the IP changes when I stop/restart SiteB.
One theoretical option is a configuration setting that specifies another running docker instance and automatically adds that IP address and hostname to the integrated site's /etc/hosts file.
Thanks!
Different projects can talk to each other in two ways.
The first way is by using the container name directly, and I think that's what you were doing here.
But there's an alternate way (see FAQ - latest. You just need to add a docker-compose.comm.yaml to the client project's .ddev directory like this:
version: '3.6'
services:
web:
external_links:
- "ddev-router:otherproject.ddev.site"
That way you can use the canonical name of the other site for communications. This only works for HTTP/S traffic, because it's going through the ddev-router, which is a reverse proxy.
I've looked over most of the documentation provided, couldn't find an absolute answer about changing jhipster-registry port, it's default is 8761, but when I try to chnage it's port through YAML config file it gets indeed working in that port but both the gateway and microservice cannot be found by the registry. am i doing anything wrong ? is jhipster-registry bound to remain intact when it comes to port manipulation ?
You must change port in spring.cloud.config.uri in all application's bootstrap*.yml so they can retrieve their config from the registry and also change it in eureka.client.defaultZone in application.yml in jhipster-registry's central-config folder if you use file system backend or in git repo if you use git backend.
This is because the registry is both a Spring Cloud Config server and an Eureka server. In JHipster's setup, the applications first connect to the config server, retrieve their config which indicate the URL of the Eureka server. As this is a common config for all apps, it's set in application*.yml in config server.
Please read also the jhipster-registry doc: https://www.jhipster.tech/jhipster-registry/
I have setup a JMeter client and server , following the instructions in the documentation .
I could successfully invoke transactions locally as well remotely .
Now I want to increase the number of JMeter servers
added the server Ip and port in jmeter.properties
made an entry in server rmi config file
started the client
When I start the server , it starts but does not refer to the rmi server config , in logs it says
jmeter.Launcher$Companion.prepareJMeterArguments$jmeter - No rmi server mapping found, using default server.rmi.localport - assuming no ssh tunnelling in effect
The command used to run server:
java -jar jmeter-corda-4.0-capsule.jar -XjmeterProperties jmeter.properties -XrverRmiMappings sample-server-rmi.config -- -s
Any config has to be modified? other then the remote_hosts and server rmi config file?
I'd say to take a look at the jmeter page on the docs to double check whether any of the config options to see if any of them have changed. (https://docs.corda.net/docs/corda-enterprise/4.4/performance-testing/running-jmeter-corda.html#running-jmeter-corda)
So this is a feature that only works on corda enterprise and NOT on corda open source, if you're paying R3 for it you should have a contact for enterprise support that should be able to help you with the small stuff like this.
Worth mentioning as well that there's new releases of corda (now 4.5) so you might want to take a look at that as well to see if your issue has been fixed already.
I am using Spring Cloud Config Server connected to Eureka Server with BitBucket git repository.
I found out under debugger that org.eclipse.jgit.api.PullCommand#call is being invoked via scheduler each time Config Server is updating it's status with Eureka.
Moreover, it's invoked each time connected services are querying for the updated config, and even each time /health endpoint is requested on Spring Cloud Config Server or on the connected client.
I believe it's a big overhead in terms of HTTP response time, but also in terms of the outgoing traffic.
Is there a way to update locally cloned repository less often?
P.S. I know that there is a File System Backend, or I can point Config Server into manually cloned local (i.e., file:///) repository. But I wonder if there is such a functionality out of the box.
You can turn off the health indicator on config server, via spring.cloud.config.server.health.enabled=false and health.config.enabled=false on the config client. Requests to config server always clone, so you need to turn down or disable health checks.