Buat aplikasi kontainer Service Fabric pertama Anda di Windows

Menjalankan aplikasi yang ada di kontainer Windows pada klaster Service Fabric tidak memerlukan perubahan apa pun pada aplikasi Anda. Artikel ini memandu Anda membuat gambar Docker yang berisi aplikasi web Python Flask dan menyebarkannya ke klaster Azure Service Fabric. Anda juga akan membagikan aplikasi kontainer Anda melalui Azure Container Registry. Artikel ini mengasumsikan pemahaman dasar tentang Docker. Anda dapat mempelajari tentang Docker dengan membaca Gambaran umum Docker.

Catatan

Artikel ini berlaku untuk lingkungan pengembangan Windows. Runtime klaster Service Fabric dan runtime Docker harus berjalan pada OS yang sama. Anda tidak dapat menjalankan kontainer Windows pada klaster Linux.

Catatan

Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Prasyarat

  • Komputer pengembangan yang berjalan:

  • Klaster Windows dengan tiga atau lebih node yang berjalan di Windows Server dengan Kontainer.

    Untuk artikel ini, versi (bangun) Windows Server dengan Kontainer yang berjalan pada node klaster Anda harus cocok dengan yang ada di komputer pengembangan Anda. Ini karena Anda membangun gambar docker pada komputer pengembangan Anda dan ada batasan kompatibilitas antara versi OS kontainer dan OS host tempatnya disebarkan. Untuk informasi selengkapnya, lihat OS kontainer Windows Server dan kompatibilitas OS host.

    Untuk menentukan versi Windows Server dengan Kontainer yang Anda butuhkan untuk klaster Anda, jalankan ver perintah dari prompt perintah Windows pada komputer pengembangan Anda. Lihat OS kontainer Windows Server dan kompatibilitas OS host sebelum Anda membuat klaster.

  • Registri di Azure Container Registry - Buat registri kontainer di langganan Azure Anda.

Catatan

Menyebarkan kontainer ke klaster Service Fabric yang berjalan pada Windows 10 didukung. Lihat artikel ini untuk informasi tentang cara mengonfigurasi Windows 10 untuk menjalankan kontainer Windows.

Catatan

Service Fabric versi 6.2 dan yang lebih baru mendukung penyebaran kontainer ke klaster yang berjalan di Windows Server versi 1709.

Tentukan kontainer Docker

Bangun gambar berdasarkan gambar Python yang terletak di Docker Hub.

Tentukan kontainer Docker Anda di Dockerfile. Dockerfile terdiri dari instruksi untuk mengatur lingkungan di dalam kontainer Anda, memuat aplikasi yang ingin Anda jalankan, dan memetakan port. Dockerfile adalah input ke perintah docker build, yang membuat gambar.

Buat direktori kosong dan buat file Dockerfile (tanpa ekstensi file). Tambahkan hal berikut ini ke Dockerfile dan simpan perubahan Anda:

# 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"]

Baca referensi Dockerfile untuk informasi selengkapnya.

Membuat aplikasi web dasar

Buat aplikasi web Flask mendengarkan di port 80 yang kembali Hello World!. Dalam direktori yang sama, buat file requirements.txt. Tambahkan yang berikut ini dan simpan perubahan Anda:

Flask

Buat juga file app.py dan tambahkan cuplikan berikut:

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)

Masuk ke Docker dan membangun gambar

Selanjutnya kita akan membuat gambar yang menjalankan aplikasi web Anda. Saat menarik gambar publik dari Docker (seperti python:2.7-windowsservercore di Dockerfile kami), ini adalah praktik terbaik untuk mengautentikasi dengan akun Docker Hub Anda daripada membuat permintaan pull anonim.

Catatan

Saat sering membuat permintaan pull anonim, Anda mungkin melihat kesalahan Docker mirip dengan ERROR: toomanyrequests: Too Many Requests. atau You have reached your pull rate limit. Autentikasi ke Docker Hub untuk mencegah kesalahan ini. Lihat Mengelola konten publik dengan Azure Container Registry untuk informasi selengkapnya.

Buka jendela PowerShell dan navigasikan ke direktori yang berisi Dockerfile. Kemudian jalankan perintah berikut:

docker login
docker build -t helloworldapp .

Perintah ini membangun gambar baru menggunakan instruksi di Dockerfile Anda, penamaan (-t tagging) gambar helloworldapp. Untuk membangun gambar kontainer, gambar dasar pertama kali diunduh dari Docker Hub tempat aplikasi ditambahkan.

Setelah perintah bangun selesai, jalankan perintah docker images untuk melihat informasi pada gambar baru:

$ docker images

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

Menjalankan aplikasi secara lokal

Verifikasi gambar Anda secara lokal sebelum mendorongnya ke registri kontainer.

Jalankan aplikasi:

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

nama memberikan nama pada kontainer yang sedang berjalan (bukan ID kontainer).

Setelah kontainer dimulai, temukan alamat IP-nya sehingga Anda dapat tersambung ke kontainer yang sedang berjalan dari browser:

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

Jika perintah tersebut tidak mengembalikan apa pun, jalankan perintah berikut dan periksa elemen NetworkSettings->Networks untuk alamat IP:

docker inspect my-web-site

Sambungkan ke kontainer yang sedang berjalan. Buka browser web yang menunjuk ke alamat IP yang dikembalikan, misalnya "http://172.31.194.61". Anda akan melihat tampilan judul "Halo Dunia!" di browser.

Untuk menghentikan kontainer Anda, jalankan:

docker stop my-web-site

Hapus kontainer dari komputer pengembangan Anda:

docker rm my-web-site

Mendorong gambar ke registri kontainer

Setelah Anda memverifikasi bahwa kontainer berjalan pada komputer pengembangan Anda, dorong gambar ke registri Anda di Azure Container Registry.

Jalankan docker login untuk masuk ke registri kontainer Anda dengan kredensial registri Anda.

Contoh berikut meneruskan ID dan kata sandi perwakilan layanan Microsoft Entra. Misalnya, Anda mungkin telah menetapkan prinsipal layanan ke registri Anda untuk skenario otomatisasi. Atau, Anda dapat masuk menggunakan nama pengguna dan kata sandi registri Anda.

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

Perintah berikut membuat tag, atau alias, gambar, dengan jalur yang sepenuhnya memenuhi syarat ke registri Anda. Contoh ini menempatkan gambar di namespace samples untuk menghindari clutter di akar registri.

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

Dorong gambar ke registri kontainer Anda:

docker push myregistry.azurecr.io/samples/helloworldapp

Membuat layanan kontainer di Visual Studio

Service Fabric SDK dan alat menyediakan templat layanan untuk membantu Anda membuat aplikasi kontainer.

  1. Mulai Visual Studio. Pilih File>Baru>Proyek.
  2. Pilih aplikasi Service Fabric, beri nama "MyFirstContainer", dan klik OK.
  3. Pilih Kontainer dari daftar templat layanan.
  4. Di Nama Gambar masukkan "myregistry.azurecr.io/samples/helloworldapp", gambar yang Anda dorong ke repositori kontainer Anda.
  5. Beri nama layanan Anda, dan klik OK.

Mengonfigurasi komunikasi

Layanan kontainer membutuhkan titik akhir untuk komunikasi. Tambahkan Endpoint elemen dengan protokol, port, dan ketikkan ke ServiceManifest.xml ini. Dalam contoh ini, port tetap 8081 digunakan. Jika tidak ada port yang ditentukan, port acak dari rentang port aplikasi dipilih.

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

Catatan

Titik Akhir tambahan untuk layanan dapat ditambahkan dengan mendeklarasikan elemen Titik akhir tambahan dengan nilai properti yang berlaku. Setiap Port hanya dapat mendeklarasikan satu nilai protokol.

Dengan menentukan titik akhir, Service Fabric menerbitkan titik akhir ke layanan Penamaan. Layanan lain yang berjalan di dalam klaster dapat menyelesaikan kontainer ini. Anda juga dapat melakukan komunikasi kontainer-ke-kontainer menggunakan proksi terbalik. Komunikasi dilakukan dengan menyediakan port mendengarkan HTTP proksi terbalik dan nama layanan yang ingin Anda komunikasikan dengan variabel lingkungan.

Layanan ini mendengarkan pada port tertentu (8081 dalam contoh ini). Saat aplikasi disebarkan ke klaster di Azure, baik klaster maupun aplikasi berjalan di Azure load balancer. Port aplikasi harus terbuka di Azure load balancer sehingga lalu lintas masuk dapat masuk ke layanan. Anda dapat membuka port ini di Azure load balancer menggunakan skrip PowerShell atau di portal Azure.

Mengonfigurasi dan mengatur variabel lingkungan

Variabel lingkungan dapat ditentukan untuk setiap paket kode dalam manifes layanan. Fitur ini tersedia untuk semua layanan terlepas apakah mereka disebarkan sebagai kontainer atau proses atau tamu yang dapat dieksekusi. Anda dapat mengambil alih nilai variabel lingkungan dalam manifes aplikasi atau menentukannya selama penyebaran sebagai parameter aplikasi.

Cuplikan XML manifes layanan berikut menunjukkan contoh cara menentukan variabel lingkungan untuk paket kode:

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

Variabel lingkungan ini dapat diambil alih dalam manifes aplikasi:

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

Mengonfigurasi kontainer pemetaan port port-ke-host dan penemuan kontainer-ke-kontainer

Konfigurasi port host yang digunakan untuk berkomunikasi dengan container. Pengikatan port memetakan port di mana layanan mendengarkan di dalam kontainer ke port pada host. Tambahkan PortBinding elemen dalam ContainerHostPolicies elemen file ApplicationManifest.xml. Untuk artikel ini, ContainerPort 80 (kontainer mengekspos port 80, seperti yang ditentukan dalam Dockerfile) dan EndpointRef "Guest1TypeEndpoint" (titik akhir yang sebelumnya ditentukan dalam manifes layanan). Permintaan masuk ke layanan pada port 8081 dipetakan ke port 80 pada kontainer.

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

Catatan

PortBinding tambahan untuk layanan dapat ditambahkan dengan mendeklarasikan elemen PortBinding tambahan dengan nilai properti yang berlaku.

Mengonfigurasi autentikasi repositori kontainer

Lihat Container Repository Authenticationuntuk mempelajari cara mengonfigurasi berbagai jenis autentikasi untuk mengunduh gambar kontainer.

Mengonfigurasi mode isolasi

Windows mendukung dua mode isolasi untuk kontainer: proses dan Hyper-V. Dengan mode isolasi proses, semua kontainer yang berjalan pada mesin host yang sama berbagi kernel dengan host. Dengan mode isolasi Hyper-V, kernel diisolasi antara setiap kontainer Hyper-V dan host kontainer. Mode isolasi ditentukan diContainerHostPolicies elemen dalam file manifes aplikasi. Mode isolasi yang dapat ditentukan adalah process, hyperv, dan default. Standarnya adalah mode isolasi proses pada host Windows Server. Pada host Windows 10, hanya mode isolasi Hyper-V yang didukung, sehingga kontainer berjalan dalam mode isolasi Hyper-V terlepas dari pengaturan mode isolasinya. Cuplikan berikut menampilkan bagaimana mode isolasi ditentukan dalam file manifes aplikasi.

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

Catatan

Mode isolasi hyperv tersedia di Ev3 dan Dv3 Azure SKU yang memiliki dukungan virtualisasi bersarang.

Mengonfigurasi tata kelola sumber daya

Tata kelola sumber daya membatasi sumber daya yang dapat digunakan kontainer pada host. Elemen ResourceGovernancePolicy, yang ditentukan dalam manifes aplikasi, digunakan untuk mendeklarasikan batas sumber daya untuk paket kode layanan. Batas sumber daya dapat diatur untuk sumber daya berikut: Memori, MemorySwap, CpuShares (berat relatif CPU), MemoryReservationInMB, BlkioWeight (Berat relatif BlockIO). Dalam contoh ini, paket layanan Guest1Pkg mendapatkan satu inti pada node klaster di mana paket layanan ditempatkan. Batas memori bersifat mutlak, sehingga paket kode terbatas pada memori 1024 MB (dan reservasi jaminan sementara yang sama). Paket kode (kontainer atau proses) tidak dapat mengalokasikan lebih banyak memori daripada batas ini, dan mencoba melakukannya sehingga menghasilkan pengecualian di luar memori. Agar penegakan batas sumber daya berfungsi, semua paket kode dalam paket layanan harus memiliki batas memori yang ditentukan.

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

Mengonfigurasi docker HEALTHCHECK

Mulai v6.1, Service Fabric secara otomatis mengintegrasikan aktivitas docker HEALTHCHECK dalam laporan kesehatan sistemnya. Ini berarti bahwa jika kontainer Anda telah mengaktifkan HEALTHCHECK, Service Fabric akan melaporkan kesehatan setiap kali status kesehatan kontainer berubah seperti yang dilaporkan oleh Docker. Laporan kesehatan OK akan muncul di Service Fabric Explorer ketika health_statussehat dan PERINGATAN akan muncul ketika health_statustidak sehat.

Dimulai dengan rilis refresh terbaru v6.4, Anda memiliki opsi untuk menentukan bahwa evaluasi HEALTHCHECK docker harus dilaporkan sebagai kesalahan. Jika opsi ini diaktifkan, laporan kesehatan OK akan muncul ketika health_statussehat dan KESALAHAN akan muncul ketika health_statustidak sehat.

Instruksi HEALTHCHECK yang menunjuk ke pemeriksaan aktual yang dilakukan untuk memantau kesehatan kontainer harus ada di Dockerfile yang digunakan ketika menghasilkan gambar kontainer.

Screenshot shows details of the Deployed Service Package NodeServicePackage.

HealthCheckUnhealthyApp

HealthCheckUnhealthyDsp

Anda dapat mengonfigurasi perilaku HEALTHCHECK untuk setiap kontainer dengan menetapkan opsi HealthConfig sebagai bagian dari ContainerHostPolicies di ApplicationManifest.

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

Secara default IncludeDockerHealthStatusInSystemHealthReport diatur ke true, RestartContainerOnUnhealthyDockerHealthStatus diatur ke false, dan TreatContainerUnhealthyStatusAsError diatur ke false.

Jika RestartContainerOnUnhealthyDockerHealthStatus diatur ke true, kontainer yang berulang kali melaporkan tidak sehat direstart (mungkin pada node lainnya).

Jika TreatContainerUnhealthyStatusAsError diatur ke true, laporan kesehatan KESALAHAN akan muncul ketika health_status kontainer tidak sehat.

Jika Anda ingin menonaktifkan integrasi HEALTHCHECK untuk seluruh klaster Service Fabric, Anda perlu mengatur EnableDockerHealthCheckIntegration ke false.

Menerapkan aplikasi kontainer

Simpan semua perubahan Anda dan buat aplikasi. Untuk menerbitkan aplikasi Anda, klik kanan pada MyFirstContainer di Penjelajah Solusi dan pilih Terbitkan.

Di Titik Akhir Koneksi, masukkan titik akhir manajemen untuk klaster. Contohnya, containercluster.westus2.cloudapp.azure.com:19000. Anda dapat menemukan titik akhir koneksi klien di tab Gambaran Umum untuk klaster Anda di portal Azure.

Klik Terbitkan.

Service Fabric Explorer adalah alat berbasis web untuk memeriksa dan mengelola aplikasi serta node dalam klaster Service Fabric. Buka browser dan navigasikan ke http://containercluster.westus2.cloudapp.azure.com:19080/Explorer/ serta ikuti penerapan aplikasi. Aplikasi menyebarkan tetapi berada dalam status kesalahan sampai gambar diunduh pada node kluster (yang dapat memakan waktu, tergantung pada ukuran gambar): Error

Aplikasi siap ketika dalam Ready status: Ready

Buka browser dan navigasikan ke http://containercluster.westus2.cloudapp.azure.com:8081. Anda akan melihat tampilan judul "Halo Dunia!" di browser.

Penghapusan

Anda terus dikenakan biaya ketika klaster berjalan, pertimbangkan untuk menghapus klaster Anda.

Setelah Anda memasukkan citra ke registri kontainer, Anda dapat menghapus citra lokal dari komputer pengembangan Anda:

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

Kompatibilitas OS kontainer dan OS host Windows Server

Kontainer Windows Server tidak kompatibel di semua versi OS host. Contohnya:

  • Kontainer Windows Server yang dibuat menggunakan Windows Server versi 1709 tidak berfungsi pada host yang menjalankan Windows Server versi 2016.
  • Kontainer Windows Server yang dibuat menggunakan Windows Server 2016 hanya berfungsi dalam mode isolasi Hyper-V pada host yang menjalankan Windows Server versi 1709.
  • Dengan kontainer Windows Server yang dibuat menggunakan Windows Server 2016, mungkin perlu untuk memastikan bahwa revisi OS kontainer dan OS host sama ketika berjalan di mode isolasi proses pada host yang menjalankan Windows Server 2016.

Untuk mempelajari selengkapnya, lihat Kompatibilitas Versi Kontainer Windows.

Pertimbangkan kompatibilitas OS host dan OS kontainer Anda ketika membuat dan menerapkan kontainer ke klaster Service Fabric Anda. Contohnya:

  • Pastikan Anda menerapkan kontainer dengan OS yang kompatibel dengan OS pada node klaster Anda.
  • Pastikan mode isolasi yang ditentukan untuk aplikasi container Anda konsisten dengan dukungan untuk OS container pada node tempat aplikasi tersebut di-deploy.
  • Pertimbangkan bagaimana peningkatan OS ke node atau kontainer klaster Anda dapat memengaruhi kompatibilitasnya.

Kami menyarankan praktik berikut untuk memastikan bahwa kontainer diterapkan dengan benar pada klaster Service Fabric Anda:

  • Gunakan penandaan citra eksplisit dengan citra Docker Anda untuk menentukan versi OS Windows Server tempat kontainer dibuat.
  • Gunakan penandaan OS dalam file manifes aplikasi Anda untuk memastikan bahwa aplikasi Anda kompatibel di berbagai versi dan peningkatan Windows Server.

Catatan

Dengan Service Fabric versi 6.2 dan yang lebih baru, Anda dapat menerapkan kontainer berdasarkan Windows Server 2016 secara lokal pada host Windows 10. Pada Windows 10, kontainer berjalan dalam mode isolasi Hyper-V, terlepas dari mode isolasi yang diatur dalam manifes aplikasi. Untuk mempelajari selengkapnya, lihat Mengonfigurasi mode isolasi.

Menentukan citra kontainer khusus build OS

Kontainer Windows Server mungkin tidak kompatibel di berbagai versi OS. Contohnya, kontainer Windows Server yang dibuat menggunakan Windows Server 2016 tidak berfungsi pada Windows Server versi 1709 dalam mode isolasi proses. Oleh karena itu, jika node klaster diperbarui ke versi terbaru, layanan kontainer yang dibuat menggunakan versi OS yang lebih lama mungkin gagal. Untuk menghindari hal ini dengan runtime versi 6.1 dan yang lebih baru, Service Fabric mendukung penentuan beberapa citra OS per kontainer dan penandaannya dengan versi build OS dalam manifes aplikasi. Anda dapat memperoleh versi build OS dengan menjalankan winver pada perintah Windows. Perbarui manifes aplikasi dan tentukan penggantian citra per versi OS sebelum memperbarui OS pada node. Cuplikan berikut menampilkan cara menentukan beberapa citra kontainer dalam manifes aplikasi, ApplicationManifest.xml:

      <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> 

Versi build Windows Server 2016 adalah 14393, dan versi build Windows Server versi 1709 adalah 16299. Manifes layanan terus menentukan hanya satu citra per layanan kontainer seperti yang ditunjukkan berikut ini:

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

Catatan

Fitur penandaan versi build OS hanya tersedia untuk Service Fabric di Windows

Jika OS yang mendasari pada VM adalah build 16299 (versi 1709), Service Fabric memilih citra kontainer yang sesuai dengan versi Windows Server tersebut. Jika citra kontainer yang tidak diberi tag juga disediakan bersama dengan citra kontainer yang diberi tag dalam manifes aplikasi, maka Service Fabric memperlakukan citra yang tidak diberi tag sebagai citra yang berfungsi di berbagai versi. Tandai citra kontainer secara eksplisit untuk menghindari masalah selama peningkatan.

Citra kontainer yang tidak diberi tag akan berfungsi sebagai pengganti untuk citra yang disediakan di ServiceManifest. Jadi citra "myregistry.azurecr.io/samples/helloworldappDefault" akan mengganti ImageName "myregistry.azurecr.io/samples/helloworldapp" di ServiceManifest.

Contoh lengkap manifes aplikasi dan layanan Service Fabric

Berikut adalah manifes layanan dan aplikasi yang lengkap yang digunakan dalam artikel ini.

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>

Mengonfigurasi interval waktu sebelum kontainer dihentikan paksa

Anda dapat mengonfigurasi interval waktu untuk runtime agar menunggu sebelum kontainer dihapus setelah penghapusan layanan (atau pindah ke node lainnya) telah dimulai. Mengonfigurasi interval waktu mengirimkan perintah docker stop <time in seconds> ke kontainer. Untuk lebih jelasnya, lihat pemberhentian docker. Interval waktu untuk menunggu ditentukan di bawah bagian Hosting. Bagian Hosting dapat ditambahkan pada pembuatan klaster atau nanti dalam peningkatan konfigurasi. Cuplikan manifes klaster berikut menampilkan cara mengatur interval tunggu:

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

Interval waktu default diatur ke 10 detik. Karena konfigurasi ini dinamis, konfigurasi hanya meningkatkan klaster yang memperbarui waktu habis.

Mengonfigurasi runtime untuk menghapus gambar kontainer yang tidak digunakan

Anda dapat mengonfigurasi klaster Service Fabric untuk menghapus gambar kontainer yang tidak digunakan dari node. Konfigurasi ini memungkinkan ruang disk diambil kembali jika terlalu banyak citra kontainer ada pada node. Untuk mengaktifkan fitur ini, perbarui bagian Hosting di manifes klaster seperti yang ditunjukkan dalam cuplikan berikut:

"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|..."
          }
          ...
          }
        ]
	} 
]

Untuk citra yang tidak boleh dihapus, Anda dapat menentukannya di bawah parameter ContainerImagesToSkip.

Mengonfigurasi waktu pengunduhan gambar kontainer

Runtime Service Fabric mengalokasikan 20 menit untuk mengunduh dan mengekstrak citra kontainer, yang berfungsi untuk sebagian besar citra kontainer. Untuk citra yang besar atau ketika koneksi jaringan lambat, mungkin perlu untuk menambah waktu untuk menunggu sebelum membatalkan pengunduhan dan ekstraksi citra. Batas waktu ini diatur menggunakan atribut ContainerImageDownloadTimeout di bagian Hosting dari manifes klaster seperti yang ditunjukkan dalam cuplikan berikut:

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

Mengatur kebijakan penyimpanan kontainer

Untuk membantu mendiagnosis kegagalan pengaktifan kontainer, Service Fabric (versi 6.1 atau lebih tinggi) mendukung penahanan kontainer yang dihentikan atau gagal dimulai. Kebijakan ini dapat diatur dalam file ApplicationManifest.xml seperti yang ditunjukkan dalam cuplikan berikut:

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

Pengaturan ContainersRetentionCount menentukan jumlah kontainer yang akan dipertahankan ketika gagal. Jika nilai negatif ditentukan, semua kontainer yang gagal akan dipertahankan. Jika atribut ContainersRetentionCount tidak ditentukan, tidak ada kontainer yang akan dipertahankan. Atribut ContainersRetentionCount juga mendukung Parameter Aplikasi sehingga pengguna dapat menentukan nilai yang berbeda untuk kluster pengujian dan produksi. Gunakan batasan penempatan untuk menargetkan layanan kontainer ke node tertentu saat menggunakan fitur ini untuk mencegah layanan kontainer berpindah ke node lain. Setiap kontainer yang dipertahankan menggunakan fitur ini harus dihapus secara manual.

Mulai daemon Docker dengan argumen khusus

Dengan versi 6.2 dari runtime Service Fabric dan yang lebih besar, Anda dapat memulai daemon Docker dengan argumen khusus. Ketika argumen khusus ditentukan, Service Fabric tidak meneruskan argumen lain apa pun ke mesin docker kecuali argumen --pidfile. Oleh karena itu, --pidfile tidak boleh diteruskan sebagai argumen. Selain itu, argumen harus terus membuat daemon docker mendengarkan pipa nama default di Windows (atau soket domain unix di Linux) agar Service Fabric berkomunikasi dengan Daemon. Argumen khusus diteruskan dalam manifes klaster di bawah bagian Hosting di bawah ContainerServiceArguments seperti yang ditunjukkan dalam cuplikan berikut:

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

Pengambilalihan EntryPoint

Dengan versi 8.2 dari ServiceFabric Runtime, entrypoint untuk paket kode host kontainer dan exe dapat diganti. Ini dapat digunakan dalam kasus di mana semua elemen manifes tetap sama tetapi gambar kontainer perlu diubah, kemudian penyediaan versi jenis aplikasi yang berbeda tidak diperlukan lagi, atau argumen yang berbeda perlu diteruskan berdasarkan skenario uji atau dorongan dan titik masuk tetap sama.

Berikut ini adalah contoh tentang cara mengambil alih titik masuk kontainer:

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>

Setelah pengambilalihan dalam manifes aplikasi ditentukan, kontainer dengan nama gambar myregistry.azurecr.io/samples/helloworldapp, perintah commandsOverride, source sourceOverride, dan entryPoint entryPointOverride akan dimulai.

Demikian pula, di bawah ini adalah contoh tentang cara mengambil alih ExeHost:

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

Catatan

Pengambilalihan titik masuk tidak didukung untuk SetupEntryPoint.

Langkah berikutnya