Stockage des paramètres de configuration dans les applications Azure Service Fabric et MVC

J'ai atteint le point où je dois déployer mon cluster de matrice de service sur Azure :) Outre les services avec état/sans état, j'ai 2 applications MVC. J'ai actuellement quelques paramètres dans les fichiers web.config (principalement des chaînes de connexion).Stockage des paramètres de configuration dans les applications Azure Service Fabric et MVC

Je prévois de configurer la génération/déploiement en continu à l'aide de Visual Studio Online, mais je n'ai pas encore pris cette décision.

Où sont les emplacements recommandés pour stocker les paramètres de configuration. J'ai besoin de paramètres pour 3 environnements différents (dev/test/prod).

Je trouve une référence, à un moment donné, pour stocker les paramètres de la définition de construction qui ressemble à un meilleur endroit pour stocker les informations d'identification de production que dans les fichiers de configuration qui sont une partie du code source pour les applications. J'ai besoin de limiter l'accès aux valeurs pour l'environnement de production et de les avoir dans les fichiers de configuration auxquels tous les développeurs ont accès ne semble pas être le meilleur moyen de le faire.

Tout livre blanc ou les meilleures pratiques en ce qui concerne ce que je devrais être au courant?

Source

2017-06-13 Tony Fabian

https://stackoverflow.com/questions/33928204/where-do-you-set-and-access-run-time-configuration -parameters-per-environment-fo Je stocke mes valeurs de configuration en utilisant une méthode similaire à celle-ci, puis utilise le remplacement de jeton sur VSTS avant la publication. Il y a peut-être un meilleur moyen, alors je ne poste pas cela comme une réponse! – Mardoxx

Merci. Je pense que c'est la seule façon d'éviter d'avoir le mot de passe de production dans le code source qui est un gros gros pas –

Après quelques considérations, j'ai conclu qu'il est préférable de stocker les valeurs dans un coffre-fort azur. Cela me permettra de meilleures options pour le script/déploiement/test comparé à maintenir les valeurs dans une définition de construction. –

Vous pouvez utiliser de publier les profils et les paramètres d'application du projet de structure de service pour stocker vos paramètres pour chaque environnement. Dans mon cas, j'ai un dev, un homologue et un environnement de production avec différentes chaînes de connexion à la base de données, j'ai donc créé des profils de publication nommés Cloud.Homolog.xml, Cloud.Production.xml et pour l'environnement de développement que j'utilise encore Local.5Node.xml. Ensuite, lorsque je veux déployer dans certains de ces environnements, je choisis le bon profil de publication.

Voici la documentation de multiples gestion de l'environnement:

Link

Source

2017-06-13 17:05:59

Je ne suis pas satisfait de cette solution car le mot de passe de production sera enregistré dans le système de contrôle de source et c'est exactement ce que je veux éviter. Merci pour le lien btw. Il contient beaucoup d'informations complètes. –

C'est la solution que je vais combiner avec le stockage des appset dans un Azure Vault. De cette façon, les informations sont gardées confidentielles car elles ne seront pas vérifiées dans le contrôle des sources, car le code ne contiendra que des références aux clés à la place des valeurs. https://docs.microsoft.com/fr-fr/azure/service-fabric/service-fabric-application-secret-management –

Le coffre-fort est très intéressant aussi, si vous découvrez comment stocker les mots de passe dans le coffre-fort et combiner avec Ceci, s'il vous plaît partager votre solution, parce que j'avais déjà essayé de stocker dans le coffre-fort clé, mais je n'ai pas découvert comment accéder au coffre-fort clé et récupérer cette valeur. –

Stockage des paramètres de configuration dans les applications Azure Service Fabric et MVC

Répondre

Questions connexes