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/
Related
I have a fully functioning bootstrap project. Whenever I want to access it locally I go to localhost:8080
Now I would like to run it on my server under domain name websitename.com and I want to be able to access first page of my bootstrap project without having to type websitename.com:8080 and instead just type websitename.com/
Is there any way to configure the server to do so? Or is this bootstrap configuration?
You have to change your port from 8080 to 80. This is the default http port recognized by browsers.
To achieve that you have to add line
server.port = 80
to your application.properties config file (find details in the documentation)
Note: Depending on operation system usage of 80 port might be restricted to only root user. You'll probably have to run the app with sudo or set up http proxy.
We are having the following problem, when deploying several microservices, randomly sometimes one of them is registered in the registry with an incorrect IP. I understand that eureka is incorrectly identifying the IP of the container ...
We tested several solutions like this application.yml config, but we did not get it working properly. Any ideas?
eureka:
instance:
prefer-ip-address: true
hostname: ${server.address}
ip-address: ${server.address}
I saw this solution here: https://groups.google.com/d/msg/jhipster-dev/n7s7OTgT18E/RtZ3O4hlEwAJ
But this config throws "Could not resolve placeholder "server.address" in string value". This make sense when I read this: Reference a key in application.yml
#snowblind This is most probably a problem with docker container networking. Actually when doing initial registration, Eureka only uses what is available from inside the application. So it will determine it's address with something like java.net.InetAddress and then propagate this value to the Registry to advertize how the service can be reached. However in your case it seems to be reporting wrong informations.
So first make sure you always map the container port to the same host port. Alternatively you can use docker host networking (--net=host) so that your container share the same network interface as your host. This is possible in docker-compose by adding net: "host" to your service descption.
Another idea would be to use hostname based Eureka registration as opposed to the IP based one that we configure by default (prefer-ip-adress = true), but I cannot guarantee that it will work as I've never tried it myself, please refer to Eureka docs if you want to do this.
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.
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.
I have gitlab running behind a proxy, gitlab itself running on port 3000 not accessible from outside.
Mail notifications generated by gitlab always contain URLs with port 3000 in them, so where can I configure gitlab to generate links accessible from outside?
I already found
gitlab email setup
but I do not have email:host: or anything like that in my gitlab.yml
I'm running gitlab 5.2.0 right now.
EDIT: I would also appreciate any link to some info about the config options in gitlab.yml...
The setting is indeed in gitlab/config/gitlab.yml, it just isn't that clear anymore (config names and comments changed in gitlab 5.0 I think).
The section ## Web Server Settings is actually used to generate the links in emails. The only settings referring to emails are email_from: and support_email: but host:, port: and https: are also used for links in emails.
The actual IP and port settings can be found in puma.rb config file which is why I was confident enough to just tinker around with the gitlab.yml settings and it worked.
Solution for my problem: just comment the production:gitlab:port: setting or change it to your external port.