This topic contains 4 replies, has 4 voices, and was last updated by
March 15, 2018 at 5:28 pm #96074ParticipantPoints: 0Rank: Member
- I would like a GUI Report server because ... why wouldn't you?
- I would like it to store my configurations on my existing on-prem GitLab instance.
- I would like it to just use CI to build, test, and deploy my configurations and resources. Currently this is easy by just allowing the CI to drop the configs in a Share in the Pull Server's Configuration and Module folders. Not sure about the other two projects.
- I would like it to securely suck in my existing infrastructure without having to touch each system; there's a lot of them. Current plan is to just use GPO for a StartUp Script that ensures DSC LCM is configured properly.
- I would like to stay away from AA DSC; this is already well discussed.
Thanks for your time and feedback. I'm just interested in working in a direction that makes sense to the veterans.
March 15, 2018 at 6:23 pm #96080KeymasterPoints: 1,811Rank: Community Hero
You could program Tug to do anything of those things. I'd probably start there.
March 15, 2018 at 6:47 pm #96086ParticipantPoints: 0Rank: Member
I'm one of the Traek maintainers and while we are excited about the possibilities of where that project will take us, if you want something in the near term that meets your requirements I would go with Tug.
If there comes a point in the future where you move towards a cloud solution I hope you will give AADSC another look.
March 16, 2018 at 4:38 pm #96212ParticipantPoints: 0Rank: Member
I like the idea of using AA DSC, but we don't like uncertainty in the billing scheme. When you have to work within budgets, you don't want a surprise if a script runs rampid and consumes a lot of resources because of a bug. Especially when it's not your fault. Yes, you can set up alerts and notifications, but all that takes time to hone in and will likely result in a few surprises along the way.
Tug looks like it is written in C#. I'm not a C# developer because ... well ... I don't hate myself enough to fight with it everyday. 😉 So, programming it to do any of those things is not really an option for me.
I like the direction TRÆK is going, but don't have time to really wait until it becomes stable. I've coded in NodeJS before, but I'm definitely not a NodeJS developer. I'll look into assisting with the development of it, but I need to focus on getting this going for now.
March 17, 2018 at 1:40 pm #96260ParticipantPoints: 95Rank: Member
Just to clarify things a bit:
– While TUG's implementation of the MS-DSCPM protocol is written in C#, the provider model allows you to implement the 'processing' (handlers) in C#, PowerShell, or other tech with minimal C#. That does not mean you won't have to write any C# for a production-ready solution that fits your need, but it would hopefully be minimal. (And iirc there's an example provider for PS)
– The AA DSC issue you mention is not a Pull server bug but a WMF v5.0 LCM bug. That bug in particular had very obvious consequences ($$$) because it was using metered cloud resources. In an on-prem infrastructure, the cost is hidden but not inexistent (i.e. over-provision, reduced vm density...). So you'll need monitoring, alerts and notification anyway. LCM in v5.1 I think has problems such as not cleaning up the status despite setting the 'StatusRetentionTimeInDays' settings (so you may be using loads of GBs over time).
– An element of your approach is key, and should be emphasised: "I need to focus on getting this going for now". This is very true and before you can benefit of all the bells and whistles, you need to start transforming somewhere. There's much more to it than just installing a tool, and the design of a pipeline that works for your business context takes more time and effort than the technology part. In the current transformation effort I'm working on, we're actually going a long way with a simple SMB-based pull server (we already had a way to pull DSC Configuration Status and logs for reporting).
We'll certainly look at investing into TUG when it's right for us, as that's probably the most flexible implementation that suits our context.
As a first step to get started with a PULL server I'd recommend the following process:
– If you've got a very simple infrastructure, and you'd rather not deal with adding a web server to try it out, consider a SMB pull server (but you don't get the Report server and you need to use ConfigurationID)
– if SMB does not cut it, start with the default Pull Server or the AA DSC one. Keep an eye on their limitations and experiment (i.e. SQL backend) but don't try to optimise prematurely.
– I've heard that Ben Gelens is working on an interesting proof of concept for his PSConfEU talk: "The DSC Pull Server is dead, long live the DSC Pull Server – by Ben Gelens". Watch this space, and bear in mind it's always changing.
– Longer term, as you have a better understanding of your needs, you might want to invest in a more custom solution, based on TUG, TRAEK or other solution...
Also remember that DSC is not a fully-fledged Solution but a platform. AADSC is MSFT's solution, and the main area of investment in the Configuration Management Solution space, with a strong opinion on Multi-Cloud SaaS Solution. Other CM solutions are Chef, Puppet, Ansible, Salt and so on... They can all leverage the DSC platform, and each their own characteristics, and are all relevant to some contexts, don't discard them too early, and experiment if you can (Ben has some nice resources here)!
Good luck, and I hope you'll share your journey!
The topic ‘Tug or TRÆK?’ is closed to new replies.