I've got a strange situation today. I called one of my variables in a playbook environment. If I dump variables using debug instruction, it is shown ok
"environment": "development",
But if I try to access it from a script using {{ environment }} it is always assigned a value of {}. I renamed it and it worked ok. Why is that? Is environment a reserved name in Ansible? I checked variable dump - there is no clashes with defined vars.
I found a statement regarding environment in the Google group:
Yes, environment is a restricted keyword. Initially specific within
playbooks, but it gets injected in the runner:
inject['environment'] = self.environment
so it will erase whatever value was set by inventory of vars.
There is a yet unaddressed feature request to warn if reserved variables are used.
Interestingly enough, Environment (proper-case) is usable, but environment (lower-case) is not as you found out.
I came across this one day when I accidentally used my existing Environment variable specified in lower-case and had a fun time trying to diagnose the issue.
I'd stick to using a different name as well (although I still use Environment on purpose just to remind myself about case sensitivity in variable names).
Related
I'm using AWX as a task runner to run a variety of Ansible modules. Some of the Ansible modules are third-party modules whose parameters I can't control without forking the module, which is undesirable for a variety of reasons.
AWX supplies ansible_user as one variable that is used by some of the modules I'm using, and I'm trying to allow a user to some hosts by setting another variable, user_override.
I first thought to simply add the line ansible_user: "{{ user_override | default(ansible_user) }}" to the task's parameters, which would work... but the modules in question don't accept credentials via parameters. My next thought was to add a vars: entry to the playbook and supply the override there via the same markup as above. This unfortunately results in the error recursive loop detected in template string, which has been the bane of my existence while working through this problem.
I've also tried using the if/else syntax and intermediate variables, but neither appear to solve this problem.
How can I achieve this override functionality without forking AWX or the module in question?
Mods: This is distinct from the pile of questions asking about simple variable defaulting because the existing questions aren't in the context of AWX or can be solved by simply using default() or default(lookup()).
At this point, I'm pretty sure that the thing I (the asker) was trying to do is intended to be done by just sometimes setting a value, but some challenging-to-anonymize constraints in our software make that somewhere between challenging and not an option.
A sideways solution to the particular problem of overriding the user is that AWX sets the username in remote_user as well as ansible_user, which is then used by networkcli. So you can use the line `remote_user: "{{ override_user | default(ansible_user) }}". This doesn't help generally, but does answer the question.
Sorry, pretty simple question:
I can't find any resource that explains the order of evaluation of the ENV variable in Laravel... Usually in Spring Boot if I define a variable in the docker-compose I know for a fact that it overrides the application.properties value.. is the same in Laravel?
E.g.:
.env
DB_HOST = A
docker-compose.yml
environment:
- DB_HOST = B
in the application, is guarantee that DB_HOST is B?
At time of writing Laravel uses this dotenv environment. The key behaviour of this is determined by line:
static::$repository = $builder->immutable()->make();
Immutable, as described in the official dotenv repository, means that existing environment variables are not overwritten. Therefore the variables that docker-compose sets which are part of the container environment will not be overwritten by .env.
However since this is inferred by digging in the code and not explicitly documented (as far as I can tell), I think you need to treat it as undocumented behaviour and if you are relying on this then be vigilant before upgrading Laravel versions to make sure it has not changed.
Usually the variables that are defined in the .env are returned first. They are stored on config/ files as well. In your case it's stored on config/database.php file.
In my case env('DB_HOST', '127.0.0.1') it's this code.
What's it's saying basicly is that you get the value stored from the variable DB_HOST on .env, otherwise return the defaul value specified which is 127.0.0.1
Edit: As specified in the comments, you can always testing by using dd() or return env(DB_HOST); and you will get the result.
I search a lot on the web, almost all links says define JVM custom variables in jvm.options also placed it on ${server.config.dir}/jvm.options.For example I added a variable called -DAPP_ENV=PROD. But this is getting as NULL after server startup.
Any idea?
It looks like you want to define an environment variable, so you have two options.
1. Use an Environment variable
In this case, you can define an environment variable (like $PATH) and load it in your app. Note this is not a JVM argument, and it will be set in the bin/server shell command used to start the server.
In the file:${server.config.dir}/server.env
Add the following line: APP_ENV=PROD
Access the value with:
System.getenv("APP_ENV"); -> PROD
2. Use a System property
This is what you are trying to do, so I am not sure why it doesn't work for you, but here's how:
In the file:${server.config.dir}/jvm.options
Add the following line: -DAPP_ENV=PROD
Access the value with:
System.getProperty("APP_ENV"); -> PROD
Note that in both cases these values are set at server start-up, and they are not changed dynamically (most Liberty configuration is dynamic). The JVM options and environment are sourced and set during the start script so a restart is required if you want to change either one.
My personal recommendation is go to the server.env route - its more generic and (to me) feels more appropriate since you are trying to influence the execution environment of the process, rather than defining behaviors or configuration of the JVM.
Assume that a normal deployment script does a lot of things and many of them are related to preparing the OS itself.
These tasks are taking a LOT of time to run even if there is nothing new to do and I want to prevent running them more often than, let's say once a day.
I know that I can use tags to filter what I am running but that's not the point: I need to make ansible aware that these "sections" executed successfully one hour ago and due to this, it would skip the entire block now.
I was expecting that caching of facts was supposed to do this but somehow I wasnt able to see any read case.
You need to figure out how to determine what "executed successfully" means. Is is just that a given playbook ran to completion? Certain roles ran to completion? Certain indicators exist that allow you determine success?
As you mention, I don't think fact caching is going to help you here unless you want to introduce custom facts into each host (http://docs.ansible.com/ansible/playbooks_variables.html#local-facts-facts-d)
I typically come up with a set of variables/facts that indicate a role has already been run. Sometimes this involves making shell calls and registering vars, looking at gathered facts and determining if certain files exist. My typical pattern for a role looks something like this
roles/my_role/main.yml
- name: load facts
include: facts.yml
- name: run config tasks if needed
include: config.yml
when: fact_var1 and fact_vars2 and inv_var1 and reg_var1
You could also dynamically write a yaml variable file that get's included in your playbooks and contains variables about the configured state of your environment. This is a more global option and doesn't really work if you need to look at the configured status of individual machines. An extension of this would be to write status variables to host_vars or group_vars inventory variable files. These would get loaded automatically on a host by host basis.
Unfortunately, as far as I know, fact caching only caches host based facts such as those created by the setup module so wouldn't allow you to use set_fact to register a fact that, for example, a role had been completed and then conditionally check for that at the start of the role.
Instead you might want to consider using Ansible with another product to orchestrate it in a more complex fashion.
I'm currently writing a tutorial on setting up Wordpress on Heroku. Right now I'm using the ClearDB add-on which sets a CLEARDB_DATABASE_URL ENV variable automatically. Is it possible to alias the ENV variable through Heroku as DATABASE_URL?
It's not possible to alias an config var or refer to one from another. I asked a similar question and this is what they said:
I'm afraid that Config Variables can't refer to each other in this
way, as they are simple a collection of Names and Values, with no
interpolation or calculation available to the values.
You might like try a
profile
file...
I've had a similar issue - where I'm trying to use an app in a pipeline connected to 2 different heroku DB's - in order to keep all he environments consistent in code, I did the following:
Heroku Configs:
DATABASE_URL=XXXXXXXX - this was the first DB that heroku attached
HEROKU_POSTGRESQL_JADE_URL=XXXX - this was the second DB that heroku attached (the key name changes in each environment)
SECOND_DB_KEY_NAME=HEROKU_POSTGRESQL_JADE_URL
(ie. after each environment was set up - I added a reference to the new key)
This second DB key name, does not change if the DB credentials refresh.
In code, I then did the following at start up:
const databaseUrlKey = process.env.SECOND_DB_KEY_NAME
process.env['SECOND_DATABASE_URL'] = process.env[databaseUrlKey]
Maybe I'll just say something stupid, but why not just do this:
heroku config:set DATABASE_URL=CLEARDB_DATABASE_URL
In code:
ENV[ENV['DATABASE_URL']]
I'm not sure this information will be helpful for anyone but just in case:
This question involves an eroneous assertion. The ClearDB add-on does not set a CLEARDB_DATABASE_URL ENV variable. The ClearDB add-on creates a CLEARDB_DATABASE_URL config var. When the app is started an ENV variable is created from the config var. These two variables are different and could even have different values if you changed the ENV variable in your code base.
Of course, within your code base, you can do whatever you want with the ENV variables.
As to whether config vars can reference other config vars, or other ENV variables, or vica versa - I don't know. But surely this would be something pretty hacky, and contrary to intended use, and proper coding practice, and socially responsible behavior.