Reproducibly deploying Snap Store Proxy in a cloud instance, with a persistent volume

Hi everyone,

as I’m being bitten by bug 1710022 and I need IPv6-only clients to be able to install snaps, I’ve looked into deploying the Snap Store Proxy on a dual-stack cloud instance — the idea being that snap clients talk to the proxy via IPv6, and the proxy then talks to api.snapcraft.io via IPv4.

I want to build this in a reproducible cloud instance. I am using OpenStack Nova and Cinder for this purpose, but I guess the same considerations would apply to an Amazon EC2 instance and an EBS volume. What I’d like to be able to do is deploy an instance in such a way that it stores its PostgreSQL data on the persistent volume, so that if my instance dies or fails, I can spin up a new one, attach the volume, and be on my way (without having to re-register the proxy, of course). And in doing so, I’m running into a few road blocks, hence this post. :slight_smile:

The “Installation” documentation gives me a good head start on what I need to do to automate deploying and configuring PostgreSQL, installing snap-store-proxy, and configuring snap-store-proxy to talk to its PostgreSQL backend. I can automate this to make it work reliably both on initial spin-up, and on instance re-creation with attachment of the pre-existing volume.

It gets somewhat murky as I progress to the “Registration” docs, though (apologies, I can’t link to that because Discourse limits new users to two links in a post), specifically when it comes to configuring the proxy with keys. I noticed that sudo snap-proxy generate-keys does the right thing on first install, and it does subsequently fail when running the same command again, noting that the proxy has already been configured with keys. This strikes me as perfectly sensible.

However, if I throw my server away, respin, and attach the pre-existing, pre-populated volume, the sudo snap-proxy generate-keys command again succeeds, which presumably creates a new proxy identity and requires re-registration.

Which means that I should probably instead use the sudo snap-proxy config approach to pre-seed the private and public keys upon initial creation, and subsequent re-creation, of the instance. The documentation, however, says only this about how this command should be used:

Or you can manually generate a key pair, in OpenSSH format (e.g., via ssh-keygen) and configure it explicitly:

sudo snap-proxy config \
   proxy.key.public="<public key data>" \
   proxy.key.private="<private key data>"

… and I’m not exactly sure how that should be interpreted. ssh-keygen creates a multi-line private key by default, so how exactly should the <public key data> be formatted here? Is it an SSH private key that has had all its newlines and the -----BEGIN OPENSSH PRIVATE KEY----- and -----END OPENSSH PRIVATE KEY----- bits removed? Or should ssh-keygen be used with a set of non-default options here?

I’m also trying to understand if there’s any other persistent data that would need to be preserved for my approach to work. My guess is that the entirety of the /var/snap/snap-store-proxy/common directory is a good candidate; is that hunch accurate?

Also, is there anything else I’m missing in my approach?

Thanks in advance for any insight on this one!

Cheers,
Florian