munki VS Capistrano

The Demo setup is super simple to follow. When I migrated our Mac server to a new machine, I moved the repo folder and just followed the guide. Took me an afternoon, so imagine a few days tops for someone who has never used it before. We also have autopkgr feeding app updates into Munki each week, but if ABM and Jamf is close, you could just do manual imports of what you want into Munki.

Munki client will try 5 different ways to get the manifest, https://github.com/munki/munki/wiki/Default-Manifest-Resolution

From what I remember, munki doesn’t use the built in python, instead it bundles it’s own. What version of munki are you running? If it’s less than 5.5 consider upgrading munki before moving forward. https://github.com/munki/munki/releases/tag/v5.5.0 Bumped the Python version to 3.9.5 (from 3.9.4)

You can create a nopkg. https://github.com/munki/munki/wiki/nopkgs

You can try https://github.com/munki/munki We used to use it quite a bit.

> sudo managedsoftwareupdate Managed Software Update Tool Copyright 2010-2021 The Munki Project https://github.com/munki/munki Starting... Performing preflight tasks... WARNING: Skipping execution of preflight due to insecure file permissions. Error: /usr/local/munki/preflight is not secure! owner does not match munki process! Checking for available updates... Unable to register this device: internalError ERROR: Unexpected error in updatecheck: # [TRUNCATED STACK TRACE] File "/usr/local/munki/middleware_simplemdm.py", line 15, in process_request_options raise Exception("Device is unenrolled from SimpleMDM") Exception: Device is unenrolled from SimpleMDM

Munki (Managed Software Center, pointed at https repository) https://www.munki.org/munki/

To get around this there are two options. 1. Use the DEP package - https://github.com/munki/munki/releases/download/v5.6.2/munkitools_DEP-5.6.2.4398.pkg. Any of the DEP packages in the releases page should work but might as well grab the latest. I can’t find the link at the moment but I believe this just loads the daemons on the postinstall script.

- Integrate automation deployment: [capistrano](https://github.com/capistrano/capistrano)

Integrate automation deployment: capistrano

The deployment process generally includes making the new version available, directing traffic from the old to the new version, and stopping the old versions. Capistrano has been doing this since 2006. However, what makes Kubernetes deployments better is the minimum number of pods required, and its rollout strategy minimizes or eliminates downtime. For example, a rolling update strategy can ensure new pods gradually replace old pods with configs like maxSurge and maxUnavailable. Because this is done in a declarative way, as a user or operator, you only need to ask Kubernetes to apply a given deployment and Kubernetes does the rest. Next up is the Kubernetes config map.

[1] https://github.com/capistrano/capistrano

Capistrano

What I had considered was writing a deployment script where upon successful build in a separate folder, it'd swap out the deployed folder, similar to how Capistrano works. It has a "current" folder and it'll build in a temporary folder and then replace the symlink to a newer build.

capistrano with plugins for deployment

deployer is a deployment tool written in PHP. It comes with "Zero Downtime Deployments" out of the box and can be extended by writing simple PHP code. (capistrano would be the equivalent in the Ruby world).

Capistrano, if you like Ruby.