Linux’ta Azure App Service hakkında SSS

Bu komutlar veya betikler, yerleşik Docker kapsayıcısı başlatıldıktan sonra ancak uygulama kodunuz başlatılmadan önce yürütülür.

Bu eylem, Docker yeniden başlatma işlemiyle aynıdır.

Evet, bunu kaynak denetimi yönetimi (SCM) sitesi aracılığıyla yapabilirsiniz.

App Service'in ayrılmış alanını true olarak ayarlayın.

Evet, Kapsayıcılar için Web App ile Sürekli Dağıtım'ı izleyerek Azure Container Registry veya DockerHub için sürekli tümleştirme/dağıtım ayarlamak için. Özel kayıt defterleri için, web uygulamanızı durdurup başlatarak kapsayıcıyı yenileyebilirsiniz. Alternatif olarak, kapsayıcınızın yenilenmesini zorlamak için sahte bir uygulama ayarını değiştirebilir veya ekleyebilirsiniz.

Evet.

Evet, false olarak adlandırılan WEBSITE_WEBDEPLOY_USE_SCM bir uygulama ayarı ayarlamanız gerekir.

Linux web uygulamanızda Git dağıtımı başarısız olursa, uygulama kodunuzu dağıtmak için aşağıdaki seçeneklerden birini belirleyin:

• Sürekli Teslim (Önizleme) özelliğini kullanın: Azure Sürekli Teslim'i kullanmak için uygulamanızın kaynak kodunu bir Azure DevOps Git deposunda veya GitHub deposunda depolayabilirsiniz. Daha fazla bilgi için bkz . Linux web uygulaması için Sürekli Teslim'i yapılandırma.

• ZIP dağıtım API'sini kullanın: Bu API'yi kullanmak için web uygulamanıza SSH ekleyin ve kodunuzu dağıtmak istediğiniz klasöre gidin. Aşağıdaki kodu çalıştırın:

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  Komutun curl bulunamadığını belirten bir hata alırsanız, önceki curl komutu çalıştırmadan önce kullanarak apt-get install curl curl yüklediğinizden emin olun.

Evet, sunucu tarafı Node.js kodunuzda devre dışı bırakın perMessageDeflate . Örneğin, socket.io kullanıyorsanız aşağıdaki kodu kullanın:

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

Evet.

Evet, Git dağıtımı sırasında Kudu bir PHP uygulaması dağıttığınızı algılamalıdır (composer.lock dosyasının varlığı sayesinde) ve Kudu daha sonra bir oluşturucu yüklemesini tetikler.

Evet, bu işlev Azure CLI'dan kullanılabilir. Sistem tarafından atanan veya kullanıcı tarafından atanan kimlikleri kullanabilirsiniz. Bu işlev şu anda Azure portalında desteklenmiyor.

Ayar belirtilmezse veya false olarak ayarlanırsaWEBSITES_ENABLE_APP_SERVICE_STORAGE, /home/ dizin ölçek örnekleri arasında paylaşılmaz ve yazılan dosyalar yeniden başlatmalar arasında kalıcı olmaz. Açıkça true olarak ayarlanması WEBSITES_ENABLE_APP_SERVICE_STORAGE bağlamayı etkinleştirir. Bu true olarak ayarlandıktan sonra bağlamayı devre dışı bırakmak istiyorsanız, açıkça false olarak ayarlamanız WEBSITES_ENABLE_APP_SERVICE_STORAGE gerekir.

Linux üzerinde App Service iki farklı depolama türü kullanır:

• Dosya sistemi depolama alanı: Dosya sistemi depolama alanı App Service planı kotasında yer alır. Dosyalar dizinde kök olarak /home bulunan kalıcı depolama alanına kaydedildiğinde kullanılır.
• Konak disk alanı: Konak disk alanı, kapsayıcı görüntülerini depolamak için kullanılır. Docker depolama sürücüsü aracılığıyla platform tarafından yönetilir.

Konak disk alanı, dosya sistemi depolama kotasından ayrıdır. Genişletilebilir değildir ve her örnek için 15 GB sınırı vardır. Çalışanda özel görüntüleri depolamak için kullanılır. Konak disk alanının tam kullanılabilirliğine bağlı olarak 15'ten büyük GB'lar kullanabilirsiniz, ancak bu garanti değildir.

Kapsayıcının yazılabilir katmanı verileri dizinin veya bağlı azure depolama yolunun /homedışına kaydederse, konak disk alanı da kullanılır.

Platform, kullanılmayan kapsayıcıları kaldırmak için konak disk alanını düzenli olarak temizler. Kapsayıcı dizin veya Kendi DepolamaNızı Getir (BYOS) dışında /home büyük miktarda veri yazarsa, konak disk alanı sınırı aşıldığında başlatma hatalarına veya çalışma zamanı özel durumlarına neden olur.

Linux App Service'te çalışırken kapsayıcı görüntülerinizi mümkün olduğunca küçük tutmanızı ve kalıcı depolama alanına veya BYOS'a veri yazmanızı öneririz. Mümkün değilse, konak disk alanı sabit olduğundan ve App Service Planı'ndaki tüm kapsayıcılar arasında paylaşıldığından App Service planını bölmeniz gerekir.

Platformun kapsayıcınızı yeniden başlatmadan önce bekleyeceği süreyi yapılandırabilirsiniz. Bunu yapmak için uygulama ayarını istediğiniz değere ayarlayın WEBSITES_CONTAINER_START_TIME_LIMIT . Varsayılan değer 230 saniye, ve maksimum değer 1800 saniyedir.

veya https://dahil olmak üzere http:// tam kayıt defteri URL'sini sağlayın.

Özel kayıt defteri URL'si de dahil olmak üzere tam görüntü adını ekleyin (örneğin, myacr.azurecr.io/dotnet:latest). Özel bağlantı noktası kullanan resim adları portal üzerinden girilemez. ayarlamak docker-custom-image-nameiçin komut satırı aracını kullanınaz.

Birden fazla bağlantı noktasının açığa çıkartılması desteklenmez.

Evet, kendi depolama alanınızı getirin önizleme aşamasındadır.

SCM sitesi ayrı bir kapsayıcıda çalışır. Dosya sistemini veya uygulama kapsayıcısının çalışan işlemlerini denetleyemazsınız.

Hayır, platform paylaşılan ön uçlarda HTTPS sonlandırmayı işler.

Evet, bu özel kapsayıcılar için gereklidir. Özel bir bağlantı noktasını el ile yapılandırmak için Dockerfile içindeki EXPOSE yönergesini ve kapsayıcıya bağlamak üzere bağlantı noktası değeriyle WEBSITES_PORT uygulama ayarını kullanın.

Evet, .NET core uygulaması başlamadan önce ortam değişkeninin üzerine yazın. Örneğin init.sh betiğinde: export ASPNETCORE_URLS={Your value}

ACR'yi çok kapsayıcılı olarak kullanmak için tüm kapsayıcı görüntülerinin aynı ACR kayıt defteri sunucusunda barındırılması gerekir. Aynı kayıt defteri sunucusuna eklendikten sonra uygulama ayarları oluşturmanız ve ardından Docker Compose yapılandırma dosyasını ACR görüntü adını içerecek şekilde güncelleştirmeniz gerekir.

Aşağıdaki uygulama ayarlarını oluşturun:

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL (tam URL, örn: https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD (ACR ayarlarında yönetici erişimini etkinleştirme)

Yapılandırma dosyasının içinde aşağıdaki örnekte olduğu gibi ACR görüntünüze başvurun:

image: <server-name>.azurecr.io/<image-name>:<tag>

• Erişim için yalnızca bir kapsayıcı açılabilir
• Yalnızca 80 ve 8080 numaralı bağlantı noktaları erişilebilir (kullanıma sunulan bağlantı noktaları)

Öncelik sırasına göre hangi kapsayıcının erişilebilir olduğunu belirlemeye yönelik kurallar şunlardır:

• Kapsayıcı adına ayarlanmış uygulama ayarı WEBSITES_WEB_CONTAINER_NAME
• 80 veya 8080 numaralı bağlantı noktasını tanımlayan ilk kapsayıcı
• Yukarıdakilerden hiçbiri doğru değilse, dosyada tanımlanan ilk kapsayıcı erişilebilir (kullanıma sunulur)

depends_on Bu seçenek App Service'te desteklenmez ve yoksayılır. Docker'dan gelen denetim başlatma ve kapatma önerilerinde olduğu gibi, App Service Çok kapsayıcılı uygulamalar da uygulama kodu aracılığıyla bağımlılıkları denetlemelidir ( hem başlatma hem de bağlantı kesilmesi sırasında). Aşağıdaki örnek kod, Redis kapsayıcısının çalışıp çalışmadığını görmek için python uygulaması denetimini gösterir.

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Web Yuvaları

Web Yuvaları Linux uygulamalarında desteklenir. webSocketsEnabled Web Yuvaları her zaman Linux için etkinleştirildiğinden ARM ayarı Linux uygulamaları için geçerli değildir.

Fiyatlandırma SKU'ya ve bölgeye göre değişiklik gösterir, ancak fiyatlandırma sayfamızda daha fazla ayrıntı görebilirsiniz: App Service Fiyatlandırması.

Azure Uygulaması Hizmetleri kapsayıcınızı başlattığında, ısınma isteği uygulamanızın /robots933456.txt uç noktasına bir HTTP isteği gönderir. Bu yalnızca sahte bir uç noktadır, ancak uygulamanızın 5XX olmayan herhangi bir durum koduyla yanıtlaması gerekir. Uygulama mantığınız var olmayan uç noktalara herhangi bir HTTP durum koduyla yanıt vermezse, ısınma isteği yanıt alamaz ve kapsayıcınızı kalıcı olarak yeniden başlatır. Bağlantı noktası yanlış yapılandırması nedeniyle ısınma isteği de başarısız olabilir.

Bağlantı noktasının Azure Uygulaması Hizmetleri'nde doğru yapılandırıldığından emin olmak için Linux kapsayıcımda bağlantı noktasını belirtme Nasıl yaparım? sorusuna bakın.

Kapsayıcıdan yanıt almak için 240 saniye bekledikten sonra varsayılan olarak ısınma isteği başarısız olur. Uygulama ayarını WEBSITES_CONTAINER_START_TIME_LIMIT 240 ile 1800 saniye arasında bir değerle ekleyerek kapsayıcı ısınma isteği zaman aşımını artırabilirsiniz.

Uygulamanızın dosya sistemi bağlı bir ağ paylaşımıdır. Bu, kodunuzun birden çok konakta yürütülmesi gereken ölçeği genişletme senaryolarına olanak tanır. Ne yazık ki bu, veritabanı dosyasında özel kilitler almak mümkün olmadığından SQLite gibi dosya tabanlı veritabanı sağlayıcılarının kullanımını engeller. Yönetilen veritabanı hizmeti öneririz: Azure SQL, MySQL için Azure Veritabanı veya PostgreSQL için Azure Veritabanı

Uygulama ayarları için yalnızca harfleri (A-Z, a-z), sayıları (0-9) ve alt çizgi karakterini (_) kullanabilirsiniz.

Fikrinizi Web Apps geri bildirim forumunu kullanarak gönderebilirsiniz. Fikrinizin başlığına "[Linux]" ekleyin.

Sonraki adımlar

• Linux'ta Azure Uygulaması Hizmeti nedir?
• Azure App Service’ta hazırlık ortamları ayarlama
• Kapsayıcılar için Web App ile Sürekli Dağıtım
• Bilmeniz Gerekenler: Web Apps ve Linux
• Ortam değişkenleri ve uygulama ayarları başvurusu

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.