On Sun, Aug 9, 2020 at 5:24 PM Aleksandar Kostadinov <akost...@redhat.com>
wrote:

> Ben Parees wrote on 9.08.20 г. 2:38 ч.:
> > On Sat, Aug 8, 2020 at 7:23 AM Aleksandar Kostadinov
> > <akost...@redhat.com <mailto:akost...@redhat.com>> wrote:
> >
> >     Thank you for the explanation. While running on 3.11, there is some
> >     subscription available but is not enough so I need to use custom one.
> >
> >     FYI I filed a documentation bug for some critical details that could
> >     have saved me a lot of time [3].
> >
> >     For my use case, because image is not public I decided to make 2
> stage
> >     build where first stage adds subscription and second is same
> Dockerfile
> >     used for non-OpenShift build.
> >
> >     My simple first stage is:
> >           COPY ./etc-pki-entitlement /etc/pki/entitlement
> >
> >           COPY ./rhsm-ca /etc/rhsm/ca
> >
> >           COPY ./rhsm-conf /etc/rhsm
> >
> >           USER 0
> >
> >           RUN rm /etc/rhsm-host
> >
> >           USER 185
> >
> >
> >     Then second stage uses the result from above. Drawback is that there
> is
> >     no way to remove subscription details from the first stage layer.
> >
> >
> > I believe this is now supported in 4.x:
> > https://github.com/openshift/api/blob/master/build/v1/types.go#L684
> >
> > which means if you COPY the file in one layer, use it in another, and
> > remove it in a third, the file will not be present in any layer of the
> > image (because there will only be a single new layer added to the image).
> >
>
> I know about imageOptimizationPolicy: SkipLayers, it works on 3.11 too.
> But it only spans current build. If I do two builds in the way I
> described, there is no way the resulting image to be without the layer
> where the secret lives. At least I know no way.
>

if you're saying you're building a base image that bakes in the creds, and
then building your app image by extending that base image, then i think you
are correct that we don't have an api mechanism to squash the layers from
the base image with the layers from the app image.



>
> My basic goal is to use same unmodified Dockerfile for local and
> OpenShift builds.
>
> >
> >     Isn't it possible in the future to allow mounting secrets and config
> >     maps in the build container so that subscription data is never
> recorded
> >     into the layers and no modifications to Dockerfile are needed?
> >
> >
> > yes that is part of the plan for implementing build parts the
> > enhancement proposal i linked.
>
> I didn't read it like this. Maybe I missed that. And I already filed an
> issue about it [4]. If you or the enhancement authors think that this is
> already there, then feel welcome to close it.
>

It was probably not clearly described in the top level enhancement, but i
believe it is in one of the lower level ones.  In any case the intended
flow when all the pieces are in place would be:

1) creds exist in a resource in the cluster
2) build-pod gets launched which mounts the creds as a volume
3) buildah gets invoked within the build-pod, passing the cred-dir as a
volume path to buildah

So buildah will make the creds available within the container executing the
dockerfile, but not include them in the committed image.

I'm CCing Adam who's driving this enhancement so he can confirm/deny my
understanding and perhaps point you to the sub-EP that specifically covers
this behavior.



>
> Thanks again for the helpful replies.
>
> [4] https://github.com/openshift/enhancements/issues/428
>
> >
> >     [3] https://github.com/openshift/openshift-docs/issues/24625
> >
> >     Ben Parees wrote on 8.08.20 г. 0:49 ч.:
> >     >
> >     >
> >     > On Fri, Aug 7, 2020 at 3:29 PM Aleksandar Kostadinov
> >     > <akost...@redhat.com <mailto:akost...@redhat.com>
> >     <mailto:akost...@redhat.com <mailto:akost...@redhat.com>>> wrote:
> >     >
> >     >     I'm reading documentation [1] but adding the secret mounted
> under
> >     >     `etc-pki-entitlement` directory but subscription manager still
> >     doesn't
> >     >     find the extra repos.
> >     >
> >     >     I don't see 3.11 specific information. Should it work in
> >     another way?
> >     >
> >     >     I also see a blog post from this year [2]. It suggests copying
> >     >     entitlement files inside the Dockerfile which approach I don't
> >     like
> >     >     since I prefer independent build logic from underlying
> >     environment and
> >     >     doesn't match documentation [1]. Blog doesn't allow comments
> >     though.
> >     >
> >     >     So is documentation or the blog correct? Is there a difference
> >     between
> >     >     4.x and 3.11?
> >     >
> >     >
> >     > there is a major difference between 3.x and 4.x.
> >     >
> >     > 1) hosts aren't subscribed so there are no subscription creds
> >     available
> >     > normally (in 3.x the builds picked them up from the host
> filesystem,
> >     > like any other container)
> >     >
> >     > 2) the container executing your Dockerfile commands doesn't run
> >     directly
> >     > on the host, it runs inside the build-pod, so it doesn't have
> >     access to
> >     > the host filesystem anyway.
> >     >
> >     > in 3.x we had the host filesystem available and the host was
> >     subscribed,
> >     > so we could just map those files through to the container running
> your
> >     > dockerfile commands.
> >     >
> >     > in 4.x that is not possible(the host doesn't have a subscription,
> thus
> >     > the build-pod doesn't have subscription creds, thus the container
> >     > running your dockerfile commands, which runs inside the build-pod,
> >     does
> >     > not have a way to get subscription creds), hence the hoops you
> >     must jump
> >     > through to make the subscription creds available(including the COPY
> >     > statements) before executing your dnf commands.
> >     >
> >     > we are working on efforts to improve this experience.
> >     >
> >     > you can see the top level summary here:
> >     > https://github.com/openshift/enhancements/pull/384
> >     >
> >     > but other EPs are associated to the work.
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >     Thank you!
> >     >
> >     >     [1]
> >     >
> >
> https://docs.openshift.com/container-platform/4.4/builds/runnAddSuitesing-entitled-builds.html#builds-source-secrets-entitlements_running-entitled-builds
> >     >
> >      <
> https://docs.openshift.com/container-platform/4.4/builds/running-entitled-builds.html#builds-source-secrets-entitlements_running-entitled-builds
> >
> >     >     [2]
> >     >
> >
> https://www.openshift.com/blog/how-to-use-entitled-image-builds-to-build-drivercontainers-with-ubi-on-openshift
> >     >
> >     >     _______________________________________________
> >     >     users mailing list
> >     >     users@lists.openshift.redhat.com
> >     <mailto:users@lists.openshift.redhat.com>
> >     >     <mailto:users@lists.openshift.redhat.com
> >     <mailto:users@lists.openshift.redhat.com>>
> >     >     http://lists.openshift.redhat.com/openshiftmm/listinfo/users
> >     >
> >     >
> >     >
> >     > --
> >     > Ben Parees | OpenShift
> >     >
> >
> >
> >
> > --
> > Ben Parees | OpenShift
> >
>
>

-- 
Ben Parees | OpenShift
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to