Distribute Fabric binaries via Docker images, not HTTP

[jkneubuh]

Fabric binaries are assembled in a CI flow and made available for HTTP download by running the platform-neutral bit.ly installer.

E.g.:

curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.2.5 1.5.2 

There's nothing inherently wrong with using the short-url-installer-script approach to download a targeted build of Fabric, but it can lead to confusion for our users. Also the revision numbering schemes are littered throughout many places in the Fabric repositories, making the release process an onerous and error prone task.

One additional, acute challenge with the reliance on a HTTP/CDN download link for the Fabric binaries is that it is preventing us from migrating some of the CI/CD flows from Azure over to GitHub. Without a recipient web / blob storage from GitHub, there's no viable option for us to publish the outputs of the build pipeline.

Instead of hosting a zip/archive of platform+revision native build outputs on a web server, let's alter the output of CI such that the Fabric binaries and release artifacts are published to the community via Docker Images. With this alternate approach, the "installation script" can be bundled into the image, along with the platform-specific binaries, tagged with a series of labels (+ image metadata, git tags, checksums, etc.), and published to one of any publicly available container registries.

Not only does this approach enable a CI migration to GHA, but it is very amenable to a consistent semantic tag and release strategy. To "run" the installer, the user (or in this case, the bit.ly installation script) merely needs to mount the appropriate volume for the installation target, and do a docker run to unfurl the archive contents into the desired target location.

I.e., publish something like the following images / tags to ghcr.io :

ghcr.io/hyperledger/fabric-installer:<arch>-v2.4
ghcr.io/hyperledger/fabric-installer:<arch>-v2.4.1
ghcr.io/hyperledger/fabric-installer:<arch>-v2.4.1-174-g0e9b9d3 : 
    install.sh 
    fabric-bundle-<arch>.zip 

A different option would be to bundle all of the arch-specific binaries together into a single image. At the expense of some download time, this seems much preferable:

ghcr.io/hyperledger/fabric-installer:latest 
ghcr.io/hyperledger/fabric-installer:v2.4
ghcr.io/hyperledger/fabric-installer:v2.4.1
ghcr.io/hyperledger/fabric-installer:v2.4.1-174-g0e0bd3 : 
    install.sh 
    fabric-bundle-<arch1>.zip 
    fabric-bundle-<arch2>.zip 
    ... 

The Dockerfile for the installer image can have a simple RUN command, calling install.sh within the context of the volume share set up by the user (or greatly-reduced-in-complexity, or none-at-all) bit.ly script:

Install fabric binaries on my machine with:

docker run -v $(PWD)/fabric/bin ghcr.io/hyperledger/fabric-installer

Nice and easy, clean semantics of the tagging, and portable to ghcr.io.

[mbwhite]

Couple of thoughts:

• would prefer to use install-fabric.sh
• use the github.com registry

[jkneubuh]

To clarify there is still some value in providing the "natural" distribution route for running Fabric Administrative Activities.

E.g., differentiate between the installation of binaries necessary to Run Fabric and binaries necessary to Administer a Fabric Network (fabric-cli)

For instance, this seems very, very natural:

brew install fabric-cli

or

sudo yum install fabric-cli

...