I'm trying to update my elastic beanstalk configuration with custom web.config keys for our production servers, passwords, etc.
According to these .NET docs, I can use ConfigurationManager.AppSettings to access these variables. I have some defaults that are in there for my local machine, and these are what get read, instead of the overrides in the web UI.
Specify up to five additional key-value pairs by entering them in the
PARAM boxes.
You might have a code snippet that looks similar to the following to
access the keys and parameters:
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string param1 = appConfig["PARAM1"];
How do I access my web.config overrides in Elastic Beanstalk?
It turns out that the configuration variables will only be added if they do not previously exist in web.config. This is a different behavior than I have experienced in Azure, where parameters would override web.config.
You can validate this by RDP'ing into an EC2 instance, and viewing web.config. New parameters will be added, but ones that exist in web.config will be ignored.
You can replicate the override behavior by using the xdt "Remove" Transform in Web.Release.Config
<add key="foo" xdt:Transform="Remove" xdt:Locator="Match(key)"/>
Then set the "foo" parameter in Elastic Beanstalk using the web tool, file config, or CLI
Related
I have multiple instances of a web app (Azure App Services), they're all the same code, but are connected to client specific DBs. So they're all deployed with the same web.config, but they have different connection strings and app settings, which I'm currently storing in the App Service's Configuration blade.
I want to move to using Key Vault instead. I have it working on a test app, configured in the web.config like this:
<add name="AzureKeyVault" vaultName="my-vault" vaultUri="https://my-vault.vault.azure.net" type="Microsoft.Configuration.ConfigurationBuilders.AzureKeyVaultConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Azure, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /></builders>
However, I realise I'll need a Key Vault per instance of the app, yet each app's web config will then need to be different to hold the relevant vaultUri.
So my question is: is it possible to store the vaultUri in an AppSetting (stored in the App's Configuration blade) and somehow reference that in the configBuilder line, for example, something like this:
<add name="AzureKeyVault" vaultName="my-vault" vaultUri="[AppSetting.VaultName]" ...
Or, is there another way to achieve what I'm try to do - essentially reference a different Key Vault without requiring a different web.config for each app instance
If I understand this correctly, you're asking how to get the key vault info from configuration blade -> web.config -> configbuilder code
If that's accurate, then I think you're overthinking this. Go straight from configuaration blade -> configbuilder code. Skip the web.config altogether.
Based on my research you can add the keyvault name inside appsettings.json Not the URI
example:
The use the provider, add a reference to the Microsoft.Extensions.Configuration.AzureKeyVault package and add the following configuration to the startup code in Program.cs.
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((context, config) =>
{
var root = config.Build();
config.AddAzureKeyVault(
$”https://{root["KeyVault:Vault"]}.vault.azure.net/",
root[“KeyVault:ClientId”],
root[“KeyVault:ClientSecret”]);
})
.UseStartup<Startup>();
For more details refer this document
And Also check with the Configuration builders provide a modern and agile mechanism for ASP.NET apps to get configuration values from external sources.
Configuration builders used to improve protection of configuration data by drawing from sources previously unavailable (for example, Azure Key Vault and environment variables) in the .NET configuration system
We're having an issue right now where we're unable to debug our Dev server environment:
Now, I've spent literal hours searching for how to set ASPNETCORE_ENVIRONMENT and I've only found two (practical) ways:
Create a web.[MYCONFIGURATION].config file and add in the following, where [MYCONFIGURATION] would be something like Development or Release:
web.[MYCONFIGURATION].config:
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
Set IIS variables on the deployed server to enable ASPCORE_ENVIRONMENT
Here are the problems with each:
Since .NET Core uses appsettings.json files for its configuration (a web.config is generated from it, so far as I understand), things like our database connection strings and other settings get lost if we create a web.config ourselves.
We are running in an enterprise-level, multi-application environment with a combination of .NET Core and non-Core ASP.NET applications (which I do not have access to), so changing IIS's settings for our application only is not an option.
It should be noted that we are using TFS's Build/Release to publish to our Dev server. I had hoped that adding a BuildConfiguration variable of "development" would also work to set ASPNETCORE_ENVIRONMENT, but unfortunately it does not.
What can I do to set ASPNETCORE_ENVIRONMENT for our application only without needing a web.config or IIS settings? Or, if that is presently impossible, how can I make one of the two options work, given the constraints I have described?
I don't think I'm following correctly, seems to me you're almost there. We have a similar setup and here's what my deploy looks like.
Essentially, you don't create web.config from appsettings.json. You tell your app (running on Kestrel behind IIS) which appsettings.[Env].json to use, depending on ASPNETCORE_ENVIRONMENT value set in web.config. Not really sure what you mean by
things like our database connection strings and other settings get
lost if we create a web.config ourselves
All my deployment scripts are using PS and PS remoting via our build server (as a TFS user, you should be familiar with this), so in a nutshell, this is what happens:
// Where Env.Name is the runtime configuration - i.e. "Production"
$environmentVariable = [PSCustomObject]#{Name='ASPNETCORE_ENVIRONMENT'; Value=$using:Env.Name}
// This is how I add the actual value for ASPNETCORE_ENVIRONMENT in web.config
Add-WebConfigurationProperty $IISSite -Filter "system.webServer/aspNetCore" -Name environmentVariables -Value $environmentVariable
The last line adds
<aspNetCore processPath=".\PathToMyApp.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>
</aspNetCore>
to web.config, and you're all set.
You can also use the "IIS Web App Manage" task to set the variables using the section Advanced and Additional appcmd.exe commands:
set config "APPNAME" -section:system.webServer/aspNetCore /+"environmentVariables.[name='ASPNETCORE_ENVIRONMENT',value='Staging']" /commit:site
However, multiple executions of this script are not working. Maybe anyone has an idea?
See also: How to set environment variables per site on IIS using appcmd.exe?
Since I didn't have access to the server, the server admins refused to set a global environment variable across a multi-app server, and I couldn't pre-modify a web.config file in Visual Studio pre-release, the admins found an alternate solution.
Since I'm building/releasing using TFS, they added a Patch XML File task to TFS and instructed me to configure the task as seen below:
+ /configuration/system.webServer/aspNetCore/- => "environmentVariables"
+ /configuration/system.webServer/aspNetCore/environmentVariables/- => "environmentVariable"
= /configuration/system.webServer/aspNetCore/environmentVariables/environmentVariable/#name => "ASPNETCORE_ENVIRONMENT"
= /configuration/system.webServer/aspNetCore/environmentVariables/environmentVariable/#value=> "Development"
It seems to have worked just fine:
I must say it is irritating that this was my only recourse in .Net Core 2.0. Apparently being a server admin or having access to one who is very willing to update server configurations is a requirement to properly using .Net Core 2. Not impressed.
How do you access IIS "server variables" in Rails? Are they passed in the ENV object?
We are using IIS to reverse proxy some Tomcat instances running a Rails app using JRuby. It looked like IIS can send server variables per request. I would like to dynamically change view content based on the values of some of these server variables.
Retrieve server variables set by IIS by inspecting request object:
request.env['some-variable']
We've developed a Grails application that uses redirects.
Beacuse of external reasons, we are just recently using reverse-proxy, to split some traffic to domains:
From:
demo1.company.local (the server itself)
To:
tomcat.company.local (for all java applications, including our grails app)
lotus.company.local (for all Domino applications)
Since tomcat is only configured in the hosts file on the demo1 server, the redirects do not work when I access the application from anywhere else then the demo1 server itself.
I've tried to solve this using "absolute" and/or "base" parameter in Grails' redirect(), but if I understand correctly, this is Grails 2+ only and we're using Grails 1.3.4.
Are there other ways to redirect to a specified host?
Am I misusing things?
Thanks,
Bram
If you define grails.serverURL in Config.groovy, redirects with absolute:true will use that value for the URL.
Grails 2.0 changed with the way it uses grails.serverURL for development and test environments (as described in the manual). However, I've had several problems with serverURL in regard to production deployment on Tomcat. There seem to be several options for serverURL (production mode):
(Added) this setting is just "smoke and mirrors", because Tomcat and Jetty have methods to control how the URL is handled for the App, down to the "App" level.
Use it to specify the server (as is pointed out as a "TODO" in Config.groovy)
Don't use it as indicated here by one of the Grails contributors, i.e. "It should always be safe to remove the serverURL property and let Grails generate urls relative to the current running app." It's not clear if this extends to production or not (when not generating emails).
Use another method instead, namely grails.app.context, which is not documented in Grails 2.0 manual, but is described in certain references, here and here.
Can you please clarify the correct use of serverURL and app.context, both for Jetty and Tomcat (production mode)?
Thanks
Good question! I was just looking for the correct way to get the actual serverURL without explicitly needing to configure it in Config.groovy (in a Grails 2.1 application).
Since Grails 2.0, there is a super-useful class called LinkGenerator that you can use virtually anywhere, for example in a Service:
import org.codehaus.groovy.grails.web.mapping.LinkGenerator
Class MyService {
LinkGenerator grailsLinkGenerator
String serverUrl() {
// Generate: http://localhost:8080/link-generator
grailsLinkGenerator.serverBaseURL
}
}
Thanks to Mr. Haki for blogging about this!
So the basic idea of the grails.serverURL configuration parameter is to allow the createLink method to know what URL you want when creating absolute links. If no grails.serverURL configuration parameter is specified, it will default to http://localhost:8080 (unless server.port is specified, then 8080 will be whatever) ...
The application context tells Jetty/Tomcat to run the application in a different root. For example, specifying
grails.app.context="/myApp"
will set your application root to "/myApp". In production mode, the application context is handled by the web container and this directive is ignored. The choice to configure your production jetty or tomcat instances to run your application in a different context is entirely dependent on what your technical requirements are.
So the real thing to consider is, in your application are you creating a lot of absolute links in your GSPs where you need to define a "production" serverURL? If not, then you don't need to specify it; if you are, then you'll need to specify it.
As a personal preference, the first thing that I always do after creating a new grails project is go into the config and change the grails.app.context to "/" ... It makes mirroring a production environment much easier for me.
Hope this clears things up!