Linux hakkında Azure App Service SSS

GitHub'da tüm Docker dosyalarını bulabilirsiniz.

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.

Uygulama hizmetinin ayrılmış alanını true olarak ayarlayın.

Evet, Kapsayıcılar için Web Uygulaması 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, adlı bir uygulama ayarını false olarak WEBSITE_WEBDEPLOY_USE_SCM 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 desteklenmemektedir.

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şlatmalarda 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 depolaması: Dosya sistemi depolama alanı App Service planı kotasında yer alır. Dosyalar dizinindeki kalıcı /home 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. Platform tarafından docker depolama sürücüsü aracılığıyla 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ışan üzerinde özel görüntüleri depolamak için kullanılır. Konak disk alanının tam kullanılabilirliğine bağlı olarak 15 GB'tan büyük bir alan kullanabilirsiniz, ancak bu garanti değildir.

Kapsayıcının yazılabilir katmanı verileri dizinin veya bağlı bir Azure depolama yolunun/home dışı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 Depolama Alanını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 üzerinde çalışırken kapsayıcı görüntülerinizi mümkün olduğunca küçük tutmanızı ve kalıcı depolamaya 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ı 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 görüntü 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. Uygulama kapsayıcısının dosya sistemini veya çalışan işlemlerini denetleyemezsiniz.

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'daki EXPOSE yönergesini ve kapsayıcıya bağlanacak 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. Bunlar 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>

• Yalnızca bir kapsayıcı erişim için açık olabilir
• 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:

• Uygulama ayarı WEBSITES_WEB_CONTAINER_NAME kapsayıcı adına ayarlandı
• 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)

seçenek depends_on App Service desteklenmez ve yoksayılır. Docker'dan gelen denetim başlatma ve kapatma önerisi gibi App Service Çok kapsayıcılı uygulamalar da hem başlatma hem de bağlantı kesilmesi sırasında uygulama kodu aracılığıyla bağımlılıkları denetlemelidir. Aşağıdaki örnek kodda Redis kapsayıcısının çalıştırılıp çalıştırılamadığını görmek için python uygulaması denetimi gösterilmektedir.

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ırma.

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 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 App Service nedir?
• Azure App Service'de hazırlama ortamlarını 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.