Add an option to stage docker images locally to KIND

[jkneubuh]

This PR addresses a compromise for development workflows requiring different patterns for loading images into the KIND / kubernetes cluster.

• For casual / default usage, the docker images are loaded from the public container registries (docker.io and ghcr.io)

• For developers with network issues connecting to public registries, this PR allows for an offline "pull" and stage to the KIND control plane:

export TEST_NETWORK_STAGE_DOCKER_IMAGES=true
./network kind     # << this will pull from the public repos, and run kind load docker-image ...  

./network up 

• For test/development of the CI latest build outputs, the container registry and revision can be overridden:

export TEST_NETWORK_FABRIC_VERSION=amd64-latest 
export TEST_NETWORK_FABRIC_CA_VERSION=amd64-latest 
export TEST_NETWORK_FABRIC_CONTAINER_REGISTRY=hyperledger-fabric.jfrog.io

./network up 

• For active development of core Fabric images (e.g. peer, orderer), the KIND control plane can be directly loaded with local builds:

make docker # (in fabric) 

export TEST_NETWORK_FABRIC_VERSION=2.4.0 

./network load-images 
./network up 

@mbwhite and @SamYuan1990 can you please give this PR a test run to double-check that it meets your target use cases? Matthew I had some difficulty testing out PR #507 and the candidate-use-builtin-ccs-builder branch with the mainline network scripts. I think this is a better fit for that workflow.

Signed-off-by: Josh Kneubuhl jkneubuh@us.ibm.com

[SamYuan1990]

Hi @jkneubuh,

I would like to request a change for this PR.
if I am correct, as I tested, the load image steps are
Plan A

export TEST_NETWORK_STAGE_DOCKER_IMAGES=true
export TEST_NETWORK_FABRIC_CONTAINER_REGISTRY=localhost:5000

./network kind 
./network up 

Plan B

./network kind 
export TEST_NETWORK_FABRIC_CONTAINER_REGISTRY=localhost:5000
./network load-images
./network up 

• How about we keep the steps as Plan B as default?
  which means

./network kind 
export TEST_NETWORK_FABRIC_CONTAINER_REGISTRY=localhost:5000 // optional here if you want to use costumer settings.
./network load-images
./network up 

Thanks and Regards
Sam

[SamYuan1990]

yuanyi@192 test-network-k8s % docker images | grep localhost:5000/fabric-ca      
localhost:5000/fabric-ca                                          1.5.2                                                   4ea287b75c63   7 weeks ago     69.8MB
yuanyi@192 test-network-k8s % docker pull localhost:5000/fabric-ca:1.5.2
1.5.2: Pulling from fabric-ca
Digest: sha256:faa3b743d9ed391c30f518a7cc1168160bf335f3bf60ba6aaaf1aa49c1ed023e
Status: Image is up to date for localhost:5000/fabric-ca:1.5.2
localhost:5000/fabric-ca:1.5.2

and it seems harmless to pull the image again?

[jkneubuh]

Hi Sam, no this is incorrect. With this PR we no longer use the localhost:5000 registry for core fabric images:

• The localhost:5000 registry is used for building, testing, and running chaincode and gateway client applications.

• The kind image plane is used to run the core fabric images.

Here are four different scenarios:

A) Default use case: fabric images are pulled from public docker.io and ghcr.io repositories directly into KIND:

./network kind 
./network up 

B) Network errors reading from docker.io/ghcr.io into KIND. Solution : pre-pull and load images into the KIND control plane: (This is option (A) above)

export TEST_NETWORK_STAGE_DOCKER_IMAGES=true

./network kind 
./network up

C) Run the daily/CI builds of fabric (not available at docker.io):

./network kind 

export TEST_NETWORK_FABRIC_VERSION=amd64-latest 
export TEST_NETWORK_FABRIC_CA_VERSION=amd64-latest 
export TEST_NETWORK_FABRIC_CONTAINER_REGISTRY=hyperledger-fabric.jfrog.io

./network up 

D) Run a local / custom build of core fabric images:

./network kind 

make docker # in fabric/ 

./network load-images 
./network up 

The important change here is that this no longer uses the localhost:5000 registry for core fabric images.

Also in general it is OK to re-pull an image, but preferable to denote this only when using an imagePullPolicy: Always and the latest tag for images. This is OK for interactive development but not ideal for production release pipelines, which should use clear labels/tags tied to semantic revisions numbering and the imagePullPolicy: IfNotPresent strategy.

@SamYuan1990 can you try option "B" above and see if this solves your issues loading the fabric base images?

[SamYuan1990]

@jkneubuh,

1. localhost:5000 is just a sample here for me to do the test.
2. Let's talk about the 4 options.
   In my point of view,

• The different between Option A/B is that we docker image from local docker and load into kind or not.

export TEST_NETWORK_STAGE_DOCKER_IMAGES=true

It resolve may things, as for sample the network issue/delay with local kind to access remote docker reg.

• C is a specific case that show customer use image... well it may due to ci using other image reg?

• And for B/D share one case that upload image from local to kind.(same way as A/C)

so, just focus on load image to kind or not.

• AC is the same case as download image via kind.
• BD is the same case as load image from local to kind.

Description	Image via kind	load Image
Default image	A	B
Customer image via Env/Make	C	D

which in my point of view,
Plan B/C/D, as kind fails to download image from docker reg.

export TEST_NETWORK_STAGE_DOCKER_IMAGES=true
./network kind 

<customer script here to download the images>
#B: docker pull
#C: export TEST_NETWORK_FABRIC_VERSION ...
#D: make docker # in fabric

./network load-images 
./network up

considering, it seems no harmful to pull image again.

yuanyi@192 test-network-k8s % docker images | grep localhost:5000/fabric-ca      
localhost:5000/fabric-ca                                          1.5.2                                                   4ea287b75c63   7 weeks ago     69.8MB
yuanyi@192 test-network-k8s % docker pull localhost:5000/fabric-ca:1.5.2
1.5.2: Pulling from fabric-ca
Digest: sha256:faa3b743d9ed391c30f518a7cc1168160bf335f3bf60ba6aaaf1aa49c1ed023e
Status: Image is up to date for localhost:5000/fabric-ca:1.5.2
localhost:5000/fabric-ca:1.5.2

in which case, ./network load-images and export TEST_NETWORK_STAGE_DOCKER_IMAGES=true duplicated.
we can change the behavior to below and remove TEST_NETWORK_STAGE_DOCKER_IMAGES ?

./network kind 
# costumer scripts here
./network load-images
./network up 

[jkneubuh]

Hi @SamYuan1990

When TEST_NETWORK_STAGE_DOCKER_IMAGES=true, the images are:

1. Pulled from TEST_NETWORK_FABRIC_CONTAINER_REGISTRY (calls pull_docker_images)
2. loaded into the KIND control plane. (calls load_docker_images)

When running network load-images:

1. images are loaded into the KIND control plane (calls load_docker_images)

Is there something about the use case above that makes it difficult for your use case? If you have custom scripts to pull images locally, then the option "D" is also available.

@mbwhite does this new scheme enable your scenario to run with local Fabric images? I was able to run this without the auto "pull" overwriting the local images.

[SamYuan1990]

it works for my case.