[DO NOT MERGE] Naive push + pull implementation

[radu-matei]

This PR adds push and pull implementation for CNAB bundles using coras (which is using a combination of deislabs/oras and pivotal/image-relocation to push all referenced images to a new OCI repository, then store the actual bundle file).

This is not intended for mainstream use, but to explore how Porter would interact with OCI registries (currently regardless of actual implementation), and this PR adds porter bundle push [input bundle file] [target registry] and porter bundle pull [output bundle file] [target registry].

This has been tested with Azure Container Registries and the upstream registry image, and the easiest way to test is to start a container with that image:

$ docker run -it --rm -p 5000:5000 registry

Then, create a new project / use an existing one, update the invocation image field from porter.yaml to a registry with push access, in order to build the image (it doesn't have to be the same registry you intent to actually push the bundle, as long as you can build the bundle using Porter). For simplicity, you can use the same instance of registry started earlier:

invocationImage: localhost:5000/porter-azure-wordpress-invocation:latest

Then, build and push the bundle:

$ porter build
[...]

$ porter bundle push bundle.json localhost:5000/porter-push-test:v1
2019/04/30 06:50:03 mounted blob: sha256:ca01e42d7510bb1792e37a0054b3484c645eb8d21828bacfa080a9f4e3fbb6f3
2019/04/30 06:50:03 mounted blob: sha256:f7622d01fcec094e83b77da6c6ff92976533731b0c39146d17329ff007171176
2019/04/30 06:50:03 mounted blob: sha256:e79bb959ec00faf01da52437df4fad4537ec669f60455a38ad583ec2b8f00498
2019/04/30 06:50:03 mounted blob: sha256:9d8a30a3b7748ce21c87f7a5d06123b639d4064aa5dd2f195bdc46b90e842319
2019/04/30 06:50:03 mounted blob: sha256:16b771448fe3ac7b78d806e7ad444734967a7baabe21a2404825d319fa23a817
2019/04/30 06:50:03 mounted blob: sha256:e1efeba61359e5ff4c07f2e6391369acb292a9595592157e4f33a38c55d9807d
2019/04/30 06:50:03 pushed blob: sha256:b393a8c377bd1a02b4ab495e95df8406b65ea15f4f3f95d876301fc370f8ffbd
2019/04/30 06:50:03 localhost:5000/porter-push-test:localhost-5000-porter-azure-wordpress-invocation-sha256-e30833bef760b25300c69054b2d7e3c94b39f42d18019b5cfe04e4df1432b007: digest: sha256:e30833bef760b25300c69054b2d7e3c94b39f42d18019b5cfe04e4df1432b007 size: 1580
WARN[0000] encountered unknown type application/vnd.cnab.bundle.thin.v1-wd+json; children may not be fetched 
WARN[0000] reference for unknown type: application/vnd.cnab.bundle.thin.v1-wd+json  digest="sha256:4a1c368dc18277cde708b8c07be4a32daff2f579a5186873a7ec41795957eb6f" mediatype=application/vnd.cnab.bundle.thin.v1-wd+json size=1303

This relocates all container images referenced in the bundle to the target repository, then uploads the updated bundle file (with the new image references) to the registry, using oras.

At this point, you can pull the bundle:

$ porter bundle pull bundle-pulled.json localhost:5000/porter-push-test:v1
WARN[0000] reference for unknown type: application/vnd.cnab.bundle.thin.v1-wd+json  digest="sha256:4a1c368dc18277cde708b8c07be4a32daff2f579a5186873a7ec41795957eb6f" mediatype=application/vnd.cnab.bundle.thin.v1-wd+json size=1303
WARN[0000] unknown type: application/vnd.oci.image.config.v1+json 
WARN[0000] encountered unknown type application/vnd.cnab.bundle.thin.v1-wd+json; children may not be fetched

Note that the current UX around these operations is extremely rough, and a major reason for opening this PR so early is to get some feedback around how this should be handled, directly integrated with porter install, or any other ideas that make sense.

Thanks!

cc @carolynvs @jeremyrickard

[carolynvs]

Sorry to take so long to make time to look at this!

I think understand the user scenario for push. They want to share a bundle that they've created with other people. I've been working on improving porter's commands that abstract over CNAB and have come up with an issue to explain the whys (See #320) but to make push match, the command would look like this and is outlined further in #254:

porter push [--file porter.yaml] [--tag registry/img:tag] [--cnab-file bundle.json]

So for most people they'll run it from a porter bundle directory and can just run porter push without any arguments or flags.

---

I have a bit more questions about how we want pull to work, and if it should be pull at all or a more specialized command(s). I think there are a few different use cases for pull:

• I want to get the bundle just so that I can install it. I don't care if it's a porter bundle, I don't want to edit it, or have files hanging around.
• I want to get a porter-authored bundle in a state such that I can edit it with porter again.
• I want to get the files from a non-porter bundle down so that I can look at them.

I'm going to stop there so that we can discuss further. 😀

[jeremyrickard]

@radu-matei should we close this in favor of a cnab-to-oci based implementation, similar to duffle?

[radu-matei]

Yes, as we plan for cnab-to-oci to be the reference implementation for storing bundles in OCI registries, we can close this.

Thanks!