View a markdown version of this page

Dokumen Perintah SSM untuk menambal: AWS-RunPatchBaselineWithHooks - AWS Systems Manager
Langkah-langkah operasional AWS-RunPatchBaselineWithHooksParameter AWS-RunPatchBaselineWithHooks

• AWS Systems Manager CloudWatch Dasbor tidak akan lagi tersedia setelah 30 April 2026. Pelanggan dapat terus menggunakan CloudWatch konsol Amazon untuk melihat, membuat, dan mengelola dasbor Amazon CloudWatch mereka, seperti yang mereka lakukan hari ini. Untuk informasi selengkapnya, lihat dokumentasi CloudWatch Dasbor Amazon.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Dokumen Perintah SSM untuk menambal: AWS-RunPatchBaselineWithHooks

AWS Systems Manager mendukungAWS-RunPatchBaselineWithHooks, dokumen Manajer Sistem (dokumen SSM) untukPatch Manager. Dokumen SSM ini melakukan operasi tambalan pada node terkelola untuk pembaruan terkait keamanan dan jenis lainnya.

AWS-RunPatchBaselineWithHooks berbeda dari AWS-RunPatchBaseline dengan cara berikut:

  • Dokumen pembungkus – AWS-RunPatchBaselineWithHooks adalah pembungkus untuk AWS-RunPatchBaseline dan bergantung pada AWS-RunPatchBaseline untuk beberapa operasinya.

  • InstallOperasi — AWS-RunPatchBaselineWithHooks mendukung kait siklus hidup yang berjalan pada titik yang ditentukan selama tambalan node terkelola. Karena instalasi patch terkadang memerlukan node terkelola untuk reboot, operasi tambalan dibagi menjadi dua peristiwa, dengan total tiga kait yang mendukung fungsionalitas khusus. Kait pertama adalah sebelum operasi Install with NoReboot. Kait kedua adalah setelah operasi Install with NoReboot. Kait ketiga tersedia setelah reboot dari node yang dikelola.

  • Tidak ada support daftar patch kustom – AWS-RunPatchBaselineWithHooks tidak support parameter InstallOverrideList.

  • SSM Agentdukungan - AWS-RunPatchBaselineWithHooks mengharuskan SSM Agent 3.0.502 atau yang lebih baru diinstal pada node terkelola untuk ditambal.

Saat dokumen dijalankan, ia menggunakan dasar patch yang ditentukan saat ini sebagai "default" untuk suatu jenis sistem operasi jika tidak ada grup patch yang ditentukan. Jika tidak, ia menggunakan dasar patch yang terkait dengan grup patch. Untuk informasi tentang grup patch, lihat Grup patch.

Anda dapat menggunakan AWS-RunPatchBaselineWithHooks untuk menerapkan patch untuk sistem operasi dan aplikasi. (Pada Windows Server, support aplikasi dibatasi pada pembaruan untuk aplikasi yang dirilis oleh Microsoft.)

Dokumen ini mendukung Linux dan node Windows Server terkelola. Dokumen ini akan melakukan tindakan yang sesuai untuk setiap platform.

catatan

AWS-RunPatchBaselineWithHookstidak didukung dimacOS.

Linux

Pada node yang dikelola Linux, AWS-RunPatchBaselineWithHooks dokumen memanggil modul Python, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node yang dikelola. Snapshot baseline patch ini menggunakan aturan yang ditentukan dan daftar patch yang disetujui dan diblokir untuk mendorong manajer paket yang sesuai untuk setiap jenis node:

  • Amazon Linux 2,Oracle Linux, dan RHEL 7 node terkelola menggunakan YUM. Untuk operasi YUM, Patch Manager memerlukan Python 2.6 atau versi yang didukung yang lebih baru (2.6 - 3.12). Amazon Linux 2023 menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi Python 2 atau yang didukung Python 3 (2.6 - 3.12).

  • RHEL8 node terkelola menggunakan DNF. Untuk operasi DNF, Patch Manager memerlukan versi Python 2 atau yang didukung Python 3 (2.6 - 3.12). (Tidak ada versi yang diinstal secara default pada RHEL 8. Anda harus menginstal satu atau yang lain secara manual.)

  • Debian Serverdan Ubuntu Server instance menggunakan APT. Untuk operasi APT, Patch Manager memerlukan versi yang didukung Python 3 (3.0 - 3.12).

Windows Server

Pada Windows Server node terkelola, AWS-RunPatchBaselineWithHooks dokumen mengunduh dan memanggil PowerShell modul, yang pada gilirannya mengunduh snapshot dari baseline patch yang berlaku untuk node terkelola. snapshot dasar patch ini berisi daftar patch yang disetujui yang dikumpulkan dengan melakukan kueri dasar patch pada server Windows Server Update Services (WSUS). Daftar ini diteruskan ke API Windows Update, yang mengendalikan pengunduhan dan instalasi patch yang disetujui sesuai kebutuhan.

Setiap snapshot khusus untuk grup patch Akun AWS, sistem operasi, dan ID snapshot. Snapshot dikirimkan melalui URL Amazon Simple Storage Service (Amazon S3) yang telah ditandatangani sebelumnya, yang kedaluwarsa 24 jam setelah snapshot dibuat. Namun, setelah URL kedaluwarsa, jika Anda ingin menerapkan konten snapshot yang sama ke node terkelola lainnya, Anda dapat membuat URL Amazon S3 baru yang telah ditandatangani sebelumnya hingga tiga hari setelah snapshot dibuat. Untuk melakukannya, gunakan perintah get-deployable-patch-snapshot-for-instance.

Setelah semua pembaruan yang disetujui dan berlaku telah diinstal, dengan reboot dilakukan seperlunya, informasi kepatuhan patch dihasilkan pada node yang dikelola dan dilaporkan kembali kePatch Manager.

Jika RebootOption parameter disetel ke NoReboot dalam AWS-RunPatchBaselineWithHooks dokumen, node yang dikelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi selengkapnya, lihat Nama parameter: RebootOption.

penting

Meskipun NoReboot opsi mencegah restart sistem operasi, itu tidak mencegah restart tingkat layanan yang mungkin terjadi ketika paket tertentu diperbarui. Misalnya, memperbarui paket seperti Docker dapat memicu restart otomatis layanan dependen (seperti layanan orkestrasi kontainer) bahkan ketika NoReboot ditentukan.

Untuk informasi tentang melihat data kepatuhan patch, lihat Tentang kepatuhan patch.

Langkah-langkah operasional AWS-RunPatchBaselineWithHooks

Saat AWS-RunPatchBaselineWithHooks berjalan, langkah-langkah berikut dilakukan:

  1. Pindai - Scan Operasi menggunakan AWS-RunPatchBaseline dijalankan pada node terkelola, dan laporan kepatuhan dihasilkan dan diunggah.

  2. Verifikasi status patch lokal - Script dijalankan untuk menentukan langkah-langkah apa yang akan dilakukan berdasarkan operasi yang dipilih dan hasil Scan dari Langkah 1.

    1. Jika operasi yang dipilih adalah Scan, operasi ditandai selesai. Operasi berakhir.

    2. Jika operasi yang dipilih adalahInstall, Patch Manager evaluasi Scan hasil dari Langkah 1 untuk menentukan apa yang akan dijalankan selanjutnya:

      1. Jika tidak terdeteksi ada patch yang hilang, dan tidak perlu reboot tertunda, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati.

      2. Jika tidak terdeteksi ada patch yang hilang, tapi ada reboot tertunda yang diperlukan dan opsi reboot yang dipilih adalah NoReboot, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati.

      3. Jika tidak, operasi dilanjutkan ke langkah berikutnya.

  3. Pre-patch operasi kait - Dokumen SSM yang telah Anda berikan untuk kait siklus hidup pertama,PreInstallHookDocName, dijalankan pada node yang dikelola.

  4. Instal dengan NoReboot - Install Operasi dengan opsi reboot NoReboot penggunaan AWS-RunPatchBaseline dijalankan pada node yang dikelola, dan laporan kepatuhan dibuat dan diunggah.

  5. Post-install operasi kait - Dokumen SSM yang telah Anda sediakan untuk kait siklus hidup kedua,PostInstallHookDocName, dijalankan pada node yang dikelola.

  6. Verifikasi reboot - Skrip berjalan untuk menentukan apakah reboot diperlukan untuk node yang dikelola dan langkah-langkah apa yang harus dijalankan:

    1. Jika opsi reboot yang dipilih adalah NoReboot, operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati.

    2. Jika opsi reboot yang dipilih adalahRebootIfNeeded, periksa Patch Manager apakah ada reboot yang tertunda yang diperlukan dari inventaris yang dikumpulkan pada Langkah 4. Ini berarti bahwa operasi berlanjut ke Langkah 7 dan node yang dikelola di-reboot dalam salah satu kasus berikut:

      1. Patch Managermenginstal satu atau lebih patch. (Patch Managertidak mengevaluasi apakah reboot diperlukan oleh patch. Sistem di-reboot bahkan jika patch tidak memerlukan reboot.)

      2. Patch Managermendeteksi satu atau lebih patch dengan status INSTALLED_PENDING_REBOOT selama operasi Install. INSTALLED_PENDING_REBOOTStatus dapat berarti bahwa opsi NoReboot dipilih saat terakhir kali operasi Install dijalankan, atau bahwa patch diinstal di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang.

      Jika tidak ada patch yang memenuhi kriteria ini ditemukan, operasi tambalan node terkelola selesai, dan operasi berlanjut langsung ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati.

  7. Reboot dan lap orkan - Operasi instalasi dengan opsi reboot RebootIfNeeded berjalan pada node terkelola menggunakanAWS-RunPatchBaseline, dan laporan kepatuhan dibuat dan diunggah.

  8. Post-reboot operasi kait - Dokumen SSM yang telah Anda sediakan untuk kait siklus hidup ketiga,OnExitHookDocName, dijalankan pada node yang dikelola.

Untuk operasi Scan, jika Langkah 1 gagal, proses menjalankan dokumen berhenti dan langkah tersebut dilaporkan gagal, meskipun langkah-langkah berikutnya dilaporkan sebagai sukses.

Untuk operasi Install, jika salah satu langkah aws:runDocument gagal selama operasi, langkah-langkah tersebut dilaporkan gagal, dan operasi langsung melanjutkan ke langkah terakhir (Langkah 8), yang mencakup kait yang telah Anda berikan. Setiap langkah yang ada di antaranya dilewati. Langkah ini dilaporkan gagal, langkah terakhir melaporkan status hasil operasi, dan semua langkah di antaranya dilaporkan sebagai sukses.

Parameter AWS-RunPatchBaselineWithHooks

AWS-RunPatchBaselineWithHooks support enam parameter.

parameter Operation diperlukan.

Parameter RebootOption, PreInstallHookDocName, PostInstallHookDocName, dan OnExitHookDocName bersifat opsional.

Snapshot-ID secara teknis opsional, tetapi kami merekomendasikan Anda untuk menyediakan nilai kustom untuknya ketika Anda menjalankan AWS-RunPatchBaselineWithHooks di luar jendela pemeliharaan. Biarkan Patch Manager memberikan nilai secara otomatis ketika dokumen dijalankan sebagai bagian dari operasi jendela pemeliharaan.

Nama parameter: Operasi

Penggunaan: Wajib.

Opsi: Scan | Install.

Pemindaian

Ketika Anda memilih Scan opsi, sistem menggunakan AWS-RunPatchBaseline dokumen untuk menentukan status kepatuhan patch dari node yang dikelola dan melaporkan informasi ini kembali kePatch Manager. Scantidak meminta pembaruan untuk diinstal atau node yang dikelola untuk di-boot ulang. Sebagai gantinya, operasi mengidentifikasi di mana pembaruan hilang yang disetujui dan berlaku untuk node.

Menginstal

Saat Anda memilih Install opsi, mencoba AWS-RunPatchBaselineWithHooks menginstal pembaruan yang disetujui dan berlaku yang hilang dari node yang dikelola. Informasi kepatuhan patch yang dihasilkan sebagai bagian operasi Install tidak mencantumkan pembaruan yang hilang, tetapi mungkin melaporkan pembaruan yang berstatus gagal jika instalasi pembaruan tidak berhasil karena alasan apa pun. Setiap kali pembaruan diinstal pada node terkelola, node di-reboot untuk memastikan pembaruan diinstal dan aktif. (Pengecualian: Jika RebootOption parameter disetel ke NoReboot dalam AWS-RunPatchBaselineWithHooks dokumen, node yang dikelola tidak di-boot ulang setelah Patch Manager dijalankan. Untuk informasi lebih lanjut, lihatNama parameter: RebootOption.)

catatan

Jika patch yang ditentukan oleh aturan dasar diinstal sebelum Patch Manager memperbarui node terkelola, sistem mungkin tidak melakukan reboot seperti yang diharapkan. Ini dapat terjadi ketika patch diinstal secara manual oleh pengguna atau diinstal secara otomatis oleh program lain, seperti unattended-upgrades paket aktifUbuntu Server.

Nama parameter: ID Snapshot

Penggunaan: Opsional.

Snapshot IDadalah ID unik (GUID) yang digunakan Patch Manager untuk memastikan bahwa satu set node terkelola yang ditambal dalam satu operasi semuanya memiliki set patch yang disetujui yang sama persis. Meskipun parameter didefinisikan sebagai opsional, rekomendasi praktik terbaik kami bergantung pada apakah Anda menjalankan AWS-RunPatchBaselineWithHooks di jendela pemeliharaan, seperti yang dijelaskan dalam tabel berikut.

Praktik terbaik AWS-RunPatchBaselineWithHooks
Mode Praktik terbaik Detail
Menjalankan AWS-RunPatchBaselineWithHooks di dalam jendela pemeliharaan Jangan berikan ID Snapshot. Patch Managerakan menyediakannya untuk Anda.

Jika Anda menggunakan jendela pemeliharaan untuk menjalankanAWS-RunPatchBaselineWithHooks, Anda seharusnya tidak memberikan ID Snapshot yang dibuat sendiri. Dalam skenario ini, Systems Manager menyediakan nilai GUID berdasarkan ID eksekusi jendela pemeliharaan. Hal ini memastikan bahwa digunakan ID yang benar untuk semua pemanggilan AWS-RunPatchBaselineWithHooks dalam jendela pemeliharaan tersebut.

Jika Anda menentukan nilai dalam skenario ini, perhatikan bahwa snapshot dari baseline patch mungkin tidak tetap di tempatnya selama lebih dari 3 hari. Setelah itu, snapshot baru akan dihasilkan bahkan jika Anda menentukan ID yang sama setelah snapshot berakhir.

Menjalankan AWS-RunPatchBaselineWithHooks di luar jendela pemeliharaan Menghasilkan dan menentukan nilai GUID kustom untuk ID Snapshot.¹

Jika Anda tidak menggunakan jendela pemeliharaan untuk dijalankanAWS-RunPatchBaselineWithHooks, sebaiknya buat dan menentukan ID Snapshot unik untuk setiap baseline patch, terutama jika Anda menjalankan AWS-RunPatchBaselineWithHooks dokumen pada beberapa node terkelola dalam operasi yang sama. Jika Anda tidak menentukan ID dalam skenario ini, Manajer Sistem akan menghasilkan ID Snapshot yang berbeda untuk setiap node terkelola yang dikirim perintah. Ini mungkin mengakibatkan berbagai set patch ditentukan di antara node.

Misalnya, Anda menjalankan AWS-RunPatchBaselineWithHooks dokumen secara langsung, menggunakan alat Run CommandAWS Systems Manager, dan menargetkan grup 50 node terkelola. Menentukan ID Snapshot kustom menghasilkan pembuatan snapshot dasar tunggal yang digunakan untuk mengevaluasi dan menambal semua node yang dikelola, memastikan bahwa node tersebut berakhir dalam keadaan yang konsisten.

¹ Anda dapat menggunakan alat yang mampu menghasilkan GUID untuk menghasilkan nilai untuk parameter ID Snapshot. Misalnya, di PowerShell, Anda dapat menggunakan New-Guid cmdlet untuk menghasilkan GUID dalam format. 12345699-9405-4f69-bc5e-9315aEXAMPLE

Nama parameter: RebootOption

Penggunaan: Opsional.

Pilihan: RebootIfNeeded | NoReboot

Default: RebootIfNeeded

Awas

Opsi default-nya adalah RebootIfNeeded. Pastikan untuk memilih opsi yang benar untuk kasus penggunaan Anda. Misalnya, jika node terkelola Anda harus segera reboot untuk menyelesaikan proses konfigurasi, pilihRebootIfNeeded. Atau, jika Anda perlu mempertahankan ketersediaan node terkelola hingga waktu reboot yang dijadwalkan, pilihNoReboot.

penting

Kami tidak menyarankan penggunaan Patch Manager untuk menambal instans cluster di Amazon EMR (sebelumnya disebut Amazon Elas MapReduce tic). Secara khusus, jangan pilih RebootIfNeeded opsi untuk RebootOption parameter. (Opsi ini tersedia di dokumen Perintah SSM untuk menambal, AWS-RunPatchBaselineAWS-RunPatchBaselineAssociation, danAWS-RunPatchBaselineWithHooks.)

Perintah yang mendasari untuk menambal menggunakan Patch Manager use yum dan dnf perintah. Oleh karena itu, operasi menghasilkan ketidakcocokan karena bagaimana paket diinstal. Untuk informasi tentang metode pilihan untuk memperbarui perangkat lunak pada cluster Amazon EMR, lihat Menggunakan default AMI untuk Amazon EMR di Panduan Manajemen Amazon EMR.

RebootIfNeeded

Ketika Anda memilih RebootIfNeeded opsi, node terkelola akan di-boot ulang dalam salah satu kasus berikut:

  • Patch Managermenginstal satu atau lebih patch.

    Patch Managertidak mengevaluasi apakah reboot diperlukan oleh patch. Sistem di-reboot bahkan jika patch tidak memerlukan reboot.

  • Patch Managermendeteksi satu atau lebih patch dengan status INSTALLED_PENDING_REBOOT selama Install operasi.

    INSTALLED_PENDING_REBOOTStatus dapat berarti bahwa opsi NoReboot dipilih saat terakhir kali Install operasi dijalankan, atau bahwa patch diinstal di luar Patch Manager sejak terakhir kali node terkelola di-boot ulang.

Mem-boot ulang node terkelola dalam dua kasus ini memastikan bahwa paket yang diperbarui dihapus dari memori dan menjaga perilaku menambal dan reboot tetap konsisten di semua sistem operasi.

NoReboot

Ketika Anda memilih NoReboot opsi, Patch Manager tidak me-reboot node terkelola bahkan jika itu menginstal patch selama Install operasi. Opsi ini berguna jika Anda tahu bahwa node terkelola Anda tidak memerlukan reboot setelah patch diterapkan, atau Anda memiliki aplikasi atau proses yang berjalan pada node yang seharusnya tidak terganggu oleh reboot operasi tambalan. Ini juga berguna ketika Anda ingin lebih banyak kontrol atas waktu reboot node terkelola, seperti dengan menggunakan jendela pemeliharaan.

catatan

Jika Anda memilih opsi NoReboot dan sebuah patch diinstal, patch diberikan status InstalledPendingReboot. Node yang dikelola itu sendiri, bagaimanapun, ditandai sebagaiNon-Compliant. Setelah reboot terjadi dan Scan operasi dijalankan, status node diperbarui keCompliant.

File pelacakan instalasi patch: Untuk melacak instalasi patch, terutama patch yang diinstal sejak reboot sistem terakhir, Manajer Sistem memelihara file pada node yang dikelola.

penting

Jangan menghapus atau memodifikasi file pelacakan. Jika file ini dihapus atau rusak, laporan kepatuhan patch untuk node terkelola tidak akurat. Jika ini terjadi, reboot node dan jalankan operasi patch Scan untuk mengembalikan file.

File pelacakan ini disimpan di lokasi berikut di node terkelola Anda:

  • Sistem operasi Linux:

    • /var/log/amazon/ssm/patch-configuration/patch-states-configuration.json

    • /var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json

  • Sistem operasi Windows Server:

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json

Nama parameter: PreInstallHookDocName

Penggunaan: Opsional.

Default: AWS-Noop.

Nilai untuk disediakan untuk parameter PreInstallHookDocName adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen terkel AWS ola atau nama atau ARN dokumen SSM kustom yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari yang berbeda Akun AWS, Anda harus menentukan ARN sumber daya lengkap, sepertiarn:aws:ssm:us-east-2:123456789012:document/MySharedDocument.)

Dokumen SSM yang Anda tentukan dijalankan sebelum Install operasi dan melakukan tindakan apa pun yang didukung olehSSM Agent, seperti skrip shell untuk memeriksa pemeriksaan kesehatan aplikasi sebelum tambalan dilakukan pada node yang dikelola. (Untuk daftar tindakan, lihat Referensi plugin dokumen perintah). Nama dokumen SSM default adalahAWS-Noop, yang tidak melakukan operasi apa pun pada node yang dikelola.

Untuk informasi tentang membuat dokumen SSM kustom, lihat Membuat konten dokumen SSM.

Nama parameter: PostInstallHookDocName

Penggunaan: Opsional.

Default: AWS-Noop.

Nilai untuk disediakan untuk parameter PostInstallHookDocName adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen terkel AWS ola atau nama atau ARN dokumen SSM kustom yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari yang berbeda Akun AWS, Anda harus menentukan ARN sumber daya lengkap, sepertiarn:aws:ssm:us-east-2:123456789012:document/MySharedDocument.)

Dokumen SSM yang Anda tentukan dijalankan setelah Install with NoReboot operasi dan melakukan tindakan apa pun yang didukung olehSSM Agent, seperti skrip shell untuk menginstal pembaruan pihak ketiga sebelum reboot. (Untuk daftar tindakan, lihat Referensi plugin dokumen perintah). Nama dokumen SSM default adalahAWS-Noop, yang tidak melakukan operasi apa pun pada node yang dikelola.

Untuk informasi tentang membuat dokumen SSM kustom, lihat Membuat konten dokumen SSM.

Nama parameter: OnExitHookDocName

Penggunaan: Opsional.

Default: AWS-Noop.

Nilai untuk disediakan untuk parameter OnExitHookDocName adalah nama atau Amazon Resource Name (ARN) dari dokumen SSM pilihan Anda. Anda dapat memberikan nama dokumen terkel AWS ola atau nama atau ARN dokumen SSM kustom yang telah Anda buat atau yang telah dibagikan dengan Anda. (Untuk dokumen SSM yang telah dibagikan dengan Anda dari Akun AWS berbeda, Anda harus menentukan ARN sumber daya lengkap, seperti arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument.)

Dokumen SSM yang Anda tentukan dijalankan setelah operasi reboot node terkelola dan melakukan tindakan apa pun yang didukung olehSSM Agent, seperti skrip shell untuk memverifikasi kesehatan node setelah operasi tambalan selesai. (Untuk daftar tindakan, lihat Referensi plugin dokumen perintah). Nama dokumen SSM default adalahAWS-Noop, yang tidak melakukan operasi apa pun pada node yang dikelola.

Untuk informasi tentang membuat dokumen SSM kustom, lihat Membuat konten dokumen SSM.