Fermer

avril 2, 2019

Mise en route de Chef Habitat sous Windows

Mise en route de Chef Habitat sous Windows


Présentation générale

Cet article est le deuxième de notre série sur Chef Habitat. Pour une introduction à Habitat, veuillez vous reporter à notre post initial . Dans cet article, nous allons examiner de près Habitat dans un contexte Windows. Il existe quelques différences entre Habitat sous Windows et Linux ou Mac, que nous soulignerons. De plus, nous vous expliquerons comment créer vos propres applications Windows dans Habitat.

Habitat sous Windows utilise PowerShell au lieu des scripts shell Linux pour créer des packages et procéder à leur installation. Les packages dépendants doivent fonctionner sur Windows ou sur plusieurs plates-formes, telles que .NET Core ou Java. PowerShell Core est utilisé pour Habitat Studio sous Windows, fournissant une salle blanche pour l'utilisation de packages. Vous pouvez également exécuter Habitat Studio dans un conteneur Windows Server 2016 pour une isolation supplémentaire. Outre les applications Windows modernes, Habitat prend en charge la création, l’emballage et le déploiement des applications Windows héritées. Voir cet article de Chef pour plus d'informations et celui celui pour les applications Windows héritées.

Chef a créé des packages pour PowerShell Core, les outils de compilation Visual Studio, 7-Zip, WIX, Fichiers binaires redistribuables .NET Core et Visual C ++ pouvant être utilisés comme dépendances dans votre plan Habitat pour créer des packages d'application personnalisés. Une fois le package HART existant, vous pouvez le déployer directement sur des serveurs physiques ou virtuels, ou exporter le package pour des environnements d'exécution cibles tels que Docker, Kubernetes ou Cloud Foundry. Les packages HART peuvent également être téléchargés vers un générateur public ou privé pour les déploiements archivés et futurs.

Notre exemple d'application, Contoso University est écrit en ASP.NET et basé sur Microsoft Entity Framework Core. Contoso University est une application basée sur une base de données permettant de gérer les étudiants, les cours et les informations relatives aux instructeurs dans une université fictive. Si vous voulez ignorer le didacticiel et voir immédiatement le code terminé, je l'ai poussé vers ce référentiel .

Conditions préalables

Bon nombre de ces conditions préalables s'appliquent à la configuration du poste de travail Linux. Les comptes d'utilisateur sont requis pour GitHub, Habitat Builder et Docker Hub.

  1. Google Chrome – Pour parcourir le modèle d'application. Google Chrome est le navigateur le plus compatible pour notre application.
  2. Git – Pour la gestion du code source et le clonage du référentiel source.
  3. GitHub – Un compte GitHub est utilisé pour l'authentification auprès d'Habit Builder. ] Habitat Builder – Un compte Habitat Builder est nécessaire pour créer et publier des packages Habitat.
  4. Docker et Docker Hub – Nous allons utiliser Docker pour exécuter notre application après la création du package Habitat. .

Configuration du poste de travail

Chocolatey est un gestionnaire de packages open source, géré par la communauté (similaire à Homebrew sur Mac). Chocolatey est utilisé par un certain nombre de sociétés, y compris Chef. Les packages Chocolatey sont contrôlés contre VirusTotal . Toutefois, un processus de contrôle plus approfondi doit être adopté si vous utilisez ces packages dans des environnements de production. Chocolatey illustre ici le fonctionnement des gestionnaires de packages et la simplification de la configuration du poste de travail sous Windows.

Installer Choclatey, Habitat, Git et Google Chrome

Installer Choclatey avec PowerShell:

 Set-ExecutionPolicy Bypass -Scope Processus-force; iex ((New-Object System.Net.WebClient) .DownloadString (' https://chocolatey.org/install.ps1 ')) 

Installez Chef Habitat:

 choco install habitat -y 

Installez Google Chrome:

 choco installez googlechrome -y 

Installez Git et actualisez le chemin système:

 choco installez git -y 
refreshenv

Configurez Habitat

. Démarrez la configuration de l'interface de ligne de commande Habitat en utilisant avec la configuration . Tout d'abord, pointez l'interface de ligne de commande Habitat sur une instance Habitat Builder. Cela peut être un générateur sur site ou un générateur hébergé publiquement. Si vous choisissez Yes le système d'extrémité Builder sur site vous sera demandé (les étapes suivantes supposent l'utilisation du générateur Builder public):

 Se connecter à une instance bldr sur site? Oui 
Entrez un constructeur local

Entrez le nom de l'origine créé sur le site Habitat Public Builder:

 Configurer une origine par défaut? Oui 
Nom d'origine par défaut: manny-rodriguez

Une paire de clés d'origine permet un téléchargement sécurisé vers le dépôt de constructeur. Créez-en une maintenant, si nécessaire:

 Créez une clé de signature publique pour le dépôt de constructeur? Oui 

Ajoutez un jeton d'accès personnel Habitat à votre configuration CLI pour le télécharger dans Builder et vérifier l'état du travail:

 Configurer un jeton d'accès personnel Habitat par défaut? Oui 
Jeton d'accès personnel Habitat:

La configuration vous invite maintenant à propos d'une passerelle de contrôle (CTL). Ce sera couvert dans un blog séparé. Entrez Non pour continuer:

 Configurer un secret Habitat CTLGateway par défaut? Non 

Ajoutez un lien de liaison au chemin système pour faciliter la recherche des fichiers binaires de package:

 Ajouter un lien bin au répertoire Path? Oui 

Choisissez d'activer ou de désactiver l'analyse de l'utilisation:

 Activer l'analyse? Oui 

Créer un package et déployer une application Windows ASP.NET

Vous êtes maintenant prêt à commencer à travailler avec Habitat!

Habitat exige que vous déclariez toutes les dépendances de l'application dans un plan Habitat. Sous Windows, ce fichier est généralement nommé plan.ps1 . Voir ici pour plus d'informations.

Commençons par télécharger le code, développer les archives et naviguer dans le répertoire approprié:

 cd c: 
Invoke-Webrequest -uri https://code.msdn.microsoft.com/ASPNET-MVC-Application-b01a9fe8/file/169473/2/ASP.NET%20MVC%20Application%20Using%20Entity%20Framework%20Code%20First.zip&19459006] -OutFile contosouniversity.zip
Expand-Archive contosouniversity.zip
cd contosouniversity

Nous commençons maintenant à créer notre plan pour l'habitat. La commande hab plan init est utile pour commencer ici:

 hab plan init --windows 

La structure de répertoires résultante est présentée ci-dessous:

 habitat de l'arbre / F 
| default.toml
| plan.ps1
| LISEZMOI.md
├── config
hooks

Variables et dépendances de package

$ pkg_name et $ pkg_origin sera automatiquement mis à jour par Habitat basé sur le contenu du référentiel local. $ pkg_mainataner et $ pkg_license doivent être mis à jour manuellement avec les détails appropriés. Ces variables sont transmises aux fonctions et aux fichiers de script utilisés comme modèles pour l’installation et la configuration du package:

 $ pkg_name = "contosouniversity" 
$ pkg_origin = "myorigin" $ pkg_version = "0.1.0"
$ pkg_maintainer = "Manny Rodriguez "
$ pkg_license = @ ("Apache-2.0")

Les dépendances de paquets doivent être déclarées à ce stade. Utilisez la variable $ pkg_deps pour les dépendances de déploiement / exécution. Ici, nous spécifions core / dsc en tant que dépendance de package, qui est un package principal représentant la configuration DSC (PowerShell Desired State Configuration). Cela permet à toute configuration ne se trouvant pas dans le hook de exécuter (décrit plus bas) d'être implémentée. Nous demandons à PowerShell DSC de configurer SQL Server 2017 et l'application ASP.NET:

$ pkg_deps = @ ("core / dsc-core")

$ pkg_build_deps concerne les dépendances au moment de la construction. core / nuget est requis pour l'extraction des packages .NET dépendants:

 $ pkg_build_deps = @ ("core / nuget") 

Nous utilisons $ pkg_binds pour spécifier les détails de connexion à la base de données:

 $ 1965 pkg_binds = {"database" = "nom d'utilisateur mot de passe port"} 

Logique de construction

Pour notre application, nous devons remplacer la logique de construction standard afin de nous assurer que notre package ASP.NET est construit correctement. Plus précisément, nous annulons les fonctions Invoke-Build et Invoke-Install . Une différence ici entre la syntaxe Linux Bash et PowerShell réside dans le fait que les fonctions Bash sont définies à l'aide de do au lieu de fonction :

 fonction Invoke-Build {
Copie-Item $ PLAN_CONTEXT / ../* $ HAB_CACHE_SRC_PATH / $ pkg_dirname -recurse -force
nuget restore "$ HAB_CACHE_SRC_PATH / $ pkg_nom-en-santé" https://www.nuget.org/api/v2"
nuget installez MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3 -OutputDirectory $ HAB_CACHE_SRC_PATH / $ pkg_dirname /
$ env: VSTool $ HAB_CACHE_SRC_PATH / $ pkg_dirname / MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3 / tools / VSToolsPath "
." "Env: SystemRoot Microsoft.NET Framework64 v4.0.30319 MSBuild.exe" $ HAB_CACHE_SRC_PATH / $ pkg_dirname / C # / $ pkg_name / $ {pkg_name} .csproj "/ t: Construire /p:VisualStudioVersion=14.0
if ($ LASTEXITCODE -ne 0) {
Write-Error "La construction de la dotnet a échoué!"
}
}

function Invoke-Install {
. "$ Env: SystemRoot Microsoft.NET Framework64 v4.0.30319 MSBuild.exe" " $ HAB_CACHE_SRC_PATH / $ pkg_dirname / C # / $ pkg_name / $ {pkg_name} .csproj "/ t: WebPublish / p: WebPublishMethod = FileSystem / p: publishUrl = $ pkg_prefix / pkg_prefix www /
} La configuration de notre application ASP.NET est définie dans un fichier default.toml . Les valeurs de configuration sont transmises aux fichiers appropriés lors de la construction de l'application. Nous voyons ci-dessous que le port d'écoute de l'application est spécifié, ainsi que le pool d'applications IIS, le nom de l'application et le nom du site. PowerShell DSC utilise ces valeurs pour configurer correctement IIS. Si l'un de ces éléments de configuration devait changer, apportez les mises à jour dans le fichier default.toml puis transmettez ces modifications au superviseur de l'habitat à l'aide de hab config et appliquez pour appliquer les mises à jour:

 port = 8099 
app_pool = "hab_pool"
app_name = "hab_app"
site_name = "hab_site
la configuration est valide --remote-sup =
hab1.mcompagnie.com maapp .prod 1 /tmp/newconfig.toml

Plus sur PowerShell DSC

PowerShell DSC est la méthode préférée de Microsoft pour la gestion de la configuration de Windows, qui utilise PowerShell pour les tâches de bas niveau et la création de scripts, ainsi que DSC pour fournir idempotent Configurations pouvant être appliquées et exécutées uniquement en cas de modification du serveur nécessitant des corrections. Microsoft fournit des ressources DSC, telles que xWebAdministration pour le développement rapide de configurations devant être appliquées à un ou plusieurs serveurs. , ainsi que des instructions sur comment créer des ressources personnalisées. Cela s’intègre parfaitement à Habitat, vous permettant de définir l’état souhaité pour vos applications. Les variables de plan (de plan.ps1 ) sont utilisées pour mettre à jour le script PowerShell basé sur un modèle avec les valeurs correctes:

 Configuration NewWebsite 
{
Import-DscResource -Module xWebAdministration
Node ' localhost '{
WindowsFeature ASP
{
Ensure = "Présent"
Name = "Web-Asp-Net45"
}
xWebAppPool {{cfg.app_pool}}
{
Name = "{{cfg.app_pool}}"
Ensure = "Présent"
State = "Démarré"
}
xWebsite {{cfg.site_name}} (19459036] {1945}
Ensure = "Present"
Name = "{{cfg.site_name}}"
State = "Démarré"
PhysicalPath = Resolve-Path "{{pkg.svc_path}}"
ApplicationPool = "{{cfg.app_pool}}"
BindingInfo = @ (
MSFT_xWebBindingInformation
{
Protocole = "http"
Port = {{cfg.port}}
}
)
}
xWebApplication {{cfg.app_name}}
{
Name = "{ {cfg.app_name}} "
Website =" {{cfg.site_name}} "
WebAppPool =" {{cfg.app_pool}} "
PhysicalPath = Resolve-Path" {{pkg.svc_var_path}] } "
Ensure =" Present "
}
}
}

Définition de base de données con Logique de connexion

Pour vous connecter à la base de données, vous devez exécuter les étapes suivantes afin de créer la configuration permettant de vous connecter au serveur SQL.

Dans la section suivante, Lifecycle Event Handlers (Hooks), le code est affiché.

Le code PowerShell ci-dessous analyse le fichier csproj pour le fichier web.config et en crée un nouveau qui peut être mis à jour avec la chaîne de connexion appropriée:

 Copier-élément .C # ContosoUniversityWeb.config .habitatconfig 
Remove-Item .C # ContosoUniversityWeb * .config
[xml] $ xml = Obtenir-Contenu .C # ContosoUniversityContosoUniversity.csproj
$ nodes = $ xml.Project.ItemGroup.Content | ? {$ _. Include -like "Web. *"}
$ nodes | % {$ _. ParentNode.RemoveChild ($ _)}
$ f = Resolve-Path .C # ContosoUniversityContosoUniversity.csproj
$ xml.Save ($ f)

Mettre à jour le web.config à l'habitat / config avec le code ci-dessous:

web.config

 
      
  

Le code.config modélisé devra être mis à jour pendant l'init hook avec le code ci-dessous:

Mise à jour d'Init Hook

 Set-Location {{pkg. svc_path}} var
 Nouvel-Nom-Nom Web.config -ItemType SymbolicLink -target "{{pkg.svc_config_path}} / Web.config" -Force | Out-Null 

Une dernière étape est nécessaire. Le hook d’exécution doit pouvoir mettre à jour les autorisations du fichier web.config. Ajoutez le code ci-dessous au point d'exécution:

Mise à jour du pointage

 Import-Module "{{pkgPathFor" core / dsc-core "}} / Modules / DscCore"
 Start-DscCore (Join-Path {{pkg.svc_config_path}} website.ps1) NouveauSite Web
$ pool = "{{cfg.app_pool}}"
 $ access = New-Object System.Security.AccessControl.FileSystemAccessRule "pool IPO APPPOOL $", "ReadAndExecute", "Autoriser"
 $ acl = Get-Acl "{{pkg.svc_config_path}} / Web.config"
$ acl.SetAccessRule ($ access)

$ acl | Set-Acl "{{pkg.svc_config_path}} / Web.config" essayer { ...

Gestionnaires d'événement du cycle de vie (crochets)

Sous Windows, PowerShell Core est utilisé dans le plan Habitat pour mettre en œuvre des crochets fondés sur des événements qui se produisent tout au long du cycle de vie des applications / services. . Dans notre exemple, nous nous concentrerons sur les crochets init et (ceux-ci sont les plus courants).

Le crochet init s'exécute lorsque le package d'application est initialement installé et peut être utilisé pour vérifier que certains fichiers sont disponibles ou que des éléments de configuration sont en place:

Init Hook

 Set-Location {{pkg.svc_path}}
 if (Test-Path var) {Remove-Item var -Recurse -Force}
 New-Item -Name var -ItemType Junction -target "{{pkg.path}} / www" | Out-Null
 Set-Location {{pkg.svc_path}} var
 Nouvel-Nom-Nom Web.config -ItemType SymbolicLink -target "{{pkg.svc_config_path}} / Web.config" -Force | Out-Null 

Le hook run est exécuté après le hook init soit au démarrage ou à la mise à jour du package d'application, soit à la modification de la configuration du package. Le hook run est utilisé dans notre cas pour préparer le serveur à l'installation de l'application et pour démarrer le service lui-même. Là encore, dans notre cas, les ressources PowerShell DSC sont disponibles. Ils sont téléchargés à partir de la galerie PowerShell, un référentiel public hébergé par Microsoft, bien qu'ils puissent également être téléchargés ailleurs. Des autorisations sont également définies pour la configuration IIS dans notre hook run . N'importe quel code PowerShell arbitraire peut être utilisé ici pour configurer l'application:

Run Hook

 # Le flux Powershell Progress peut parfois interférer 
# avec la sortie du superviseur. Non critique, désactivez-le.
$ ProgressPreference = "SilentlyContinue"
# Nous devons installer la ressource DSC xWebAdministration. # Habitat tient ses crochets à l'intérieur de Powershell Core mais DSC # les configurations sont appliquées dans un processus WMI hébergé par # Windows Powershell. Pour que Windows Powershell puisse localiser # la ressource installée, elle doit être installée sous Windows # Powershell au lieu de Powershell Core. Nous pouvons utiliser Invoke-Command # et pointez sur localhost sur "distant" de Powershell Core vers # Windows Powershell. Invoke-Command -ComputerName localhost -EnableNetworkAccess { $ ProgressPreference = "SilentlyContinue" Write-Host "Vérification du fournisseur de paquet de pépites ..." if (! (Get-PackageProvider -Name nuget -ErrorAction SilentlyContinue -ListAvailable)) { Write-Host "Installation du fournisseur de pépites ..." Install-PackageProvider -Name NuGet -Force | Out-Null
}
Write-Host "Vérification du module PS xWebAdministration ..." if (! (Get-Module xWebAdministration -ListAvailable)) { Write-Host "Installation du module PS xWebAdministration ..."
Module d'installation xWebAdministration -Force | Out-Null }
}

# Utilisation du module Powershell dans le package dsc-core # qui permet d'appliquer des configurations DSC dans Powershell # Noyau simple. Module d'importation "{{pkgPathFor" noyau / dsc-core "}} / Modules / DscCore" Start-DscCore (Join-Path {{pkg.svc_config_path}} website.ps1) NouveauSite Web # Le svc_config_path manque d'une ACL pour le groupe USERS # nous devons donc nous assurer que l'utilisateur du pool d'applications peut accéder à ces fichiers $ pool = "{{cfg.app_pool}}" $ access = New-Object System.Security.AccessControl.FileSystemAccessRule `
" Pool IIS APPPOOL ",`
"ReadAndExecute", ` "Autoriser" $ acl = Get-Acl "{{pkg.svc_config_path}} / Web.config" $ acl.SetAccessRule ($ access) $ acl | Set-Acl "{{pkg.svc_config_path}} / Web.config" # Le pointeur doit être exécuté indéfiniment sinon le superviseur # pensera que le service est terminé et bouclera # essayant de le redémarrer. L’application DSC ci-dessus commence notre # application dans IIS. Nous allons continuellement interroger notre application # et ferme proprement que si l'application s'arrête # répondant ou si le service Habitat est arrêté ou # non chargé. essayer { Write-Host "{{pkg.name}} est en cours d'exécution" $ en cours = $ vrai while ($ running) {
Start-Sleep -Seconds 1 $ resp = Invoke-WebRequest "http: // localhost: {{cfg.port}} / {{cfg.app_name}}" -Method Head if ($ resp.StatusCode -ne 200) {$ running = $ false} } }

prise { Write-Host "Le contrôle {{pkg.name}} HEAD a échoué"
}

finalement { # Ajoutez ici n'importe quel nettoyage qui sera exécuté après que le superviseur ait arrêté le service Write-Host "{{pkg.name}} s'arrête ..." . "$ Env: SystemRootSystem32inetsrvappcmd.exe" arrêtez l'apppool "{{cfg.app_pool}}" . "$ Env: SystemRootSystem32inetsrvappcmd.exe" site d'arrêt "{{cfg.site_name}}" Write-Host "{{pkg.name}} est arrêté"
}

Création du package

Habitat Studio est une salle blanche permettant de créer et de tester vos packages Habitat. Sous Windows, Studio expose le système Windows, les principaux services Habitat et les répertoires sources de l'application. Le Studio téléchargera les paquetages manquants requis ou mettra à jour tout paquet préinstallé lors du démarrage. Le démarrage peut donc prendre quelques minutes de plus. Lorsque vous utilisez Docker pour exécuter Habitat Studio, les conteneurs Windows sous-jacents sont extraits, ce qui peut également prendre du temps. L'exécution de la commande build dans le studio va rassembler les dépendances du paquet et le code source (il peut s'agir d'installations binaires pour les applications COTS) et assembler un paquet HART (Habitat Artifact) à des fins de test et de distribution:

 hab studio enter -W 

ou

 $ env: HAB_DOCKER_OPTS = "- 2 Go de mémoire -p 80: 8099" 
entré par le studio -D
build

Tester localement le paquet sur l'habitat

À tester le paquet localement dans Habitat Studio, exécutez les commandes ci-dessous. Cela installera et configurera SQL Server 2017, IIS, ASP.NET et notre exemple d'application. Après avoir chargé le paquet core / sqlserver, nous vérifions le journal Habitat Supervisor afin de nous assurer qu’il est pleinement opérationnel avant de charger d’autres paquets dépendants:

 hab svc load core / sqlserver 
Get-SupervisorLog
sqlserver.default hook [post-run] ] :( HK): 1> 2> 3> 4> 5> 6> Configuration de l'utilisateur de l'application terminée
hab svc charger manny-rodriguez / contosouniversity --bind database: sqlserver.default

Ouvrez un navigateur vers http: // / hab_app après l'affichage du résultat suivant dans le journal du superviseur:

 contosouniversity.default (O): contosouniversity est en cours d'exécution 

Félicitations! Tu y es presque. Enfin, le package Habitat doit être chargé sur le dépôt de constructeur à l’aide de la commande ci-dessous. Vous devez pointer vers le fichier de construction actuel pour vous assurer de publier les dernières modifications:

 hab pkg télécharger .resultsmanny-rodriguez-contosouniversity-0.2.0-2019014110601-x86_64-windows.hart 

Déploiement sur un serveur

Lorsque vos applications sont livrées avec Chef Habitat, Chef Habitat est la seule exigence d’installation sur vos serveurs cibles. Chocolatey peut être utilisé ici ou toute autre méthode de déploiement. Habitat devra également être configuré comme indiqué dans Configuration de la station de travail. Démarrez Habitat Supervisor avec hab sup, exécutez et exécutez les mêmes commandes que celles utilisées lors des tests locaux pour charger votre application. Après le démarrage du superviseur, il peut être nécessaire d’ouvrir une nouvelle invite PowerShell. Un service Windows peut également être utilisé pour exécuter Habitat Supervisor sans surveillance, ce que nous verrons dans un article ultérieur:

 hab sup run 
a chargé svc / core serveur
Get-SupervisorLog
sqlserver. crochet par défaut [post-run] :( HK): 1> 2> 3> 4> 5> 6> Configuration de l'utilisateur de l'application terminée
Chargement svp manny-rodriguez / contosouniversity --bind base de données: sqlserver.default

] Une fois encore, ouvrez un navigateur Web à l'adresse http: // / hab_app une fois que le journal du superviseur indique que votre service est en cours d'exécution.

Exportation de packages pour Docker

Outre le déploiement de fichiers HART directement dans des environnements de serveur traditionnels, les packages Habitat peuvent être exportés vers des conteneurs Docker ou d’autres formats d’exécution à l’aide de hab pkg export . Nous illustrons cela ci-dessous à l'aide de deux packages: le package principal de SQL Server 2017 et celui que nous venons de créer pour notre exemple d'application.

 avec export docker core / sqlserver 
avec export docker .resultsmanny-rodriguez-contosouniversity- 0.2.0-2019014110601-x86_64-windows.hart

Pour que notre conteneur d'application puisse communiquer avec le conteneur SQL Server, nous devons noter l'adresse IP du conteneur SQL Server et l'indiquer dans l'exécution du menu fixe . commande pour notre application. Voici quelques exemples de code PowerShell permettant de capturer l’adresse du conteneur SQL Server dans une variable:

 $ sql = docker exécuter -d --memory 2 Go core / sqlserver 
$ ip = docker inspecter -f '{{range .NetworkSettings. Réseaux}} {{.IPAddress}} {{fin}} '$ sql
exécution du menu fixe -it -p 80: 8099 myorigin / contosouniversity --peer $ ip --bind base de données: sqlserver.default

Conclusion

Dans cet article de blog, nous avons pris une application ASP.NET moderne, puis l'avons emballée et déployée avec Chef Habitat. Cela comprenait les conditions préalables à l’installation du logiciel requis, à la création des comptes nécessaires et à la configuration de Chef Habitat. Un plan Habitat a été créé et modifié pour l’emballage et le déploiement de l’application ASP.NET. Nous avons appris à propos des gestionnaires d’événements Lifecycle (hooks) et comment les utiliser pour construire le package et exécuter l’application. Un environnement local a été utilisé pour créer, empaqueter, tester et télécharger sur le dépôt de constructeur. Ensuite, un conteneur Docker a été exporté pour SQL Server 2017 et notre application ASP.NET. Les conteneurs Docker ont été démarrés, les applications et les fonctionnalités Windows

ont été installées et configurées. Les tests ont abouti à l'exécution de l'application ASP.NET.

Ce qu'il faut retenir, c'est que les applications peuvent être rapidement créées, empaquetées, déployées et gérées à l'aide de Chef Habitat. Cela modifie la façon dont les applications sont actuellement gérées au cours de leur cycle de vie, ce qui réduit le temps passé au cycle de développement et accélère les déploiements, permettant ainsi d'économiser du temps et de l'argent.

qui utilise une version de SQL Server qui n'est plus prise en charge.

Perfficient peut aider!

Avec la fin de la prise en charge de Windows et de SQL Server à compter de cette année, il est maintenant temps de commencer à migrer ces applications héritées avec Habitat . Cette approche élimine vos dépendances sur ces systèmes d'exploitation hérités et vous évite des contrats de support coûteux. Nous pouvons également vous aider à moderniser vos processus de développement d’applications en utilisant une approche indépendante du système d’exploitation qui rend votre entreprise plus innovante et résiliente pour l’avenir. Dites-nous si nous pouvons aider.





Source link

0 Partages