[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] automation: set architecture in docker files



On Tue, 14 Nov 2023, Roger Pau Monné wrote:
> On Tue, Nov 14, 2023 at 03:00:17PM +0000, Anthony PERARD wrote:
> > On Tue, Nov 14, 2023 at 10:01:06AM +0100, Roger Pau Monné wrote:
> > > On Mon, Nov 13, 2023 at 04:10:24PM -0800, Stefano Stabellini wrote:
> > > > On Mon, 13 Nov 2023, Roger Pau Monne wrote:
> > > > > Pass the desired architecture of the image in the FROM instruction if 
> > > > > the
> > > > > image is possibly multi-platform.
> > > > > 
> > > > > This allows using the x86 Dockerfiles on OS X on arm64 hardware.
> > > > > 
> > > > > No functional change intended.
> > > > > 
> > > > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > > 
> > > > Although I am not opposed to this change, so far we have been using:
> > > > arm64v8/alpine:3.18
> > > > 
> > > > for x86 it is not specified but it would be:
> > > > amd64/alpine:3.18
> > > > 
> > > > Two options:
> > > > 1) we add amd64/ everywhere and leave the arm containers alone
> > > > 2) we change all containers, including the arm containers, to use the
> > > > --platform option
> > > > 
> > > > I don't think is a good idea to have 2 different ways to specify the
> > > > architecture for x86 and arm containers
> > > 
> > > I'm not an expert on this, but attempting to use (2):
> > > 
> > > -FROM arm64v8/alpine:3.18
> > > +FROM --platform=linux/arm64v8 alpine:3.18
> > > 
> > > Does not work for me:
> > > 
> > > % make -C automation/build alpine/3.18-arm64v8
> > > docker build --pull -t 
> > > registry.gitlab.com/xen-project/xen/alpine:3.18-arm64v8 -f 
> > > alpine/3.18-arm64v8.dockerfile alpine
> > > [+] Building 1.4s (3/3) FINISHED                                          
> > >         docker:desktop-linux
> > >  => [internal] load .dockerignore                                         
> > >                         0.0s
> > >  => => transferring context: 2B                                           
> > >                         0.0s
> > >  => [internal] load build definition from 3.18-arm64v8.dockerfile         
> > >                         0.0s
> > >  => => transferring dockerfile: 818B                                      
> > >                         0.0s
> > >  => ERROR [internal] load metadata for docker.io/library/alpine:3.18      
> > >                         1.4s
> > > ------
> > >  > [internal] load metadata for docker.io/library/alpine:3.18:
> > > ------
> > > 3.18-arm64v8.dockerfile:1
> > > --------------------
> > >    1 | >>> FROM --platform=linux/arm64v8 alpine:3.18
> > >    2 |     LABEL maintainer.name="The Xen Project" \
> > >    3 |           maintainer.email="xen-devel@xxxxxxxxxxxxxxxxxxxx"
> > > --------------------
> > > ERROR: failed to solve: alpine:3.18: no match for platform in manifest 
> > > sha256:eece025e432126ce23f223450a0326fbebde39cdf496a85d8c016293fc851978: 
> > > not found
> > > make: *** [alpine/3.18-arm64v8] Error 1
> > > 
> > > That's why I've left the prefixed images alone.
> > > 
> > > I could prefix the x86 images with amd64/ if that's preferred, I
> > > didn't try that option, as the Docker manual suggested using
> > > --platform.
> > 
> > So a few things to know, "--platform=linux/amd64" just select a
> > different build of one container. For example, for the "alpine"
> > containers, you can see all the different builds available on the docker
> > hub, here a few links:
> > - Official Docker, Alpine images, home:
> >   https://hub.docker.com/_/alpine
> > - The different builds: 
> >   https://hub.docker.com/_/alpine/tags
> > 
> > So, for amd64v8, you probably want --platform=linux/arm64/v8
> 
> Interesting, I guess I was looking at an outdated documentation that
> stated the tag as arm64v8 instead of arm64/v8.
> 
> > 
> > Then, they are per-architecture repository that make it easier to deal
> > with foreign architecture, and probably maintained by a different
> > community. e.g. for alpine arm64v8:
> >     https://hub.docker.com/r/arm64v8/alpine/
> > 
> > Those provide a build for a single architecture.
> 
> Right, so those two are not actually the same image.  I wonder whether
> we would want to uniformly switch to using --platform when possible,
> in order to make sure we are using the same (multi arch) image to
> avoid surprises.
> 
> > 
> > 
> > Sometime, you actually need to "--platform=*" to select a particular
> > architecture, like I did for "jessie-i386.dockerfile".
> > 
> > 
> > One thing I've notice when using --platform is that, if for example I
> > use the container "--platform=linux/amd64 alpine:3" then
> > "--platform=linux/arm/v6 alpine:3"; later when I only specify
> > "alpine:3", it's going to be the armv6, and I think docker is going to
> > complain if I try tu use "--platform=linux/amd64 alpine:3" without
> > "docker pull" first (or I guess docker build --pull).
> > 
> > Hope that help.
> > 
> > So I guess using containers "amd64/*" or "arm64v8/*" is fine, but
> > sometime will need to use "--platform=*".
> 
> My take is that it's better to use --platform when possible, as then
> all platforms share the same image, and the contents of the image
> should be more consistent.
> 
> I guess we could see about switching some of the image that currently
> use a prefix (like the Alpine one) in order to instead use --platform
> and share the same image.  I wouldn't want to do it in this patch
> however, as the change presented here should be non-functional, while
> switching to the multi arch image might introduce changes.

I am OK with any way forward as long as we are consistent across
architectures.

If you don't want to change the existing arm64v8 prefixes, I am fine
with that, but then I would ask you to use the amd64 prefix not to break
consistency (do not use --platform).

After that, if you prefer to use --platform, I am totally fine with that
too and it can be a follow-up patch changing the containers of both
architectures.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.