Apa yang berbeda / lebih baik tentang skrip DSC vs "reguler"?


8

Saya menonton video di ITPro.tv tentang PowerShell Desired State Configuration DSC . Mereka memperkenalkannya, dan secara efektif menjalankan skrip. Namun, ini adalah pengenalan skrip (nyata) pertama mereka juga, jadi saya tidak mengambil perbedaan antara DSC dan skrip biasa. Saya telah melakukan beberapa scripting biasa sebelumnya, dan mungkin mereka hanya tidak memiliki contoh yang bagus; sepertinya skrip biasa dapat menginstal peran / fitur dan menyalin beberapa file dengan baik. Saya tidak melihat manfaatnya bagi DSC dibandingkan hanya dengan skrip. Selain dari mesin yang dapat melakukan polling untuk beberapa jenis perubahan, yang tidak mereka sertakan dalam praktik, hanya secara teori.

Apa manfaat DSC dibandingkan skrip tradisional; misalnya "instal peran, salin file"?

  • Dengan PowerShell, Anda dapat terhubung ke mesin jarak jauh dan menyuruh mereka melakukan hal-hal, jadi itu tidak eksklusif untuk DSC.
  • Dengan DSC sepertinya Anda sedang melakukan semacam kompilasi untuk membuat file mof, dan kemudian Anda menjalankannya dari shell setelah skrip, yang sepertinya merupakan langkah yang tidak perlu.
  • The gambaran MSDN dibaca seperti gambaran PowerShell, dan saya tidak melihat karakteristik pembeda.

Jawaban:


7

Seperti yang Anda katakan, Anda dapat melakukan hampir semua yang Anda lakukan dengan DSC, dengan kode powershell lurus.

Tapi, DSC adalah semua tentang manajemen konfigurasi.

Manajemen konfigurasi adalah tentang pola dan praktik menggunakan kode dan berbagai sistem untuk memastikan sistem berada dalam keadaan tertentu. Ref 1 2

Satu hal penting tentang manajemen konfigurasi adalah idempoten. Berarti kode yang menggambarkan sistem Anda dalam sistem manajemen konfigurasi akan diperiksa dan dijalankan terhadap sistem Anda secara berkala. Banyak skrip dasar tidak dirancang dengan baik, dan akan melakukan hal yang benar saat pertama kali Anda menggunakannya untuk mengonfigurasi sistem, tetapi kali berikutnya skrip akan salah, duplikat, dan sebagainya. Sistem manajemen konfigurasi idealnya akan mengabstraksi sebagian besar pengujian dan menyatakan kode pemeriksaan yang harus Anda tambahkan secara manual dalam sebuah skrip, untuk membuat skrip idempoten.

Hal penting lainnya tentang DSC dan banyak sistem manajemen konfigurasi lainnya adalah tentang membuat sumber daya yang dapat digunakan kembali yang benar-benar melakukan pekerjaan yang dapat dibagikan dengan siapa saja dan semua orang di dunia. Dengan cara ini, sebenarnya 'konfigurasi' Anda hanya beberapa detail spesifik yang spesifik untuk lingkungan Anda. Ini juga berarti Anda harus menulis lebih sedikit kode, karena Anda dapat menggunakan kembali hal-hal yang telah digunakan dan diperiksa oleh banyak orang lain.

Saya telah memasukkan beberapa tautan di atas, tetapi ada banyak situs web bagus yang dapat Anda temukan di Internet tentang teori sistem manajemen konfigurasi. Teori umum berlaku untuk semua sistem manajemen konfigurasi (boneka, koki, dsc, mungkin, dll) tentu saja layak dipelajari, dan layak digunakan di sebagian besar lingkungan.


1

Saya sarankan Anda melihat di https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-doneed-desired-stired-configuration .

Saya sudah melakukan devops sebagai pemimpin proyek C # sejak jauh sebelum itu disebut itu. Saya telah menulis lusinan "setup a share", dan "buat aplikasi di IIS", dan "periksa apakah skrip IIS Rewrite sudah diinstal". Saya biasanya diminta untuk melakukannya oleh seseorang yang berpikir "Itu hanya satu baris kode untuk melakukan X." Tetapi bagaimana jika benda itu sudah ada? Bagaimana jika langkah 1,3 sudah ada tetapi 2,4 tidak, atau langkah 2 (katakanlah kumpulan aplikasi IIS) tidak dikonfigurasi persis sama seperti terakhir kali?

Ya, DSC mengharuskan Anda memberi nama setiap "bagian" dari skrip. Yang awalnya terasa membosankan. Tetapi jika Anda tidak menyebutkannya maka mesin dan penyedia DSC tidak dapat memberi tahu Anda bagian mana dari skrip yang terlalu lama, atau bagian skrip mana yang gagal.

Jika Anda melakukan folder, IIS, penyebaran aplikasi, atau Fitur Windows Saya sangat menyarankan Anda berinvestasi beberapa hari dalam mempelajari DSC.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.