Menyiapkan cluster Windows untuk deployment

Halaman ini membahas beberapa skenario yang mungkin mengharuskan Anda menyesuaikan artefak migrasi.

Sebelum memulai

Dokumen ini mengasumsikan bahwa Anda telah menyelesaikan migrasi.

Pastikan cluster target memiliki akses baca ke registry Docker

Sebagai bagian dari menjalankan migrasi, Migrate to Containers mengupload image Docker yang mewakili VM yang dimigrasikan ke registry Docker. Image Docker ini mewakili file dan direktori VM yang bermigrasi.

Untuk registry Docker, Anda dapat memilih untuk menggunakan:

Container Registry
Semua registry Docker yang mendukung autentikasi dasar

Untuk informasi selengkapnya, lihat Menentukan repositori data.

Men-deploy beban kerja ke project Google Cloud selain beban kerja yang digunakan untuk migrasi

Sering kali Anda memiliki beberapa project Google Cloud di lingkungan Anda. Jika Anda melakukan migrasi dalam satu project Google Cloud, tetapi ingin men-deploy beban kerja yang dimigrasikan ke cluster di project berbeda, Anda harus memastikan bahwa izin telah dikonfigurasi dengan benar.

Misalnya, Anda melakukan migrasi di project A. Dalam hal ini, beban kerja yang dimigrasikan akan disalin ke bucket Container Registry di project A. Contoh:

gcr.io/project-a/image_name:image_tag

Anda kemudian ingin men-deploy beban kerja ke cluster di project B. Jika Anda tidak mengonfigurasi izin dengan benar, pod workload akan gagal dijalankan karena cluster di project B tidak memiliki akses pull image ke project A. Anda kemudian akan melihat peristiwa di pod yang berisi pesan dalam formulir:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Semua project yang telah mengaktifkan Compute Engine API memiliki akun layanan default Compute Engine, yang memiliki alamat email berikut:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dengan PROJECT_NUMBER adalah nomor project untuk project B.

Untuk mengatasi masalah ini, pastikan akun layanan default Compute Engine untuk project B memiliki izin yang diperlukan untuk mengakses bucket Container Registry. Misalnya, Anda dapat menggunakan perintah gsutil berikut untuk mengaktifkan akses:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Men-deploy beban kerja pada cluster pemrosesan

Anda dapat men-deploy beban kerja yang dimigrasikan di cluster yang sama seperti yang Anda gunakan untuk melakukan migrasi, yang disebut sebagai cluster pemrosesan Migrate to Containers. Dalam kebanyakan situasi, Anda tidak perlu melakukan konfigurasi tambahan pada cluster pemrosesan karena cluster sudah memerlukan akses baca atau tulis ke registry Docker untuk melakukan migrasi.

Men-deploy pada cluster target menggunakan Container Registry sebagai registry Docker

Untuk memastikan bahwa cluster target memiliki akses ke Container Registry, buat rahasia Kubernetes yang berisi kredensial yang diperlukan untuk mengakses Container Registry:

Buat akun layanan untuk men-deploy migrasi seperti yang dijelaskan dalam artikel Membuat akun layanan untuk mengakses Container Registry dan Cloud Storage.

Proses ini mengharuskan Anda mendownload file kunci JSON bernama m4a-install.json.
Buat rahasia Kubernetes yang berisi kredensial yang diperlukan untuk mengakses Container Registry:
```
kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com
```
dengan:
- docker-registry menentukan nama rahasia Kubernetes, gcr-json-key dalam contoh ini.
- docker-server=gcr.io menentukan Container Registry sebagai server.
- docker-username=_json_key menentukan bahwa nama pengguna ada dalam file kunci JSON.
- docker-password menentukan untuk menggunakan sandi dari file kunci JSON.
- docker-email menentukan alamat email akun layanan.
Tetapkan rahasia Kubernetes dengan:
- Mengubah nilai imagePullSecrets default:
```
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'
```
- Mengedit file deployment_spec.yaml untuk menambahkan nilai imagePullSecrets ke definisi spec.template.spec. Jika menggunakan WebSphere tradisional, file YAML deployment akan diberi nama twas_deployment_spec.yaml, liberty_deployment_spec.yaml, atau openliberty_deployment_spec.yaml, bergantung pada target Anda.
```
spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key
```
  Ganti PROJECT_ID dengan project ID Anda.
Deploy rahasia beban kerja, jika secrets.yaml ada. File secret akan ada untuk workload berbasis Tomcat dan workload berbasis tradisional WebSphere dengan Liberty. File Liberty diberi nama liberty-secrets.yaml.
```
kubectl apply -f secrets.yaml
```

Men-deploy pada cluster target menggunakan registry Docker dengan autentikasi dasar

Jika Anda menggunakan registry Docker untuk menyimpan image migrasi, registry tersebut harus mendukung autentikasi dasar menggunakan nama pengguna dan sandi. Karena ada banyak cara untuk mengonfigurasi koneksi hanya baca ke registry Docker, Anda harus menggunakan metode yang sesuai dengan platform cluster dan registry Docker Anda.

Mengonfigurasi workload yang dimigrasikan untuk menggunakan gMSA

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

Saat men-deploy penampung yang dimigrasikan ke cluster, Anda dapat menggunakan Akun Layanan Terkelola Grup (gMSA). Gunakan gMSA untuk menjalankan penampung dalam identitas akun layanan tertentu. Anda dapat 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 beban kerja. Migrate to Containers secara 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 spesifik Anda.

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

Untuk mendukung gMSA dalam container Windows yang dimigrasikan, Anda harus:

Edit paket migrasi untuk menetapkan properti yang diperlukan guna mengonfigurasi penampung yang dimigrasikan agar dapat menggunakan gMSA.
Konfigurasi cluster target yang menghosting container yang di-deploy.

Mengonfigurasi cluster target untuk mendukung gMSA

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

Untuk mengonfigurasi cluster yang menghosting container Windows yang dimigrasikan agar mendukung gMSA, Anda harus memiliki:

Untuk informasi selengkapnya, lihat referensi berikut:

Membuat gMSA untuk penampung Windows.
Buat Akun Layanan Terkelola grup.
Menggunakan gMSA dalam dokumentasi Google Cloud.
Konfigurasikan aplikasi Anda untuk menggunakan gMSA dalam dokumentasi Microsoft.

Men-deploy container saat menyimpan sertifikat SSL sebagai secret Kubernetes

Sebaiknya gunakan Cloud Load Balancing, Ingress, atau Anthos Service Mesh sebagai frontend HTTPS untuk mengamankan akses eksternal ke container yang Anda deploy. Opsi ini dapat Anda gunakan untuk 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 dalam container.

Untuk menggunakan secret Kubernetes:

Buat filePFX dengan sertifikat dan sandi.
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 diproses 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 thumbprint SHA-1 file PFX yang dapat diambil menggunakan perintah PowerShell:
```
Get-PfxCertificate -FilePath "path to pfx"
```
  Atau lihat di Windows {i>Certificate Manager<i}.

Buat secret Kubernetes:

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

Membuat pemasangan volume dan 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 seperti 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 rahasia yang Anda buat di langkah 3.

Mengonfigurasi SSL

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

Gunakan sertifikat yang dibuat secara otomatis dan ditandatangani sendiri

Secara default, penampung Windows dengan binding HTTPS diberi sertifikat yang dibuat otomatis dan ditandatangani sendiri, yang dihasilkan saat inisialisasi container 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 container dijalankan.

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

Anda dapat menyesuaikan binding dalam rencana migrasi untuk menggunakan HTTP. Selanjutnya, gunakan Cloud Load Balancing, Ingress, atau Anthos 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 HTTP dan port beban kerja Windows.

Menyimpan sertifikat SSL sebagai rahasia Kubernetes

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

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

Mengonfigurasi logging ke Cloud Logging

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

Secara default, Migrate to Containers memungkinkan logging IIS untuk memantau log IIS, dan juga meneruskan log peristiwa Aplikasi atau Sistem ke Cloud Logging.

Konfigurasikan 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 cara 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 berjalan dengan benar. Migrate to Containers secara otomatis memindai semua aplikasi IIS yang dimigrasikan dan menambahkan izin khusus yang ditentukan di VM sumber yang berlaku untuk akun IIS (akun IUSR dan grup IIS_IUSRS), serta menerapkannya ke file dan direktori yang disalin di image penampung yang dihasilkan.

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

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

Skrip ini menggunakan alat icacls bawaan Windows untuk menetapkan izin.

Tentang .NET Global Assembly Cache

Migrate to Containers memindai gambar sumber .NET Global Assembly Cache (GAC) untuk menemukan 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 utilitas install_gac.ps1.

Semua assembly .NET disalin ke dalam konteks Docker di bagian direktori m4a\gac. Untuk menghapus assembly dari image, hapus assembly 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 mendeteksi DLL yang terdaftar sebagai objek COM, yang kemudian didaftarkan dalam container.

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 kembali, dan didaftarkan.

Langkah selanjutnya

Pelajari cara mem-build dan men-deploy workload Windows IIS.