I have a lot of configuration objects that get populated by reading an appsettings file. Similar to this:
builder.Services.Configure<VaRideshare.Service.Common.Provider.Google.GoogleApiConfiguration>(builder.Configuration.GetSection("GoogleApiConfiguration"));
I see where environment variables get defined in Elastic Beanstalk but is it possible to use a production appSettings file to define the configuration or do I need to break apart my appsettings file into individual environment variables in order to access them?
Related
how to hostname and IP address of the instances deployment from the deployment manager for a particular deployment session?
I have seen it can be done via gcloud but I am looking for alternate via saving files through jinja
Also, would like to know if we can save via Jinja templates
need to know if there are any postscript available for gcloud deployment manager
for example, I have deployed 4 centos instances and now I need to create a config file using the above four instances and then go about starting services on all four.
I doubt it can be done through start-up script
You can simulate a creation of a vm instance reserving the desired IP, specifying the hostname and the start-up script where you start the services of your machines, then, check the REST file at the bottom of the page to see the actual labels used for that and where those should be used, but remember that for IP static assign you must reserve one or more first, for internals check this, for externals check this.
You can create an instance-templates based on this documentation[1] and deploying your VM/s with gcloud[2]. The Hostname and IP Address can be specified on the instance template itself:
gcloud deployment-manager deployments create [DEPLOYMENT_NAME]
--config [CONFIG.YAML]
I am not familiar with Jinja but based on Google doc [3], you can use it to create templates used by Deployment Manager.
You can also add a metadata resource in the template to use the startup-script[4]. Keep in mind that startup-script can simply download and execute a python/bash if it is come to be too complex.
I've a nodejs application which connect to mssql using the connection string defined in a json file. Different environment will connect to different db.
In minishift, what is the proper way to pass the json config file to different container at runtime?
Regards, nww
First, define this json file as a configmap. You can do it on web UI (under Resources/Config Maps) or command line, for example:
oc create configmap mssql1 --from-file=json=/path/to/your/json
Secondly, mount the configmap onto your nodejs deployment. You can do it on web UI (find your nodejs deployment, switch to Configuration tab, and click Add Config Files link).
First let me give some background
We have our own VPS, so we do not wish to use Azure to host our web applications.
We have already successfully created a CI/CD pipeline to our VPS by installing an agent on it for a .NET Core project.
We use Azure DevOps (formerly known as VSTS) to host our code in GIT and handle our backlogs and CI/CD pipelines.
We have several .NET Framework projects where we use XTD transforms to transform our web.config files on delivery/deployment to have the correct connection strings and other configuration properties.
This makes it possible to pull the master branch from our remote repo and have it working in seconds on a previously unused (for this application) development environment without the need for any configuration.
Now to get to my question
The master branch of the .NET Core project for which we already have the CI/CD pipeline in place holds the configuration in the json files for the staging environment it is continuously delivered to. When a developer pull the master branch, he/she first needs to configure these to suite the local debug environment.
This is an undesirable situation for us.
How can we make it so that if we use .NET Core we can use a mechanism that will allow us to have the project work on a local debug environment without any configuration and in the CI/CD pipeline?
What have we already tried?
we have found that we can have multiple versions of the appsettings.json file for the different environments like appsettings.debug.json and than in the static method CreateWebhost of the Program class we can call on or the other. But how we can automate this is something that we haven't been able to figure out or find documentation about.
Okay, so here are some options you can take advantage of TODAY. (there are im sure more options/approaches)
Option A
Configure the master branch to have appsetting.development.json with connection string to DEV database( or lowest environment)
remove any connection string from appsettings.json
Merge master accordingly.
Create environment variables on each of the backend servers for the connection string; ex, system environment variable named ConnectionStrings:cartDB with connection string to the database for the environment for which the backend server used.
The result of this will be that when running using DEVELOPMENT as the environment variable, then it will be able to connect to database everyone can access.
However, since all OTHER web servers have environment variables with connection string, they will take highest level of precedence, and will therefore be the values set when calling something such as
string connectionString = Configuration.GetConnectionString("cartDB");
This will satisfy the requirements you mentioned above.
Option B:
Configure the master branch to have appsetting.development.json with connection string to DEV database( or lowest environment)
remove any connection string from appsettings.json
Place appsetting.staging.json, appsettings.prod.json in source control, and set environment name variable in web servers. :/ not the best of options/advised against.
(its worth mentioning since I have seen this happen, we all have)
Option C
Add appsetting.staging.json, appsettings.prod.json to source control and use a token in place of the connection string value. Then, leverage some type of Tokenization Task to replace those tokens with the appropriate values.
What is the best way to include the steps for mysql_secure_installation in a template using CloudFormation?
Take a look at Deploying Applications on Amazon EC2 with AWS CloudFormation. Specifically the UserData property and Metadata properties.
You can use either one of those to run the mysql_secure_installation command when the instance launches.
We are a team working on a bunch of SSIS packages, which we share using version control (SVN). We have three ways of saving sensitive data in these packages :
not storing them at all
storing them with a user key
storing them with a password
However, each of these options is inconvenient while testing packages saved and committed by an other developer. For each such package, one has to update the credentials, no matter how the sensitive data was persisted.
Is there a better way to collaborate on SSIS packages?
Since my workplace uses file deployment, I use "Don't save sensitive" In order to make development easier, we also store config files with the packages in our version control system, and the connection strings for the development environment are stored in the config files. The config files are also stored in a commonly named folder, so if I retrieve the config files into my common config file area, then I can open any of our project packages and they will work for me for development. When the packages are deployed, they are secured by the deployment team on a machine where developers do not have access and the config file values for connection strings are changed to match the production environment.
We do somthing similar using database deployment. Each enviroment has a configuration database, and every package references a single xml config file in a common file path on every server/workstation, e.g., "c:\SSISConfig". This xml config file has one entry that points to the appropriate config database for that environment. All of the rest of the SSIS configs are stored in that config database. The config database in production is only accessible by the admin group, the developers do not have access. When new packages and configurations are deployed to prod, connection strings are updated by the admin group. The packages are all set to "Dont save sensitive".