Bonnes pratiques pour la configuration Azure?

Question

Ainsi, lorsque nous avons commencé notre migration Azure, nous avons migré nos paramètres web.config vers le fichier de configuration Azure .cscfg. Alors que cela fonctionne, et est joliment utile dans les environnements de test car je peux rapidement pirater la configuration, cela semble plutôt dangereux en production ... car je peux rapidement pirater la configuration. Plus formellement, cela signifie qu'il est facile pour quiconque ayant accès à la console de gestion Azure d'apporter des modifications incontrôlées à une instance de production Azure.

Cela me semble très mauvais.

Y a-t-il en pratique un utilitaire derrière le fichier .cscfg au-delà de la configuration de chaîne de diagnostic standard et ainsi de suite?

Answer 1

Nous aimons la flexibilité des fichiers .cscfg dans les tests, et nous Nous ne voulons pas avoir une base de code légèrement différente pour les tests et la production car nous pensons que notre environnement de test devrait être une réplique exacte de l'environnement de production ... sans quelques différences de configuration.

En même temps, nous sommes paranoïaques à propos de certains développeurs qui suppriment accidentellement le mauvais déploiement ou qui modifient le mauvais fichier/valeur .cscfg. Pour résoudre ce problème, nous avons créé deux abonnements, un pour les tests et un pour la production. Nous donnons à tous les développeurs accès à l'abonnement de test, mais seuls ceux qui sont responsables du déploiement ont accès à l'abonnement de production. Les ingénieurs de déploiement savent exactement ce qu'ils peuvent et ne peuvent pas faire dans un environnement de production (redémarrer/réimager des instances, supprimer des déploiements, etc.). Ils savent que la seule valeur .cscfg à toucher en production est la propriété "Instances count" (notre serveur de construction définit toutes les autres valeurs de production .cscfg).

Jusqu'à présent, cette configuration a très bien fonctionné pour nous.

Answer 2

Selon votre sécurité & politiques de conformité, vous pouvez avoir une solution app-paramètres personnalisés pour héberger toutes vos app-settings dans le stockage peut-être Azure ou SQL Azure ...

Il n'y a rien de plus « recommandé "mais il est extrêmement utile d'avoir les paramètres de l'application être disponibles pour le changement sans redéploiement ...

Pour faciliter la commutation entre les environnements dans Visual Studio, consultez une entrée de blog que j'ai récemment publié @http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx

Answer 3

Vous pouvez toujours utiliser web.config dans Azure pour les éléments de configuration que vous souhaitez conserver non configurables. Nous combinons les deux ...

pas si configurable dans ce cas, signifie que vous aurez besoin de redéployer les changer ...

Answer 4

L'ensemble du problème peut vraiment être utilisé en limitant simplement l'accès à Azure Management Console. Si plusieurs personnes doivent pouvoir être déployées, vous pouvez simplement créer des certificats à utiliser au lieu de leur donner accès à Azure Management Console.

Nous avons en fait notre environnement de construction reconfigurer nos fichiers de configuration lorsque nous déployons en production. Cela élimine fondamentalement le besoin d'entrer dans l'interface de gestion et la configuration finit toujours par être la même.