Azure App Service – Service Endpoint เปิด GA แล้ว

Azure App Service เป็นบริการ Web Hosting แบบ Platform-as-a-Service (PaaS) การใช้งานจะได้ IP ที่อยู่นอก Virtual Network การจะเชื่อมต่อกับ VNet ทำยากเพราะต้องป้องกันเรื่อง Network Security ตอนนี้มี Service Endpoint แล้วจะช่วยให้การควบคุมเวลาเรียกใช้ Web APp ทำได้ง่ายครับ เพิ่มเติม https://azure.microsoft.com/en-us/updates/app-service-private-endpoints-ga/ครับ

Azure – Advisor Score

Advisor เป็นเครื่องมือที่่คอยตรวจสอบการติดตั้ง Azure ของเราว่าเป็นไปตาม Best Practice หรือไม่ ด้วยการตรวจ Configuration และเครื่องเก็บข้อมูล (Telemetry) เพื่อนำไปวิเคราะห์และแสดงข้อมูลด้วยกระบวนการ คำแนะนำช่วยเรื่อง Cost, Performance, Availability และ Security

แนะนำ Feature ใหม่ – Advisor Score

Azure จะเทียบผลการประเมินของ Subscription ของเราเทียบกับข้อมูลที่ Microsoft เคยทำกับการใช้งานของคนอื่นแล้วให้เป็น score

Reference

  1. https://azure.microsoft.com/en-us/blog/introducing-the-microsoft-azure-wellarchitected-framework/
  2. https://azure.microsoft.com/en-us/blog/optimize-your-azure-workloads-with-azure-advisor-score/

#AzureThailandUserGroup

Container Data Encryption

การ Run Container ต้องมี Container Host ที่เป็น VM หรืออาจเป็น Physical ซึ่ง Container Host นี้ดูแลให้โดยผู้ดูแล Host หรืออาจะไปอยู่บน Public Cloud ก็ได้  ตามที่เคยเล่าเรื่อง Docker Volume ไปแล้วว่ามันการ กำหนด storage ให้กับ Container   วิธีที่ Docker จะใช้งาน Storage จะทำผ่าน Storage Driver

มุมมองด้าน Security การเก็บข้อมูลลง Volume มีการควบคุมสิทธิด้วยระบบ Access Control แม้มีการควบคุมแล้วก็ยังมีจุดเสี่ยงเหลืออยู่ ดังนั้น จึงมีผู้ทำเครื่องเข้ารหัส volume โดยผ่านช่องทาง Storage Driver  ตัวอย่างที่ยกมาเป็นของ Zettaset – Xcrypt  ในภาพด้านล่างเป็นการอธิบายว่า เมื่อ Container ขอใช้ Volume (Storage) เครื่องมือ Zettaset จะเป็น Driver เพื่อ Access Storage โดยทำการเข้ารหัส ที่มี Key เก็บอยู่บน Key Manager

zettaset-storage-driver

ผมได้ข้อมูลจาก Webinar ที่จัดโดย Mirantis Inc. หากใครสนใจฟังเต็มๆ ก็กด Link ด้านล่างนี้ได้

Slide -> https://info.mirantis.com/l/530892/is-zettaset-webinar-slides-pdf/3bdcll

Youtube -> https://www.youtube.com/embed/cHVbI-xXqn4

 

PowerShell Azure Module และ Cloud Shell

สวัสดีครับ ผม Chaba_OK! คราวนี้เป็นเรื่อง การใช้งาน Azure สำหรับผู้ทำหน้าที่เป็น Administrator ที่ต้องใช้ Portal มีวิธีสั่งงานได้หลายวิธีวิธี คือ ผ่านหน้า Web Page, Command-Line, REST API และ Visual Studio ที่ใช้สำหรับ Admin บ่อยๆ คือ Web และ Command-line  ขอแนะนำวิธีง่ายเพียง 2 วิธีคือ

1. Azure Portal –  Web Page (https://portal.zure.com) – ใช้งาน Web Application ที่เป็น GUI

image

2. PowerShell เป็นการใช้ Command-line หรือ Script เป็น PowerShell มี 2 แบบให้เลือก

2.1 PowerShell ที่ทำงานจากเครื่อง Computer ของเราเอง ก่อนใช้งานต้องติดตั้ง Azure Module ลงไปก่อน ซึ่งแน่นอนว่าเครื่องจะต้องต่อ Internet เพื่อ Connect กับ Azure

– ก่อนลงมือติดตั้ง ขอแนะนำให้ Update PowerShell เป็น Version 5 วิธีดู Version PowerShell ใช้คำสั่งนี้

image

– ปกติ PowerShell ในเครื่องของเรา ถูกกำหนดให้ชี้ไป Repository ซึ่งช่วยให้สะดวกเวลาที่ต้องติดตั้ง Module เพิ่มเติม การดูค่า Repository ทำตามนี้ ผลคือ Repository คือ http://www.powershellgallery.com

image

– ลงมือติดตั้ง Module Azure ด้วยคำสั่ง find-module azure*|install-module และกด Yes to All  หรือ download .msi จากที่นี่ https://github.com/Azure/azure-powershell/releases

image

image

image

2.2 Azure Cloud Shell เป็นการใช้ PowerShell Command-line บน Browser

– วิธีนี้การทำงานต้องจำคำสั่งที่คีย์ทีละ command หรือจะใช้วิธี Upload script ก็ได้  เทคนิคการสร้าง Azure PowerShell Console นี้น่าสนุก ผมเคยเล่าเรื่อง Windows Container มันถูกนำมาใช้ในงานนี้ ภาพด้านล่างแสดงให้เห็นว่า Console ถูก Run บน Windows Container ตามปกติใน Container มัน save file ลงไม่ได้ ทำให้ต้อง Mount ไปที่ Storage ดังนั้น การใช้ Console ต้องมี Cloud Storage ประกอบด้วย เมื่อเข้า Console ครั้งแรกจึงสร้าง Cloud Storage และ Azure File Share

AzurePowerShellConsole

การเข้าใช้งานครั้งแรกจะต้อง Create storage ตามภาพด้านล่าง

image

ด้านล่างเป็นหน้าจอ Console ใช้คำสั่ง  get-psdrive จะเห็น drive y: ที่เป็นที่เก็บ file AzurePowerShellDrive

ด้านล่าง ใน Azure Portal จะเห็น Storage Account ใน Resource Group “cloud-shell-storage-xx” ตามภาพ ได้สร้าง Directory-work เพื่อเก็บ Script

AzurePowerShellPortalUpload

สรุป การใช้สั่งงาน Azure ทำงานผ่าน PowerShell ได้ มีทั้งวิธีจากเครื่อง Computer เราเอง และวิธี Azure PowerShell Console

#https://www.facebook.com/groups/1912394935675514/

#AzureThailandUserGroup

 

 

PowerShell Code Sign และ Self-Signed Certificate

สวัสดีครับ ผม Chaba_OK! เราจะมาเรียนรู้การสร้าง PowerShell script file ให้มีความน่าเชื่อถือว่า ไม่โดนแก้ไขโดยใช้ Code signing certificate ซึ่งเหมาะกับการนำไปใช้งานใน Production System

เริ่มต้นต้องตรวจสอบก่อนว่า PowerShell ต้องเป็น version 4.0 ขึ้นไป

01

การ Sign ต้องใช้ Certificate ถ้าเป็นงาน Production เราควรใช้ Certificate ที่ออกจาก Certificate Authority แต่สำหรับการทดสอบเราจะใช้ Self-signed certificate สร้างด้วยคำสั่งนี้

02

จากคำสั่ง เป็นการสร้าง Certificate เพื่อทำ Digital Signature มีอายุ 5 ปี สำหรับ domain ชื่อ api.vm360degree.com ซึ่งหากตั้งเป็นชื่ออื่นที่เหมาะกับงานก็ได้  เมื่อสร้างสำเร็จ Certificate จะถูกเก็บไว้ที่ Local Machine วิธีเปิดดูให้กด [Windows]+[R] | mmc.exe | File | Add/Remove Snap-in … เลือก Certificates | Click ที่ปุ่ม Add > | เลือก Computer account | เลือก Local Computer | กด Finish ผลตามภาพด้านล่าง

03

ลำดับต่อไป เราจะต้องย้าย Certificate ไปเก็บไว้ที่ Trusted Root Certificate ด้วยคำสั่ง move-item การอ้างอิงถึง Certificate จะใช้ค่า Thumbprint ของ Cettificate ที่สร้างไปไว้แล้ว

04

จะได้ผลลัพธ์ตามภาพด้านล่าง

05

หรือ กลับไปเรียกด้วย PowerShell คือ

06.PNG

ตอนนี้เรามี Certificate – Code Signing พร้อมจะ Signed ซึ่งในตัวอย่าง ได้เตรียม file  hello.ps1 มีหน้าตาแบบนี้

07

ใช้คำสั่งเพื่อสร้าง Sign ในภาพ

08

ในตัวอย่างผมใช้เครื่องหมาย ` เพื่อขึ้นบบรทัดใหม่โดยที่ยังไม่จบคำสั่ง ซึ่งในคีย์บอร์ดภาษาไทยเป็นตัวเปลี่ยนภาษา ก็ให้ copy ไปแปะแทนก็ได้ และหลังสัญลักษณ์นี้ห้ามเว้นวรรคให้ขึ้นบรรทัดใหม่ทันที ผลที่ได้คือในไฟล์ hello.ps1 จะมี Signature แปะไว้

09

วิธีการตรวจสอบว่าไฟล์ที่ Signed ไว้มีการแก้ไขหรือเปล่าให้คำสั่ง Get-AuthenticodeSignature ผลก็ได้ตามภาพด้านล่าง ปกติ Status ต้องเป็น valid แต่ถ้าถูกแก้จะได้เป็น  HashMismatch10.PNG

Script ที่ใช้ทั้งหมดอยู่ด้านล่าง

$MyCert = new-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\my `
-DnsName api.vm360degee.com `
-friendlyname api.vm360degree.com `
-NotAfter ( [DateTime]::Now.AddYears(5)) `
-KeyAlgorithm RSA `
-KeyLength 2048 `
-KeySpec Signature `
-Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
-KeyExportPolicy Exportable `
-KeyUsage DigitalSignature `
-Type CodeSigningCert
$MyPath = 'Cert:\LocalMachine\my\' + $MyCert.Thumbprint
Move-Item -Path $MyPath -Destination Cert:\LocalMachine\Root
$cert= Get-ChildItem cert:\localmachine\root -CodeSigningCert |?{$_.friendlyname -eq "api.vm360degree.com"}
Set-AuthenticodeSignature C:\work\Azure\cert\hello.ps1 `
-Certificate $cert `
-TimestampServer http://timestamp.comodoca.com/authenticode
Get-AuthenticodeSignature -FilePath C:\work\Azure\cert\hello.ps1
view raw ps-signed.ps1 hosted with ❤ by GitHub

สรุป เราเรียนรู้ 2 เรื่องคือ

  1. การสร้าง Self-signed certificate ด้วย PowerShell ทำความเข้าใจให้ดี เพราะจะใช้งานต่อไปอีกในครั้งต่อไป เช่น Azure KeyVault, WinRM แบบ HTTPS
  2. การ Signed PowerShell Script เพื่อป้องกันการแก้ไข

สุดท้ายขอฝาก Facebook group – Azure Thailand User Group ไว้ด้วยครับ

Reference

Create Code Signing Certificate on Windows for signing PowerShell scripts

https://blogs.technet.microsoft.com/heyscriptingguy/2010/06/17/hey-scripting-guy-how-can-i-sign-windows-powershell-scripts-with-an-enterprise-windows-pki-part-2-of-2/

https://www.ddls.com.au/blog/creating-a-self-signed-certificate-for-powershell/

Azure VM ให้ drive D: มาทำไม?

เวลาที่สร้าง VM ใน Azure จะมี drive temporary มาให้พร้อมกับคำเตือนว่า “This temporary storage must not be used to store data that you are not willing to lose.”  จะมีมาให้ทำไม?

คำตอบ คือ จาก Understanding the temporary drive on windows azure VM ที่น่าสนใจคื Drive นี้เอาไว้ใช้เก็บ Page file และไม่คิดเงินครับ

#AzureThailandUserGroup

 

 

Update your Windows

ทุกวันนี้การพัฒนา Application แข่งกันมากและทำกันไวมากเพื่อช่วยให้ธุรกิจแข่งขันกันได้ สำหรับ Microsoft ผู้พัฒนา Windows Server ก็เข้าใจประเด็นนี้ ได้บอกชัดเจนว่าให้ความสำคัญมากกับเรื่อง Container/Microservice  และการใช้ Windows Server บน Cloud และ On-Premise  จึงได้เปลี่ยนวิธีการออก Feature ใหม่ๆ ให้เร็วขึ้นและเปลี่ยน Security Update (hotfix) ด้วย

Nano Server และ Server Core

ตอนที่ Windows Server 2016 ออกมา เราได้รู้จัก Windows Server, Server Core และมีของใหม่คือ Nano Server (อ่านที่นี่) โดย Nano ถูกวางให้เป็นความหวังว่าจะลดงานของของ Server Admin ได้เพราะมันมีขนาดเล็ก ใช้ Resource น้อยและไม่ต้องลง Hotfix บ่อย แต่ Nano มาพร้อมกับความยากเพราะมันไม่มี Driver หรือ Plug and Play สำหรับอุปกรณ์บน Server มาให้  ทำให้ Nano บน Physical Server ติดตั้งยาก  ไม่เหมือน Windows Server ปกติ จึงทำให้การใช้งานจริงๆ นั้น Nano ถูก Run เป็น Virtual Machine (VM) เพื่อทำเป็น Container Server (อ่านที่นี่)

ในส่วน Server Core นั้นก็คือ Windows Server with Desktop (Windows Server ที่มี GUI) ที่ถูกถอด GUI ออกไปจึงมีแต่ Command Line การสั่งงานก็ใช้ PowerShell หรือ Remote Admin Tool จากเครื่องที่มี GUI โดยที่มันยังคง Role/Feature ไว้เหมือนกัน ข้อดีของ Server Core คือ มีขนาดเล็กกว่า GUI และมี  Hotfix น้อยกว่าแบบที่มี GUI ที่ Azure หรือ Azure Stack ก็ใช้ Server Core

New Model of Deliverying of Windows Server และคำยืนยันว่า Nano Server ใช้เพื่อ Container

หลักจาก Nano Server ถูกใช้งานไปสักระยะ Microsoft ได้พบว่า Nano Server ถูกนำไปใช้เป็น Container มาก เพราะมันเล็ก ประกอบกับต้องออก Feature ใหม่เร็วขึ้นจึงได้ประกาศเรื่อง New Model of Deliverying of Windows Server หรือการออก Update Feature มาในเดือนมิถุนายน 2560 ดังนี้

  1. Nano Server – ทำมาให้ใช้เป็น Container อย่างเดียว มาพร้อมกับกับ .Net core 2.0 และ PowerShell แต่ไม่มี WMI และไม่มี Role สำหรับไปทำงาน Infrastructure อื่นๆ
  2. การประกาศความถี่ในการปล่อย  Update ด้วยชื่อเรียกใหม่คือ
  • Semi-annual Channel
    • เหมาะกับผู้ที่ต้องใช้ Feature ใหม่ๆ ไม่ต้องรอเป็นปี
    • ออกปีละ 2 ครั้ง ในเดือน มีนาคม และเดือนกันยายน
    • มีให้เฉพาะ Nano Server และ Server Core
    • Support เป็นระยะเวลา 18 เดือนนับจากวันที่ออก
    • เลข Version ใช้รูปแบบ YYMM เช่น verion 1709 หมายถึง version ปี 2017 เดือนกันยายน (09)
    • ลูกค้าที่ซื้อ License ที่รองรับการ  Upgrade คือ Software Assurance หรือใช้ VM License บน Cloud จึงจะได้  Update
  • Long-term Servicing Channel
    • เหมาะกับผู้ที่ไม่ต้องการเปลี่ยน Version บ่อย เป็นงานที่ใช้กันยาวๆ
    • มีให้เฉพาะ Windows Server with Desktop
    • Support กันยาวๆ ถึง 10 ปี (5 ปีแรกเป็น mainstream และ 5 ปีหลังเป็น extended)
    • ลูกค้าซื้อ License ของ Windows ตามปกติ

Installation option Semi-annual Channel (Windows Server) Long-term Servicing Channel (Windows Server 2016)
Nano Server Yes No
Server Core Yes Yes
Server with Desktop No Yes

Source: https://docs.microsoft.com/en-us/windows-server/get-started/semi-annual-channel-overview

 

Servicing Model (Security Update)

เนื่องจากการลง Security Update เมื่อก่อนนี้ลูกค้าสามารถเลือกลงเป็นบางตัวหรือไม่ได้ลงทุกตัว การลงไม่ครบสร้างปัญหาการใช้งาน ทาง Microsoft จึงเลิกการปล่อย Security Update แบบรายตัว แล้วเปลี่ยนมาเป็นต้องลงทุกตัว ในรูปแบบ Pack โดยมีรูปแบบดังนี้

  1. Security-only Update เป็นการรวม Security Patch ประจำของเดือนไว้ด้วยกัน ลูกค้าไม่สามารถเลือกว่าจะลงอันไหนได้เอง ระบบจะลงทุกตัว ถ้าพบปัญหาจากการ  Update แล้วคิดจะถอยก็ต้องถอนทั้งหมด หากถอนไม่ได้ต้องเปิด case กับ Microsoft
  2. Monthly Rollup เป็นการรวม Security Patch, Update อื่นๆ เป็นเดือนไว้ ครอบคลุมย้อนหลังให้ด้วย  6-8 เดือน  กรณีทำผ่านการใช้ Windows Update ผ่าน Internet ที่ใครๆ ก็ทำได้

 

ถึงตรงนี้จะเข้าใจได้ว่า Update มีชุดเล็กกับชุดใหญ่ ชุดเล็กเป็นการลง  update ที่มีให้ทำกันเป็นรายเดือน ไม่มีค่าใช้จ่าย ส่วนชุดใหญ่เป็นการ  Update Feature สำหรับผู้ที่ต้องการใช้ Feature แต่มีค่าใช้จ่าย Software Assurance หรือใช้จาก Cloud

 

Reference

  1. https://docs.microsoft.com/en-us/windows-server/get-started/semi-annual-channel-overview
  2. https://docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel
  3. https://blogs.technet.microsoft.com/hybridcloud/2017/06/15/delivering-continuous-innovation-with-windows-server/

Azure และ AWS

การเลือกระหว่าง Azure กับ AWS คงไม่ง่ายถ้าจะบอกใคร ดี เด่น ดัง เพราะฉะนั้น System มืออาชีพ ควรทำความเข้าใจทั้ง 2 ฝั่ง ช่วงนี้รีบ Update ความรู้เรื่อง Cloud ประเดิมด้วยการเทียบ Product กัน ซึ่งต่อไป vm360degree.com จะเป็น blog ที่เน้น cloud ระหว่างนี้หาชั่วโมงฟรีก่อน การได้ชั่วโมง cloud ฟรีๆ นานๆ สำหรับ bloger เองก็ไม่ใช่เรื่องง่ายครับ

อันแรก เป็นตัว map product ของ 2 cloud
https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services
อันต่อมา เป็นตัวแปลง AWS เป็น Azure
https://docs.microsoft.com/en-us/azure/architecture/aws-professional/index

PowerShell DSC

การดูแลระบบ Computer มักยึดติดกับขั้นตอน (Step) และ Configuration โดยเฉพาะการติดตั้ง Application (Software deployment), ควบคุมค่า Configuration ของ OS หรือ Application และเก็บค่า Configuration นั้นไว้ เพื่อควบคุมสถานะให้มันใช้งานได้ เวลาที่ระบบมีปัญหามันมักเป็นเรื่องที่ติดค้างอยู่ในใจของผู้ที่ต้องดูแลระบบ เมื่อได้ยินคำถาม เช่น “ใครไปแก้อะไร?” หรือ “ทำอะไรไม่เหมือนกันกับเครื่องที่ใช้งานได้หรือเปล่า” บางทีระบบงานอาจใช้งานมากจนเพิ่มจำนวนเครื่อง (scale-out) หรือย้ายเครื่องไปเครื่องใหม่ที่มีประสิทธิภาพดีกว่า (scale-up) จะต้องติดตั้ง Application ใหม่ ก็ต้องไปหาขั้นตอนการทำหรือไปตามคนที่ทำเป็นมาทำให้ได้ไหม? สมัยนี้ Hardware ก็ไปทาง Virtualization หรืออยู่บน Cloud เป็นหลัก ทำให้การย้ายเครื่องทำได้ง่าย เหตุการณ์ที่ยกมานี้มีโอกาสเกิดขึ้นจริงได้เสมอ ถ้าเรามองภาพ Server กันใหม่ ว่าเครื่อง Server มันประกอบด้วย Hardware, Application และ Configuration แล้วทำเราเอกสารบันทึกขั้นตอนการ Setup และค่า Configuration เก็บไว้ทำเป็น Version เมื่อมีเอกสารนี้แล้วเวลาจะทำอะไรก็อ้างอิงจากเอกสารนี้ แล้วนี่ก็เป็นที่มาของระบบที่เรียกว่า Configuration Management

Configuration Management

การเปลี่ยนแปลงในระบบมักถูกเหมาเรียกว่า Change ไปหมด เพราะมันคือการเปลี่ยนแปลง แต่หากมองในด้านการกระทำของ Change ใน 2 ส่วนคือ เปลี่ยนอะไร (What) และ เปลี่ยนอย่างไร (How) มันมีคำเรียกใหม่คือ Configuration Management เพื่อให้เข้าใจง่ายๆ เราจะเรียก Change ว่าคือกระบวนการ (Process) เมื่อต้องการจะเปลี่ยนแปลงอะไรสักอย่าง ที่ควบคุมตลอด Life-Cycle ของการเปลี่ยนแปลงนั้นๆ เช่น การขอ Change เพื่อทำ Web Application, จัดลำดับของ Change ว่าจะเลือกทำอะไรก่อน , Resource , Timeline เป็นต้น ส่วนของ Configuration Management จะเน้นไปการติดตั้ง (Implementation) ของ Change เช่น การทำขั้นตอน (Step) การติดตั้ง Web Application, การบันทึกค่า Configuration เป็นต้น การทำ Configuration Management เป็นกระบวนการดูแลและควบคุมค่า Configuration ในระบบ การไปลงมือทำก็มีเครื่องมือตามหลัก ITIL ก็อาจพูดถึง CMDB แต่ในหัวข้อของเรา จะพูดถึงเครื่องมือ Configuration Management ในส่วนของการทำ Configuration และติดตั้ง

การนำ Configuration Management มาใช้มีประโยชน์ดังนี้

  • สร้าง Standard ของการทำงาน จะทำกี่ครั้ง
    หรือบนเครื่องไหนก็ให้ผลเหมือนกัน
  • ทำ Version control ได้
  • ควบคุมเวลาได้และประหยัดเวลา
  • ทดสอบเพื่อควบคุมคุณภาพได้
  • ตรวจสอบผลและแก้ปัญหาได้ง่าย

เครื่องมือ Configuration Manage ที่มีอยู่มากมาย เช่น Chef, Puppet เป็นต้น มันทำงานได้ดีบน Unix/Linux แม้จะมี Version ที่อยู่บน Windows ด้วย แต่มันก็ยังไม่ค่อยดี เพราะการจัดการ Configuration ของ Unix เป็น Document Oriented OS แต่ Windows เป็น API Oriented OS นั่นคือ การ Configure ระบบงาน Unix มักอยู่ในรูป Text File และเมื่อเป็น Windows มักจะเป็น Registry, การเรียก API หรือ WMI

PowerShell DSC

เครื่องมือ Configuration Management ที่ออกมาหลายตัว มีความถนัดกันคนละอย่าง เพราะการเรียกใช้ Function ก่อนหน้านี้ยังไม่มีมาตราฐาน ก็เป็นภาระของผู้ที่ซื้อเอง ที่จะต้องพิจารณาว่าเลือกถูกตัว หรือเหมาะกับงาน แต่ตอนนี้ Microsoft สร้าง PowerShell Desire State Configuration (DSC) ขึ้นมาเพื่อสร้างเป็นมาตรฐาน ทำให้ใช้ PowerShell จัดการ Configuration Management ได้ โดยเป็นได้ทั้งการเขียนเพื่อใช้เองหรือเรียกจาก พวกเครื่องมาที่ซื้อมาก็ไดั

PowerShell – Imperative vs. Declarative และ Idempotent (ไอ-เด็ม-โพ-เทน)

เราจะใช้ PowerShell เพื่อทำหน้าที่ Configuration Management หากพูดถึง PowerShell ที่เป็น Script มันมีรูปแบบที่เรียกว่า Imperative หมายถึง หากอยากทำงานอะไรก็ต้องเขียนขั้นตอนทุกอย่างเอง ตัวอย่าง เมื่อเราต้องดูแล Print Server มันเป็น Windows Service ชื่อ Spooler ในตัวอย่างเป็นรูปด้านซ้ายเป็นแบบ Script (imperative) และด้านขวาเป็นแบบ DSC (declarative)

img-1

ด้านซ้ายต้องเขียนเงื่อนไขไปดูว่า Service Start (บรรทัดที่ 1) หรือไม่ ถ้าไม่ Start ก็สั่ง Start (บรรทัดที่ 8) แต่ด้านขวา รูปแบบของ DSC ซึ่งเป็นแบบ Declarative ทางด้านขวาเป็นการสั่งการว่าให้ดู Service Name = Spooler ต้องมีสถานะเป็น Running แบบนี้ไม่ต้องเขียนเงื่อนไข ทำแค่กำหนดค่าที่ต้องการให้เป็นลงไป เราเรียกแบบนี้ว่า Declarative ยังมีอีกคำอันที่จับเรื่อง DSC แล้วต้องรู้จักคือ Idempotent หรือ ทำกี่ครั้งก็เหมือนเดิม หมายถึง การใช้ Configuration Management เราต้องการให้เครื่องอยู่ในสถานะที่เรากำหนดไว้ ดังนั้น เมื่อ Run script DSC แม้ว่าจะ Run กี่ครั้งก็ตาม มันก็ทำให้ Configuration เหมือนที่กำหนดไว้ทุกครั้ง

เริ่ม PowerShell DSC แรกกันเลย

การเขียน PowerShell DSC มี format และลำดับดังนี้

1. สร้าง Configuration ขึ้นมาตามตัวอย่างในภาพ
A. ใช้คำสั่งว่า Configuration แล้วตามด้วยชื่อที่ตั้งขึ้นมาเอง
B. สามารถส่งค่า Parameter ได้ เช่น ที่ใช้บ่อยก็เป็นชื่อ Computer
C. หัวใจของ DSC อันหนึ่งคือ Resource ส่วนนี้ใช้ import resource file
D. ระบุ  node โดยใส่ชื่อ Computer name ที่ต้องการ config ลง และลงมือเขียนสิ่งที่เราต้องการทำ ในภาพเป็นการกำหนดให้ Service ที่ชื่อ Spooler ต้องอยู่ในสถานะ RunningCreate-config

2. Compile ได้ผลลัพธ์เป็น mof file (Windows Management Object file) ด้วยการเรียกชื่อ Configuration ตามด้วย Parameter คือ NodeName จะได้ Output เป็นไฟล์อยู่ใน folder mof-folder
3. สั่ง Run configuration โดยระบุแค่ Path ในตัวอย่างใส่ -Verbose -Wait เพื่อให้แสดง Message ตอนที่มัน Run ด้วย ด้านล่างเป็นผลลัพธ์ โดยก่อนจะ Run ได้ stop service spooler ไว้ จะเป็นว่าช่วงแรกมันจะ Test เพื่อดูว่าต้องทำอะไร ซึ่งมันพบว่า Service stop มันจึงสั่ง Start ในส่วน Setimg-2

Script ตัวอย่าง

Configuration ManagePrintServer
{
param (
[string[]]$NodeName = 'localhost'
)
Import-DscResource –ModuleName 'PSDesiredStateConfiguration'
Node $NodeName
{
Service StartSpooler
{
Name = "spooler"
State = "running"
Ensure = "Present"
}
}
}
ManagePrintServer -NodeName localhost -OutputPath C:\mof
Start-DscConfiguration -Path C:\mof -Verbose -wait
view raw set-spooler.ps1 hosted with ❤ by GitHub

สรุป

เราได้ทำความเข้าใจ Configuration Management ว่ามันไม่ได้เป็นเพียง Script ที่ใช้ Run งานทั่วไป แต่มันเป็นการสอนเครื่องว่า เครื่องนี้เราต้องการให้มี Configuration เป็นแบบนี้ แล้วมันจะช่วย Set ให้เป็นแบบนี้เสมอ ในตอนต่อไปเราจะหัดเขียน Configuration เรียนรู้เรื่อง Local Configuration Manager และ Resource

 

Reference

https://www.pluralsight.com/blog/software-development/powershell-dsc-pull-server

https://pmstudycircle.com/2012/01/configuration-management-vs-change-management/

Remote Admin – Nano Server ตอนที่ 1 PowerShell Remote อย่างง่าย

ใน ตอนที่ 1 ได้ทำความรู้จักว่า Nano Server นอกจากไม่มีหน้าจอ GUI และไม่มี Command Windows หรือ PowerShell ให้เราเข้าไปทำงาน จากนี้ไปเราจะได้รู้ว่า Windows มี Remote Access ที่เป็น Command-Line Console ที่ช่วยให้การทำงานแบบ Remote เป็นเรื่องง่ายๆ เราจะศึกษาการสั่งงาน Windows และ Nano Server ด้วย Windows Remote Management และ PowerShell Remoting ขอใช้ตัวอย่างทั้งหมดเป็น PowerShell

WS-Management

เมื่อก่อนเวลาที่ Administrator ของ Windows Server ต้องทำงานกับ Server ผ่าน Network หากไม่นับ Remote Desktop ยังมีวิธีเรียกผ่าน WMI ที่ใช้ Protocol Remote Procedure Call (RPC) ที่ต้องเปิด Firewall  Port TCP/135 และอีกเปิดอีกหลาย Port ในเวลาต่อมา เมื่อ Microsoft ได้เข้าร่วมกับ Distributed Management Task Force (DMTF) ในยุคที่ Web ได้รับความนิยม ได้เกิด Web Service – Management (WS-Management) ที่เป็น Open standard โดยใช้ Protocol HTTP SOAP ใน Version ของ Microsoft เรียกชื่อว่า Windows Remote Management (WinRM) การใช้งานต้องมี Tool ที่ใช้บ่อยๆ มี 2 ตัวคือ WinRS และ PowerShell Remote ในภาพด้านล่างแสดงให้เห็นการเรียกใช้งาน WS-Management ทำงานเป็นด้าน Client และ Server ที่จะทดลองทำกัน

WinRM จะมีฝั่ง Client ในภาพด้านซ้ายจะเป็น Windows version Desktop หรือ Server ก็ได้ WinRM จะมี Configuration ของมันเอง ในส่วนของ Server ก็เหมือนกัน Configuration นี้ แบ่งเป็น Client, Service (หรือ Server), Listener และอื่นๆ ด้าน Server ยังมี End Point ที่สามารถเขียน Application ไปเกาะไว้กับ WinRM ในที่นี้จะเป็นตัว PowerShell Remote

ใช้งาน PowerShell Remoting ครั้งแรก

ในขั้นตอนและ Script ตัวอย่างใช้ Server IP 192.168.1.113 เมื่อนำไปทดลองต้องเปลี่ยนเป็น IP ของ Server ที่ใช้งานได้จริงด้วย

  1. ขั้นตอนแรก เป็นการ Enable ให้ Windows Server เปิดการใช้งาน PowerShell Remote ได้ เริ่มจาก Logon ไปที่ Server เพื่อ Configure WinRM โดยให้เปิด PowerShell ด้วย runas administrator แล้ว run Enable-PSRemoting –force


คำสั่งด้านบน Windows ได้ทำงานไป 4 ขั้นตอนคือ

  • กำหนดให้ Service – Windows Remote Management เป็น auto start
  • Register ให้ PowerShell เป็น endpoint ไว้กับ WinRM Listener เมื่อมี Client connect เข้ามา WinRMจะได้ส่ง Request ไปได้ถูกตัว เช่น เมื่อ Client ที่เป็น PowerShell เรียกเข้ามาก็จะส่งต่อให้ PowerShell Remote รับงานไปทำ เป็นต้น
  • สร้าง policy ใน Windows Firewall ให้ allow port tcp 5985 และ tcp 5986 สำหรับ HTTP และ HTTPS ตามลำดับ
  • กำหนด Permission การใช้งาน Remote

2. การ Configure เครื่อง Client ที่เราใช้ Remote ไปทำงานบน Server ในนี้เป็นการทดสอบกับ Workgroup  ขั้นตอนดังนี้คือ

  • ด้าน Client จะต้องดูว่า Service – Windows Remote Management (WS-Management) อยู่ใน Status Running จึงจะใช้งานได้
  • ลงทะเบียน Server ที่เราต้องการ Remote ไปทำงานไว้ในค่า TrustedHosts ด้วยคำสั่ง set-Item WSMan:\localhost\Client\TrustedHosts -value  ถ้ามีหลาย Server ใช้เครื่องหมาย “,” คั่นไว้ (ส่วนนี้ Server 1 เครื่อง ก็ add ครั้งเดียวพอ)ถ้าต้องการอ่านค่ามาดูใช้คำสั่ง get-Item WSMan:\localhost\Client\TrustedHosts 

3. เปิด Remote ไปทำงาน

  • เตรียม User ID และ Password สำหรับ Logon เข้า Server ด้วยคำสั่ง get-Credential
  • สร้าง Remote Session ด้วยคำสั่ง  new-PSSession โดยเราเก็บค่า Session ไว้ในตัวแปร
  • เข้า Remote Session ด้วยคำสั่ง enter-PSSession สังเกตุว่า Prompt ในภาพด้านล่างเปลี่ยนไป มันแสดงเป็น IP Address ของเครื่อง Remote แทน
  • เมื่ออยากจะกลับมาที่เครื่อง Client ก็ใช้คำสั่ง exit

4. เราสามารถ Remote ไปเป็น Command Prompt ก็ได้ ตัวอย่างคำสั่ง Remote ไปใช้คำสั่ง cmd.exe บน remote server

c:\winrs -r:192.168.1.113 -u:administrator -p:Passw0rd cmd.exe

เมื่อได้ทำตามตัวอย่างคงพอเห็นภาพว่าการ Remote ไม่ยาก ใช้ได้กับ Windows Server และ Nano Server ในครั้งต่อไปจะกลับไปสร้าง Nano Server มาใช้งานต่อไป

รวมภาพตัวอย่างการทำงานและ PowerShell Script

ด้านล่างเป็น Script ที่ได้ทดสอบฝั่ง Client ตอนทำต้อง runas Administrator ด้วย

Start-Service WinRM
$myTrustWinRM = get-Item WSMan:\localhost\Client\TrustedHosts
if($myTrustWinRM.Value.Length -eq 0)
{
$myNewTrust = "192.168.1.113"
Write-Host "new trustedhosts"
}
else
{
$myTargetServerIP = "192.168.1.113"
$myNewTrust = ($myTrustWinRM).Value + ", $myTargetServerIP"
Write-Host "append trustedhosts"
}
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $myNewTrust
$MyCred = Get-Credential "administrator"
$nanoPSHost = New-PSSession -ComputerName $myNewTrust -Credential $MyCred
Enter-PSSession -Id ($nanoPSHost).id
view raw addtrustedhost.ps1 hosted with ❤ by GitHub

client_connect_2

client_connect_3

client_connect_4

client_connect_5

client_connect_6