Configuration file for Cloudera Management Service - cloudera

Is the a configuration file for Cloudera Management Service?
I'd like to have the service roles' configuration stored in repository. This way, service configuration can be shared between environments without the need to change the configuration via CM ui or rest API on each environment.

Cloudera deploys configs for those dynamically when service is started by agent, for example Service Monitor will end up in /run/cloudera-scm-agent/process/XXXXX-cloudera-mgmt-SERVICEMONITOR
Config itself is stored in database, in configs table.
So I would say that your only solution (sadly) is to manage config via api. Client libraries for that are pretty friendly though.

Related

App Configuration service for on-prem dotnet core app

We have a dotnet core 3.1 console application. It is deployed to on-premise Windows server. There is some sensitive information that we would like to keep in Azure Key Vault. However, instead of accessing Key Vault directly, we would like to access it via App Configuration service.
https://learn.microsoft.com/en-us/azure/architecture/solution-ideas/articles/appconfig-key-vault
Above article mentions that any application can use Azure App Configuration (under Potential use cases).
Does "any" include application hosted outside of Azure? If so, can you share high level steps on how to access App Configuration service from dotnet core app that is not running in Azure.
it seems that any means any, looks like the steps remains the same as long as the connection string to config services work, i'll do some testing with quick start material and let you know..
Best!

How to have environment-specific configurations on Azure app service

We are migrating some of our on-site hosted web API to Azure app services. However, we aren't sure how to handle environment-specific configuration files on the Azure hosted apps.
What we do right now, in .NET Core, is include a directory of different JSON configuration files, each with the naming scheme:
myappname.SOMEMACHINENAME.json
Then, in the app startup, we load the appropriate file based on the machine that is running the app. This lets the app load an environment-appropriate configuration only knowing what machine it is running on.
Config = new ConfigurationBuilder()
.AddJsonFile(#"Configurations\myappname." +
Environment.MachineName +
".json", false)
.Build();
However, we're not sure how to accomplish something like this in the Azure app services world, where we do not know the machine name that the app will be running on. What is the best practice method of loading an environment-specific configuration at runtime with an Azure hosted app service?
Thanks for any help!
Edited to add .NET framework info.
Set the ASPNETCORE_ENVIRONMENT app setting to CustomConfig to the value matching appsettings.CustomConfig.json. Or, use a custom solution with a custom app setting. Either way, an app setting in the Azure Web App may be a good solution.
https://learn.microsoft.com/en-us/azure/app-service/configure-common#configure-app-settings

application insights configuration in yml

We are using DropWizard to create java applications running as a server inside a docker container.
Command to create such applications is as below -
java -jar service-name.jar server service-name.yml
service-name.yml is a file that holds all configuration settings.
Can you suggest how do we configure application insights inside this yml file?
I don't know how DropWizard configuration reading works. But if there are hooks in the code to read the configuration, you can read all the configuration required for ApplicationInsights and manually configure in your code using TelemetryInitializers.

Elastic Beanstalk deployment of Spring Boot application - where to put the external application.properties

I am deploying a Spring Boot application to AWS Elastic Beanstalk using AWSCLI. I want to put an external application.properties file containing customer specification configurations (database credentials, etc.) in the same directory of the application. The application should pick up this properties file. How can I accomplish that? Are there any alternatives?
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
This above approach is what I would recommend for the scenario you described. I would not bother with having a separate directory on the application server for your configuration files. Spring Cloud Config is a great approach as it solves the problem you described and a few more.
You can alternatively specify them in an application-prod property like
server.port=5000
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.hibernate.ddl-auto=create
and specify an environment variable called SPRING_PROFILES_ACTIVE with the value prod making the beanstalk smart enough to pick values from out there.

Installing Web Deploy on IIS 7+ with Shared Configuration enabled

We have a web farm environment running IIS 7.5 on Windows 2008R2. We use shared configuration and web storage replication.
We tried to install Web Deploy (v3.5) on one of the servers but receive an error message saying that Web Deploy is not supported with Shared Configuration.
Is it possible to run Web Deploy in a shared configuration environment? If so how?
NOTE: We have figured this out so I am posting the answer here. There is little to no documentation that we could find on this topic so I thought it best to host the info here so the rest of the world can easily find it.
Yes Web Deploy can be installed on an IIS server using Shared Configuration. Here are the step we used to get it to work. Any comments, improvements or considerations are welcome.
Open IIS and select the server node in the tree.
Open the Shared Configuration in the Management section.
Uncheck Shared Configuration select Yes to copy the configuration to the local storage.
Do this to ALL servers that have been sharing configuration as you need to rebuild the configuration once Web Deploy is installed and reattach each server.
Install Web Deploy 3.5 (or newer) via the Web Platform Installer found here:
http://www.microsoft.com/web/gallery/install.aspx?appid=WDeploy
Installing Web Deploy will modify the authentication rules which will cause issues in a Shared Configuration environment so these rules need to be manually updated.
Open IIS and select the server node in the tree.
Open the Management Service Delegation module in the Management section (this module appears once Web Deploy is installed).
Edit the following rules and set the credentials to the a user that has access to the Shared Configuration. Typically a new account can be made that can be granted access to the Shared Configuration storage or use IIS service account. This will enable the web deployment agent to access the shared configuration with a domain account instead of the default local account.
createApp
recycleAPP
appPoolPipeline,appPoolNetFx
backupSettings
Restart the Web Deployment Agent service.
Restart the Web Management service.
Restart the IIS service.
Make sure you have disabled shared configuration on all servers.
Now to re-enable shared configuration, open IIS and select the server node in the tree.
Open the Shared Configuration in the Management section.
If this is the first server you need to export the configuration using the following steps (if not skip to next step):
Click Export Configuration...
Set the Physical Path to the shared configuration location and enter the appropriate encryption key.
You should see a success dialog if the export was successful.
Check Enable shared configuration.
Set the Physical Path to the shared configuration location and click Apply.
Enter the appropriate encryption key and click Ok.
Restart the IIS service.
You will then need to perform these steps again for each server using the shared configuration except you can skip step #14.

Resources