Share via


Windows üzerinde ilk Service Fabric kapsayıcı uygulamanızı oluşturma

Bir Service Fabric kümesindeki Windows kapsayıcısında mevcut olan bir uygulamayı çalıştırmak için uygulamanızda herhangi bir değişiklik yapılması gerekmez. Bu makalede Python Flask web uygulaması içeren bir Docker görüntüsü oluşturma ve bunu Azure Service Fabric kümesine dağıtma adımları açıklanmaktadır. Ayrıca, kapsayıcıya alınmış uygulamanızı Azure Container Registry aracılığıyla paylaşırsınız. Bu makale Docker hakkında temel bir anlayışınızın olduğunu varsayar. Docker’a Genel Bakış makalesini okuyarak Docker hakkında bilgi edinebilirsiniz.

Dekont

Bu makale bir Windows geliştirme ortamı için geçerlidir. Service Fabric küme çalışma zamanı ve Docker çalışma zamanı aynı işletim sisteminde çalışıyor olmalıdır. Windows kapsayıcılarını linux kümesinde çalıştıramazsınız.

Dekont

Azure ile etkileşim kurmak için Azure Az PowerShell modülünü kullanmanızı öneririz. Başlamak için bkz. Azure PowerShell'i yükleme. Az PowerShell modülüne nasıl geçeceğinizi öğrenmek için bkz. Azure PowerShell’i AzureRM’den Az’ye geçirme.

Ön koşullar

  • Şunları çalıştıran bir geliştirme bilgisayarı:

  • Kapsayıcılar ile Windows Server üzerinde çalışan üç veya daha fazla düğüme sahip bir Windows kümesi.

    Bu makale için, küme düğümlerinizde çalışan Kapsayıcılar ile Windows Server sürümünün (derlemesinin) geliştirme makinenizdeki sürümle eşleşmesi gerekir. Bunun nedeni, docker görüntüsünü geliştirme makinenizde oluşturmanız ve kapsayıcı işletim sisteminin sürümleri ile dağıtıldığı konak işletim sistemi arasında uyumluluk kısıtlamaları olmasıdır. Daha fazla bilgi için bkz . Windows Server kapsayıcı işletim sistemi ve konak işletim sistemi uyumluluğu.

    Kümeniz için ihtiyacınız olan Kapsayıcılar ile Windows Server sürümünü belirlemek için, geliştirme makinenizde bir Windows komut isteminden komutunu çalıştırın ver . Küme oluşturmadan önce Windows Server kapsayıcı işletim sistemi ve konak işletim sistemi uyumluluğuna bakın.

  • Azure Container Registry’deki bir kayıt defteri - Azure aboneliğinizde Kapsayıcı kayıt defteri oluşturun.

Dekont

Kapsayıcıların Windows 10 üzerinde çalışan bir Service Fabric kümesine dağıtılması desteklenir. Windows 10'u Windows kapsayıcılarını çalıştıracak şekilde yapılandırma hakkında bilgi için bu makaleye bakın.

Dekont

Service Fabric sürüm 6.2 ve üzeri, Windows Server sürüm 1709'da çalışan kümelere kapsayıcı dağıtmayı destekler.

Docker kapsayıcısını tanımlama

Docker Hub’ında bulunan Python görüntüsünü temel alan bir görüntü oluşturun.

Docker kapsayıcınızı bir Dockerfile içinde belirtin. Dockerfile, kapsayıcınızın içindeki ortamı ayarlama, çalıştırmak istediğiniz uygulamayı yükleme ve bağlantı noktalarını eşleme yönergelerinden oluşur. Dockerfile, görüntüyü oluşturan docker build komutunun girdisidir.

Boş bir dizin oluşturun ve Dockerfile dosyasını oluşturun (dosya uzantısı kullanmayın). Aşağıdakini Dockerfile dosyasına ekleyin ve değişikliklerinizi kaydedin:

# Use an official Python runtime as a base image
FROM python:2.7-windowsservercore

# Set the working directory to /app
WORKDIR /app

# Copy the current directory contents into the container at /app
ADD . /app

# Install any needed packages specified in requirements.txt
RUN pip install -r requirements.txt

# Make port 80 available to the world outside this container
EXPOSE 80

# Define environment variable
ENV NAME World

# Run app.py when the container launches
CMD ["python", "app.py"]

Daha fazla bilgi için Dockerfile başvurusunu okuyun.

Temel bir web uygulaması oluşturma

Bağlantı noktası 80 üzerinden dinleyen ve Hello World! döndüren bir Flask web uygulaması oluşturun. Aynı dizinde, requirements.txt dosyasını oluşturun. Aşağıdakini dosyaya ekleyin ve değişikliklerinizi kaydedin:

Flask

Ayrıca, app.py dosyasını da oluşturun ve aşağıdaki kod parçacığını ekleyin:

from flask import Flask

app = Flask(__name__)


@app.route("/")
def hello():

    return 'Hello World!'


if __name__ == "__main__":
    app.run(host='0.0.0.0', port=80)

Docker'da oturum açın ve görüntüyü oluşturun

Şimdi web uygulamanızı çalıştıran görüntüyü oluşturacağız. Docker'dan genel görüntüleri çekerken (Dockerfile'ımızda olduğu gibi python:2.7-windowsservercore ), anonim çekme isteğinde bulunmak yerine Docker Hub hesabınızla kimlik doğrulaması yapmak en iyi yöntemdir.

Dekont

Sık sık anonim çekme isteklerinde bulunurken, bu hataları önlemek için Docker Hub'a ERROR: toomanyrequests: Too Many Requests. benzer Docker hataları veya You have reached your pull rate limit. Docker Hub'da Kimlik Doğrulaması görebilirsiniz. Daha fazla bilgi için bkz . Azure Container Registry ile genel içeriği yönetme.

PowerShell penceresini açın ve Dockerfile dosyasını içeren dizine gidin. Sonra aşağıdaki komutları çalıştırın:

docker login
docker build -t helloworldapp .

Bu komut Dockerfile içindeki yönergeleri kullanarak yeni görüntüyü oluşturur ve helloworldapp olarak adlandırır (-t etiketi). Bir kapsayıcı görüntüsü oluşturmak için, önce temel görüntü uygulamanın eklendiği Docker Hub’ından indirilir.

Oluşturma komutu tamamlandıktan sonra, yeni görüntü üzerindeki bilgileri görmek için docker images komutunu çalıştırın:

$ docker images

REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
helloworldapp                 latest              8ce25f5d6a79        2 minutes ago       10.4 GB

Uygulamayı yerel olarak çalıştırma

Görüntüyü kapsayıcı kayıt defterine göndermeden önce yerel olarak doğrulayın.

Uygulamayı çalıştırın:

docker run -d --name my-web-site helloworldapp

name, çalışan kapsayıcıya bir ad verir (kapsayıcı kimliği yerine).

Kapsayıcı başladıktan sonra çalışan kapsayıcınıza bir tarayıcıdan bağlanabilmek için IP adresini bulun:

docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" my-web-site

Bu komut hiçbir şey döndürmezse, aşağıdaki komutu çalıştırın ve IP adresi için Network Ayarlar-Networks> öğesini inceleyin:

docker inspect my-web-site

Çalışan kapsayıcıya bağlanın. Döndürülen IP adresine işaret eden bir web tarayıcısı açın, örneğin "http://172.31.194.61". Tarayıcıda "Merhaba Dünya!" başlığının görüntülendiğini görmeniz gerekir.

Kapsayıcınızı durdurmak için şu komutu çalıştırın:

docker stop my-web-site

Kapsayıcıyı geliştirme makinenizden silin:

docker rm my-web-site

Görüntüyü kapsayıcı kayıt defterine gönderme

Kapsayıcının geliştirme makinenizde çalıştığını doğruladıktan sonra, görüntüyü Azure Container Registry içindeki kayıt defterinize gönderin.

Kayıt defteri kimlik bilgilerinizle kapsayıcı kayıt defterinizde oturum açmak için komutunu çalıştırındocker login.

Aşağıdaki örnek bir Microsoft Entra hizmet sorumlusunun kimliğini ve parolasını geçirir. Örneğin, bir otomasyon senaryosu için kayıt defterinize bir hizmet sorumlusu atamış olabilirsiniz. Alternatif olarak, kayıt defteri kullanıcı adınızı ve parolanızı kullanarak da oturum açabilirsiniz.

docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword

Aşağıdaki komut, görüntünün kayıt defterinize ait tam yolu içeren bir etiketini veya diğer adını oluşturur. Bu örnek, kayıt defterinin kökünde dağınıklığı önlemek için samples ad alanına görüntüyü yerleştirir.

docker tag helloworldapp myregistry.azurecr.io/samples/helloworldapp

Görüntüyü kapsayıcı kayıt defterinize gönderin:

docker push myregistry.azurecr.io/samples/helloworldapp

Visual Studio’da kapsayıcıya alınmış hizmet oluşturma

Service Fabric SDK’sı ve araçları, kapsayıcıya alınmış uygulamalar oluşturmanıza yardımcı olan bir hizmet şablonu sağlar.

  1. Visual Studio’yu çalıştırın. Dosya>Yeni>Proje’yi seçin.
  2. Service Fabric uygulaması’nı seçin, "MyFirstContainer" olarak adlandırın ve Tamam’a tıklayın.
  3. Hizmet şablonları listesinden Kapsayıcı’yı seçin.
  4. Görüntü Adı alanına, kapsayıcı deponuza gönderdiğiniz görüntünün dizini olan "myregistry.azurecr.io/samples/helloworldapp" değerini girin.
  5. Hizmetinize bir ad verin ve Tamam’a tıklayın.

İletişimi yapılandırma

Kapsayıcıya alınmış hizmetin iletişim sağlayabilmesi için bir uç nokta gerekir. ServiceManifest.xml dosyasına protokol, bağlantı noktası ve tür bilgileriyle bir Endpoint öğesi ekleyin. Bu örnekte, 8081 numaralı sabit bağlantı noktası kullanılır. Hiçbir bağlantı noktası belirtilmemişse, uygulama bağlantı noktası aralığından rastgele bir bağlantı noktası seçilir.

<Resources>
  <Endpoints>
    <Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
  </Endpoints>
</Resources>

Dekont

Bir hizmet için ek Uç Noktalar, geçerli özellik değerlerine sahip ek EndPoint öğeleri bildirilerek eklenebilir. Her Bağlantı Noktası yalnızca bir protokol değeri bildirebilir.

Uç nokta tanımlandığında, Service Fabric uç noktayı Adlandırma hizmetinde yayımlar. Kümede çalışan diğer hizmetler bu kapsayıcıyı çözümleyebilir. Ayrıca, ters proxy’yi kullanarak kapsayıcıdan kapsayıcıya iletişim kurabilirsiniz. İletişim, ters proxy’nin HTTP dinleme bağlantı noktasını ve iletişim kurmak istediğiniz hizmetlerin adlarının ortam değişkenleri olarak sağlanmasıyla gerçekleştirilir.

Hizmet belirli bir bağlantı noktasında (bu örnekte 8081) dinliyor. Uygulama Azure'daki bir kümeye dağıtıldığında hem küme hem de uygulama bir Azure yük dengeleyicinin arkasında çalışır. Gelen trafiğin hizmete ulaşabilmesi için Azure yük dengeleyicide uygulama bağlantı noktası açık olmalıdır. Azure yük dengeleyicide bu bağlantı noktasını bir PowerShell betiği kullanarak veya Azure portalından açabilirsiniz.

Ortam değişkenlerini yapılandırma ve ayarlama

Ortam değişkenleri, hizmet bildirimindeki her kod paketi için belirtilebilir. Bu özellik, kapsayıcı olarak mı dağıtıldıklarına yoksa konuk yürütülebilir dosyası olarak mı işlendiklerine bakılmaksızın tüm hizmetlerde sağlanır. Ortam değişkeni değerlerini, uygulama bildiriminde geçersiz kılabilir veya dağıtım sırasında uygulama parametresi olarak belirtebilirsiniz.

Aşağıdaki hizmet bildirimi XML kod parçacığı, kod paketi için ortam değişkenlerinin nasıl belirtileceğini gösteren bir örnektir:

<CodePackage Name="Code" Version="1.0.0">
  ...
  <EnvironmentVariables>
    <EnvironmentVariable Name="HttpGatewayPort" Value=""/>    
  </EnvironmentVariables>
</CodePackage>

Bu ortam değişkenleri, uygulama bildiriminde geçersiz kılınabilir:

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
  <EnvironmentOverrides CodePackageRef="FrontendService.Code">
    <EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
  </EnvironmentOverrides>
  ...
</ServiceManifestImport>

Kapsayıcı bağlantı noktasından konak bağlantı noktasına eşlemeyi ve kapsayıcıdan kapsayıcıya keşfi yapılandırma

Kapsayıcıyla iletişim kurmak için kullanılan konak bağlantı noktasını yapılandırın. Bağlantı noktası bağlama, hizmetin kapsayıcı içinde dinlediği bağlantı noktasını konaktaki bağlantı noktasıyla eşler. ApplicationManifest.xml dosyasının ContainerHostPolicies öğesine bir PortBinding öğesi ekleyin. Bu makalede ContainerPort değeri 80 (Dockerfile içinde belirtildiği gibi kapsayıcı 80 numaralı bağlantı noktasını gösterir) ve EndpointRef değeri "Guest1TypeEndpoint" (hizmet bildiriminde daha önce tanımlanmış olan uç nokta) olarak verilir. 8081 numaralı bağlantı noktasında hizmete gelen istekler, kapsayıcı üzerindeki 80 numaralı bağlantı noktasıyla eşlenir.

<ServiceManifestImport>
    ...
    <Policies>
        <ContainerHostPolicies CodePackageRef="Code">
            <PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
        </ContainerHostPolicies>
    </Policies>
    ...
</ServiceManifestImport>

Dekont

Bir hizmet için ek PortBinding'ler, geçerli özellik değerlerine sahip ek PortBinding öğeleri bildirilerek eklenebilir.

Kapsayıcı deposu kimlik doğrulamayı yapılandırma

Kapsayıcı görüntüsü indirme için farklı kimlik doğrulama türlerini yapılandırmayı öğrenmek için bkz . Kapsayıcı Deposu Kimlik Doğrulaması.

Yalıtım modunu yapılandırma

Windows, kapsayıcılar için iki yalıtım modunu destekler: İşlem ve Hyper-V. İşlem yalıtım moduyla, aynı konak makinesinde çalışan tüm kapsayıcılar çekirdeği konakla paylaşır. Hyper-V yalıtım moduyla, çekirdekler her Hyper-V kapsayıcısı ile kapsayıcı konağı arasında yalıtılır. Yalıtım modu, uygulama bildirimi dosyasında bulunan ContainerHostPolicies öğesinde belirtilir. Belirtilebilen yalıtım modları process, hyperv ve default modlarıdır. Varsayılan ayar, Windows Server konaklarında işlem yalıtım modudur. Windows 10 konaklarında yalnızca Hyper-V yalıtım modu desteklenir, bu nedenle kapsayıcı, yalıtım modu ayarından bağımsız olarak Hyper-V yalıtım modunda çalışır. Aşağıdaki kod parçacığı uygulama bildirimi dosyasında yalıtım modunun nasıl belirtildiğini gösterir.

<ContainerHostPolicies CodePackageRef="Code" Isolation="hyperv">

Dekont

Hyperv yalıtım modu, iç içe sanallaştırma desteğine sahip Ev3 ve Dv3 Azure SKU’ları üzerinde kullanılabilir.

Kaynak idaresini yapılandırma

Kaynak idaresi kapsayıcının konakta kullanabildiği kaynakları kısıtlar. Uygulama bildiriminde belirtilen ResourceGovernancePolicy öğesi, hizmet kod paketinin kaynak sınırlarını tanımlamak için kullanılır. Şu kaynaklar için kaynak sınırları ayarlanabilir: Memory, MemorySwap, CpuShares (CPU göreli ağırlığı), MemoryReservationInMB, BlkioWeight (BlockIO göreli ağırlığı). Bu örnekte, Guest1Pkg hizmet paketi bulunduğu küme düğümlerinde bir çekirdek alır. Bellek sınırları mutlaktır; dolayısıyla, kod paketi 1024 MB bellekle (aynı genel garantili ayırmayla) sınırlıdır. Kod paketleri (kapsayıcılar veya işlemler) bu sınırı aşan miktarda bellek ayıramazlar ve bunu denediklerinde yetersiz bellek özel durumu ortaya çıkar. Kaynak sınırı zorlamasının çalışması için, hizmet paketi içindeki tüm kod paketlerinin bellek sınırlarının belirtilmiş olması gerekir.

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
  <Policies>
    <ServicePackageResourceGovernancePolicy CpuCores="1"/>
    <ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024"  />
  </Policies>
</ServiceManifestImport>

Docker HEALTHCHECK ayarlarını yapılandırma

Service Fabric, v6.1 sürümünden itibaren docker HEALTHCHECK olaylarını otomatik olarak sistem durumu raporuyla tümleştirir. Bu, kapsayıcınızda HEALTHCHECK özelliği etkinse kapsayıcının sistem durumuna ilişkin Docker tarafından bildirilen her değişiklik için Service Fabric’in durumu bildireceği anlamına gelir. health_status özelliği healthy olduğunda Service Fabric Explorer’da OK şeklinde bir durum raporu görüntülenirken, health_status özelliği unhealthy olduğunda WARNING görünür.

v6.4'ün en son yenileme sürümünden başlayarak, docker HEALTHCHECK değerlendirmelerinin hata olarak bildirilmesi gerektiğini belirtme seçeneğiniz vardır. Bu seçenek etkinleştirilirse, health_status iyi durumda olduğunda bir Tamam sistem durumu raporu ve health_status iyi durumda olmadığında ERROR görüntülenir.

Kapsayıcı durumunun izlenmesi için gerçekleştirilen gerçek denetimi gösteren HEALTHCHECK yönergesi, kapsayıcı görüntüsü oluşturulurken kullanılan Dockerfile dosyasında mevcut olmalıdır.

Screenshot shows details of the Deployed Service Package NodeServicePackage.

HealthCheckUnhealthyApp

HealthCheckUnhealthyDsp

ApplicationManifest dosyasındaki ContainerHostPolicies kapsamında HealthConfig seçeneklerini belirterek HEALTHCHECK davranışını yapılandırabilirsiniz.

<ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="ContainerServicePkg" ServiceManifestVersion="2.0.0" />
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <HealthConfig IncludeDockerHealthStatusInSystemHealthReport="true"
		      RestartContainerOnUnhealthyDockerHealthStatus="false" 
		      TreatContainerUnhealthyStatusAsError="false" />
      </ContainerHostPolicies>
    </Policies>
</ServiceManifestImport>

Varsayılan olarak IncludeDockerHealthStatusInSystemHealthReporttrue, RestartContainerOnUnhealthyDockerHealthStatus false ve TreatContainerUnhealthyStatusAsError false olarak ayarlanır.

RestartContainerOnUnhealthyDockerHealthStatus özelliği true olarak ayarlanırsa, tekrarlanan şekilde durumunun iyi olmadığı bildirilen kapsayıcılar yeniden başlatılır (muhtemelen diğer düğümlerde).

TreatContainerUnhealthyStatusAsError true olarak ayarlanırsa, kapsayıcının health_status iyi durumda olmadığında HATA durumu raporları görüntülenir.

Tüm Service Fabric kümesi için HEALTHCHECK tümleştirmesini devre dışı bırakmak istiyorsanız EnableDockerHealthCheckIntegration özelliğini false olarak ayarlamanız gerekir.

Kapsayıcı uygulamasını dağıtma

Tüm değişikliklerinizi kaydedin ve uygulamayı derleyin. Uygulamanızı yayımlamak için Çözüm Gezgini’nde MyFirstContainer’a sağ tıklayın ve Yayımla’yı seçin.

Bağlantı Uç Noktası’nda kümenin yönetim uç noktasını girin. Örneğin, containercluster.westus2.cloudapp.azure.com:19000. İstemci bağlantı uç noktasını Azure portalında kümenizin Genel Bakış sekmesinde bulabilirsiniz.

Yayımla öğesine tıklayın.

Service Fabric Explorer, bir Service Fabric kümesindeki uygulama ve düğümleri inceleyip yönetmeye yönelik web tabanlı bir araçtır. Bir tarayıcı penceresi açıp http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ konumuna gidin ve uygulama dağıtımını izleyin. Uygulama dağıtılır ancak görüntü küme düğümlerine indirilene kadar bir hata durumundadır (görüntü boyutuna bağlı olarak biraz zaman alabilir): Error

Uygulama şu durumdayken Ready hazır olur: Ready

Bir tarayıcıyı açın ve http://containercluster.westus2.cloudapp.azure.com:8081 dizinine gidin. Tarayıcıda "Merhaba Dünya!" başlığının görüntülendiğini görmeniz gerekir.

Temizleme

Küme çalışırken size ücret yansımaya devam edebilir, bu nedenle kümenizi silmeyi düşünün.

Görüntüyü kapsayıcı kayıt defterine gönderdikten sonra, yerel görüntüyü geliştirme bilgisayarınızdan silebilirsiniz:

docker rmi helloworldapp
docker rmi myregistry.azurecr.io/samples/helloworldapp

Windows Server kapsayıcı işletim sistemi ve konak işletim sistemi uyumluluğu

Windows Server kapsayıcıları, konak işletim sisteminin tüm sürümlerinde uyumlu değildir. Örnek:

  • Windows Server sürüm 1709 kullanılarak oluşturulan Windows Server kapsayıcıları, Windows Server sürüm 2016 çalıştıran bir konakta çalışmaz.
  • Windows Server 2016 kullanılarak oluşturulan Windows Server kapsayıcıları yalnızca Windows Server sürüm 1709 çalıştıran bir konakta Hyper-V yalıtım modunda çalışır.
  • Windows Server 2016 kullanılarak oluşturulan Windows Server kapsayıcılarında, Windows Server 2016 çalıştıran bir konakta işlem yalıtımı modunda çalışırken kapsayıcı işletim sistemi ve konak işletim sisteminin düzeltmesinin aynı olduğundan emin olmak gerekebilir.

Daha fazla bilgi edinmek için bkz . Windows Kapsayıcı Sürümü Uyumluluğu.

Service Fabric kümenize kapsayıcı oluşturup dağıtırken konak işletim sisteminin ve kapsayıcı işletim sisteminizin uyumluluğunu göz önünde bulundurun. Örnek:

  • Küme düğümlerinizdeki işletim sistemiyle uyumlu bir işletim sistemine sahip kapsayıcılar dağıttığınızdan emin olun.
  • Kapsayıcı uygulamanız için belirtilen yalıtım modunun dağıtıldığı düğümdeki kapsayıcı işletim sistemi desteğiyle tutarlı olduğundan emin olun.
  • Küme düğümlerinize veya kapsayıcılarınıza işletim sistemi yükseltmelerinin uyumluluklarını nasıl etkileyebileceğini göz önünde bulundurun.

Service Fabric kümenizde kapsayıcıların doğru dağıtıldığından emin olmak için aşağıdaki uygulamaları öneririz:

  • Kapsayıcının oluşturulduğu Windows Server işletim sistemi sürümünü belirtmek için Docker görüntülerinizle açık görüntü etiketlemeyi kullanın.
  • Uygulamanızın farklı Windows Server sürümleri ve yükseltmeleri arasında uyumlu olduğundan emin olmak için uygulama bildirim dosyanızda işletim sistemi etiketlemesini kullanın.

Dekont

Service Fabric sürüm 6.2 ve üzeriyle, Windows Server 2016'yı temel alan kapsayıcıları bir Windows 10 konağına yerel olarak dağıtabilirsiniz. Windows 10'da kapsayıcılar, uygulama bildiriminde ayarlanan yalıtım modundan bağımsız olarak Hyper-V yalıtım modunda çalışır. Daha fazla bilgi için bkz . Yalıtım modunu yapılandırma.

İşletim sistemi derlemesine özgü kapsayıcı görüntüleri belirtme

Windows Server kapsayıcıları işletim sisteminin farklı sürümleri arasında uyumlu olmayabilir. Örneğin, Windows Server 2016 kullanılarak oluşturulan Windows Server kapsayıcıları, Windows Server sürüm 1709'da işlem yalıtım modunda çalışmaz. Bu nedenle, küme düğümleri en son sürüme güncelleştirilirse, işletim sisteminin önceki sürümleri kullanılarak oluşturulan kapsayıcı hizmetleri başarısız olabilir. Service Fabric, bunu çalışma zamanının 6.1 ve daha yeni sürümleriyle aşmak için kapsayıcı başına birden çok işletim sistemi görüntüsü belirtmeyi ve uygulama bildiriminde işletim sisteminin derleme sürümleriyle etiketlemeyi destekler. Bir Windows komut isteminde çalıştırarak winver işletim sisteminin derleme sürümünü alabilirsiniz. Düğümlerde işletim sistemini güncelleştirmeden önce uygulama bildirimlerini güncelleştirin ve işletim sistemi başına görüntü geçersiz kılmalarını belirtin. Aşağıdaki kod parçacığında, ApplicationManifest.xml adlı uygulama bildiriminde nasıl birden çok kapsayıcı görüntüsü belirtileceği gösterilmektedir:

      <ContainerHostPolicies> 
         <ImageOverrides> 
	       <Image Name="myregistry.azurecr.io/samples/helloworldappDefault" /> 
               <Image Name="myregistry.azurecr.io/samples/helloworldapp1701" Os="14393" /> 
               <Image Name="myregistry.azurecr.io/samples/helloworldapp1709" Os="16299" /> 
         </ImageOverrides> 
      </ContainerHostPolicies> 

Windows Server 2016'nın derleme sürümü 14393 ve Windows Server sürüm 1709 için derleme sürümü 16299'dir. Aşağıda gösterildiği gibi, hizmet bildiriminde kapsayıcı hizmeti başına tek bir görüntü belirtilmeye devam edilir:

<ContainerHost>
    <ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName> 
</ContainerHost>

Dekont

İşletim sistemi derleme sürümü etiketleme özellikleri yalnızca Windows’da Service Fabric için sunulmaktadır

VM’deki temel işletim sistemi derleme 16299 (sürüm 1709) ise Service Fabric bu Windows Server sürümüne karşılık gelen kapsayıcı görüntüsünü seçer. Uygulama bildiriminde etiketli kapsayıcı görüntülerinin yanı sıra etiketsiz bir kapsayıcı görüntüsü de sağlanırsa, Service Fabric etiketsiz görüntüyü farklı sürümlerde çalışan bir görüntü olarak işler. Yükseltmeler sırasında sorunlardan kaçınmak için kapsayıcı görüntülerini açıkça etiketleyin.

Etiketlenmemiş kapsayıcı görüntüsü, ServiceManifest’te sağlanan görüntü için geçersiz kılma işlevi görür. Yani “myregistry.azurecr.io/samples/helloworldappDefault” görüntüsü ServiceManifest’teki “myregistry.azurecr.io/samples/helloworldapp” ImageName’i geçersiz kılar.

Tam Service Fabric uygulaması ve hizmet bildirimleri örneği

Bu makalede kullanılan tam hizmet ve uygulama bildirimleri aşağıda verilmiştir.

ServiceManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="Guest1Pkg"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <!-- This is the name of your ServiceType.
         The UseImplicitHost attribute indicates this is a guest service. -->
    <StatelessServiceType ServiceTypeName="Guest1Type" UseImplicitHost="true" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <!-- Follow this link for more information about deploying Windows containers to Service Fabric: https://aka.ms/sfguestcontainers -->
      <ContainerHost>
        <ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName>
        <!-- Pass comma delimited commands to your container: dotnet, myproc.dll, 5" -->
        <!--Commands> dotnet, myproc.dll, 5 </Commands-->
        <Commands></Commands>
      </ContainerHost>
    </EntryPoint>
    <!-- Pass environment variables to your container: -->    
    <EnvironmentVariables>
      <EnvironmentVariable Name="HttpGatewayPort" Value=""/>
      <EnvironmentVariable Name="BackendServiceName" Value=""/>
    </EnvironmentVariables>

  </CodePackage>

  <!-- Config package is the contents of the Config directory under PackageRoot that contains an
       independently-updateable and versioned set of custom configuration settings for your service. -->
  <ConfigPackage Name="Config" Version="1.0.0" />

  <Resources>
    <Endpoints>
      <!-- This endpoint is used by the communication listener to obtain the port on which to
           listen. Please note that if your service is partitioned, this port is shared with
           replicas of different partitions that are placed in your code. -->
      <Endpoint Name="Guest1TypeEndpoint" UriScheme="http" Port="8081" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

ApplicationManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="MyFirstContainerType"
                     ApplicationTypeVersion="1.0.0"
                     xmlns="http://schemas.microsoft.com/2011/01/fabric"
                     xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                     xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <Parameters>
    <Parameter Name="Guest1_InstanceCount" DefaultValue="-1" />
  </Parameters>
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion
       should match the Name and Version attributes of the ServiceManifest element defined in the
       ServiceManifest.xml file. -->
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
    <EnvironmentOverrides CodePackageRef="FrontendService.Code">
      <EnvironmentVariable Name="HttpGatewayPort" Value="19080"/>
    </EnvironmentOverrides>
    <ConfigOverrides />
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <RepositoryCredentials AccountName="myregistry" Password="MIIB6QYJKoZIhvcNAQcDoIIB2jCCAdYCAQAxggFRMIIBTQIBADA1MCExHzAdBgNVBAMMFnJ5YW53aWRhdGFlbmNpcGhlcm1lbnQCEFfyjOX/17S6RIoSjA6UZ1QwDQYJKoZIhvcNAQEHMAAEg
gEAS7oqxvoz8i6+8zULhDzFpBpOTLU+c2mhBdqXpkLwVfcmWUNA82rEWG57Vl1jZXe7J9BkW9ly4xhU8BbARkZHLEuKqg0saTrTHsMBQ6KMQDotSdU8m8Y2BR5Y100wRjvVx3y5+iNYuy/JmM
gSrNyyMQ/45HfMuVb5B4rwnuP8PAkXNT9VLbPeqAfxsMkYg+vGCDEtd8m+bX/7Xgp/kfwxymOuUCrq/YmSwe9QTG3pBri7Hq1K3zEpX4FH/7W2Zb4o3fBAQ+FuxH4nFjFNoYG29inL0bKEcTX
yNZNKrvhdM3n1Uk/8W2Hr62FQ33HgeFR1yxQjLsUu800PrYcR5tLfyTB8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBybgM5NUV8BeetUbMR8mJhgFBrVSUsnp9B8RyebmtgU36dZiSObDsI
NtTvlzhk11LIlae/5kjPv95r3lw6DHmV4kXLwiCNlcWPYIWBGIuspwyG+28EWSrHmN7Dt2WqEWqeNQ==" PasswordEncrypted="true"/>
        <PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
      </ContainerHostPolicies>
      <ServicePackageResourceGovernancePolicy CpuCores="1"/>
      <ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024"  />
    </Policies>
  </ServiceManifestImport>
  <DefaultServices>
    <!-- The section below creates instances of service types, when an instance of this
         application type is created. You can also create one or more instances of service type using the
         ServiceFabric PowerShell module.

         The attribute ServiceTypeName below must match the name defined in the imported ServiceManifest.xml file. -->
    <Service Name="Guest1">
      <StatelessService ServiceTypeName="Guest1Type" InstanceCount="[Guest1_InstanceCount]">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
</ApplicationManifest>

Kapsayıcı zorla sonlandırılmadan önceki zaman aralığını yapılandırın

Hizmet silme (veya başka bir düğüme taşıma) başladıktan sonra, çalışma zamanının kapsayıcı kaldırılmadan önce ne kadar bekleyeceğine ilişkin bir zaman aralığı yapılandırabilirsiniz. Zaman aralığını yapılandırma, kapsayıcıya docker stop <time in seconds> komutunu gönderir. Daha ayrıntılı bilgi için bkz. docker durdurma. Beklenecek zaman aralığı, Hosting bölümünde belirtilir. Bölüm Hosting , küme oluşturma sırasında veya daha sonraki bir yapılandırma yükseltmesinde eklenebilir. Aşağıdaki küme bildirimi kod parçacığı, bekleme aralığının nasıl ayarlandığını gösterir:

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
                "name": "ContainerDeactivationTimeout",
                "value" : "10"
          },
	      ...
        ]
	}
]

Varsayılan zaman aralığı 10 saniye olarak ayarlanır. Bu yapılandırma dinamik olduğundan, kümedeki yalnızca yapılandırmaya yönelik bir güncelleştirme zaman aşımını güncelleştirir.

Kullanılmayan kapsayıcı görüntülerini kaldırmak için çalışma zamanını yapılandırma

Service Fabric kümesini kullanılmayan kapsayıcı görüntülerini düğümden kaldıracak şekilde yapılandırabilirsiniz. Bu yapılandırma, düğümde çok fazla kapsayıcı görüntüsü varsa yeniden disk alanı elde edilmesine imkan tanır. Bu özelliği etkinleştirmek için küme bildirimindeki Barındırma bölümünü aşağıdaki kod parçacığında gösterildiği gibi güncelleştirin:

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
                "name": "PruneContainerImages",
                "value": "True"
          },
          {
                "name": "ContainerImagesToSkip",
                "value": "mcr.microsoft.com/windows/servercore|mcr.microsoft.com/windows/nanoserver|mcr.microsoft.com/dotnet/framework/aspnet|..."
          }
          ...
          }
        ]
	} 
]

Silinmemesi gereken görüntüleri ContainerImagesToSkip parametresi altında belirtebilirsiniz.

Kapsayıcı görüntüsü indirme süresini yapılandırma

Service Fabric çalışma zaman, kapsayıcı görüntülerinin indirilip ayıklanması için 20 dakika ayırır ve bu süre çoğu kapsayıcı görüntüsü için yeterlidir. Görüntüler büyükse veya ağ bağlantısı yavaşsa görüntü indirme ve ayıklama işlemi iptal edilmeden önce beklenecek sürenin artırılması gerekebilir. Zaman aşımı, aşağıdaki kod parçacığında gösterildiği gibi küme bildiriminin Barındırma bölümündeki ContainerImageDownloadTimeout özniteliği kullanılarak ayarlanabilir:

"fabricSettings": [
	...,
	{
        "name": "Hosting",
        "parameters": [
          {
              "name": "ContainerImageDownloadTimeout",
              "value": "1200"
          }
        ]
	}
]

Kapsayıcı bekletme ilkesi ayarlama

Service Fabric (6.1 veya üzeri sürümler), kapsayıcı başlatma hatalarının tanılanmasına yardımcı olmak için sonlandırılan veya başlatılamayan kapsayıcıların bekletilmesini destekler. Bu ilke, aşağıdaki kod parçacığında gösterildiği gibi ApplicationManifest.xml dosyasında ayarlanabilir:

 <ContainerHostPolicies CodePackageRef="NodeService.Code" Isolation="process" ContainersRetentionCount="2"  RunInteractive="true"> 

ContainersRetentionCount ayarı, başarısız olduğunda bekletilecek kapsayıcı sayısını belirtir. Negatif bir değer belirtilirse başarısız olan tüm kapsayıcılar bekletilir. ContainersRetentionCount özniteliği belirtilmezse hiçbir kapsayıcı bekletilmez. ContainersRetentionCount özniteliği, kullanıcıların test ve üretim kümeleri için farklı değerler belirtebilmesi amacıyla Uygulama Parametrelerini destekler. Kapsayıcı hizmetinin diğer düğümlere taşınmasını önlemek için bu özellikler kullanılırken kapsayıcı hizmetinin belirli bir düğümü hedeflemesini sağlamak için yerleştirme kısıtlamaları kullanın. Bu özellik kullanılarak bekletilen tüm kapsayıcılar el ile kaldırılmalıdır.

Docker cinini özel bağımsız değişkenlerle başlatma

Service Fabric çalışma zamanı 6.2 sürümü ve üzeriyle, Docker cinini özel bağımsız değişkenler kullanarak başlatabilirsiniz. Özel bağımsız değişkenler belirtildiğinde, Service Fabric --pidfile bağımsız değişkeni hariç hiçbir bağımsız değişkeni Docker altyapısına geçirmez. Bu nedenle, --pidfile bir bağımsız değişken olarak geçirilmemelidir. Ayrıca, Service Fabric’in Daemon ile iletişim kurması için bağımsız değişken docker’ın Windows’da varsayılan ad kanalında (veya Linux’ta unix etki alanı yuvasında) dinlemeye devam etmesini sağlamalıdır. Özel bağımsız değişkenler, aşağıdaki kod parçacığında gösterildiği gibi ContainerServiceArguments altındaki Barındırma bölümü altındaki küme bildiriminde geçirilir:

"fabricSettings": [
	...,
	{ 
        "name": "Hosting", 
        "parameters": [ 
          { 
            "name": "ContainerServiceArguments", 
            "value": "-H localhost:1234 -H unix:///var/run/docker.sock" 
          } 
        ] 
	} 
]

EntryPoint Geçersiz Kılma

ServiceFabric Runtime'ın 8.2 sürümüyle, kapsayıcı ve exe ana bilgisayar kodu paketi için giriş noktası geçersiz kılınabilir. Bu, tüm bildirim öğelerinin aynı kaldığı ancak kapsayıcı görüntüsünün değiştirilmesi gerektiği durumlarda kullanılabilir, ardından farklı bir uygulama türü sürümü sağlamak artık gerekli değildir veya test veya üretim senaryosuna göre farklı bağımsız değişkenlerin geçirilmesi gerekir ve giriş noktası aynı kalır.

Aşağıda, kapsayıcı giriş noktasını geçersiz kılmaya yönelik bir örnek verilmiştir:

ApplicationManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="MyFirstContainerType"
                     ApplicationTypeVersion="1.0.0"
                     xmlns="http://schemas.microsoft.com/2011/01/fabric"
                     xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                     xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <Parameters>
    <Parameter Name="ImageName" DefaultValue="myregistry.azurecr.io/samples/helloworldapp" />
    <Parameter Name="Commands" DefaultValue="commandsOverride" />
    <Parameter Name="FromSource" DefaultValue="sourceOverride" />
    <Parameter Name="EntryPoint" DefaultValue="entryPointOverride" />
  </Parameters>
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion
       should match the Name and Version attributes of the ServiceManifest element defined in the
       ServiceManifest.xml file. -->
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Guest1Pkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <CodePackagePolicy CodePackageRef="Code">
        <EntryPointOverride>
         <ContainerHostOverride>
            <ImageOverrides>
              <Image Name="[ImageName]" />
            </ImageOverrides>
            <Commands>[Commands]</Commands>
            <FromSource>[Source]</FromSource>
            <EntryPoint>[EntryPoint]</EntryPoint>
          </ContainerHostOverride>
        </EntryPointOverride>
      </CodePackagePolicy>
    </Policies>
  </ServiceManifestImport>
</ApplicationManifest>

ServiceManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="Guest1Pkg"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <!-- This is the name of your ServiceType.
         The UseImplicitHost attribute indicates this is a guest service. -->
    <StatelessServiceType ServiceTypeName="Guest1Type" UseImplicitHost="true" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <!-- Follow this link for more information about deploying Windows containers to Service Fabric: https://aka.ms/sfguestcontainers -->
      <ContainerHost>
        <ImageName>default imagename</ImageName>
        <Commands>default cmd</Commands>
        <EntryPoint>default entrypoint</EntryPoint>
        <FromSource>default source</FromSource>
      </ContainerHost>
    </EntryPoint>
  </CodePackage>

  <ConfigPackage Name="Config" Version="1.0.0" />
</ServiceManifest>

Uygulama bildirimindeki geçersiz kılmalar belirtildikten sonra, görüntü adı myregistry.azurecr.io/samples/helloworldapp, komut komutlarıOverride, sourceOverride ve entryPoint entryPointOverride olan kapsayıcı başlatılır.

Benzer şekilde, ExeHost'un nasıl geçersiz kılınacaklarına ilişkin bir örnek aşağıda verilmiştir:

<?xml version="1.0" encoding="utf-8"?>
<Policies>
  <CodePackagePolicy CodePackageRef="Code">
    <EntryPointOverride>
      <ExeHostOverride>
        <Program>[Program]</Program>
        <Arguments>[Entry]</Arguments>
      </ExeHostOverride>
    </EntryPointOverride>
  </CodePackagePolicy>
</Policies>

Dekont

SetupEntryPoint için giriş noktası geçersiz kılma desteklenmiyor.

Sonraki adımlar