We are using DropWizard v0.8.1 and we're wondering if we can have a YAML files with default values that will then get overridden by the specific environment file (such as dev.xml).
Spring boot works this way, where the application.yml file act as a template for default values and then application-dev.yml will override duplicate properties.
We don't want to duplicate all the repetitive properties and only want to update in one file the defaults.
You can write your own ConfigurationProvider that combines 2 InputStreams and use yaml merge directives
You can use a configuration management tool, such as Ansible, to manage your configurations files.
Set up a template .yml file, and substitute the variables per environment as needed.
Related
Is it possible somehow to do a general configuration for Eleventy so that 'my_file.html' in the input folder ends up just as 'my_file.html' in the _site folder, not '/my_file/index.html'?
I know I can do it on a file by file basis with permalinks. But I'd like it configured for the site as a whole, if possible.
Unfortunately, since this behavior isn't encouraged, there isn't a simple configuration option to disable the directory output.
However, since permalink is part of the data cascade, you can set a global default, and in combination with the filePathStem computed data, you can set the output to be .html files.
To set a permalink using a global data file, add a permalink.js file to your global _data directory.
// _data/permalink.js
module.exports = '/{{ page.filePathStem }}.html'
There is also a config global data option coming soon to v1.0.0. I am not sure if it will handle the {{ page.filePathStep }} preprocessing, but if it does, that could be an option too, especially since it will keep config-related things inside the config file.
Yes, you can control where Eleventy writes things out by specifying a permalink value in the front matter. This is covered here: https://www.11ty.dev/docs/permalinks/#remapping-output-(permalink)
An example would be:
---
permalink: "/my_file.html"
---
I'm creating a custom Fluent-Bit image and I want a "generic" configuration file that can work on multiple cases, i.e.: it should work with a forward input sometimes and with tail input some other times.
I thought about using environment variables so to only have one input but it seems we cannot set variables in the key part only on the value side (see following code).
When I set the corresponding environment variables in a docker-entrypoint file with corresponding conditions
export INPUT_PATH="/myLogPath"
export INPUT_PATH_TYPE="path"
export INPUT_NAME="tail"
[INPUT]
Name ${INPUT_NAME}
${INPUT_PATH_TYPE} ${INPUT_PATH}
This is the error message I got
[error] [config] tail: unknown configuration property '${INPUT_PATH_TYPE}'. The following properties are allowed: path, exclude_path, key, read_from_head, refresh_interval, watcher_interval, rotate_wait, docker_mode, docker_mode_flush, docker_mode_parser, path_key, ignore_older, buffer_chunk_size, buffer_max_size, skip_long_lines, exit_on_eof, parser, tag_regex, db, db.sync, db.locking, multiline, multiline_flush, parser_firstline, and parser_.
I'm looking for a way to make it dynamic so either to have a single file with dynamic configuration or multiple files which can be included dynamically (#Include requires a static filepath from what I've seen).
EDIT: the only option I see is to have multiple input files (for each use case) and call it dynamically when starting fluent-bit in the docker-entrypoint file
I use a docker-entrypoint and split the input, filters to different files and then depending of the environment variables in the entrypoint I create a symbolic link to the corresponding file
How would one define environment variables for traefik2 so that they could be used within the dynamic file configuration ? e.g:
[http.routers]
[http.routers.the-rtr]
entrypoints = https
rule = Host(`rtr.$DOMAINNAME`)
where DOMAINNAME would have been defined somewhere (in a file, CLI arguments etc.)
Traefik's dynamic configuration does accept Go templating:
Traefik supports using Go templating to automatically generate repetitive portions of configuration files. These sections must be valid Go templates, augmented with the Sprig template functions.
See https://doc.traefik.io/traefik/providers/file/#go-templating
Note that Go Templating only works with dedicated dynamic configuration files. Templating does not work in the Traefik main static configuration file.
For example, if $DOMAINNAME is set as an environment variable, you can do
rule: Host(`{{ env "DOMAINNAME" | trimAll "\"" }}`)
Note: due to "env" quoting, the trimAll is needed — it might be better solution, but it's the better I've found so far.
Not sure if it's directly supported from traefik product.
I use file provider and in traefik.toml, I have:
[providers.file]
filename = "/etc/traefik/dynamic.config.toml"
watch = true
And I use separate mechanism like envsubst to generate (or regenerate as needed) the dynamic.config.toml file. Since I've watch = true, it gets loaded with latest info by traefik
Basically, the snipped you shared in the question can be used as a template file. Then use envsubst or similar to generate dynamic.config.toml.
Q&A on envsubst that I found useful: How to substitute shell variables in complex text files
Hope that helps.
I want to read a variable from CSV and use that value into another variable.
Example:
I have a variable as:
${url}: wwww.$(value_from_csv}.com
and secondary url ${url}/xyz
In my Jmeter script, ${value_from_csv} is not passed.
What I am missing?
Observed that CSV Dataset Config values are not passed (not available) to any of the Config Elements irrespective of the order of the components (Config Elements) in JMeter Test Plan (checked with User Defined Config & MongoDB Source Config), though passed to Samplers.
so, suggested the OP to define the value in jmeter.properties instead of a CSV file, so we can access user.host in MongoDB Source Config.
Steps:
Add user.host=address in jmeter.properties
Restart Jmeter
Add ${__P(user.host,)} in Server Address List field in MongoDB Source Config
Note: In case of running JMeter script from Jenkins, property will be picked by the script, from jmeter.properites file.
MongoDB Source Config is initialized before any JMeter Variables so the only way to make it dynamic is using JMeter Properties instead.
You can set a JMeter Property in 2 ways:
Define it in user.properties file like:
server.address.1=some.ip.or.hostname.1
server.address.2=some.ip.or.hostname.2
Pass the properties via -J command-line arguments like:
jmeter -Jserver.address.1=some.ip.or.hostname.1 -Jserver.address.2=some.ip.or.hostname.2 ....
See Apache JMeter Properties Customization Guide for more information on using JMeter Properties
I'd like to store properties in a database tables and have defaults for those properties set in Config.groovy. For example, I want to put a default email address into Config.groovy:
app.send.report.to = 'me#example.com'
and then be able to override this in a database table (key, value columns...).
Is there a plugin (or functionality inside grails) to do this?
There is Dynamic Config Plugin.
It stores config property in ConfigProperty domain and merges properties from Config.groovy and from database using:
grailsApplication.config.merge(configObject)
You may want to look at the plugin source code. If plugin does not work for you, you can implement something similar to this.
This approach is useful when you have UI for editing config properties.
Grails does not have functionality that I'm aware of to override configuration values from a database, but it shouldn't be that difficult to do. In your Config.groovy you could put the defaults, and then as part of your bootstrap process, you could generate a temporary config file that has the values from the database (a simple query and iteration over the results could be used to generate that temp file). Include that temp file as one of your grails config locations, and it will override any values that are in the Config.groovy
If your goal is to have a shared configuration file that is used by multiple grails apps, you might also look into using something like Zookeeper to manage the shared configuration, but that may be a bit overkill for a single config file.
Not quite what you're asking for, but depending on what you want to achieve the External Configuration Reload plugin might be of use. It helps you to override default properties (in runtime), but not by using the DB.