Partager via

Microsoft Azure Pack : Sites web - Étapes de préinstallation

  • Article

 

S’applique à : Windows Azure Pack

Les étapes de ce chapitre sont importantes pour une installation réussie du Microsoft Azure Pack : Sites web. Lisez chaque section attentivement et effectuez les actions requises. Les sections sont les suivantes :

Comparaison entre un environnement joint et un environnement non joint à un domaine

Créer des serveurs pour les rôles Sites Web

Conseil pour préparer vos disques durs virtuels ou vos serveurs

Préparer un serveur SQL pour contenir la base de données d'exécution de Windows Azure Pack : Sites web

Configurer des bases de données d'application SQL et MySQL pour les locataires

Configuration du pare-feu des rôles Sites Web

Configurer les rôles Serveur frontal, Serveur de publication, Traitement web, Serveur d'administration et de serveur de fichiers non préconfiguré (facultatif) pour l'accès entrant à partir d'Internet

Configurer Microsoft Azure Pack : Sites web pour utiliser des serveurs proxy

Modifier un contrôle de compte d'utilisateur pour l'accès distant

Configurer les mappages DNS pour le cloud Sites Web

Comparaison entre un environnement joint et un environnement non joint à un domaine

Microsoft Azure Pack : Sites web peut être installé dans un environnement joint ou non joint à un domaine (groupe de travail). Bien qu'un environnement de groupe de travail puisse être approprié pour des scénarios de développement ou de test, nous vous recommandons d'utiliser un environnement joint à un domaine pour les raisons suivantes :

  • Les utilisateurs peuvent utiliser Kerberos pour l'établissement de liaisons d'authentification, ce qui est beaucoup plus sûr que NTLM ou NTLM v2.

  • La gestion des utilisateurs et des informations d'identification est simplifiée.

  • Gestion améliorée grâce à des stratégies de groupe

Créer des serveurs pour les rôles Sites Web

Avant d'installer le cloud Sites web, préparez un serveur Windows Server 2012 R2 par rôle de site web (les serveurs peuvent être physiques ou virtuels). Ultérieurement, pour la haute disponibilité, vous pouvez ajouter plus d'un serveur par rôle. Pour une maintenance facile, utilisez des noms d'ordinateur descriptifs, comme ceux ci-dessous. La convention d'attribution de noms suggérée ici consiste à remplacer le « x » de chaque nom par « 1 » (en complétant avec des zéros si nécessaire), puis à incrémenter ce nombre au fur et à mesure que vous ajoutez des instances de serveur à un rôle.

  • SitesCNx : contrôleur de cloud de sites web

  • SitesMNx : serveur d'administration de cloud Sites web

  • SitesFEx : serveur frontal de cloud Sites web

  • SitesPBx : serveur de publication de cloud Sites web

  • SitesWWSx : traitement web partagé du cloud Sites web

  • SitesWWRx : traitement web réservé du cloud Sites web

  • SitesFSx : serveur de fichiers de cloud Sites web

Conseil pour préparer vos disques durs virtuels ou vos serveurs

  • Utilisez de nouvelles installations de Windows Server 2012 (Windows Server 2012 R2 est recommandé).

  • Ne colocalisez pas les rôles de sites Web. Chaque rôle de site Web doit avoir sa propre machine virtuelle ou son propre serveur.

  • Ne colocalisez pas les rôles de sites Web avec le portail d'administrateur ou de locataire, ou les serveurs d'API. Par exemple, les rôles API de contrôleur de cloud Sites Web et d'administrateur doivent se trouver dans des machines distinctes.

  • Il est recommandé d'utiliser des serveurs joints à un domaine, comme indiqué précédemment.

  • Si vous utilisez des machines virtuelles, il est conseillé de prendre des instantanés de chaque rôle aux jointures suivantes :

    • Avant l'installation

    • Après l'installation

    • Après la configuration

Notes

Pour éviter des erreurs NetBIOS et la troncation de nom automatique, veillez que les noms d'ordinateur que vous choisissez aient plus de 15 caractères.

Préparer un serveur SQL pour contenir la base de données d'exécution de Windows Azure Pack : Sites web

Pour la base de données d'exécution des sites Web, préparez une base de données SQL Server. En tant que meilleure pratique, tous les rôles de SQL Server, notamment la base de données d'exécution des sites Web et la base de données d'API de gestion des services qui en fait partie, doivent être sur des machines distinctes.

  • Pour le test, le développement, ou à des fins de « preuve de concept », utilisez SQL Express 2012 SP1 ou une version ultérieure. Pour télécharger des informations, consultez Télécharger SQL Server 2012 Express avec SP1.

  • À des fins de production, utilisez une version complète de SQL 2012 SP1 ou ultérieur. Pour plus d’informations sur l’installation de SQL Server, consultez Installation pour SQL Server 2012.

  • Le mode d'authentification mixte doit être activé.

  • Le runtime des sites Web SQL Server doit être accessible depuis tous les rôles Sites Web.

  • Pour tous les rôles SQL Server, vous pouvez utiliser une instance par défaut ou une instance nommée. Toutefois, si vous utilisez une instance nommée, assurez-vous de démarrer manuellement le service SQL Browser et d’ouvrir le port 1434.

Pour plus d'informations, voir Using SQL Server or MySQL with Windows Azure Pack.

Configurer des bases de données d'application SQL et MySQL pour les locataires

Votre environnement peut nécessiter la prise en charge d'applications de base de données SQL Server et/ou MySQL de locataire. Si tel est le cas, vous devez installer et configurer des instances SQL Server et MySQL distinctes dédiées à l'utilisation des bases de données d'application des locataires.

Configuration de serveur requise pour une base de données d'applications SQL Server de locataire

  • Le mode d'authentification mixte doit être activé.

  • Le serveur SQL doit être accessible depuis les rôles Traitement Web et Serveur de publication

  • Le serveur SQL doit être accessible depuis les rôles d'API Admin et Locataire

Configuration de serveur requise pour une base de données d'applications MySQL de locataire

  • Avec l'interface de ligne de commande, l'utilisateur racine doit disposer d'un accès à distance avec un mot de passe. Exemple de syntaxe :

    GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;

    Pour plus d'informations sur l'interface de ligne de commande MySQL, consultez la Documentation MySQL.

  • Le serveur MySQL doit être accessible depuis les rôles Traitement web et Serveur de publication

  • Le serveur MySQL doit être accessible depuis les rôles d'API Admin et Locataire

  • Pour la prise en charge d'IPv6, utilisez MySQL version 5.5.30 ou ultérieure

Pour plus d'informations, voir Configure SQL Server and MySQL Application databases for tenant use. Pour plus d'informations sur la mise à l'échelle de SQL Server à des fins de production, consultez Configuration de SQL Server pour la haute disponibilité.

Configuration du pare-feu des rôles Sites Web

Si vous implémentez Microsoft Azure Pack : Sites web entièrement dans un environnement intranet, un accès Internet public n'est pas nécessaire. (Même si l'accès à Internet est nécessaire, une topologie de réseau bien planifiée peut empêcher l'exposition des rôles Sites Web directement sur Internet.)

Les paramètres de pare-feu du serveur doivent être configurés avant d'ajouter un rôle Sites Web au serveur. La liste suivante résume les conditions requises pour l'accès Internet pour chaque rôle de site web :

  • Serveur d'administration - Ne nécessite pas d'accès Internet public.

  • Serveur de fichiers - Ne nécessite pas d'accès Internet et ne doit jamais être accessible via Internet.

  • Contrôleur de sites Web - Exige un accès HTTP sortant mais non entrant. Le contrôleur a besoin d'un accès sortant, de sorte à pouvoir télécharger des dépendances de logiciel pour l'installation des rôles Sites Web.

  • Traitements Web - Ne nécessitent jamais un accès Internet entrant, mais peuvent éventuellement avoir besoin d'un accès sortant si (par exemple) une application Web utilise un service Web externe.

  • Les serveurs frontaux peuvent exiger ou non un accès réseau direct entrant afin d'accepter les demandes clientes pour les sites Web, selon la topologie du réseau.

  • Les serveurs de publication peuvent exiger ou non un accès réseau direct entrant afin d'accepter les demandes de publication FTP et WebDeploy, selon la topologie du réseau.

Pour les rôles de serveur frontal et de serveur de publication, évitez l'accès Internet direct si vous disposez de programmes d'équilibrage de charge ou de périphériques NAT en amont qui gèrent la traduction d'adresses réseau entre adresses privées et publiques.

Configurer les rôles Serveur frontal, Serveur de publication, Traitement web, Serveur d'administration et de serveur de fichiers non préconfiguré (facultatif) pour l'accès entrant à partir d'Internet

Sur les serveurs qui deviendront les rôles Serveur frontal, Serveur de publication, Traitement web et Serveur d'administration, autorisez l'accès entrant aux services suivants. Vous devez également appliquer ces paramètres pour le rôle de serveur de fichiers, si vous utilisez l'option de serveur de fichiers non préconfiguré.

  • Partage de fichiers et d'imprimantes (SMB-In)

  • Windows Management Instrumentation (WMI-In)

Pour configurer l'accès entrant, utilisez les commandes netsh suivantes :

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

Notes

Les cartes réseau pour les rôles de serveur frontal et de serveur de publication doivent être configurées dans le Pare-feu Windows pour utiliser le profil public.

Configurer Microsoft Azure Pack : Sites web pour utiliser des serveurs proxy

Si vous utilisez une adresse proxy pour l'accès sortant vers Internet, vous devez permettre aux sites web d'utiliser l'adresse proxy avant de pouvoir installer et exécuter Microsoft Azure Pack : Sites web.

Notes

L'authentification d'une batterie de serveurs Web via un serveur proxy n'est pas prise en charge actuellement. Cette section décrit les étapes requises pour installer et exécuter Microsoft Azure Pack : Sites web derrière un serveur proxy. Elle n'explique pas comment configurer des serveurs proxy.

Pour permettre à la batterie de communiquer via un proxy sans authentification, exécutez les commandes PowerShell suivantes avec des privilèges d'administrateur sur le contrôleur. Remplacer <ProxyAddress> par l’adresse du proxy

Import-Module WebSites

Set-WebSitesConfig Global -ProxyEnabled True -ProxyAddress <ProxyAddress>

Notes

Lors de l'installation du service Sites Web pour Windows Azure Pack, exécutez le programme d'installation de la plateforme Web avec un compte qui peut s'authentifier sur le proxy.

Autorisez Microsoft Updates à accéder au service Microsoft Azure Pack : Sites web derrière le proxy

En tant qu'étape facultative lorsque Microsoft Azure Pack : Sites web est situé derrière un proxy, il est suggéré d'activer Microsoft Updates afin qu'il puisse fonctionner correctement avec Microsoft Azure Pack : Sites web. Pour ce faire, exécutez les commandes PowerShell suivantes avec des privilèges d’administration sur le contrôleur, où l’utilisateur <ProxyUser> avec mot de passe <ProxyUserPassword> peut s’authentifier auprès du proxy :

Import-Module WebSites

New-WebSitesConfig Credential -CredentialName ProxyUserCredential -UserName <ProxyUser> -Password <ProxyUserPassword> -CredentialType SystemCredential

Modifier un contrôle de compte d'utilisateur pour l'accès distant

Sur chaque serveur à utiliser pour un rôle Microsoft Azure Pack : Sites web, désactivez le contrôle de compte d'utilisateur (UAC) pour les connexions distantes comme décrit ci-dessous. Cela autorise l'administration à distance.

Notes

La configuration UAC locale reste inchangée.

  1. Exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges :

    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

  2. Redémarrez le serveur.

Configurer les mappages DNS pour le cloud Sites Web

Pendant l'installation du cloud Sites Web, lorsque vous configurez le contrôleur Sites Web, un message vous demande le nom de domaine par défaut à utiliser pour les sites Web des utilisateurs finaux.

Par défaut, les sites Web sont créés sous un domaine par défaut. Une fois qu'un site Web est créé, les utilisateurs peuvent ajouter des noms de domaines personnalisés à chaque site Web. Les sites web de locataire peuvent être configurés pour prendre en charge des domaines personnalisés, alors que Microsoft Azure Pack : Sites web ne met pas à jour les enregistrements DNS personnalisés. Pour vérifier que tous les sites Web exposés à Internet sont configurés avec les attributions d'adresse IP appropriées, suivez les instructions ci-dessous.

Pour un domaine donné, tel que Contoso.com, créez les enregistrements A DNS suivants :

Nom d’hôte

Adresse IP pour

*

Serveur(s) Web frontal(aux)

*.scm

Serveur(s) Web frontal(aux)

ftp

Serveur(s) de publication

Publier

Serveur(s) de publication

Ce schéma de mappage permet aux utilisateurs de se connecter à la fois https://www.contoso.com et https://contoso.com de gérer leurs sites. Le portail de gestion des administrateurs et le portail de gestion des locataires sont décrits dans la rubrique Déployer Windows Azure Pack pour Windows Server.

Dans l'exemple de configuration ci-dessus, les sites Web créés par l'utilisateur sont créés à l'aide de domaines enfants, tels que site1.contoso.com, site2.contoso.com.

Lorsque les utilisateurs publient du contenu sur leurs sites Web au moyen de Web Deploy ou FTP, ils utilisent publish.contoso.com ou ftp.contoso.com respectivement. La publication de contenu via Git utilise *.scm.contoso.com.

Notes

Aucun domaine spécial n'est nécessaire pour ce déploiement. Utilisez un sous-domaine comme my.yourdomain.com sous un domaine existant.

Voir aussi

Déployer Windows Azure Pack : Sites web