- This topic has 6 replies, 5 voices, and was last updated 3 years, 6 months ago by
May 15, 2017 at 5:41 pm #70690ParticipantTopics: 2Replies: 7Points: 0Rank: Member
This is a slightly amended copy of a post I submitted on the PowerShell Slack channel….
How are people handling package deployments in a DSC world? The package resource pretty much restricts you to using MSIs that behave nicely – but there are always other installers that go against the norm. I am interested to know if package deployment tools like Chocolatey/ProGet/etc. are being made use of and ease the pain (particularly around wrapping up ‘difficult’ installers) at all?
I am happy to write my own custom resources for specific installers that don’t conform to the behaviour desired by the package resource, but a NuGet style repo would be my ideal so I’m looking for input from others before I start building and testing
May 15, 2017 at 5:57 pm #70693ParticipantTopics: 1Replies: 5Points: 25Rank: Member
Chocolatey Business can help you create packages very quickly (with one command in many circumstances) and then you can push them to your own repository. There is a Chocolatey DSC resource as well that can help you push them out. This is what I do.
May 15, 2017 at 9:45 pm #70700ParticipantTopics: 1Replies: 58Points: 221Rank: Participant
I’ve seen some people using DSC to ‘package’ installation via the use of ScriptResource or composite resource, and I strongly recommend against it!
It mixes Package Installation with State Configuration: not only it ‘feels dirty’ given the workarounds required for some .exe or other badly packaged software, it also mixes the purposes of Configuration definition (a policy) an Installation (a mutation mechanism).
The ideal way would be to use DSC to simply say (like with MSIs), “Package yyy should be installed on Node zzz. Then (DependsOn) Configure it like this …”.
Creating your own resource to wrap around it may sound like a good idea, but truth is, you’ll keep re-working on it, as different packages will have different behaviour. Then there’ll be MUCH to do as there’s more to Package Management (like tracking the binaries, dependency management…).
And this is why Chocolatey is so popular (and created in the first place I suppose), by adding a consistent (in interface, not necessarily in package implementation) abstraction layer, on top of the different installer vendors are known to be creative with…
Since PSv5 you can use the PackageManagement/OneGet provider to install some packages, but it’s only Implementing a ‘ProtoType’ provider which does not support the latest improvement from Chocolatey.
Instead, you’d have better coverage, and future proof your setup by using the Chocolatey installer (there’s a free version).
Eventually, I’ve heard that the Chocolatey Provider might get updated if it’s required: https://github.com/chocolatey/chocolatey-oneget
In DSC the story is very much the same, the PackageManagement module exposes DSC resources for Chocolatey feeds (whether internal or hosted on Chocolatey.org), or you could use the cChoco DSC resource, which is being worked on more recently by the Chocolatey crew, as it needed some love since it’s birth from the community.
All of this can be done for free, as there’s free version of Chocolatey (and DSC resource is free as well), and you could consume package from the Chocolatey.org gallery, or setup your own internal feed with an open NuGet feed (ProGet also has a free edition).
That said, at my current gig we currently use Chocolatey as an internal self-hosted feed in ProGet (paid version with AD authentication and some other convenient features like connector filtering): https://inedo.com/proget/pricing/features-by-edition.
My current DSC configs uses the PackageManagement Provider, but we’ll be moving to cChoco DSC resource very soon.
We’re seriously looking at Chocolatey Enterprise (the paid version with bells and whistles), because it should drastically reduce the time overhead of ‘internalizing’ packages (recompile package with the local source of the binary, instead of fetching from the www): https://chocolatey.org/docs/features-automatically-recompile-packages
And it has very interesting features to help packaging some dirty installers with less efforts, plus many other features you may or may not benefit from: https://chocolatey.org/docs/features-create-packages-from-installers and https://chocolatey.org/pricing
So a recap in short, I recommend to:
– Use Chocolatey Packages hosted on a NuGet feed, ProGet is an option
– Package the apps you need using chocolatey (https://github.com/chocolatey/choco/wiki/CreatePackages)
– Use DSC to define what package should be installed where, and to manage post-installation configuration
– Evaluate Choco Enterprise if you think it’d save you time, and pay itself off
Hope that helps 🙂
May 16, 2017 at 12:07 pm #70721ParticipantTopics: 2Replies: 7Points: 0Rank: Member
Thank you both for the responses.
Gael – I definitely agree that creating a custom resource doesn’t scale well. I would have been looking at a custom resource per ‘problem installer’ rather than lumping loads of logic in the one resource, but either way I wouldn’t be happy with that approach for more than a one off. I also agree about ensuring a state is adhered to and maintained rather than just banging in an automated install!
I have booked myself a demo meeting with Chocolatey as the package creation aspect is of great interest to me.
May 16, 2017 at 1:02 pm #70745ParticipantTopics: 1Replies: 23Points: 22Rank: Member
Using Choco or any of those is great but, depending on the level, you need to stand up your own infrastructure which might be competing with already existing (such as SCCM). I know Choco has an integration with SCCM but still not sure in regards connectivity, etc. And then you also have the discussion around what approach to use On-Prem or in the Cloud. Regardless of that, given my current scenario, I’ve been giving out a thought on how to implement this by re-using our currently widely distributed SCCM infrastructure with all the required network rules in place. What I got, so far, is:
* Create a package in SCCM with a known structure. Something like a subfolder called “Source” with the binaries to install and then, similar to Choco, Install.ps1, Uninstall.ps1 and Check.ps1
* Develop my custom PS DSC Resource to using SCCM Client Communication SDK to find the closest Distribution Point (SCCM HTTP Server to serve content) and download it. (I’m planning to publish this to gitHub when I have it)
* Depending on the case, call the right PS1 with provided parameters.
Not sure if this is too far fetch; just adding some more discussion points. Glad to see this discussion going on too.
May 17, 2017 at 2:53 pm #70915ParticipantTopics: 0Replies: 3Points: 2Rank: Member
tl;dr: You can use Chocolatey with SCCM w/out additional infrastructure.
For Leandro, you’ve likely chosen a way forward, and this post may not sway the solution you have set forth (which is totally okay). But I did want to respond for others who may be asking the same questions as you.
Disclaimer: I am the founder of Chocolatey Software, the company behind Chocolatey.
As stated, SCCM and Chocolatey are not competing concerns. If you have SCCM and are using it to distribute software, it can also distribute Chocolatey packages. We have customer and users doing this very thing. It’s likely you missed the documentation on using SCCM distribution points as Chocolatey sources? Sometimes finding things in the documentation can be difficult – our docs are good reference material, we are working on better narrative / walkthrough types of documentation to help with the learning aspect a bit more.
Understand that there is a lot you get with Chocolatey – it’s main purpose and focus has been on package management (complete software management in the business offering) for the last six years, so it is going to excel above any home-grown solution.
If you really evaluate a technology and then decide it doesn’t meet your needs, that feels like a better idea than writing off a known technology before you have educated yourself on it (and I do mean more than a high level).
Chocolatey really does bring a lot to the table, did you know if you were to recreate it you would spend an estimated 10 person years with a cost of over $550,000? Black Duck’s Open Hub estimate based on a salary of $55K/yr, which feels like a very conservative estimate – https://www.openhub.net/p/chocolatey/widgets/project_cocomo. I’m just not sure if I would be comfortable with telling an organization that there is a free, secure, and enterprise-ready option available, but I decided to use the organization’s time and money to make my own solution instead (that would be very uncomfortable conversation for me, I’m not sure about others). Then on top of that, there is a business edition that has even more organizational-focused features (and support) which pays for itself within a few months.
At the end of the day it feels like a better idea to ask yourself “When there are so many organizations that use both SCCM and Chocolatey – Why is it that they would go to that trouble?” People don’t typically choose to do things because they like more work, it’s typically quite the contrary. 🙂
I’m not saying you should give Chocolatey another look, you would need to decide to do that for yourself. I would hope that this has helped persuade you that given the choice between rebuilding an existing technology and using what is available that you might take a closer look next time. HTH
May 17, 2017 at 2:57 pm #70918ParticipantTopics: 0Replies: 3Points: 2Rank: Member
Side note: The custom resource for finding the closest SCCM distribution point sounds really cool! Definitely something I am interested in learning more about when you have it.
- The topic ‘Package management in a DSC world’ is closed to new replies.