Cette question peut ne pas se rapporter spécifiquement aux machines virtuelles Azure, mais j'espère que Azure offre un moyen plus facile de le faire que Amazon EC2.
J'ai des applications longues exécutées sur plusieurs machines virtuelles Azure (c'est-à-dire des sites Web non azur ou des rôles [PAAS]). Ce sont des applications de console simples / Windows Services. Parfois, je ferai une actualisation du code et besoin de arrêter ces processus , mettre à jour le code / binaires , puis redémarrez ces processus .
Dans le passé, j'ai tenté d'utiliser des pstools ( Psexec ) pour le faire à distance, mais cela semble être un tel piratage. Y a-t-il un meilleur moyen de tuer l'application à distance, de rafraîchir le déploiement et de redémarrer l'application?
Idéalement, il y aurait une application " Publish Console App " équivalent de Visual Studio qui me permettrait de déployer le code comme s'il s'agissait d'un site Web Azure, mais je suppose que ce n'est pas possible.
Merci beaucoup pour toute suggestion!
3 Réponses :
Il y a un certain nombre de moyens "corrects" pour perfectionner votre tâche.
Si vous exécutez Windows Azure Application - Il existe un simple guide sur MSDN < / a>.
Mais si vous devez le faire avec une application de console régulière, vous avez un problème.
Le Microsoft-Way est d'utiliser WMI - bonne technologie pour tout type de gestion des serveurs Windows distants. Je suppose que WMI devrait être correct pour vos besoins.
Et la dernière façon: Installez Git sur chaque VM Azure et écrivez un script simple Server planifié pour exécuter toutes les 5 minutes pour mettre à jour le code du référentiel, construire, tuer l'ancien processus et commencer une nouvelle. Publiez votre mise à jour du référentiel, c'est tout.
Définitivement pirater, mais cela fonctionne même pour des machines non-fenêtres.
merci pour votre aperçu. WMI a des opportunités intéressantes.
Un modèle commun consiste à stocker des éléments, tels que les applications de ligne de commande, dans Windows Azure Blob Stockage. Je fais cela fréquemment (par exemple: je stocke tous les fichiers binaires MongoDb dans une blob, zip'd, avec une fermeture à glissière par version). Lors de la démarrage VM, j'ai une tâche qui télécharge le zip de BLOB sur le disque local, décale vers un dossier local et démarre le processus Mongod.exe (ceci s'applique également bien à d'autres applications de console). Si vous avez une installation plus complexe, vous auriez besoin de saisir un MSI ou un autre type d'installateur automatisé. Deux bonne chose à propos de stocker ces applications dans Blob Stockage:
Lors de la mise à jour de l'application de la console: Vous pouvez télécharger une nouvelle version sur Blob Stockage. Maintenant, vous avez quelques façons de signaler mes VM à mettre à jour. Par exemple:
Ceux-ci s'appliquent bien aux exe autonomes (ou exe XCopy-déployables). Pour les MSI nécessitant des autorisations de niveau administrateur, celles-ci doivent être exécutées via un script de démarrage. Dans ce cas, vous pourriez avoir un événement de changement de configuration, qui serait géré par vos instances de rôle (comme décrit ci-dessus), mais vous auriez les instances de redémarrage, ce qui leur permettrait d'exécuter le MSI via le script de démarrage.
Merci pour votre réponse bien pensée. Il y a quelques bons concepts là-bas ... jamais pensé à redémarrer comme composante des déploiements de code, mais si nous avons suffisamment de machines en cours d'exécution, je suppose que cela pourrait fonctionner. Je l'aime bien!
vous pourriez
Host pour extraire (et décompressez) le emballez dans un dossier distant
- Utilisez PowerShell Remoting vers
hôte pour exécuter un installer.ps1 à partir du contenu package (c.-à-d. Télécharger et configurer) comme vous le souhaitez.
Cette même approche peut être effectuée avec votre Entrée-PSSession -Computername $ env: ComputerNameName Pour déployer rapidement une stratégie de construction locale qui signifie que vous utilisez une stratégie identique pour Dev, Production et Test A la livraison continue .
Une optimisation potentielle que vous pouvez effectuer ultérieurement (si nécessaire) est (pour une construction locale) pour couper les étapes 2 et 3, c'est-à-dire que vous prétendez que vous avez emballé, téléchargées, téléchargées et déballées et fournissez simplement le dossier emballage à votre installation install.ps1 comme dossier distant et exécutez votre install.ps1 de manière interactive dans une session non rectotée.
Une variation commune sur le thème ci-dessus consiste à utiliser un mécanisme efficace de transfert de fichiers et de versions tels que GIT (ou (fright) TFS!) Pour obtenir le "poussé quelque part à la fin de la construction" et "tirer au début du déploiement" Des portions de l'exercice (sites Web Azure propose un point de terminaison TFS ou Git intégré qui rend chaque «poussée» implicitement d'inclure une «tirage» à l'extrémité extrême).
Si votre code est XCOPY déployable (et Shadow Copied), vous pouvez même avoir une image d'application complète dans Git et simplement faire une pioche pour mettre à jour votre site (avec ou sans étape 4 composée d'un PowerShell Remoting Execute of an install.ps1 ).
Lien vers Git Déployer pour Azure Sites Web Article windowsazure.com/en-us/develop/net/common-tasks/.../a>