I have a NodeJS apps hosted on a server behind IISNode. I have set the NODE_ENV in the web.config
<iisnode node_env="staging" />
and in the iisnode.yml
node_env: staging
but my application does not seem to pick it up. It picks up the values that I had initially set when I set up the server. Any ideas why?
Turns out Node was picking up the environment variable I had set rather than the values in the config. I removed the environment variable and boom - it started picking up the values in the config.
Related
I have some SpringBoot 1.5.19.RELEASE services hitting problems because the our Keycloak bearer token is getting big. In the short term, rather than reduce the token size we want to increase the maximum acceptable header size instead.
Lots of stack overflow pages suggest that setting server.max-http-header-size=48000 in application.properties should relieve the symptom and it does. I can also successfully use that from the command line as a system property -Dserver.max-http-header-size=48000. But even changing the command line for all of our services is a little tedious as the commmand line is embedded in each docker image so I wondered about an environment variable which can be changed at deployment time...
Spring docs suggest that application.properies can also be overridden from the environment using the RelaxedPropertyResolver allowing e.g. spring.profiles.active to be set from the SPRING_PROFILES_ACTIVE environment variable. This works well and I've used it many times.
But trying my services with an environment of SERVER_MAX_HTTP_HEADER_SIZE=48000, SERVER_MAX-HTTP-HEADER-SIZE=48000, and even SERVER_MAXHTTPHEADERSIZE=48000 results in the default limits being applied - nothing seems to be recognised by Spring.
How can I specify this setting via an environment variable without having to rebuild the docker images etc that run the services?
there seems to be a bug in spring boot 1.5.19. it works for me if I set:
SERVER_maxHttpHeaderSize=48000
We are having issues setting the Jenkins environment variables on our dynamic EC2-Fleet.
We already have a fixed master (linux) and a fixed Windows slave but wanted to add slaves dynamically when the load on the system becomes heavy.
For this we created a Spot Request Instance in AWS spinning up linux machines from an AMI and control this via the EC2-fleet-plugin in Jenkins.
Before this EC2-fleet can be of any help, our jobs must be able to run on its nodes.
Most of our jobs use Jenkinsfiles and need certain environment variables to be set but the EC2-fleet-plugin does not provide the possibility to set environment variables (https://issues.jenkins-ci.org/browse/JENKINS-36544).
As suggested on this ticket (JENKINS-36544), we tried to set the environment variables in "System Configuration" for the dynamic ec2 slaves and set the environment variables for the other nodes on the "Node Configuration" overriding the "System Configuration", or so we thought.
This should work if this bug wouldn't exist: https://issues.jenkins-ci.org/browse/JENKINS-44425. Because of this bug the "System Configuration" overrides the "Node configuration" instead of vice versa. So we can't use this as the existing nodes would not have the correct environment variables anymore.
As a last resort we tried to set the environment variables on the dynamic ec2 slaves by creating an /etc/profile.d/jenkinsvars.sh on the AMI used by the Spot Request Instance.
This script would be automatically run on login system wide (https://help.ubuntu.com/community/EnvironmentVariables#A.2Fetc.2Fprofile.d.2F.2A.sh).
Next to that we also attempted to set them in /home/ubuntu/.profile on the AMI singling out the ubuntu user which is the user running the Jenkins agent (https://help.ubuntu.com/community/EnvironmentVariables#A.2BAH4-.2F.profile).
But it appears Jenkins does not use these environment variables but its own...
A way that works is to adapt the jobs to load a groovy file that's part of the AMI to set the environment variables we need but that would mean to change almost all jobs we have, next to all Jenkinsfiles that are included in our repositories (Bitbucket project).
We would like to avoid this....
Try the following strategy:
Leverage User Data to run a shell script when the Spot Instance launches. It is the primary recommended way by Amazon and the plugin authors.
Instead of saving variables into the environment, have the user data script save them into either /var/tmp or /etc/profile or in parameter store. Refer to answers in this SO question. If you want to encrypt your info use KMS parameter store, if you dont care use one of the others.Choose one of the answers to best fit your needs.
Alter your Jenkins job to pause until your user data script has completed running (refer to the documentation from the plugin)
Change your Jenkins job to pick up the variables from the location you chose in step 2.
Try restarting the server environment.
Just saying.
So we can't use this as the existing nodes would not have the correct environment variables anymore.
Update your existing nodes to load the environment variables when they are provisioned / started, then remove them from the System configuration, then add them to the Node configuration.
You could also try setting the Slave command prefix field to ENV_VAR1=val1 ENV_VAR2=val2, although I haven't tried that.
Thirdly, you can try putting your variables directly into /etc/profile which should always be loaded no matter what user you are logging in as.
However, the easiest by far is to make all of your drones/agents exactly the same and set your environment variables in whatever scripts you run to build your projects. Use docker to pull dependencies to the agents as necessary during the job and to set up specific environments for your applications. This greatly simplifies the maintenance and configuration of your agents.
The Jenkins version or version of the EC2 plugin are missing in the question, but according to the description in this merged pull request, this bug should be fixed now: https://github.com/jenkinsci/ec2-plugin/pull/440#issuecomment-597160730
Jenkins version:
so this change works in both <=2.204, and >=2.205
EC2 plugin version: >=ec2-1.50
JENKINS-36544 - Fix Node Properties on Jenkins 2.205+ (#440) #jhansche
From the Pull Request description:
Navigate to the cloud configuration screen (this moves to a new page >=2.205)
Click "Add a new cloud"
Click "Amazon EC2"
Under the "AMIs" section, click "Add"
At the bottom of the AMI block, expand "Advanced"
Expect to see "Node Properties" block at the bottom of the block
Node Properties has the Environment variables.
I searched a lot but couldn't find any useful information about this:
What exactly setenv.sh is used for in Tomcat ?
Let's say we have a REST API (built with Java EE or Spring) which uses some parameters/variables like AWS Credentials, Database Credentials etc.
Does it make sense to parametrize the application with environment variables for these things I mentioned above and put their values to env vars on setenv.sh for each Tomcat instance in case we use more than one instance and with different parameters/variables ?
Or setenv.sh isn't for things like that ?
Thanks in advance
I've only ever seen it used for specifying CATALINA_OPTS, but I noticed that the RUNNING.txt file mentions using it to set JRE_HOME and JAVA_HOME.
RUNNING.txt also states under Advanced Configuration - Multiple Tomcat Instances:
In many circumstances, it is desirable to have a single copy of a
Tomcat binary distribution shared among multiple users on the same
server. To make this possible, you can set the CATALINA_BASE
environment variable to the directory that contains the files for your
'personal' Tomcat instance.
So I guess the answer is that a setenv file can be created for each app and can probably can be used to store credentials, but I don't think that it's commonly used for that purpose.
~/Programs/apache-tomcat-9.0.7/bin/setenv.sh
export CATALINA_OPTS="$CATALINA_OPTS -DENV_TARGET=prod -DMy_Env_Var1=Whatever -DMy_Env_Var2=CapitalOneIsTheBest"
So everything in between "" above in setenv.sh gets set as environmental variables for your applications in Tomcat. To retrieve/use those environmental variables, use this in your Java (Spring) applications:
Ex1) String myWhatever = java.lang.System.getProperties().getProperty("My_Env_Var1");
Ex2) String env= System.getProperties().getProperty("My_Env_Var2");
To change the environmental variable (for example when you are writing unit tests), do this:
System.setProperty("My_Env_Var1", "newEnv");
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.
I am struggling to get Jenkins to work with SSH and after looking at a number of questions and answers the answer seems to involve setting the Windows Environment variable HOME.
When I set this environment variable and restart JENKINS, Jenkins starts properly but i can't access it via the URL:
http://localhost:8080
Once I get rid of this variable and restart Jenkins it works well.
I am not sure why this variable is wreaking havoc? I am not sure how others have managed to set this variable and get things to work.
The outcome is the same, when i remove the Windows environment variable and replace it with the system property inside Jenkins.
Appreciate any suggestions/advice.
Thanks