Hi there, we’re currently investigating ways we could use Juju to manage some internal systems, and I’m wondering whether there is an easy way to stand up what would effectively be a “private charm store” within an organisation.
The ideal would be some small piece of software that could publish and serve charms on an internal network, so that users could say e.g. juju deploy internal:some-app (where “internal” could be the team or company name), and that prefix would tell Juju to fetch the charm from some preconfigured private host just like “cs:” tells it to fetch from the Charm Store.
Or, maybe the server software isn’t necessary, and the prefix could simply point to a well-known layout of files in static hosting somewhere. But the idea would be the same: some way to access and deploy charms “internally” without pushing to the charm store or needing to fetch and deploy from a local copy of the charm using the “offline deploy” method. Does a mechanism for this already exist?
Excellent question… @rick_h might be able to provide an authoritative answer to this.
My understanding is that current recommendation is to hold private charms in code repositories. The end-user workflow is to issue git clone and deploy them as local charms. I believe supporting private charm stores was the intention behind the charm store prefixes. But, I don’t think that implementing support for other prefixes was as easy as originally envisaged.
@maaudet uses private charms extensively. Perhaps he can offer some guidance?
Yes, we’re in a bit of a transition phase over the next 6-8 months as we take the lessons we’ve learned in the snap store and bring them to the world of charms. As we work to migrate to the new CharmHub we’ll be able to leverage the on prem ideas that snaps have. This could be a private snap proxy or other solution. If you’re interested I’d like to make sure we connect you with our folks about your needs and use cases as we put together the tools to support that as we migrate away from the old cs: charmstore setup and move to the more modern CharmHub architecture.
As a follow-up, it is possible to configure a controller to point to a custom charm store. This would involve self-hosting the charm store code (which is open source).
Right now I use the charm store and only assign read rights to a specific group in launchpad, and write rights to another specific group in launchpad for specific releases.
Whenever I use a charm, it just opens a browser window and asks me to login.
I’m not 100% sure it’s the best method, but it’s been working so far.
Thanks for the responses everyone. It’s good to know the charm store is available, although if ES is a hard dependency (is it?) that might be too much overhead for an internal system when we can probably make something quick and dirty work. One idea that was shared was writing a wrapper that allows one to run juju deploy git://foo/bar.git, which may be enough. Like @erik-lonroth says, if the result of the work @rick_h is discussing can be stood up without too much trouble (or even juju deployed?) we will probably give that a try as well.
That is a super cool construct. @rick_h wouldn’t that be something the client should/could support per default?
@evhan you might want to explore juju plug-ins and if you manage to get something rolling, please let me know as I’m looking for such a thing also and will happily contribute.
This is something that’s come up in the past but we’ve avoided. In order to do this feature correctly we’d need to support it in the case of deploy, upgrade-charm, and bundle deployments. The ways charms are pulled are from the controller and so access to git repos means managing that access from the controller which means dealing with the ssh keys or user/passwords. It also means bundles aren’t as reusable. if the charms are local then getting them is on the user vs Juju. If they need special proxies, accounts on gitlab, etc, the user is in a position to handle all that.
It comes down to that the thought was that the ways it can not work was not worth avoiding the user doing the git clone locally and then then charm is uploaded from the client to the controller.
Totally, you could imagine writing a script that you could just name juju-gitdeploy and have it accept the git repo, do the clone into /tmp or something, and then run a juju deploy into /tmp/XXXX. It would need to do the parsing of the git repo to tell what the directory that the clone went into was and such.
As long as the script is executable and in your PATH then juju will look for it when you type
