Azure App Service için özel kapsayıcıyı yapılandırma

  • Makale

Bu makalede, özel bir kapsayıcıyı Azure Uygulaması Hizmetinde çalışacak şekilde yapılandırma işlemi gösterilmektedir.

Bu kılavuz, App Service'te Windows uygulamalarını kapsayıcıya almayla ilgili temel kavramlar ve yönergeler sağlar. Yeni Azure Uygulaması Hizmeti kullanıcıları önce özel kapsayıcı hızlı başlangıcını ve öğreticiyi izlemelidir.

Bu kılavuz, App Service'te Linux uygulamalarını kapsayıcıya almayla ilgili temel kavramlar ve yönergeler sağlar. Azure Uygulaması Hizmeti'ni kullanmaya yeniyseniz, önce özel kapsayıcı hızlı başlangıcını ve öğreticiyi izleyin. Ayrıca çok kapsayıcılı bir uygulama hızlı başlangıcı ve öğreticisi de vardır. Sepet kapsayıcıları (önizleme) için bkz. Öğretici: Azure Uygulaması Hizmetinde özel kapsayıcı için sepet kapsayıcısı yapılandırma (önizleme).

Not

Hizmet Sorumlusu artık Windows kapsayıcı görüntüsü çekme kimlik doğrulaması için desteklenmiyor. Önerilen yol hem Windows hem de Linux kapsayıcıları için Yönetilen Kimlik kullanmaktır

Desteklenen üst görüntüler

Özel Windows görüntünüz için, istediğiniz çerçeve için doğru üst görüntüyü (temel görüntü) seçmeniz gerekir:

Uygulama başlatılırken üst görüntünün indirilmesi zaman alabilir. Ancak Azure App Service önbelleğinde bulunan aşağıdaki üst görüntülerden birini kullanarak başlangıç süresini kısaltabilirsiniz:

  • mcr.microsoft.com/windows/servercore:ltsc2022
  • mcr.microsoft.com/windows/servercore:ltsc2019
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

Özel kapsayıcının Docker görüntüsünü değiştirme

Mevcut bir özel kapsayıcıyı geçerli Docker görüntüsünden yeni bir görüntüye değiştirmek için aşağıdaki komutu kullanın:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Özel kayıt defterinden görüntü kullanma

Azure Container Registry gibi özel bir kayıt defterinden görüntü kullanmak için aşağıdaki komutu çalıştırın:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

Kullanıcı <adı> ve <parola> için özel kayıt defteri hesabınızın oturum açma kimlik bilgilerini sağlayın.

Azure Container Registry'den görüntü çekmek için yönetilen kimliği kullanma

Yönetilen kimliği kullanarak web uygulamanızı Azure Container Registry'den (ACR) çekecek şekilde yapılandırmak için aşağıdaki adımları kullanın. Adımlarda sistem tarafından atanan yönetilen kimlik kullanılır, ancak kullanıcı tarafından atanan yönetilen kimliği de kullanabilirsiniz.

  1. Komutunu kullanarak az webapp identity assign web uygulaması için sistem tarafından atanan yönetilen kimliği etkinleştirin:

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    değerini önceki adımda kullandığınız adla değiştirin <app-name> . Komutun çıkışı (ve --output bağımsız değişkenlerine göre --query filtrelenmiş), atanan kimliğin hizmet sorumlusu kimliğidir.

  2. Azure Container Registry'nizin kaynak kimliğini alın:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    <registry-name> değerini kayıt defterinizin adıyla değiştirin. Komutun çıkışı (ve --output bağımsız değişkenlerine göre --query filtrelenmiş), Azure Container Registry'nin kaynak kimliğidir.

  3. Kapsayıcı kayıt defterine erişmek için yönetilen kimlik izni verin:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Aşağıdaki değerleri değiştirin:

    • <principal-id>komutundan hizmet sorumlusu kimliğiyle az webapp identity assign
    • <registry-resource-id> komutundan az acr show kapsayıcı kayıt defterinizin kimliğiyle

    Bu izinler hakkında daha fazla bilgi için bkz . Azure rol tabanlı erişim denetimi nedir?

  4. Uygulamanızı Azure Container Registry'den çekmek üzere yönetilen kimliği kullanacak şekilde yapılandırın.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Aşağıdaki değerleri değiştirin:

    • <app-name> web uygulamanızın adıyla birlikte.

    İpucu

    Komutları çalıştırmak için PowerShell konsolunu kullanıyorsanız, bu ve sonraki adımda bağımsız değişkendeki --generic-configurations dizelerden kaçış yapmanız gerekir. Örneğin: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (İsteğe bağlı) Uygulamanız kullanıcı tarafından atanan bir yönetilen kimlik kullanıyorsa, kimliğin web uygulamasında yapılandırıldığından emin olun ve ardından istemci kimliğini belirtmek için özelliğini ayarlayın acrUserManagedIdentityID :

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    <identity-name> Kullanıcı tarafından atanan yönetilen kimliğinizin yerine geçin ve çıktıyı <client-id> kullanarak kullanıcı tarafından atanan yönetilen kimlik kimliğini yapılandırın.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

Hazırsınız ve web uygulaması artık Azure Container Registry'den çekmek için yönetilen kimliği kullanıyor.

Ağ korumalı kayıt defterinden görüntü kullanma

Sanal ağ veya şirket içi içindeki bir kayıt defterine bağlanmak ve kayıt defterinden çekme yapmak için uygulamanızın bir sanal ağ (VNET) ile tümleştirilmesi gerekir. Özel uç nokta ile Azure Container Registry için sanal ağ tümleştirmesi de gereklidir. Ağınız ve DNS çözümlemeniz yapılandırıldığında, site ayarını yapılandırarak görüntü çekme işleminin sanal ağ üzerinden yönlendirilmesine vnetImagePullEnabled olanak tanırsınız:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Güncelleştirilmiş kapsayıcıyı görmüyorum

Docker kapsayıcı ayarlarınızı yeni bir kapsayıcıya işaret eden şekilde değiştirirseniz, uygulamanın yeni kapsayıcıdan HTTP istekleri göndermesi birkaç dakika sürebilir. Yeni kapsayıcı çekilir ve başlatılırken App Service eski kapsayıcıdan gelen istekleri göndermeye devam eder. Yalnızca yeni kapsayıcı başlatıldığında ve istekleri almaya hazır olduğunda App Service bu kapsayıcıya istek göndermeye başlar.

Kapsayıcı görüntüleri nasıl depolanır?

App Service'te özel bir Docker görüntüsünü ilk kez çalıştırdığınızda, App Service bir docker pull yapar ve tüm görüntü katmanlarını çeker. Bu katmanlar, şirket içinde Docker kullanıyor olmanız gibi diskte depolanır. Uygulama her yeniden başlatıldığında App Service bir docker pullyapar, ancak yalnızca değişen katmanları çeker. Hiçbir değişiklik yoksa, App Service yerel diskte var olan katmanları kullanır.

Uygulama, fiyatlandırma katmanlarını artırma ve azaltma gibi herhangi bir nedenle işlem örneklerini değiştirirse App Service'in tüm katmanları yeniden aşağı çekmesi gerekir. Daha fazla örnek eklemek için ölçeği genişletdiğinizde de aynı durum geçerlidir. Uygulama örneklerinin ölçek işlemi olmadan değişebileceği nadir durumlar da vardır.

Bağlantı noktası numarasını yapılandırma

App Service, varsayılan olarak özel kapsayıcınızın 80 numaralı bağlantı noktasında dinlediğini varsayar. Kapsayıcınız farklı bir bağlantı noktasını dinliyorsa App Service uygulamanızda uygulama ayarını ayarlayın WEBSITES_PORT . Cloud Shell aracılığıyla ayarlayabilirsiniz. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

App Service şu anda kapsayıcınızın HTTP istekleri için yalnızca bir bağlantı noktasını kullanıma sunmasına izin verir.

Ortam değişkenlerini yapılandırma

Özel kapsayıcınız dışarıdan sağlanması gereken ortam değişkenlerini kullanabilir. Bunları Cloud Shell aracılığıyla geçirebilirsiniz. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Uygulamanız çalıştırıldığında App Service uygulama ayarları otomatik olarak ortam değişkenleri olarak işleme eklenir. KAPSAYıCı ortamı değişkenlerini URL https://<app-name>.scm.azurewebsites.net/Envile doğrulayabilirsiniz.

Uygulamanız özel bir kayıt defterinden veya Docker Hub'dan görüntüler kullanıyorsa, depoya erişim kimlik bilgileri ortam değişkenlerine kaydedilir: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME ve DOCKER_REGISTRY_SERVER_PASSWORD. Güvenlik riskleri nedeniyle, bu ayrılmış değişken adlarından hiçbiri uygulamaya sunulmaz.

IIS veya .NET Framework (4.0 veya üzeri) tabanlı kapsayıcılar için bunlar .NET uygulama ayarları olarak ve System.ConfigurationManager App Service tarafından otomatik olarak bağlantı dizesi. Diğer tüm dil veya çerçeveler için, bunlar işlem için ortam değişkenleri olarak sağlanır ve bunlara karşılık gelen aşağıdaki ön eklerden biri kullanılır:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Bu yöntem hem tek kapsayıcılı uygulamalar hem de ortam değişkenlerinin docker-compose.yml dosyasında belirtildiği çok kapsayıcılı uygulamalar için çalışır.

Kalıcı paylaşılan depolama kullanma

Dosyaları yeniden başlatmalar arasında kalıcı hale getirmek ve örnekler arasında paylaşmak için özel kapsayıcı dosya sisteminizde C:\home dizinini kullanabilirsiniz. Dizin C:\home , özel kapsayıcınızın kalıcı depolamaya erişmesini sağlamak için sağlanır.

Kalıcı depolama devre dışı bırakıldığında, dizine C:\home yazma işlemleri uygulama yeniden başlatmalarında veya birden çok örnekte kalıcı olmaz. Kalıcı depolama etkinleştirildiğinde, dizine C:\home yapılan tüm yazma işlemleri kalıcı olur ve ölçeklendirilen bir uygulamanın tüm örnekleri tarafından erişilebilir. Ayrıca kapsayıcının dizinindeki C:\home tüm içeriklerin üzerine kapsayıcı başlatıldığında kalıcı depolamada zaten mevcut olan tüm dosyalar yazılır.

Tek özel durum, kapsayıcıyı C:\home\LogFiles ve uygulama günlüklerini depolamak için kullanılan dizindir. Uygulama günlüğü Dosya Sistemi seçeneğiyle etkinleştirilirse, uygulama yeniden başlatıldığında, kalıcı depolamanın etkin veya devre dışı bırakılmasından bağımsız olarak bu klasör her zaman kalıcı olur. Başka bir deyişle, kalıcı depolamanın etkinleştirilmesi veya devre dışı bırakılması uygulama günlüğü davranışını etkilemez.

Varsayılan olarak, windows özel kapsayıcılarında kalıcı depolama devre dışıdır. Etkinleştirmek için Cloud Shell aracılığıyla uygulama ayarı değerini true olarak ayarlayınWEBSITES_ENABLE_APP_SERVICE_STORAGE. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

Dosyaları yeniden başlatmalar arasında kalıcı hale getirmek ve örnekler arasında paylaşmak için özel kapsayıcı dosya sisteminizde /home dizinini kullanabilirsiniz. Dizin /home , özel kapsayıcınızın kalıcı depolamaya erişmesini sağlamak için sağlanır. Verilerin içinde /home kaydedilmesi, App Service Planınıza dahil edilen depolama alanı kotasına katkıda bulunur.

Kalıcı depolama devre dışı bırakıldığında, dizine /home yazma işlemleri uygulama yeniden başlatmalarında veya birden çok örnekte kalıcı olmaz. Kalıcı depolama etkinleştirildiğinde, dizine /home yapılan tüm yazma işlemleri kalıcı olur ve ölçeklendirilen bir uygulamanın tüm örnekleri tarafından erişilebilir. Ayrıca kapsayıcının dizinindeki /home tüm içeriklerin üzerine kapsayıcı başlatıldığında kalıcı depolamada zaten mevcut olan tüm dosyalar yazılır.

Tek özel durum, kapsayıcıyı /home/LogFiles ve uygulama günlüklerini depolamak için kullanılan dizindir. Uygulama günlüğü Dosya Sistemi seçeneğiyle etkinleştirilirse, uygulama yeniden başlatıldığında, kalıcı depolamanın etkin veya devre dışı bırakılmasından bağımsız olarak bu klasör her zaman kalıcı olur. Başka bir deyişle, kalıcı depolamanın etkinleştirilmesi veya devre dışı bırakılması uygulama günlüğü davranışını etkilemez.

Verilere veya bağlı bir Azure depolama yoluna veri /home yazmanızı öneririz. Bu yolların dışında yazılan veriler yeniden başlatmalar sırasında kalıcı değildir ve App Service Planları dosya depolama kotasından ayrı olarak platform tarafından yönetilen ana bilgisayar disk alanına kaydedilir.

Varsayılan olarak, linux özel kapsayıcılarında kalıcı depolama etkindir. Bunu devre dışı bırakmak için Cloud Shell aracılığıyla uygulama ayarı değerini false olarak ayarlayınWEBSITES_ENABLE_APP_SERVICE_STORAGE. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Not

Kendi kalıcı depolama alanınızı da yapılandırabilirsiniz.

HTTPS oturumlarını algılama

App Service ön uçlarda TLS/SSL'yi sonlandırır. Bu, TLS/SSL isteklerinin uygulamanıza hiçbir zaman ulaşamayacağı anlamına gelir. Uygulamanıza TLS/SSL desteği uygulamanıza gerek yoktur ve uygulamanıza herhangi bir destek uygulamamalısınız.

Ön uçlar Azure veri merkezlerinde bulunur. Uygulamanızla TLS/SSL kullanıyorsanız İnternet genelindeki trafiğiniz her zaman güvenli bir şekilde şifrelenir.

ASP.NET makine anahtarı eklemeyi özelleştirme

Kapsayıcı başlatma sırasında otomatik olarak oluşturulan anahtarlar, ASP.NET şifreleme yordamları için makine anahtarları olarak kapsayıcıya eklenir. Kapsayıcınızda şu ortam değişkenlerini arayarak bu anahtarları bulabilirsiniz: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

Her yeniden başlatmadaki yeni anahtarlar, uygulamanız bunlara bağlıysa kimlik doğrulaması ve görüntüleme durumu ASP.NET sıfırlanabilir. Anahtarların otomatik olarak yenilenmesini önlemek için bunları App Service uygulama ayarları olarak el ile ayarlayın.

Kapsayıcıya Bağlan

SSH seçeneğine gidip https://<app-name>.scm.azurewebsites.net/ seçerek tanılama görevleri için windows kapsayıcınıza doğrudan bağlanabilirsiniz. Kapsayıcınızın içinde komut çalıştırabileceğiniz doğrudan bir SSH oturumu oluşturulur.

  • Yalnızca paylaşılan depolama alanınızdaki dosyaları gösteren yukarıdaki grafik tarayıcıdan ayrı çalışır.
  • Ölçeği genişletilmiş bir uygulamada, SSH oturumu kapsayıcı örneklerinden birine bağlanır. ÜstTeki Kudu menüsündeki Örnek açılan listesinden farklı bir örnek seçebilirsiniz.
  • Docker görüntüsünün bir parçası olmadığından, uygulamanız yeniden başlatıldığında (paylaşılan depolamadaki değişiklikler dışında) kapsayıcıda yaptığınız değişiklikler kalıcı olmaz . Kayıt defteri ayarları ve yazılım yüklemesi gibi değişikliklerinizi kalıcı hale getirmek için bunları Dockerfile'ın bir parçası yapın.

Tanılama günlüklerine erişim

App Service, Docker konağına göre eylemleri ve kapsayıcı içindeki etkinlikleri günlüğe kaydeder. Docker konağından (platform günlükleri) gelen günlükler varsayılan olarak gönderilir, ancak kapsayıcının içindeki uygulama günlüklerinin veya web sunucusu günlüklerinin el ile etkinleştirilmesi gerekir. Daha fazla bilgi için bkz . Uygulama günlüğünü etkinleştirme ve Web sunucusu günlüğünü etkinleştirme.

Docker günlüklerine erişmenin birkaç yolu vardır:

Azure portalında

Docker günlükleri portalda, uygulamanızın Kapsayıcı Ayarlar sayfasında görüntülenir. Günlükler kesilir, ancak İndir'i seçerek tüm günlükleri indirebilirsiniz.

Kudu'dan

https://<app-name>.scm.azurewebsites.net/DebugConsole Günlük dosyalarını tek tek görmek için LogFiles klasörüne gidin ve bu klasörü seçin. LogFiles dizininin tamamını indirmek için dizin adının sol kısmındaki "İndir" simgesini seçin. Bu klasöre ftp istemcisi kullanarak da erişebilirsiniz.

SSH terminalinde, kalıcı paylaşılan depolama etkinleştirilmediğinden klasöre varsayılan olarak erişemezsiniz C:\home\LogFiles . Konsol terminalinde bu davranışı etkinleştirmek için kalıcı paylaşılan depolamayı etkinleştirin.

Ftp istemcisi kullanarak şu anda kullanımda olan Docker günlüğünü indirmeye çalışırsanız, dosya kilidi nedeniyle bir hata alabilirsiniz.

Kudu API'siyle

Docker günlüklerinin meta verilerini görmek için doğrudan adresine https://<app-name>.scm.azurewebsites.net/api/logs/docker gidin. Birden fazla günlük dosyasının listelendiğini görebilirsiniz ve href özelliği günlük dosyasını doğrudan indirmenize olanak tanır.

Tüm günlükleri tek bir ZIP dosyasında birlikte indirmek için öğesine erişin https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Kapsayıcı belleğini özelleştirme

Varsayılan olarak, Azure Uygulaması Hizmeti'nde dağıtılan tüm Windows Kapsayıcılarının bir bellek sınırı yapılandırılmıştır. Aşağıdaki tabloda App Service Planı SKU'su başına varsayılan ayarlar listelenir.

App Service Planı SKU'su MB cinsinden uygulama başına varsayılan bellek sınırı
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Cloud Shell aracılığıyla uygulama ayarını sağlayarak WEBSITE_MEMORY_LIMIT_MB bu değeri değiştirebilirsiniz. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Değer MB cinsinden tanımlanır ve konağın toplam fiziksel belleğine eşit ve daha küçük olmalıdır. Örneğin, 8 GB RAM'e sahip bir App Service planında, tüm uygulamaların toplam toplamı WEBSITE_MEMORY_LIMIT_MB 8 GB'ı aşmamalıdır. Her fiyatlandırma katmanı için kullanılabilir bellek miktarıyla ilgili bilgileri App Service fiyatlandırması bölümünde, Premium v3 hizmet planı bölümünde bulabilirsiniz.

İşlem çekirdeği sayısını özelleştirme

Varsayılan olarak, bir Windows kapsayıcısı seçtiğiniz fiyatlandırma katmanı için tüm kullanılabilir çekirdeklerle çalışır. Örneğin hazırlama yuvanızın kullandığı çekirdek sayısını azaltmak isteyebilirsiniz. Kapsayıcı tarafından kullanılan çekirdek sayısını azaltmak için uygulama ayarını tercih edilen çekirdek sayısına ayarlayın WEBSITE_CPU_CORES_LIMIT . Cloud Shell aracılığıyla ayarlayabilirsiniz. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Not

Uygulama ayarının güncelleştirilmesi otomatik yeniden başlatmayı tetikleyerek minimum kapalı kalma süresine neden olur. Üretim uygulaması için bunu hazırlama yuvasına değiştirmeyi, hazırlama yuvasındaki uygulama ayarını değiştirmeyi ve ardından üretime geri döndürmeyi göz önünde bulundurun.

Portaldan veya Kudu portalı (https://<app-name>.scm.azurewebsites.net/webssh/host) aracılığıyla bir SSH oturumu açıp PowerShell kullanarak aşağıdaki komutları yazarak düzeltilen numaranızı doğrulayın. Her komut bir sayı verir.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

İşlemciler çok çekirdekli veya hiper iş parçacığı kullanan işlemciler olabilir. Her fiyatlandırma katmanı için kullanılabilir çekirdek sayısıyla ilgili bilgileri App Service fiyatlandırması bölümünde, Premium v3 hizmet planı bölümünde bulabilirsiniz.

Sistem durumu ping davranışını özelleştirme

App Service, kapsayıcı başlatıldığında ve HTTP ping'ine yanıt verirken kapsayıcının başarıyla başlatılacağı düşünülmektedir. Sistem durumu ping isteği üst bilgisini User-Agent= "App Service Hyper-V Container Availability Check"içerir. Kapsayıcı başlatılır ancak belirli bir süre sonra ping'lere yanıt vermezse, App Service Docker günlüğüne kapsayıcının başlamadığını belirten bir olay kaydeder.

Uygulamanız yoğun kaynak kullanıyorsa kapsayıcı HTTP ping'ine zamanında yanıt vermeyebilir. HTTP pingleri başarısız olduğunda eylemleri denetlemek için uygulama ayarını yapın CONTAINER_AVAILABILITY_CHECK_MODE . Cloud Shell aracılığıyla ayarlayabilirsiniz. Bash'te:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

PowerShell'de:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

Aşağıdaki tabloda olası değerler gösterilmektedir:

Değer Açıklamalar
Onarım Ardışık üç kullanılabilirlik denetiminden sonra kapsayıcıyı yeniden başlatın
ReportOnly Varsayılan değer. Kapsayıcıyı yeniden başlatmayın, ancak üç ardışık kullanılabilirlik denetiminden sonra kapsayıcı için Docker günlüklerinde rapor verin.
Kapalı Kullanılabilirliği denetlemeyin.

Grup Tarafından Yönetilen Hizmet Hesapları desteği

Grup Yönetilen Hizmet Hesapları (gMSA'lar) şu anda App Service'teki Windows kapsayıcılarında desteklenmemektedir.

SSH'yi etkinleştirme

Secure Shell (SSH), yönetim komutlarını bir komut satırı terminalinden uzaktan yürütmek için yaygın olarak kullanılır. Azure portalı SSH konsol özelliğini özel kapsayıcılarla etkinleştirmek için aşağıdaki adımlar gereklidir:

  1. Aşağıdaki örnek içeriklerle standart sshd_config bir dosya oluşturun ve bunu uygulama projesi kök dizinine yerleştirin:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Not

    Bu dosya OpenSSH'yi yapılandırıyor ve Azure portalı SSH özelliğine uyum sağlamak için aşağıdaki öğeleri içermelidir:

    • Port 2222 olarak ayarlanmalıdır.
    • Ciphers, bu listedeki en az bir öğeyi içermelidir: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs, bu listedeki en az bir öğeyi içermelidir: hmac-sha1,hmac-sha1-96.

  2. Adıyla entrypoint.sh bir giriş noktası betiği oluşturun (veya var olan herhangi bir giriş noktası dosyasını değiştirin) ve SSH hizmetini başlatmak için komutunu ve uygulama başlatma komutunu ekleyin. Aşağıdaki örnekte Python uygulaması başlatma gösterilmektedir. Son komutu proje diline/yığınına göre değiştirin:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Dockerfile dosyasına temel görüntü dağıtımına göre aşağıdaki yönergeleri ekleyin. Bu yönergeler yeni dosyaları kopyalar, OpenSSH sunucusunu yükler, uygun izinleri ayarlar ve özel giriş noktasını yapılandırıp sırasıyla uygulama ve SSH sunucusu için gereken bağlantı noktalarını kullanıma sunar:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Not

    Kök parola, Docker! kapsayıcıyla SSH oturumuna erişmenizi sağlamak için App Service tarafından kullanıldığı şekilde olmalıdır. Bu yapılandırma kapsayıcıya dış bağlantılara izin vermez. Kapsayıcının 2222 numaralı bağlantı noktasına yalnızca özel bir sanal ağın köprü ağından erişilebilir ve İnternet'te bir saldırgan tarafından erişilemez.

  4. Docker görüntüsünü yeniden derleyip kayıt defterine gönderin ve ardından Azure portalında Web Uygulaması SSH özelliğini test edin.

Daha fazla sorun giderme bilgilerine Azure Uygulaması Hizmeti blogu: Kapsayıcılar için Linux Web App'te SSH'yi etkinleştirme sayfasından ulaşabilirsiniz

Tanılama günlüklerine erişim

Kapsayıcının içinden oluşturulan konsol günlüklerine erişebilirsiniz.

İlk olarak, aşağıdaki komutu çalıştırarak kapsayıcı günlüğünü açın:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

ve <resource-group-name> öğesini web uygulamanız için uygun adlarla değiştirin<app-name>.

Kapsayıcı günlüğü açıldıktan sonra günlük akışını görmek için aşağıdaki komutu çalıştırın:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Konsol günlüklerini hemen görmüyorsanız, 30 saniye içinde yeniden kontrol edin.

Günlük akışını istediğiniz zaman durdurmak için Ctrl+C yazın.

Günlük dosyalarını tarayıcıdan https://<app-name>.scm.azurewebsites.net/api/logs/dockerda inceleyebilirsiniz.

Çok kapsayıcılı uygulamaları yapılandırma

Docker Compose'da kalıcı depolama kullanma

WordPress gibi çok kapsayıcılı uygulamaların düzgün çalışması için kalıcı depolama gerekir. Bunu etkinleştirmek için Docker Compose yapılandırmanızın kapsayıcınızın dışındaki bir depolama konumuna işaret etmesi gerekir. Kapsayıcınızın içindeki Depolama konumlar, uygulama yeniden başlatma dışında değişiklikleri kalıcı hale gelmez.

Cloud Shell'de az webapp config appsettings set komutunu kullanarak uygulama ayarını yaparak WEBSITES_ENABLE_APP_SERVICE_STORAGEkalıcı depolamayı etkinleştirin.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

docker-compose.yml dosyanızda seçeneğini ile ${WEBAPP_STORAGE_HOME}eşleyinvolumes.

WEBAPP_STORAGE_HOME, App Service içinde bulunan ve uygulamanız için kalıcı depolamayla eşlenmiş olan bir ortam değişkenidir. Örneğin:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

Önizleme sınırlamaları

Çoklu kapsayıcı şu anda önizleme aşamasındadır. Aşağıdaki App Service platformu özellikleri desteklenmez:

  • Kimlik Doğrulama/Yetkilendirme
  • Yönetilen Kimlikler
  • CORS
  • Docker Compose senaryolarında sanal ağ tümleştirmesi desteklenmez
  • Azure Uygulaması Hizmetlerinde Docker Compose şu anda 4.000 karakter sınırına sahiptir.

Docker Compose seçenekleri

Aşağıdaki listeler desteklenen ve desteklenmeyen Docker Compose yapılandırma seçeneklerini gösterir:

Desteklenen seçenekler

Desteklenmeyen seçenekler

  • build (izin verilmez)
  • depends_on (yoksayıldı)
  • networks (yoksayılır)
  • secrets (yoksayılır)
  • 80 ve 8080 dışındaki bağlantı noktaları (yoksayılır)
  • docker'daki gibi $variable and ${variable} varsayılan ortam değişkenleri

Söz Dizimi Sınırlamaları

  • "version x.x" her zaman dosyadaki ilk YAML deyimi olmalıdır
  • bağlantı noktaları bölümü tırnak içinde numaralar kullanmalıdır
  • görüntü > birimi bölümü alıntılanmalıdır ve izin tanımlarına sahip olamaz
  • birimler bölümünde birim adından sonra boş bir küme ayracı olmamalıdır

Not

Açıkça belirtilmeyen diğer seçenekler Genel Önizleme'de yoksayılır.

Günlüklerde robots933456

Kapsayıcı günlüklerinde şu iletiyi görebilirsiniz:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Bu iletiyi güvenle yoksayabilirsiniz. /robots933456.txt, App Service hizmetinin kapsayıcının istek sunmak için uygun olup olmadığını denetlemek için kullandığı işlevsiz bir URL'dir. 404 yanıtı, yolun var olmadığını belirtir ancak App Service bu sayede iyi ve isteklere yanıt vermeye uygun durumda olan kapsayıcıları belirler.

Sonraki adımlar

Öğretici: Özel bir kapsayıcı kullanarak özel yazılımı Azure Uygulaması Hizmetine geçirme

Öğretici: Çok kapsayıcılı WordPress uygulaması

Veya diğer kaynaklara bakın: