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.
Related
was wondering if it is possible to allow global variables like ${PAGE_NAME} be a part of an include?
We have different teams using different feature environments (and more environments coming up) which uses symlinks and includes to environment setup pages. At the moment we're copying everytime the literal path. It is less error prone when we can use the global variables FitNesse has to offer.
For example a simple setup:
root
.Env
.FEAT1 --> connection details to setup/connect env 1.
.FEAT2 --> connection details to setup/connect env 2.
.FEAT300 --> connection details to setup/connect env 300.
.Team1
.FEAT2 --> uses !include -seamless .Env.FEAT2 and uses a symlink to suiteX
.Team10
.FEAT300 --> uses !include -seamless .Env.FEAT300 and uses symlinks to suiteX, suiteB and suiteC
etc
When using include -seamless .Env.${PAGE_NAME} it does not load the include. Preferably we want to use the variables FitNesse offers, but I'm sure we are doing something wrong or using the wrong syntax.
Any suggestions on how to use the global variables in a way we try to achieve?
I tried an other solution by defining the whole include into a variable, but that has unfortunately the same result:
!define includes {!include -seamless .Env.${PAGE_NAME} }
$includes
Writing down the global var itself resolves as expected.
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"
---
There are some properties that I have in the default generated application.yml file in Grails 3. Take for example this property
test:
network:
path: '/home/cool/testing_data'
Now, the part that I want to do is change this property when I invoke the build script, so that it is different for the various OS that it might be executed on. I.e: On windows, that path should be 'E:/shared/testing_data', and on solaris, something different.
Using this post here, I can conclude that I can identify which OS I am currently on, so that I can potentially make some changes. Ex:
import org.apache.tools.ant.taskdefs.condition.Os
task checkWin() << {
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
// it is windows, lets change the path to not be linux like
}
}
So my question is, using gradle or any other means as necessary, can I change the properties in application.yml file to accommodate the different OS systems that the application might be deployed on? I am considering reading the application.yml file line by line and doing a string replacement, but I will resort to this only if there are no cleaner solutions.
Maybe am I using the wrong tool to solve this problem as is, so a good question to ask is, is there an easier way that I am missing here, possibly a similar approach to different "environments" like :test, dev, prod, for operating systems, already built into the core functionality of grails that I can re-use?
Just create application.groovy file in the same folder as application.yml is. In groovy file you can use any script to set value of properties.
For example add this line to application.groovy file (also remove option from yml):
test.network.path = Os.isFamily(Os.FAMILY_WINDOWS) ? 'd:\something' : '/home/something'
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.
What is the recommended way to have different values for application environment variables in an erlang application?
What I mean here is: how do you support different environment in your application (e.g. development, stage, production) in your erlang application? For example I would like tests using a specific fake service on a known host and production code use the real server on a different host.
You can use application config file as well. you can also pass the config as parameter while starting an erlang console that can help you in setting up environment variables. so you are pass test.config or production.config based on environment there by no need to compile the code and start them.
You can find more info here
http://www.erlang.org/doc/man/config.html
Dependency injection.
test_setup() -> [ {host,"http://..."}, ... ].
prod_setup() -> [ {host,"http://..."}, ... ].
test_start() -> start(test_setup()).
prod_start() -> start(prod_setup()).
start(Config) -> ... .
Alternately, policy modules. Make a policy whose interface matches the stuff you need, then pass in the name of the module containing the policy you want. Think ETS/DETS.