Menyiapkan cluster Windows untuk deployment

Halaman ini menjelaskan cara menyiapkan cluster Windows untuk deployment.

Sebelum memulai

Memilih dan menyiapkan registry Docker

Sebagai bagian dari deployment, Anda mem-build dan mengupload image Docker container ke registry Docker.

Untuk registry Docker, Anda dapat memilih untuk menggunakan:

  • Artifact Registry

  • Semua registry Docker yang mendukung autentikasi dasar

Solusi yang direkomendasikan adalah menggunakan Artifact Registry dalam project cluster deployment yang sama. GKE dapat mengakses registry secara default. Untuk informasi selengkapnya, lihat persyaratan untuk berintegrasi dengan GKE.

Jika Anda ingin menggunakan registry Docker pribadi, pelajari cara mengonfigurasi registry.

Mengonfigurasi workload yang dimigrasikan untuk menggunakan gMSA

Workload Aplikasi IIS Windows sering kali bergabung dengan Active Directory (AD) dan beroperasi menggunakan identitas domain. Saat memigrasikan VM ini ke penampung, penampung itu sendiri tidak bergabung dengan domain, tetapi node cluster Kubernetes host-nya dapat bergabung dengan domain.

Saat men-deploy penampung yang dimigrasikan ke cluster, Anda dapat menggunakan Akun Layanan Terkelola Grup (gMSA). Gunakan gMSA untuk mengeksekusi penampung dalam identitas akun layanan tertentu. Anda melampirkan gMSA di cluster Kubernetes sebagai bagian dari konfigurasi pod, bukan sebagai konfigurasi identitas statis di dalam image container.

Migrate to Containers membantu Anda dalam proses transformasi workload. Migrate to Containers akan otomatis menemukan konfigurasi kumpulan aplikasi IIS dan menambahkan rekomendasi ke rencana migrasi yang dihasilkan. Kemudian, Anda dapat mengevaluasi rekomendasi ini dan mengubahnya untuk lingkungan dan persyaratan tertentu.

Jika Migrate to Containers menentukan bahwa konfigurasi kumpulan aplikasi tidak memerlukan gMSA, Migrate to Containers akan mempertahankan konfigurasi kumpulan aplikasi asli. Misalnya, saat menggunakan jenis akun bawaan seperti ApplicationPoolIdentity, NetworkService, LocalSystem, atau LocalService.

Untuk mendukung gMSA di penampung Windows yang dimigrasikan, Anda harus:

  1. Edit rencana migrasi untuk menetapkan properti yang diperlukan guna mengonfigurasi penampung yang dimigrasikan untuk menggunakan gMSA.

  2. Konfigurasikan cluster target yang menghosting penampung yang di-deploy.

Mengonfigurasi cluster target untuk mendukung gMSA

Anda melampirkan gMSA di cluster Kubernetes sebagai bagian dari konfigurasi pod, bukan sebagai konfigurasi identitas statis di dalam image container.

Untuk mengonfigurasi cluster yang menghosting penampung Windows yang dimigrasikan untuk mendukung gMSA, Anda harus memiliki:

  1. Mengonfigurasi Active Directory agar VM bergabung dengan domain secara otomatis.

  2. Mengonfigurasi gMSA untuk Pod dan container Windows.

Untuk informasi selengkapnya, lihat referensi berikut:

Men-deploy penampung saat menyimpan sertifikat SSL sebagai secret Kubernetes

Sebaiknya gunakan Cloud Load Balancing, Ingress, atau Cloud Service Mesh sebagai frontend HTTPS untuk mengamankan akses eksternal ke penampung yang di-deploy. Opsi ini memungkinkan Anda mengamankan komunikasi eksternal tanpa menyertakan sertifikat apa pun di dalam cluster. Untuk informasi selengkapnya, lihat Menyesuaikan rencana migrasi.

Anda juga dapat menyimpan sertifikat Secure Sockets Layer (SSL) sebagai secret Kubernetes dan memasangnya saat runtime ke penampung.

Untuk menggunakan secret Kubernetes:

  1. Buat file PFX dengan sertifikat dan sandi.

  2. Buat file YAML konfigurasi yang menentukan akses situs:

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    Dengan keterangan:

    • sitename menentukan nama situs yang dikonfigurasi untuk menggunakan SSL. Properti sites dapat berisi beberapa entri sitename.

    • sslport menentukan port yang akan di-listen untuk koneksi SSL (biasanya 443).

    • pfxpath menentukan jalur ke file PFX. Konfigurasikan sebagai bagian dari volumeMounts deployment pod.

    • password menentukan sandi untuk file PFX.

    • thumbprint menentukan sidik jari SHA-1 file PFX yang dapat diambil menggunakan perintah PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      Atau lihat di Pengelola Sertifikat Windows.

  3. Buat secret Kubernetes:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. Buat volume dan pemasangan volume dalam deployment image:

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    Dengan keterangan:

    • mountPath adalah jalur yang sama dengan yang ditentukan oleh pfxpath dalam file konfigurasi yang Anda buat di Langkah 2.
    • M4A_CERT_YAML adalah variabel lingkungan yang ditetapkan ke jalur lengkap ke file YAML konfigurasi yang Anda buat di Langkah 2.
    • secret-name adalah nama secret yang Anda buat di langkah 3.

Mengonfigurasi SSL

Sebaiknya jangan menyimpan kunci pribadi sertifikat SSL di dalam image penampung karena dapat diakses oleh siapa saja yang membaca image. Migrate to Containers menyediakan beberapa cara untuk menangani SSL untuk Windows.

Menggunakan sertifikat yang ditandatangani sendiri dan dibuat secara otomatis

Secara default, penampung Windows dengan binding HTTPS diberi sertifikat yang ditandatangani sendiri dan dibuat secara otomatis yang dibuat saat inisialisasi penampung Docker. Konfigurasi ini memungkinkan Anda menguji beban kerja yang dimigrasikan, tetapi tidak dapat digunakan di lingkungan produksi. Sertifikat ditandatangani sendiri dan dibuat ulang setiap kali penampung dijalankan.

Direkomendasikan - Gunakan Cloud Load Balancing, Ingress, atau Cloud Service Mesh

Anda dapat menyesuaikan binding dalam rencana migrasi untuk menggunakan HTTP. Kemudian, gunakan Cloud Load Balancing, Ingress, atau Cloud Service Mesh sebagai frontend HTTPS untuk mengamankan akses eksternal. Opsi ini memungkinkan Anda mengamankan komunikasi eksternal tanpa menyertakan sertifikat apa pun di dalam cluster.

  • Untuk menyesuaikan binding, edit definisi site dalam rencana migrasi yang mewakili migrasi untuk menetapkan protocol ke http:

    sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

Kemudian, Anda dapat meneruskan permintaan dari frontend HTTPS ke jalur dan port HTTP beban kerja Windows.

Menyimpan sertifikat SSL sebagai secret Kubernetes

Sebaiknya gunakan Cloud Load Balancing, Ingress, atau Cloud Service Mesh sebagai frontend HTTPS untuk mengamankan akses eksternal. Namun, Anda juga dapat menyimpan sertifikat SSL sebagai secret Kubernetes dan memasangnya saat runtime ke dalam penampung.

Untuk menggunakan sertifikat SSL yang disimpan sebagai secret Kubernetes, Anda harus mengedit image deployment container. Untuk informasi selengkapnya, lihat Men-deploy penampung saat menyimpan sertifikat SSL sebagai secret Kubernetes.

Mengonfigurasi logging ke Cloud Logging

Migrate to Containers menggunakan alat LogMonitor untuk mengekstrak log dari penampung Windows dan meneruskannya ke cluster GKE Anda. Log ini kemudian diteruskan secara otomatis ke Cloud Logging, yang menyediakan serangkaian alat untuk memantau penampung Anda.

Secara default, Migrasi ke Penampung mengaktifkan logging IIS untuk memantau log IIS, dan juga meneruskan log peristiwa Aplikasi atau Sistem ke Cloud Logging.

Mengonfigurasi logging

Memperluas file artifacts.zip yang dihasilkan akan membuat beberapa direktori, termasuk direktori m4a. Direktori berisi folder untuk setiap gambar. Termasuk dalam direktori m4a adalah file LogMonitorConfig.json yang dapat Anda edit untuk mengontrol logging.

Untuk mengetahui informasi selengkapnya tentang mengedit LogMonitorConfig.json, lihat Menulis File Konfigurasi.

Tetapkan ACL

Beberapa aplikasi IIS mengharuskan Anda menetapkan izin daftar kontrol akses (ACL) tertentu pada file dan folder agar aplikasi dapat berperforma dengan benar. Migrate to Containers secara otomatis memindai semua aplikasi IIS yang dimigrasikan dan menambahkan izin tertentu yang ditentukan di VM sumber yang berlaku untuk akun IIS (akun IUSR dan grup IIS_IUSRS) dan menerapkan izin tersebut ke file dan direktori yang disalin dalam image penampung yang dihasilkan.

Karena image container Windows tidak mendukung setelan ACL sebagai bagian dari perintah COPY Docker, ACL ditetapkan dalam skrip yang disebut set_acls.bat. Migrate to Containers akan otomatis membuat set_acls.bat di direktori image yang dihasilkan untuk aplikasi Windows tertentu. Migrate to Containers kemudian memanggil set_acls.bat saat Anda menjalankan perintah docker build.

Edit set_acls.bat untuk menambahkan atau menghapus izin kustom, atau edit izin yang tidak terkait dengan pengguna IIS tertentu sehingga tidak terdeteksi oleh Migrate to Containers.

Skrip menggunakan alat icacls bawaan Windows untuk menetapkan izin.

Tentang Global Assembly Cache .NET

Migrate to Containers memindai .NET Global Assembly Cache (GAC) image sumber untuk resource .NET yang diinstal di mesin sumber dan tidak tersedia sebagai bagian dari image resmi. Setiap DLL yang ditemukan akan disalin ke dalam konteks Docker dan diinstal sebagai bagian dari pembuatan image target oleh skrip utility install_gac.ps1.

Semua assembly .NET disalin ke dalam konteks Docker di direktori m4a\gac. Untuk menghapus assembly dari image, hapus dari direktori m4a\gac.

Pendaftaran DLL objek COM

DLL yang mengekspos objek COM akan otomatis dipindai dan didaftarkan. Selama fase ekstraksi, file yang disalin akan dipindai untuk menemukan DLL yang terdaftar sebagai objek COM, yang kemudian didaftarkan dalam penampung.

Proses ini terjadi tanpa input pengguna. Namun, Anda dapat memengaruhi proses ini dengan menambahkan lebih banyak DLL untuk disalin. Jika diperlukan, DLL ini akan diperiksa secara bergantian, dan didaftarkan.

Langkah selanjutnya