I want to use dev services to start postgres db on local application startup (quarkus profile = local).
Dev services are active in test and dev mode, so by not defining quarkus.datasource.jdbc.url it is actually working already with following config:
quarkus.datasource.db-kind=postgresql
quarkus.datasource.devservices.port=5432
quarkus.datasource.username=postgres
quarkus.datasource.password=postgres
However, I don't know how to configure this besides a prod configuration which has a quarkus.datasource.jdbc.url defined e.g.
%local.quarkus.datasource.devservices.enabled=true
%local.quarkus.datasource.db-kind=postgresql
%local.quarkus.datasource.devservices.port=5432
%local.quarkus.datasource.username=postgres
%local.quarkus.datasource.password=postgres
quarkus.datasource.db-kind=postgresql
quarkus.datasource.jdbc.url=jdbc:postgresql://myProdDB.com:5432/mydb
If I start the application with quarkus profile = local, instead of spinning up postgres on docker, quarkus falls back to the prod property quarkus.datasource.jdbc.url which I don't want for my local dev environment.
If I prefix the prod properties with a prod profile like %prod.quarkus.datasource.jdbc.url this fallback can be prevented, however, I want to follow the convention that prod properties are default, thus not prefixed with profile.
I already tried without success to somehow set %local.quarkus.datasource.jdbc.url to an empty value to prevent fallback to quarkus.datasource.jdbc.url:
%local.quarkus.datasource.jdbc.url="" -> java.sql.SQLException: Driver does not support the provided URL: ""
%local.quarkus.datasource.jdbc.url=null -> java.sql.SQLException: Driver does not support the provided URL: null
%local.quarkus.datasource.jdbc.url= -> io.quarkus.runtime.configuration.ConfigurationException: Model classes are defined for the default persistence unit default but configured datasource default not found: the default EntityManagerFactory will not be created. To solve this, configure the default datasource. Refer to https://quarkus.io/guides/datasource for guidance.
Related
I am using ASP.NET Core 5.0 and I have a Web API app deployed to internal cloud where few settings like DB are controlled via environment variables on the host cloud. In my Startup.cs I have the below code
string projectDbConnection = Configuration.GetSection("ProjectDatabaseSettings").GetValue<string>("PROJECT_DB_CONNECTION");
string projectDbName = Configuration.GetSection("ProjectDatabaseSettings").GetValue<string>("PROJECT_DB_NAME");
Here as I understand, when running locally in IIS Express it looks for appsettings.<Environment>.json and they take precedence over appsettings.json values.
But this app is always connecting to the wrong DB when I deployed to Cloud where I mentioned the PROJECT_DB_CONNECTION & PROJECT_DB_NAME as Environment variables for the app.
To make the app read from the Environment variables I had to change the above Code in Startup.cs as
string projectDbConnection = Configuration.GetValue<string>("PROJECT_DB_CONNECTION");
string projectDbName = Configuration.GetValue<string>("PROJECT_DB_NAME");
I am unable to understand the difference between the GetSection.GetValue and just GetValue and why I should use Configuration.GetValue() to direct app to read from Env variables.
what am I missing and when should we use what?
Naming of environment variables
There is kind of a naming convention in the environment variables for nested appsettings to env vars, see naming of environment variables.
Each element in the hierarchy is separated by a double underscore.
In your case it would work if you name the env variable: ProjectDatabaseSettings__PROJECT_DB_CONNECTION.
Config Order
Regarding to Microsoft Documentation there is a order in which the config sources are checked.
ChainedConfigurationProvider : Adds an existing IConfiguration as a source. In the default configuration case, adds the host configuration and setting it as the first source for the app configuration.
appsettings.json using the JSON configuration provider.
appsettings.Environment.json using the JSON configuration provider. For example, appsettings.Production.json and appsettings.Development.json.
App secrets when the app runs in the Development environment.
Environment variables using the Environment Variables configuration provider.
Command-line arguments using the Command-line configuration provider.
The usecase
This is useful when you are developing local using appsettings.json, but run in a cluster or cloud in production where it is more convenient to use environment variables (f.e.: in kubernetes environment variables are set via config maps).
Is there a way to specify a postgresql database name to connect to in the cloud foundry manifest.yml file? I've been raking through the documentation and haven't yet found this specific information.
I'm imagining something like this:
applications:
- name: my-app
routes:
- route: my-app.mybluemix.net
services:
- postgres
dbname: database2
With that approach, a postgresql connection can be made by just the connection string provided by VCAP_SERVICES parsing modules (cfenv in the case of node).
If this is not possible, I will just set a dbname environment variable and build my own connection string.
There is nothing like that in a Cloud Foundry application manifest.yml.
The manifest.yml only takes a list of service instance names and the services with those names will be bound to your app. It does not allow you set other metadata.
https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html#services-block
I don't know if these will help, but when you cf bind-service directly there are two additional provisions you can make use of (these are not supported by manifest.yml as of me writing this):
Arbitrary bind parameters. These probably won't help unless your service broker supports them, but it's a way to pass additional info to the service broker. If your broker supported it, you could in theory say give me a database named XYZ by passing it some config this way.
Named service bindings. This provides what amounts to a second name. The intent is that you can create the service with a name of X, but your application can look for a service binding with name Y. You can use this to swap in differently named services, but still expose the same binding name to the application so it will always find the service.
If you are trying to pass in some other service instance related metadata to your application, you'd need to do it some other way. Like if you want to tell it the database name or the connection pool size, etc.. Using environment variables like you mentioned is one option. You could use a config file or cli arguments passed to your application. What you pick is probably a matter of preference/support in the library/framework you're using.
For what it's worth, most service brokers I've seen pass in and tell you a specific database name to use. If the broker said connect to db XYZ and you made your connection to myCoolDb, the connection would fail. Just wanted to mention this. Your mileage may vary.
I created a spring project in AWS codestar.
I would like to pass environment properties to my application (e.g. DATA_SOURCE_URL). I can do it in elastic beanstalk in "Configuration" -> "Software" "modify" and adding the properties. But whenever a new deployment is triggered this configuration gets reseted.
I was wondering what is the way of setting environment properties when using AWS codestar.
As it may help other people that search a solution
I finally get it to work by using the Saved Configuration function in Beanstalk, and calling it via the cloud formation template.yml : EBConfigurationTemplate (from the autogenerated template.yml by codestar)
EBConfigurationTemplate:
[...]
SourceConfiguration:
ApplicationName: !Ref 'EBApplication'
TemplateName: "Saved Configuration Name"
After that my django application was able to read the os.environ['ENV_VAR_NAME']
as well as django.config that was able to connect to an RDS (Non-managed by beanstalk) to do the migration as a container_command
what is the use of sling run modes property in sling.properties file?
I have a osgi felix bundle that installed onto aem admin bundle console through aem cq5 package manager.
**
configuration properties of one of the bundle service is not available
unless I put the following line in cq5/config/sling.properties file.
sling.run.modes=author,sandbox why is this so ? what is the importance
of sling.run.modes ?
**
Thank you,
Sri
Run modes allow you to tune your AEM instance for a specific purpose; for example author or publish, test, development, intranet or others.
Exampe: For dev: sling.run.modes=author,dev
use of run mode is, example - i have a config.author.prod and config.author.dev in crxd/e. Based on the run mode instance, the OSGI Bundle will pick the corresponding config.author.dev or prod configuration settings defined in nt:unstructured and start working.
Ref: https://docs.adobe.com/docs/en/cq/5-6-1/deploying/configure_runmodes.html
Ref: https://helpx.adobe.com/experience-manager/kb/RunModeDependentConfigAndInstall.html
Define a respository-based configuration for a single instance
There are two ways to configure CQ5.
Configure the Apache Felix Web Management Console
The configuration on the Apache Felix Web Management Console (http://:/system/console/configMgr) is always specific for the current instance.
You can find a description in the documentation: http://dev.day.com/content/docs/v5_2/html-resources/cq5_guide_system_administrator/ch05s03.html
Repository-based configuration
It is also possible to store configuration in the CRX repository as nodes of nodetype sling:OsgiConfig.
For more information, see http://dev.day.com/content/docs/v5_2/html-resources/cq5_guide_system_administrator/ch05s02.html
With this method, it is possible to share configuration among several instances.
The name of these nodes must be equal to the Persistent Identity (PID) of the configuration (for example, the name of the service). If you look at http://:/system/console/config, you see these names listed as service.pid properties. These configuration nodes have to be child-nodes of nodetype nt:folder with a name starting with config followed with a dot. All the run-modes that the config applies to are also separated with a dot.
Examples: config.author, config.publish, config.author.dev, config.author.foo.dev, and so on.
In my play application the database settings are not known before startup of the application. I have to read them from an environment variable after automatic deployment and start of the application.
The platform the app is deployed on is cloudfoundry. And there is a environment variable called VCAP_SERVICES (that is a json string). Here are all services listed e.g. the database service including the credentials
Is there a prefered way to do so? In means of still being able to use stuff like:
DataSource ds = DB.getDatasource();