In the case when you have to test a resource in different environments you may use postman environment variables to specify environment specific values. However, if only some of the environments use proxy you have to set it up Postman settings and enable/disable it manually every time you run the test against that environment. It is annoying and lacks automation. It gets even worse if different environments use different proxies.
In addition when you export environments and collections proxy configuration stays in Postman. It is not exported. Therefore you have to document it somewhere in order to avoid loosing the configuration, since there is no comments for an environment to document it there.
The question is: is there a way to apply proxy configuration based on environment? For example, specifying some Postman environment variables.
I tried to specify HTTP_PROXY, HTTPS_PROXY environment variables in Postman. Unfortunately, it did not work. Probably I was misled by using ambiguous "environment variable" term in "Respect HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables." setting. Obviously, Postman in fact respects system environment variables.
I was able to use Proxy Bypass to specify all hosts I do not want to apply proxy configuration to. However, the list is pretty big in my case, since proxy required only for one environment. In addition it does not resolve the issue if multiple proxies need to be used.
Related
I need to run same script in different environments like QC, UAT and PROD. I would like to know how do we configure and run based on specified environments.
Note - I tried with properties file but it requires some manual effort which we do not want.
Please help with some examples
If environments don't change you can create 3 separate HTTP Request Defaults configuration elements containing protocol/host/port/path/etc. settings for different environments and depending on the target environment you can toggle this or that HTTP Request Defaults element.
If you need unattended way of enabling/disabling HTTP Requests Defaults (or any other test element) you can consider using Taurus tool as a wrapper, it provides syntax to enable/disable any JMeter test element via YAML config or via command-line arguments.
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
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.
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");
Can someone explain the purpose and effective usage of these three environment variables?
Is there a common convention when using them?
What happens if I set all of them at the same time? Is this application specific (I assume it is, but are there best practices?).
I see this as a pretty good "long form" answer. I don't know much about these variables or where to find more information about them and would love more information.
These environment variables are used by some tools like wget.
From the wget documentation of proxies
http_proxy
https_proxy
If set, the http_proxy and https_proxy variables should contain the URLs of the proxies for HTTP and HTTPS connections respectively.
no_proxy
This variable should contain a comma-separated list of domain extensions proxy should not be used for. For instance, if the value of no_proxy is ‘.mit.edu’, proxy will not be used to retrieve documents from MIT.
But others tools use different configuration of proxy settings, for instrance curl use -x, --proxy and --no-proxy arguments :
-x, --proxy <[protocol://][user:password#]proxyhost[:port]>
--noproxy <no-proxy-list>