I am using flyway script to migrate the database.
In my project setup I have dev env scripts in the default location : /db/migration/
Also a specific location (under root) for pp scripts: /my_app/flyway_pp/
application-preprod.properties
spring.flyway.baseline-on-migrate = true
spring.flyway.locations=filesystem:/my_app/flyway-pp
My application runs as a image in kubernetes cluster. I have checked using classpath: and filesystem: both. But nothing is getting picked up from flyway_pp folder and instead it is picking up from default location always /db/migration/.
My doubt is may be in the kubernetes env it is not able to resolve the path correctly.
But what should I do in this case.
Related
I am trying to setup spring config cloud using local file system.
Below is my config on cloud server.
server.port=8888
spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=classpath:/
Bootstrap.properties on client app is as shown below
spring.application.name=hello-world
spring.cloud.config.uri=http://localhost:8888
management.endpoints.web.exposure.include=*
I have also created hello-world.yml on class path for the hello-world spring boot application with property, test: Hello World
Followed below steps to make use of config server.
Step 1: Update the config file and start cloud config server. Able to
see config http://localhost:8888/hello-world/default
Step 2: Start client app hello-world, client app able to read the
test property file from cloud config server.
Step 3: Make changes to config by updating test: Good Bye on
hello-world.yaml.
At this moment, if I check
http://localhost:8888/hello-world/default ,it still shows old value.
Step 4: Run /actuator/refresh on client app. But it won't detect
any change on config server.
The new changes are reflected only if I restart the cloud config server.
Is there any configuration issue causing the cloud config server to unable to listen to changes ?
I could see o.s.cloud.commons.util.InetUtils : Cannot determine local hostname INFO log on cloud config app.
First of all I followed the same exact steps you followed and got the same issue, after almost day of search and study on the matter found out the followings,
we shouldn't use classpath:/<whatever> for
spring.cloud.config.server.native.searchLocations
because when we use so and build the project and run the location refers to the directory inside the generated .jar file, so we will not be able to update it in runtime.
To confirm this you can stop config server, open you .jar archive and delete hello-world.yml file then try http://localhost:8888/hello-world/default you will get default null responses
So we have to use some other locations for spring.cloud.config.server.native.searchLocations either with full directory path or just directory from app running location
Examples
For full path in windows use file:///full-path
spring.cloud.config.server.native.searchLocations: file:///E:\configs
Just for a directory (which will search project root directory if you running from IDE, if running jar then target directory or jar location spring.cloud.config.server.native.searchLocations: configs
spring.cloud.config.server.native.searchLocations: configs\whatever
we can configure multiple locations too as follows, spring.cloud.config.server.native.searchLocations: file:///E:\configs, configs
I have cloned elasticsearch project from GitHub to my local machine. Built it successfully and imported it into eclipse.
When I am trying to run the main() method in org.elasticsearch.bootstrap.ElasticSearch class (which is the entry point for starting elasticsearch) getting the following error:
ERROR: the system property [es.path.conf] must be set
I tried setting the system variable ES_PATH_CONF to
E:\Elasticsearch\Github\elasticsearch-master\distribution\src\main\resources\config.
But it’s not working I am still getting the same error. Is the above location to ES_PATH_CONF variable correct? Is there any other way to solve this?
The location of the config directory can be set with following VM Option:
-Des.path.conf=/path/to/config/
Also, in your situation, it might be necessary to set the Elasticsearch path.home variable:
-Des.path.home=/path/to/elasticsearch/home/dir
I have written Ignite hello world program in Eclipse and want to connect it to localhost(127.0.0.1). But it is giving me error for example "ignite.xml file path is invalid"
I am starting ignition as follows,
try (Ignite ignite = Ignition.start("examples/config/example-ignite.xml")) {}
But I got error like:
Spring XML configuration path is invalid: examples/config/example-ignite.xml.
How do I fix it?
You have the following options:
Provide the absolute file path.
Set IGNITE_HOME system property or environment variable, put the file in this folder and provide the path relative to the home.
Add the configuration file on classpath under META-INF and provide the path relative to it.
The last option is usually the most convenient for the applications with an embedded Ignite node.
I want to run my NiFi application using ec2-user rather than default nifi user. I changed run.as=ec2-user in bootstrap.conf but it did not worked .It is not allowing me to start Nifi application getting following error while staring nifi service.
./nifi.sh start
nifi.sh: JAVA_HOME not set; results may vary
Java home:
NiFi home: /opt/nifi/current
Bootstrap Config File: /opt/nifi/current/conf/bootstrap.conf
User Runnug Nifi Application : sudo -u ec2-user
Error: Could not find or load main class org.apache.nifi.bootstrap.RunNiFi
Any pointer to this issue?
This is most likely a file permission problem, which is not covered by installing the service with nifi.sh install. A summary of the required permissions includes:
Read access to the entire distribution in the NIFI_HOME directory
Write access to the NIFI_HOME directory itself - NiFi will create a number of directories and files at runtime including logs, work, state, and various repositories.
Write access to the bin directory
Write access to the conf directory
Write access to the lib directory, and to all of the files in the lib directory
It is certainly possible to narrow the permissions by creating the working directories manually, and by adjusting NiFi's settings to rearrange the directory layout. But the permissions above should get you started.
I am using spring cloud config server to host a centralized location for all the property files configurations to be used in the project.
I tried using the config files from a local file system using below and it works fine:
spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file://${HOME}/Documents/test-config/cloud-config-properties/
I also used the git repo using: spring.cloud.config.server.git.uri=ssh://xxxxxx.com:7999/test/cloud-config-properties.git
I would like to try using a combination of this in my project.
Example - for dev/test profile - i would like to use from local filesystem and for the production - I would like to use Git repository.
I enabled both the git uri and native profiles in my application.properties in config server application. But the properties are always picked up from the local file system. Is this possible?
Not supported out of the box, however there is a workaround for this. You can define the basedir for the configuration server, which is where it saves the files it fetches from the remote server, by setting the property (in the config server):
spring.cloud.config.server.git.basedir=<your_dir>
If you are working with docker, you can map this directory to the host filesystem.
Now whatever file you put in there will be picked up by configuration-server if it matches any of the application/profile in the request. For example you could put a file there called application-dynamic.properties, and have all your clients use dynamic as the last profile, for example
spring.profiles.active=systesting,dynamic
This way everything you will put in application-dynamic.properties will override whatever is defined in your config repo.
One thing to notice though is that you need to add the file only after configuartion server starts, because it deletes this folder during startup.
Needles to say, it's not a good practice doing this in production (for example a restart will cause the file to be deleted), but for test/dev this is the best option.