Posts Tagged ‘dsc’
So, the question is – how to deploy and maintain farm of Microsoft SQL Servers? With different domains, install sources, roles, features. Should we create unattended installers for every single instance?
No, we shouldn’t.
We should use Powershell DSC – https://github.com/PowerShell/xSQLServer
With Foreman/Puppet and win_manage, we have something like:
The simplest way:
instance1: dsc_instancename: MSSQLSERVER dsc_sourcepath: "\\our.server.com\ourshare" dsc_sourcecredential: user: anonymous password: anonymous dsc_setupcredential: user: DOMAIN\someuser password: somepassword
Or, more sophisticated:
instance1: dsc_instancename: MSSQLSERVER dsc_sourcepath: "\\our.server.com\ourshare" dsc_sourcecredential: user: anonymous password: anonymous dsc_setupcredential: user: DOMAIN\someuser password: somepassword dsc_features: SQLENGINE dsc_forcereboot: true dsc_agtsvcaccount: user: DOMAIN\scvaccount password: somepassword dsc_sqlsvcaccount: user: DOMAIN\sqlaccount password: somepassword dsc_sqlcollation: SQL_Latin1_General_CP1_CI_AS dsc_sqlsysadminaccounts: - DOMAIN\someadmin - DOMAIN\someotheradmin dsc_securitymode: SQL dsc_sapwd: user: sa password: paaaswordisverysecure dsc_sqluserdbdir: D:\MSSQL\Data dsc_sqluserdblogdir: E:\MSSQL\Data dsc_browsersvcstartuptype: Disabled
Whole install from local source takes aprox. 400 seconds (with other OS related settings) to finish.
Administrator: dsc_username: Administrator dsc_disabled: false dsc_password: user: NT AUTHORITY\\SYSTEM password: P@$$w0rd
Nobody likes Windows Updates even Microsoft itself. But sometimes one should make sure, you have perks your system needs. But, we co do it old fashion way: check, update, reboot, repeat. Boring, and completly not in a way DevOps do.
Again, Win_manage to the rescue.
First we make sure what we want to do:
dsc_xwindowsupdateagent_schedule first: dsc_dayofweek: sunday dsc_afterhour: 11 dsc_usenotify: true
dsc_xwindowsupdateagent security: dsc_updatenow: 'true' dsc_category: security important: dsc_updatenow: 'true' dsc_category: important optional: dsc_updatenow: 'true' dsc_category: optional
dsc_reboot dsc_reboot: message: Machine requested a reboot when: pending
But what does it do? First, we should prepare update schedule: let’s say, we can start auto-updates on Sunday, after 11 AM (remember 11 AM = 11:00, and 11:00 PM=23:00)
Second: we want to install 3 type of updates: security, important and optional.
Third: we want to auto-reboot our machine (dsc_reboot) and notify us about pending updates count BEFORE and AFTER update patch set (dsc_usenotify: true)
So, we can switch from:
in a time needed to get some music 🙂
During last few weeks I was able to push and heavy test puppet-dsc code in a lots of environments and setups.
We had sysprepped Windows Server 2012 R2 images (different versions, builds and setups), a lots of Windows 10 Professional Workstations (Original, 1511, 1607 builds), few Windows 8.1 Pro – really great statistic sample.
As for now:
- Windows Server 2012 and Windows 2012 R2 – fully supported
- Windows 8.1/10 (original)/10 (1511) – fully supported
- Windows Server 2016/Windows 10 (1607) – unsupported due to parsing bug in Powershell 5.1 – Work in progress
- Windows 7/8 – not tested
- Windows 2008 R2 – not tested
- Chocolatey – with features and sources support (adding, removing, modyfing)
More code is coming, but this fine set allows you to deploy and manage a lots of types of servers and workstations.
Few weeks ago I started a little project – complete Puppet module called: win_manage.
My goal was to manage Windows based machines almost as easy as Linux servers, as little code inside as possible (you know, I am not a developer in any kind). And when I was thinking: KISS is no more possible with this project, I’ve found Puppet Powershell DSC module: https://github.com/puppetlabs/puppetlabs-dsc
Adding another resources it is just a breeze, the biggest part of work was to test almost every setting provided by Microsoft, to have working examples in day-to-day SysAdmin/DevOP job.
And yes, I know – we have plenty of things like this, sold with different price plans, different support plans and so on. But if you cannot afford pricey tools like Puppet Enterprise or System Center 2012 R2 in your environment, this little project comes to help you 🙂
First things first – why?
- We have excellent granularity using Puppet and Foreman architecture without complicated AD GPO with filters.
- Nested groups/copying groups helps so much in creating cloned environment
- It doesn’t matter what provider do you use: physical, virtual, VMWare,Hyper-V, Azure – it just works.
- With additional modules like Chocolatey and our private sources (and private CDNs) the story is completed – no more AD MSI voodoo stuff. Software deployment and maintenance just got really better.
- One is is to deploy, second thing is to maintain and manage. Securing running services or making permanent changes in your environment is as much important as just deploy them.
- No more ‚just another script’ approach.
- Everyone can afford simple machine with simple YAML examples 😉
So my work in progress looks just like this:
We love YAML driven configuration: setting users, rules, applications is just as easy as writing very light code:
tightvncpassword: dsc_key: HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server dsc_valuename: Password dsc_valuedata: af af af af af af af af dsc_valuetype: binary tightvncpasswordcontrol: dsc_key: HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server dsc_valuename: ControlPassword dsc_valuedata: af af af af af af af af dsc_valuetype: binary
Web-Server: dsc_ensure: present dsc_name: Web-Server dsc_includeallsubfeature: true DSC-Service: dsc_ensure: present dsc_name: DSC-Service
Installing and maintaining latest version of packages:
chocolatey: ensure: latest powershell: ensure: latest doublecmd: ensure: latest conemu: ensure: latest
So, what to do next? I will be adding additional DSC Resources to module and hopefully will be able to make it public. Stay tuned and keep your fingers crossed 😉