Hatalı bir Flex Tüketim planı uygulama dağıtımından kurtarma

Bir dağıtım hataya yol açtığında, hızla toparlanmanın bir yoluna ihtiyaç duyarsınız. Bu makalede, sürekli tümleştirme ve sürekli dağıtım (CI/CD) işlemi kullanarak Flex Consumption işlev uygulamasına hatalı bir dağıtımdan nasıl kurtarabileceğiniz gösterilmektedir. Bu işlem şu kurtarma yöntemlerini içerir:

Kurtarma yöntemi Hız Ne zaman kullanılır? Description
Önceki başarılı çalıştırmayı yeniden çalıştır (geri dön) En Hızlı Bilinen iyi sürüm var veya sürümler arasında veri veya durum değişikliği yok Önceki bir çalışmayı seçin ve yeniden çalıştırın, ardından derleme ve dağıtımın tamamlanmasını bekleyin.
git revert ve ardından git push (ileri sar) Orta Düzeltme basittir; aksi takdirde dış durum geri alınamaz. Hataya neden olan commit’i belirleyin, geri alın ve pushlayın. Ardından aynı derleme ve dağıtım süresini bekleyin.
git commit bir acil düzeltme ve ardından git push (ileri alma) En yavaş Kök neden biliniyor ve hedeflenen bir düzeltme gerekiyor Kök nedeni belirleyin; bir düzeltme oluşturma, gözden geçirme, test ve birleştirme; ve ardından derleme ve dağıtma işleminin tamamlanmasını bekleyin.

Bu stratejiler hem işlev uygulama kodunuzu hem de uygulama ayarlarınızı kurtarır, böylece yapılandırma değişiklikleriniz kod değişiklikleriyle kurtarılabilir.

Dağıtımı kurtarmak için CI/CD'ye neden ihtiyacınız var?

Flex Consumption planı uygulamanıza kod dağıttığınızda:

  • Kodunuz başlangıçta bağlanan bir blob depolama kapsayıcısına zip paketi olarak dağıtılır.
  • Her dağıtım, mevcut paketin üzerine yazar.
  • Platform, önceki sürümleri korumak için yerleşik düzeltme geçmişini tutmaz.
  • Dağıtım yuvaları özelliği şu anda desteklenmemektedir.
  • Uygulama ayarları Azure portalı, CLI veya kod olarak altyapı (IaC) aracılığıyla ayrı ayrı uygulanır ve platform bunları önceki bir duruma geri yükleyemez.

Bu dağıtım davranışları, Esnek Tüketim planı uygulamanızı hatalı bir dağıtımdan kurtarma seçeneklerinizi sınırlar.

Git geçmişiniz ve CI/CD işleminiz, belirli bir noktadaki kod dağıtımlarını izlemenin tek yolunu sağlar. Kod ve yapılandırmayı birlikte içeren bir dağıtım oluşturmak, bir sonraki çalıştırmayı bilinen sorunsuz bir commit’e yönlendirerek hatalı bir sürümden kurtulmanızı sağlar.

Esnek Tüketim dağıtım modeli hakkında daha fazla bilgi için bkz: Esnek Tüketim planı ve Esnek Tüketim planındaki Site güncelleştirmeleri.

Prerequisites

  • Azure'da Flex Consumption planına dağıtılan mevcut bir işlev uygulaması.

  • Git deposundaki kaynak kodu. Her sürüm için Git etiketlerini kullanın veya işleme SSA'larını kaydedin, böylece nelere geri dönebileceğinizi hızla belirleyebilirsiniz.

  • İşlev uygulamanız için yapılandırılmış bir dağıtım:

    GitHub Actions kullanarak sürekli teslim bölümünde açıklandığı gibi OIDC kimlik doğrulaması ile yapılandırılmış bir iş akışı. İş akışı azure/login kullanmalıdır. Yayımlama profili kimlik doğrulaması, bu kılavuzda kullanılan az cli komutlarını desteklemez.

Uygulama ayarlarını yönetmek için dağıtımınızı hazırlama

Tam bir geri alma işlemi gerçekleştirebilmeniz için önce uygulama ayarlarınızı kaynak denetimine yerleştirmeniz ve dağıtımınızın bir parçası olarak uygulamanız gerekir. Bu yaklaşım hem kodu hem de yapılandırmayı tek bir yeniden çalıştırmada kurtarmanıza olanak tanır ancak ayarları uygulama, yeniden başlatmaları bekleme ve bildirilmeyen değerleri temizleme gibi ek adımlar gerektirir.

Tip

Dağıtımınız ayarları içermediğinde, yalnızca dağıtılan kodu geri alabilir, yapılandırmayı geri almayabilirsiniz.

Bu bölümde, dağıtımınızın bir parçası olarak uygulama ayarlarını yönetmeye yönelik iki yaklaşım ayrıntılı olarak yer almaktadır:

Approach İş akışında (Azure CLI) Hizmet tanımında (Bicep)
Nasıl çalışır Dağıtım adımları, bir JSON dosyasındaki ayarları az functionapp config appsettings kullanarak uygular ve ardından bildirilmemiş ayarları kaldırır Bicep şablonu ayarları siteConfig.appSettings içinde bildirir; ARM, dağıtım sırasında koleksiyonun tamamını değiştirir
Karmaşıklık Orta. JSON dosyası ve iş akışınızda ek CLI adımları Daha yüksek. Bicep bilgisi gerektirir
Kayma algılama No Evet (what-if)
Şunun için en uygun Başlangıç, küçük ekipler için Üretime hazır, çok ortamlı, karmaşık altyapı

Uygulama ayarları hakkında daha fazla genel bilgi için bkz. Azure İşlevleri için uygulama ayarları başvurusu.

Uygulama ayarlarıyla ilgili dikkat edilmesi gerekenler

Uygulama ayarlarının programlı yapılandırmasıyla çalışırken bu noktalara dikkat edin.

Important

Her iki yaklaşımdan birini kullanarak tüm gerekli ayarların dahil edilmemesi dağıtılan uygulamanızı bozabilir.

  • Bu bölümdeki her iki yaklaşım da ayarlar dosyanızı istenen tam durum olarak ele alır. Dosyada bildirilmeyen tüm uygulama ayarlarını her dağıtımda uygulamadan kaldırır. Uygulamanızı bozmamak için her zaman tüm gerekli ayarları ekleyin.

  • app-settings.json ve Bicep dosya şablonu değişikliklerini, kod değişiklikleriyle aynı titizlikle değerlendirin. Üretime ulaşmadan önce yapılandırma hatalarını yakalamak için çekme isteklerindeki ayar değişikliklerini gözden geçirin.

  • En iyi güvenlik için bağlantılarınız için şu yönergeleri izleyin:

    • Mümkün olan her yerde yönetilen kimlik bağlantılarını kullanın. Konak depolama (), dağıtım depolama alanı ve tetikleyici/bağlama bağlantıları için AzureWebJobsStorage bağlantılar ayarlayın. Daha fazla bilgi için bkz . Dağıtım ayarlarını yapılandırma.

      • Gizli bilgilerin kullanımı kaçınılmaz olduğunda Key Vault başvurularını kullanın. Key Vault, gizli bilgilerinizi güvenli bir şekilde depolar. Gizli bilgileri doğrudan depolamak yerine, çalışma zamanında gerekli gizli bilgiye güvenli bir şekilde erişmek için bir referans kullanabilirsiniz. Daha fazla bilgi için Key Vault başvurularını kullanma bölümüne bakın.

  • CI/CD kullandığınızda, uygulama ayarlarınızda veya kodunuzda yapılan her değişiklik ayrı bir site güncelleştirmesini tetikler. Varsayılan olarak, bu dağıtım işlemi en az iki site güncelleştirmesi oluşturur: önce ayarlar uygulandığında ve ardından kod dağıtıldığında. Sıfır kapalı kalma süresi dağıtımları için bunun yerine örneklerin boşaltıldığı ve toplu olarak değiştirildiği sıralı bir güncelleştirme stratejisi kullanın. Daha fazla bilgi için bkz. Flex Consumption planında site güncelleştirmeleri.

İş akışında uygulama ayarlarını yapılandırma

Proje dağıtımınıza bir uygulama ayarları yapılandırma dosyası eklemek için şu temel adımları kullanın:

  1. Deponuzda, örneğin infra/app-settings.json içinde bir JSON dosyası oluşturun. Bu dosya, aşağıdaki örneğe benzer bir JSON biçiminde gerekli tüm uygulama ayarlarını içermelidir:

    [
  {
    "name": "FUNCTIONS_EXTENSION_VERSION",
    "value": "~4"
  },
  {
    "name": "FUNCTIONS_WORKER_RUNTIME",
    "value": "dotnet-isolated"
  },
  {
    "name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
    "value": "InstrumentationKey=00000000-..."
  },
  {
    "name": "AzureWebJobsStorage__blobServiceUri",
    "value": "https://mystorageaccount.blob.core.windows.net"
  },
  {
    "name": "AzureWebJobsStorage__queueServiceUri",
    "value": "https://mystorageaccount.queue.core.windows.net"
  },
  {
    "name": "AzureWebJobsStorage__tableServiceUri",
    "value": "https://mystorageaccount.table.core.windows.net"
  },
  {
    "name": "MyFeatureFlag",
    "value": "true"
  },
  {
    "name": "ServiceBus__fullyQualifiedNamespace",
    "value": "my-namespace.servicebus.windows.net"
  }
]

  2. Belirli dağıtım tanımınızda, kod dağıtımı gerçekleşmeden önce ayarları uygulayan ve aralarında 30 saniyelik bir duraklama olan adımlar ekleyin.

Aşağıdaki bölümlerde her iki yaklaşım kullanılarak belirli dağıtım örnekleri sağlanır.

Örnek: app-settings.json dağıtımı

Bu dağıtım örneği, dağıtımınızı yapılandırmayı içerecek biçimde nasıl ayarlayacağınızı gösterir. CI/CD yönteminizle eşleşen sekmeyi seçin.

İş akışınızdaki deploy işe aşağıdaki adımları ekleyin. actions/checkout@v4 kullanılabilir olması için deploy öğesini infra/app-settings.json job’ına ekleyin ve RESOURCE_GROUP öğesini iş akışı düzeyindeki env bloğunuza ekleyin. Adımlar önce ayarları uygular, yeniden başlatmayı bekler, kodu dağıtır ve ardından bildirilmeyen ayarları temizler.

  deploy:
    needs: build
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v4

      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v4
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ./downloaded-artifact

      - name: 'Log in to Azure'
        uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: 'Apply app settings'
        run: |
          az functionapp config appsettings set \
            --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --settings @infra/app-settings.json

      - name: 'Wait for settings restart'
        run: sleep 30

      - name: 'Deploy code'
        uses: Azure/functions-action@v1
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ./downloaded-artifact

      - name: 'Remove undeclared app settings'
        run: |
          DESIRED=$(jq -r '.[].name' infra/app-settings.json)
          CURRENT=$(az functionapp config appsettings list \
            --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --query "[].name" -o tsv)
          TO_DELETE=""
          for setting in $CURRENT; do
            if ! echo "$DESIRED" | grep -qx "$setting"; then
              TO_DELETE="$TO_DELETE $setting"
            fi
          done
          if [ -n "$TO_DELETE" ]; then
            az functionapp config appsettings delete \
              --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
              --resource-group ${{ env.RESOURCE_GROUP }} \
              --setting-names $TO_DELETE
          fi

OIDC tabanlı iş akışındaki azure/login@v2 adımı, az cli komutları için gereken kimlik doğrulamayı sağlar.

Bicep dağıtımında ayarları tanımlayın

IaC dağıtımları için uygulama ayarlarını doğrudan Bicep şablonunda yönetin. Bicep, ayrı bir temizleme adımına gerek kalmadan her dağıtımda siteConfig.appSettings koleksiyonunun tamamını doğrudan değiştirir. Ayrıca what-if kullanarak kayma algılamayı da destekler.

Bicep dosyanızın yalnızca uygulama ayarları bölümünü güncelleştirdiğinizde, dağıtım sırasında diğer tüm Azure kaynakları değiştirilmeden kalır. Bu makale, Bicep yazım sürecini uçtan uca kapsamaz. Tüm Esnek Tüketim şablonları için Azure İşlevleri için kod olarak altyapı bölümüne bakın.

İşte Bicep şablonunun ilgili parçası (appSettingsyalnızca bölümü):

siteConfig: {
  appSettings: [
    {
      name: 'MyFeatureFlag'
      value: 'true'
    }
    {
      name: 'ServiceBus__Connection'
      value: '@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/secrets/sb-conn)'
    }
  ]
}

kod dağıtımından önce Bicep şablonunu dağıtma adımlarını ekleyin ve arada 30 saniye bekleyin. Uygulama ayarlarını Bicep aracılığıyla güncelleştirmek eşzamansızdır. Uygulama yeni değerleri almak için yeniden başlatılır ve yeniden başlatma sırasında kod dağıtımı başarısız olabilir.

      - name: 'Deploy infrastructure'
        run: |
          az deployment group create \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --template-file infra/main.bicep \
            --parameters appName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      - name: 'Wait for settings restart'
        run: sleep 30

      - name: 'Deploy code'
        uses: Azure/functions-action@v1
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ./downloaded-artifact

Dağıtımı geri al

Geri dönmek, önceki başarılı çalıştırmayı yeniden çalıştırma anlamına gelir. Yeniden çalıştırma, o çalıştırmayı tetikleyen özgün işleme SHA'sını (geçerli dal HEAD'i değil) denetler, bu nedenle kodu ve ayarlar dosyasını belirli bir noktadan yeniden oluşturur ve dağıtır. Yeni commit'lere ihtiyacınız yok.

Bir dağıtımı, önceki başarılı bir çalıştırmayı yeniden çalıştırarak geri döndürmek için:

  1. GitHub deponuzda Eylemler sekmesine gidin.
  2. Hatalı dağıtımdan önceki son başarılı iş akışı çalıştırmasını bulun.
  3. Tüm işleri yeniden çalıştır'ı seçin.
  4. İş akışı, çalıştırmanın işlemesini denetler, kodu yeniden oluşturur, dağıtır ve uygulama ayarlarını bu işlemenin app-settings.jsonöğesinden eşitler.

Yeniden çalıştırmanın yeniden oluşturdukları

Yeniden çalıştırma, kodu eski işlemeden yeniden oluşturur. Özgün ikili yapıtı yeniden kullanmaz. Bu davranış şu anlama gelir:

  • Sabitlenmiş bağımlılık kilit dosyaları (package-lock.json, requirements.txtvb.) ile çıkış işlevsel olarak aynıdır.
  • Derleme süresi normal bir dağıtımla aynıdır. Anlık değil.
  • Derleme zamanında getirilen dış bağımlılıklar (NuGet, npm, pip) hala kullanılabilir olmalıdır.

Dikkat edilmesi gerekenleri geri alma

  • Bağımlılık kilit dosyalarınızı (package-lock.json, requirements.txtveya kilitli .csproj sürümleri) kaynak denetimine sabitleyin. Sabitlenmiş kilit dosyaları, bir dağıtım yeniden ne zaman çalıştırılırsa çalıştırılsın işlevsel açıdan özdeş bir derleme üretilmesini sağlar.

  • Yeniden çalıştırma, orijinal işleme içindeki iş akışı veya işlem hattı YAML dosyasını kullanır. Ancak gizli diziler ve işlem hattı değişkenleri, yeniden çalıştırılma sırasında geçerli değerlerine çözümlenir. Gizli anahtarlarınızı ilk çalıştırma ile yeniden çalıştırma arasında değiştirdiğinizde, yeni gizli anahtar değeri kullanılır.

  • Yeniden çalıştırma, dağıtılan uygulamanızı bilinen iyi bir duruma geri yükler, ancak Git geçmişinizi değiştirmez. Branch HEAD'iniz hâlâ bozuk commit'i işaret ediyor.

  • Yeniden çalıştırmanın geri yüklemediği öğeler:

    • barındırma planları, ağ ve kimlik atamaları dahil olmak üzere dağıtımınız dışında yönetilen Azure kaynak yapılandırması.
    • Veritabanları, ileti kuyrukları ve depolama gibi aşağı akış hizmetlerindeki veri veya şema değişiklikleri.
    • Key Vault gizli anahtar değerleri. Sürüm denetiminde yalnızca Key Vault referansları tutulur. Gizli dizileri döndürme, Key Vault işlemidir.

  • Geri alma işleminizi düzenli olarak test edin. Çalışmadığını anlamak için üretim ortamında bir sorun yaşanmasını beklemeyin.

Geri alma işleminden sonra dalı düzeltin

Push ile tetiklenen bir sonraki çalıştırma hatalı commit’i yeniden dağıtıma aldığı için, dalı çeken diğer geliştiriciler hâlâ hatalı kodu görür. Bu durumu şu eylemlerden biriyle düzeltmeniz gerekir:

  • Temelde bir ileri alma işlemi olan bu sorunu ele alan bir hotfix commit’i oluşturun.
  • Hatalı commit’i, aynı zamanda bir ileri alma işlemi olan yeni bir commit oluşturarak geri almak için git revert gerçekleştirin.
  • Sorunu çözene kadar birleştirmeyi engelleyen bir dal ilkesi.

Bu işlemlerden birini tamamlayana kadar, o dalda yeni bir çalıştırmayı tetiklemekten kaçının. Doğrulama kılavuzu için bkz. Birleştirmeden önce doğrulama.

Dağıtımı ileri al

Rolling forward, sorunu gidermek için yeni bir commit göndermek anlamına gelir. Bozuk dağıtım, düzeltme dağıtılana kadar canlı kalır, bu nedenle uygulama bu süre boyunca düşük davranışı tolere ettiğinde bu strateji en iyi şekilde çalışır.

  1. Dalınızda bir düzeltme commit’i oluşturun. Bu düzeltme şu şekilde olabilir:

    • Sorunu doğrudan gideren bir düzeltme .
    • git revert <bad-commit-sha> Hatalı değişiklikleri geri alan yeni bir işleme oluşturan. git revert koddaki değişiklikleri geri alsa da, yeni bir commit oluşturduğu ve yeni bir dağıtım başlattığı için bu bir ileri sarma işlemidir.

  2. Düzeltme ayrıca yapılandırma değişiklikleri de gerektiriyorsa, uygulama ayarlarınızı aynı commit'te (ya app-settings.json içinde ya da Bicep şablonunuzda) güncelleyin.

  3. Commit'i gönder. Dağıtımınız düzeltmeyi otomatik olarak derleyip dağıtır.

Birleştirmeden önce doğrulama

Kurtarma stratejiniz ne olursa olsun, sorunu daha da büyütmemek için commit’leri üretim dalınıza birleştirmeden önce doğrulayın ve düzeltin.

Bu öneriler, ister proaktif olarak ileriye alma işlemini yapıyor olun ister geri döndürmeden sonra dalı düzeltiyor olun, geçerlidir:

  • Hazırlık ortamı kullanın: Esnek Tüketim planı şu anda dağıtım yuvalarını desteklemediğinden, düzeltmenizi üretim dalıyla birleştirmeden önce doğrulamak için bunun yerine ayrı bir Esnek Tüketim planı uygulamasına dağıtmayı değerlendirin.

  • Sistem durumu denetimlerini otomatikleştirme: Uygulamanızda sistem durumu denetimi uç noktasını çağıran ve olumlu bir yanıtı doğrulayan bir postdeploy adımı ekleyin. Bir hata durumunda, otomatik olarak geri dönmek için önceki başarılı çalıştırmayı yeniden tetiklemeyi değerlendirin.

  • Dağıtımdan sonra izleme: Regresyon algılama için Application Insights uyarılarını ayarlayın. Erken algılama, kötü bir dağıtımın etkisini azaltır.

İlgili içerik

  • Last updated on