The difference between installer and non-installer images

[tamirkamara]

Hi,

When publishing a bundle (after building it) I can see 2 stages and 2 images are getting stored in the container registry:

• An installer image, e.g. my-bundle-installer:v1.0.0
• A "regular" image, e.g. my-bundle:v1.0.0

What is the difference between the two?
(Is there a doc that explains this?)

[VinozzZ]

Hi @tamirkamara , do you mind to share what version of porter you are using?
If you are using v0.38, here's the doc page that explains the difference between these two images: https://v0.getporter.org/distribute-bundles/#bundle-publish
Let me know if you have more questions!

[tamirkamara]

This is an example bundle: https://github.com/microsoft/AzureTRE/tree/main/templates/workspaces/base
The installer image is 1.83GB according to docker image ls
The non-installer one is harder to get the size of since it isn't saved locally. However, the time it takes to do the "copy" makes me think it's large... but maybe it isn't that? I mean this very last part of the porter publish command.

Starting to copy image acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25...
Completed image acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25 copy
Bundle tag acr1234.azurecr.io/tre-workspace-base:v0.3.25 pushed successfully, with digest "sha256:5b311253853b96f17077152c7aa3f3390e6992ee97472da22ca2fee3e2b442a5"

[VinozzZ]

Thank you for sharing the information. It looks like this bundle has dependencies on both terraform and azure cli mixns. The bundle will contain an os distribution, porter binary, and all the mixins it uses.
The bundles image size is proportional to the complexity of the bundles and the numbers of mixins and dependencies required for a given bundle.
We do have some proposal designs in work to help with reducing the size of bundles. https://github.com/getporter/proposals/blob/main/pep/005-mixins-are-bundles.md#reduce-bundle-size
Let me know if this helps to clarify things for you

[tamirkamara]

I understand that the install image will be large (mainly because of the az cli) and that's fine.
My question was more about the second image, the non-installer one. It looked like it takes a few minutes for porter to complete it and I assumed most of that time is network with the registry. But maybe it's not right... what is porter doing during this time?

Starting to copy image acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25...
Completed image acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25 copy
Bundle tag acr1234.azurecr.io/tre-workspace-base:v0.3.25 pushed successfully, with digest "sha256:5b311253853b96f17077152c7aa3f3390e6992ee97472da22ca2fee3e2b442a5"

[VinozzZ]

I see. Currently, porter regenerates the bundle manifest after publishing the installer image since the image digest is only generated after pushing to a registry

[carolynvs]

Here's a bit deeper dive into what's happening and why this could be slow. The explanation is for Porter v0, but is very similar to v1 in terms of activities.

1. Porter builds a docker image for the bundle containing debian slim, the mixins used by the bundle, and your bundle files.
2. Porter pushes that image to the registry at acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25 and gets the registry digest of the image.
3. Porter then creates an OCI manifest list (which represents the bundle) and pushes it to acr1234.azurecr.io/tre-workspace-base:v0.3.25. As you have noted, this is tiny. This manifest list includes a reference to the installer image.
4. Porter copies the installer image from its original location at acr1234.azurecr.io/tre-workspace-base-installer:v0.3.25 to an untagged image stored inside of the bundle's repository, for example acr1234.azurecr.io/tre-workspace-base@sha256:REPOSITORY_DIGEST_OF_INSTALLER_IMAGE.

I believe you are seeing a performance problem during the final copy from one repository in the registry to another. I'm going to open an issue in the CNAB library that performs this logic (it's not in Porter but one of our dependencies) and see if we can improve how we do the copy so that it's not essentially re-pushing twice.

[carolynvs]

I have created #2312 to investigate and make sure we can't do this more efficiently.