ProGet configuration as code (IaC)?

[mikael]

Hi,

We are currently evaluating ProGet for use in our organization, and overall it looks like a very strong product. One of our core requirements, however, is infrastructure-as-code (IaC) and fully reproducible configuration.

For most of our internal tooling (e.g. Grafana, Vault, Artifactory), we manage configuration declaratively using Terraform and Crossplane providers, and aim for a setup where the UI is largely read-only for users, with configuration changes flowing through version-controlled code instead.

I wasn’t able to find an official or community Terraform provider for ProGet, is that correct, or am I missing something?

I see that ProGet exposes a REST API. Does this API cover all configuration aspects (feeds, permissions, retention rules, connectors, etc.), and is it considered stable and supported for full lifecycle management? In other words, could the REST API reasonably serve as the foundation for a complete IaC workflow?

I also noticed the CLI utility, which looks useful, but from our perspective it would require a fair amount of scripting and custom state management to function as an IaC alternative.

What we are ideally looking for is:

• A declarative configuration model
• State management (Terraform / Crossplane style)
• Minimal configuration drift between environments
• The ability to treat the ProGet UI as mostly read-only

Does ProGet currently support (or have plans to support) this kind of workflow, either directly or via recommended tooling?

Thanks in advance, happy to clarify our use case further if helpful.

[atripp]

Hi @mikael ,

We have no plans for this and honestly, I wouldn't recommend setting up a tool like ProGet in this manner.

Outside of some very specialized use cases (like setting up labs for testing, or nodes in a ProGet Enterprise Edge Computing Edition) there are no benefits. Only headaches.

It might sound fine on paper, but every company that has set it up this way has regretted it. And you will to. The reasons they want "fully reproducible configuration" is usually:

• so we can store configuration in versioned code
• so we can easily replicate it in a testing environment
• so we can easily migrate/move to a new server

Those seem nice, but it totally fails in practice.

First, you can't "rollback" most configuration. Say you fat-finger a configuration file and delete half your feeds. There go all your packages. And when you realize you've got gigabytes/terabytes of content to deal with, plus all the metadata in storage, this is a huge headache.

The configuration you can make idempotent (say, permissions/users) is so much more a pain to work with than a UI. Again, more error prone you lose all the benefits of visual cues, input verification, etc. You fat-finger the wrong setting, and you get some obscure error instead of a helpful red box next to the text box.

The regret comes in realizing they've created a buggier environment that isn't properly tested, and is somehow less "portable" than an ordinary installation. A year later, when the new team comes in, they usually have to figure out how to "undo" it -- and you can probably guess why we need to get involved to untangle the mess.

Thank,
Alana

[davidroberts63]

As an existing customer, we haven't reached the point of considering doing IaC with ProGet ... yet. However, since it was brought up I do agree it would be helpful. Eventually we will likely make use of the existing APIs that are available. Such as the security apis, feed apis, and asset apis. Hopefully those are helpful to you @mikael.

The comment made about trying to rollback a feed that had been deleted and the original artifacts not being restored is true. However, that point is mostly irrelevant because the same exact situation occurs if one deletes the feed from the UI. One benefit of IaC in a situation like that is one of prevention. By utilizing IaC, we can engage an additional layer of review in configuration changes to tools such as ProGet. A review that is performed outside of ProGet at a textual level and informative of what is changing. While trusted administrators would be ultimately responsible, we are still human and make mistakes. IaC is a helper in reducing those mistakes and helpful in sharing knowledge of how things are configured.

To the point of IaC changes of permissions/users being more painful than the UI, that is entirely dependent upon the tool involved. We almost (again, human and making improvements) exclusively use IaC to apply permissions in our cloud resources. It works wonderfully and gives us clear indication of the config. Another benefit is we can give others outside of the admin side the ability to recommend actual changes to the permissions if need be. Responsible administrators can then review and potentially approve it or reject it with reasons. It provides a sense of shared ability within separate but closely operating teams. It also gives them easy, heavily reduced risk, read only access to the configuration.

Additionally, IaC helps from an auditing perspective immensely. The UI can be locked down to only a couple of emergency use administrators. Configuration changes being made soley via IaC gives a clear history, via git commit logs, of who made the change, what the change was and when it was implemented. While this can be done by streaming logs from tools such as ProGet to destinations like Splunk, it is incredibly useful to have that in the git history as well for teams to reference.

Admittedly these benefits are of most use to organizations with specific controls that must be adhered to. Either external regulatory requirements or by internal business security control decisions. Other organizations would not benefit from IaC of this nature.

I recognize and respect that there are no plans to do IaC of ProGet. That's a business and customer driven decision. However, it is hoped this adds positively to any other discussion of IaC configuration of ProGet.

[mikael]

@davidroberts63 is spot on — I completely agree with what you’re saying.

In our current setup, we use Terraform with Artifactory to manage everything as code for the past six years. For teams outside the core infrastructure group, this mainly means defining proxies, repositories, and permissions via pull requests in Git. All changes go through review, and this workflow has worked very well for us in practice.

This kind of Git-based, reviewable configuration is something we would definitely have been interested in if we were to go with ProGet as well.