Disabling inserting mixins lines into Dockerfile

[S1d0]

Hi folks,

is it possible to disable inserting mixins lines into Dockerfile which is generated by porter build ?
I'm working in airgap enviroment and I created based image with all tools already in place (in my case helm3 and kubernetes)

My base debian image looks like that

FROM debian:stable-slim

RUN apt-get update && apt-get install -y ca-certificates

RUN apt-get update && \
   apt-get install -y apt-transport-https curl && \
   curl -o kubectl https://storage.googleapis.com/kubernetes-release/release/v1.19.0/bin/linux/amd64/kubectl && \
   mv kubectl /usr/local/bin && \
   chmod a+x /usr/local/bin/kubectl

ARG DOCKER_VERSION=19.03.8
RUN curl -o docker.tgz https://download.docker.com/linux/static/stable/x86_64/docker-${DOCKER_VERSION}.tgz && \
    tar -xvf docker.tgz && \
    mv docker/docker /usr/bin/docker && \
    chmod +x /usr/bin/docker && \
    rm docker.tgz

RUN curl https://get.helm.sh/helm-v3.3.4-linux-amd64.tar.gz --output helm3.tar.gz && \
    tar -xvf helm3.tar.gz && \
    mv linux-amd64/helm /usr/local/bin/helm3 && \
    rm helm3.tar.gz

RUN mkdir -p /root/.local/share/helm/plugins/helmpush \
  && curl -L -f -s https://github.com/chartmuseum/helm-push/releases/download/v0.9.0/helm-push_0.9.0_linux_amd64.tar.gz \
  tar zxf - -C /root/.local/share/helm/plugins/helmpush/

My porter.yaml looks like that:

name: porter-hello
version: 0.1.0
description: "An example Porter configuration"
registry: getporter

dockerfile: Dockerfile.tmpl

mixins:
  - exec
  - helm3
--- REST OF THE PORTER.yaml IS SKIPPED ---

Dockerfile.tmpl looks like this:

FROM basedebian:latest

ARG BUNDLE_DIR

COPY . $BUNDLE_DIR

And generated Dockerifle looks like this:

FROM basedebian:latest

ARG BUNDLE_DIR

RUN apt-get update && apt-get install -y curl
RUN curl https://get.helm.sh/helm-v3.3.4-linux-amd64.tar.gz --output helm3.tar.gz
RUN tar -xvf helm3.tar.gz
RUN mv linux-amd64/helm /usr/local/bin/helm3

COPY . $BUNDLE_DIR
RUN rm -fr $BUNDLE_DIR/.cnab
COPY .cnab /cnab
COPY porter.yaml $BUNDLE_DIR/porter.yaml
WORKDIR $BUNDLE_DIR
CMD ["/cnab/app/run"]

As you can see above after running porter build I'm getting generated Dockerfile with part RUN curl https://get.helm.sh/helm-v3.3.4-linux-amd64.tar.gz --output helm3.tar.gz which fails in airgap enviroment.
Is there a way to switch off writing to Dockerfile mixins lines?

[vdice]

Oh this is an interesting use case -- thanks @S1d0 ! Do I have this right? One brings in their own base image with all the tools they need -- but some of the tools (helm3, kubectl, etc.) align with a corresponding Porter mixin. Of course, we want to be able to use the corresponding mixin syntax in the porter manifest, which requires their declaration... but, in the case where porter build will be run in an airgapped env, we want to forgo adding the mixin lines that attempt to fetch the tools.

One question: For this use case, can porter build be called at the same/similar point where the base image is built? (Meaning, at a non-airgapped point wherein these core tools can be fetched over a connection.) Classically this is the pattern we've seen: the bundle is built when a connection is available and then the bundle (and built images) are archived and transferred over the airgap. Carolyn has a recent write-up around the process here: https://github.com/cncf/podtato-head/tree/main/delivery/CNABwithPorter

Otherwise, I think it could be relatively straightforward to add a toggle to prevent mixin lines from being added to the Dockerfile... would be interested in hearing thoughts on what this might look like.

[S1d0]

Hi @vdice thanks for your reply! Yeah I make life harder then it needs to be I guess 😄. Once base docker image of debian with all tools in place (like helm3, kubectl, etc.) is delivered to airgap dev enviroment, development of porter bundles begins. So porter build, install, publish, credentials commands will be all called in airgap enviroment (without connection to outside network).
Soo answer for your question:
One question: For this use case, can porter build be called at the same/similar point where the base image is built? -- is sadly NO😒.

It would be great to have toggle to prevent adding mixin lines to the Dockerfile, and still being able to use mixin in manifest - as you pointed

[carolynvs]

Oh really interesting! You are the first to share that you are building bundles in the air-gapped environment. What if we offered an alternate comment for your dockerfile template to indicate that you don't want the mixins injected?

FROM basedebian:latest

ARG BUNDLE_DIR

COPY . $BUNDLE_DIR
# NO_PORTER_MIXINS

Let me know and we can add that to the backlog.

[lrskyum]

I need it too, and for the same conditions: the full process including build in air gapped environment.

I work around the issue by having a "dummy" porter.yaml that works but doesn't do anything interesting, then copy the relevant mixin-parts from the Dockerfile and generate a base image with required mixins. The base image would be used in the air gapped environment and with mixin-commands disabled during build in air gapped so they don't try and download, etc..

It would be nicer if porter supported air gapped build, e.g., by providing an argument that generates mixin-contribution to Dockerfile for the base-image, disables injection of mixin commands in Dockerfile, and possibly more/other.

[carolynvs]

I am investigating an alternate way to use mixins where they are never injected into the invocation image and instead are referenced as additional images distributed with the bundle alongside the invocation image. I think the new design may help with building in an airgapped environment. When I have the design proposal written up I'll link it here so that you can review and help spot gaps for your scenarios.

[carolynvs]

Here is the proposal: #1499