I am referring to this page:
https://www.instana.com/docs/setup_and_manage/host_agent/updates/#update-interval
Is there a way to pass mode and time from outside as environment variables or any other way beside logging into the pod and manually changing the files inside etc/instana/com.instana.agent.main.config.UpdateManager.cfg file?
To whoever removed his/her answer: It was a correct answer. I don't know why you deleted it. Anyhow, I am posting again in case someone stumbles here.
You can control frequency and time by using INSTANA_AGENT_UPDATES_FREQUENCY and INSTANA_AGENT_UPDATES_TIME environment variables.
Updating mode via env variable is still unknown at this point.
Look at this page for more info: https://www.instana.com/docs/setup_and_manage/host_agent/on/docker/#updates-and-version-pinning
Most agent settings that one may want to change quickly are available as environment variables, see https://www.instana.com/docs/setup_and_manage/host_agent/on/docker. For example, setting the mode via environment variable is supported as well with INSTANA_AGENT_MODE, see e.g., https://hub.docker.com/r/instana/agent. The valid values are:
APM: the default, the agent monitors everything
INFRASTRUCTURE: the agent will collect metrics and entities but not traces
OFF: agent runs but collects no telemetry
AWS: agent will collect data about AWS managed services in a region and an account, supported on EC2 and Fargate, and with some extra configurations, on hosts outside AWS
On Kubernetes, it is also of course possible to use a ConfigMap to override files in the agent container.
Related
I'm using SCDF and i was wondering if there was any way to configure default properties for one application?
I got a task application registered in SCDF and this application gets some JDBC properties to access business database :
app.foo.export.datasource.url=jdbc:db2://blablabla
app.foo.export.datasource.username=testuser
app.foo.export.datasource.password=**************
app.foo.export.datasource.driverClassName=com.ibm.db2.jcc.DB2Driver
Do i really need to put this prop in a property file like this : (it's bit weird to define them during the launch)
task launch fooTask --propertiesFile aaa.properties
Also, we cannot use the rest API, credentials would appear in the url.
Or is there another way/place to define default business props for an application ? These props will be only used by this task.
The purpose is to have one place where OPS team can configure url and credentials without playing with the launch command.
Thank you.
Yeah, SCDF feels a bit weird in the configuration area.
As you wrote, you can register an application and create tasks, but all the configuration is passed at the first launch of the task. Speaking other way round, you can't fully install/configure a task without running it.
As soon as a task has run once, you can relaunch it without any configuration and it uses the configuration from before. The whole config is saved in the SCDF database.
However, if you try to overwrite an existing configuration property with a new value, SCDF seems to ignore the new value and continue to use the old one. No idea if this is intended by design or a bug or if we are doing something wrong.
Because we run SCDF tasks on Kubernetes and we are used to configure all infrastructure in YAML files, the best option we found was to write our own Operator for SCDF.
This operator works against the REST interface of SCDF and also compensates the weird configuration issues mentioned above.
For example the overwrite issue is solved by first deleting the configuration and recreate it with the new values.
With this operator we have reached what you are looking for: all our SCDF configuration is in a git repository and all changes are done through merge requests. Thanks to CI/CD, on the next launch, the new configuration is used.
However, a Kubernetes operator should be part of the product. Without it, SCDF on Kubernetes feels quite "alien".
We distribute Docker images of our .Net Core Web API to clients.
By setting the ASPNETCORE_ENVIRONMENT environment variable to X in the client's Kubernetes Helm Chart, the correct environment settings in appsettings.X.json get picked up. This all works nicely.
But what happens if the client needs to change one of the settings in appsettings.X.json? We don't want them to rebuild the Docker image.
Can someone offer a better architecture here?
The most common practice is to get settings directly from the environment. Thus instead of a settings.json you would read from the environment (you could have defaults too. Another solution would be to use http://www.confd.io/
I use Microsoft Team Foundation Server (TFS) for most of my software deployments. TFS allows me to dynamically replace text within specific configuration files during the release process to specific environments (dev, test, prod).
The text it replaces are placeholders called "tokens". For instance, during my automated deployments, TFS will allow us to replace tokens found within configuration files with pre-defined values saved in the build administration for each environment. This way, I don't store any real credentials in source control for any environment. I also don't store any script in source that would hold these sensative credentials. The credentials are dynamically inserted over top the tokens during the release, and the credentials are hosted/saved/configured inside of the release system (not in a script).
For example, I have a configuration file (web.config) that has tokens. A token looks something like this:
MySettingName=${MYSETTINGVALUE}
During the release to DEV, I want the text ${MYSETTINGVALUE} replaced with the word TEN. During the release to PROD, I want that same ${MYSETTINGVALUE} text replaced with the word ORANGE. And I want to store those two values (TEN and ORANGE) in the release administration system, and not in a script.
How do I configure Jenkins to do this same thing?
I have searched up-and-down for this specific answer. While many blogs, articles, documentation exist, none of them speak directly to this issue.
I would prefer NOT to use some additional 3rd party software to do
this.
I would prefer NOT to kick off some manual build and supply these
values each and every time.
I would also prefer NOT to use an Operating System level system
variable (aka evironment variable). In case that server dies, I
would rather not have to remember to setup those OS environment
varialbles on the next server.
Jenkins has a built-in credentials plugin for handling secrets in builds.
See this article on how to use them: https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
Basically it stores credentials securely and injects them into your jobs as variables which can then be used like any other.
let's say I am developing 2 applications for 2 different clients which are, using 2 different database-configurations.
When using Openshift and CakePHP it is considered good practise to not store the real connection-info in the configs, but instead to use environment-variables.
That way the GIT-Repo is also always clean of server-specific stuff.
That is all fine as long as I have ONE project but as soon as there is another one, I need to override my local env-vars according to the current project.
Is there any way to avoid this? Is it possible to set up env-vars on my local machine per directory or something like that?
I am running OSX with Mamp Pro.
This may not be the best solution, but It would work. Create a different user on your local machine and then change to that other user when you need to access those other environment variables.
I create a 'data' directory in my git repo and set it to ignore. This way anything in there will be saved in the repo and sent to openshift. I place a config.ini file with all the info that I don't want in my repo.
I then manually put that config.ini file in Openshift's persistent DATA directory by using winSCP. You only have to do this when you change your config.ini.
When my app runs it detects if it's local or on Openshift and loads the config.ini file from the correct directory.
I would be interested if somebody has a better idea.
HTH
At first glance this seems like a purely subjective/aesthetic issue, but I'd be interested to hear opinions (especially any technical ones) on whether environment variables or the registry is the preferred place for storing configuration data in a Windows environment.
I can currently only think of the following differences:
Registry settings are persistent across sessions, though I believe that environment variables can also have this property.
It's easier to set environment variables from the command-line vs. using regedit
(Counter-argument: regedit easier for non-command-line apps?)
Environment variables are more common across platforms (?).
I'm also aware that environment variables can be interrogated, modified and set from the registry.
Use environment variables when you intend to be configured by other applications (or by a technical user) and that this configuration could be different (i.e. you have 2 instances running at the same time, with different settings). Cluttering a user's environment isn't usually necessary. In most cases, use the registry, or a config file stored in $HOME\AppData\Roaming\YourApp.
When using windows services, environment variables can be a pain: Just changing the variable and then restarting the service will not help. Usually the system needs to be restarted.
If the service looks up settings in the registry, this is much easier.
I saw this behavior on Windows XP, I'm not sure if the later versions have resolved this issue.