docker arm64 image is needed

[pinkworld123]

hello,

please build docker arm64 image also and push it to docker hub. thanks

[micahsnyder]

I think this is a great idea.

I found this post about doing it with docker desktop and will try to find some time to give it a try: https://www.docker.com/blog/multi-arch-images/ But I don't have any experience building arm64 images so if anyone wants to give me some tips to help me get started, I would appreciate it.

[otterley]

Hi @micahsnyder, I'm happy to help. Quick question: what is the pipeline by which x86-64 images are published to Docker Hub today? I looked for a relevant GitHub Action in this repo, but didn't find anything.

[micahsnyder]

Thanks @otterley

Right now we're building the docker images through Jenkins on a Debian 11 worker VM that has Docker installed.

The script it runs looks like this:

clamav_docker_user="${DOCKER_USERNAME}"
docker_registry="registry.hub.docker.com"

# Make sure we have the latest alpine image.
docker pull alpine:latest

# Build the base image
docker build --tag "${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base" .

# Login to docker hub
echo "${_passwd:-${DOCKER_PASSWD}}" | \
    docker login --password-stdin \
                 --username "${clamav_docker_user}" \
                 "${docker_registry}"

# Make a tag with the registry name in it so we can push wherever
docker image tag ${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base

# Push the image/tag
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base

# Give it some time to add the new ${CLAMAV_FULL_PATCH_VERSION}_base image.
# In past jobs, it didn't detect the new image until we re-ran this job. I suspect because it needed a little delay after pushing before pulling.
sleep 20

# Create extra tags of the base image. 
docker image tag ${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FEATURE_RELEASE}_base
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FEATURE_RELEASE}_base

docker image tag ${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:stable_base
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:stable_base

docker image tag ${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION}_base ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:latest_base
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:latest_base

# Generate and push an image without the "_base" suffix that contains the databases.
#
# TODO: There's bug where this actually updates _all_ containers and not just the tag we specify. 
#       See https://jira-eng-sjc1.cisco.com/jira/browse/CLAM-1552?filter=16896
CLAMAV_DOCKER_USER="${clamav_docker_user}" \
CLAMAV_DOCKER_PASSWD="$DOCKER_PASSWD" \
DOCKER_REGISTRY="${docker_registry}" \
CLAMAV_DOCKER_IMAGE="${CLAMAV_DOCKER_IMAGE_NAME}" \
CLAMAV_DOCKER_TAG="${CLAMAV_FULL_PATCH_VERSION}" \
  ./dockerfiles/update_db_image.sh -t ${CLAMAV_FULL_PATCH_VERSION}

# Login to docker hub (again, because the update_db_image.sh script removed our creds in its cleanup stage)
echo "${_passwd:-${DOCKER_PASSWD}}" | \
    docker login --password-stdin \
                 --username "${clamav_docker_user}" \
                 "${docker_registry}"

# Create extra tags of the main (database loaded) image.
docker image tag ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION} ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FEATURE_RELEASE}
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FEATURE_RELEASE}

docker image tag ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION} ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:stable
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:stable

docker image tag ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:${CLAMAV_FULL_PATCH_VERSION} ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:latest
docker image push ${docker_registry}/${CLAMAV_DOCKER_IMAGE_NAME}:latest

# log-out (again)
docker logout "${docker_registry:-}"

[micahsnyder]

I could switch this over to run on a 2020 Mac Mini M1 we have racked in a server room to make use of Docker Desktop on Mac.

[antoinedeschenes]

Moving to docker buildx is the easiest way to handle this.

Usually the arm64 build will run using qemu on the same machine as the amd64 build, but the arm64 build takes about 10x more time to run.

There are two ways to work around this:

1. Setup buildx to use a different machine for the arm64 platform (reaching the remote docker API through SSH or TLS) https://github.com/docker/buildx/discussions/683
2. Run the builder image natively, but cross-compile to a different architecture if your toolchain supports it. https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/

[strelok1]

There is another guide here https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

on Linux you may have to install buildx if you switch to building on the M1 Mac it should already be installed with Docker Desktop. Really keen to see the official arm image if you have the time to implement. I’ve tested building an image from the official Dockerfile in this repo on the M1 Mac and it works great as I mentioned in #536

[Basster]

If you search for "docker multi-arch github actions" you will find a lot of resources, how it can easily be build with github actions.

I have a pretty simple script to build multi-arch, but on gitlab:

build.sh

#!/usr/bin/env sh

architecture=$(arch)
image=<fully-qualified-image-name-with-tag>

if [ "$architecture" = "arm64" ] || [ "$CI" = true ]; then
    docker buildx build \
        --platform linux/arm64/v8,linux/amd64 \
        --no-cache --pull \
        -t "${image}" \
        --push .
else
    docker build --no-cache --pull -t "${image}" .
    docker push "${image}"
fi

Excerpt of my gitlab-ci.yml

.docker-multi-arch: # supports regular docker build as well as docker buildx build!
  stage: build
  image: jonoh/docker-buildx-qemu
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker buildx create --name "${BUILDER_NAME}" --driver docker-container --use
    - docker buildx inspect --bootstrap
    - update-binfmts --enable
    - cd $SCRIPT_DIR
  after_script:
    - docker buildx rm "${BUILDER_NAME}"
  script:
    - sh ./build.sh
  variables:
    SCRIPT_DIR: '.docker'
    DOCKER_DRIVER: overlay2
    BUILDER_NAME: multiarch-$CI_JOB_ID

References build image: https://hub.docker.com/r/jonoh/docker-buildx-qemu

Maybe someone may adopt this to github-actions/jenkins?

[gautam-nutalapati]

We use AWS CodePipeline to publish our own clamav image in ARM and AMD architectures. Same image is published via ARM and AMD machines, and uses docker manifest. Reference: https://aws.amazon.com/blogs/devops/creating-multi-architecture-docker-images-to-support-graviton2-using-aws-codebuild-and-aws-codepipeline/

[micahsnyder]

I am working on the ClamAV docker support in new clamav-docker repo: https://github.com/Cisco-Talos/clamav-docker

For multi-arch efforts, looking at using debian slim images as discussed in #673

See: https://github.com/Cisco-Talos/clamav-docker/tree/main/clamav/unstable/debian And: https://github.com/Cisco-Talos/clamav-docker/tree/main/clamav/0.105/debian

I have to pause to focus on fixes for the 1.0.0 release and will resume when I get a chance.

My plan is to publish the debian-based multi-arch image tags to dockerhub under clamav/clamav-debian. The original Alpine-based images will continue under clamav/clamav, for now. If all goes well, then we can consider setting a date to deprecate the Alpine-based images and switch to Debian for the main images.

[taylor-lindores-reeves]

Guys, am I just wasting my time trying to get ClamAV working on my M1 Mac at the moment? I am continuously running into the "No clamscan/clamdscan binaries found" after installation with HomeBrew. My NodeJS app won't pick it up at all. Is this a wasted effort or am I just not configuring it correctly?

I am running on a MB Pro M1 Max.

[micahsnyder]

@leafyshark this is really not the right place for your question. It is off topic. Since this is a homebrew install problem and not an issue with clamav, please move your question to the users mailing list, discord, or else and issue in the homebrew issue tracker.

[a7i]

@micahsnyder anything I can help with? I see the Dockerfile definition but no image has been published. Happy to help, let me know.

[micahsnyder]

@a7i @peschee we were having issues with the multiarch builder for docker buildx on our 2020 M1 Mac Mini that is in our (internal) Jenkins pipeline. In fact, Docker on that machine was entirely broken for a while for testing linux arm64 builds (we don't have linux running on arm64 metal to test). But we did just get Docker working again on that device.

I am afraid that trying to create a buildx builder on the Mac Mini will break Docker again. I am tempted to find a different dedicated linux device to do this on.

[itg-dave]

@a7i @peschee we were having issues with the multiarch builder for docker buildx on our 2020 M1 Mac Mini that is in our (internal) Jenkins pipeline. In fact, Docker on that machine was entirely broken for a while for testing linux arm64 builds (we don't have linux running on arm64 metal to test). But we did just get Docker working again on that device.

I am afraid that trying to create a buildx builder on the Mac Mini will break Docker again. I am tempted to find a different dedicated linux device to do this on.

Hetzner is offering cheap ARM VMs now. Maybe you can consider using that for your builds?

[peschee]

@micahsnyder We'd be willing to sponsor this if it helps you move the multi-arch builds forward.

[otterley]

AWS can provide the build infrastructure free of charge. If you reach out to me at fiscmi at a-m-a-z-o-n dot c-o-m, we can get the process started.

[micahsnyder]

Thank you @otterley and @peschee I will bring it up with my management and team.

[peschee]

@micahsnyder do you have any updates on this?

[micahsnyder]

@micahsnyder do you have any updates on this?

My management was going to discuss it late last week, but some high priority items came up and so they were unable to get to it before my manager wemt on PTO. He will be back in just over 2 weeks, so I will bring it up again then.

[OleKsimov]

Any updates on the discussion?

[nishils]

Is there is a draft PR for an arm based image that I can help get over the line? Happy to help. If it's a matter of CI automation, any chance we can try and publish a one-off version for now or at least get the dockerfiles available to build an arm based image locally?

[nishils]

I managed to build an ARM based image locally using the Jenkinsfile as a guide on how to build the clamav image from scratch.

It seems to work. We can host an unofficial version if folks are interested or provide the steps to do this locally. It was fairly easy.

[Anand03]

@nishils Could you kindly provide instructions for performing this task on a local setup? Additionally, hosting it would be highly beneficial and likely assist a lot of individuals.

[nishils]

I did the following steps:

1. clone clamav and clamav-docker repo

2. In clamav, remove conflicting files by running rm -rf ./Dockerfile ./dockerfiles

3. cd into the 1.2.0/alpine directory in clamav-docker and copy over the files into the root of the clamav folder. Ex. cp -r Dockerfile scripts/ ~/Documents/clamav

4. To build, go back into the clamav report and run docker build --tag clamav/clamav:1.2.0_base .

I am sure the same steps can be used for the debian or other versions but I haven't tested.

[nishils]

I can push an image in the next day or two

[micahsnyder]

We're actively working on it. Ref: https://github.com/Cisco-Talos/clamav-docker/pull/26

[vumdao]

@micahsnyder Is this available in a docker registry?

[micahsnyder]

Will be here soon: https://hub.docker.com/r/clamav/clamav-debian

[micahsnyder]

Small update: our docker build scripts currently have an issue where we can publish images with multiple architectures but cannot update the databases for all of the architectures. We're planning to work on that in a couple weeks - presently working on some other things so can't do it all right now.

Anyways, that's why we haven't announced general availability for these images.

[vumdao]

Hi, any update on this?

[micahsnyder]

@vumdao my teammate is working on the issue with updating the databases in each image (for each arch) this week. I believe that issue is the only blocker.

[peschee]

Is there something we can do / support you with to expedite this?

[micahsnyder]

This PR is the last step I'm aware of needed towards publishing multi-arch images: https://github.com/Cisco-Talos/clamav-docker/pull/33

But right now we're a little sidetracked working on a build system security audit to ensure we're following best practices, and trying to meet a deadline for that.

[JanPokorny]

@micahsnyder I see that there are arm64 (as well as amd64 and ppc64le) images available at https://hub.docker.com/r/clamav/clamav-debian. Are these working and supported? Didn't find anything about it in the docs.

[gautam-nutalapati]

Please publish ARM images in the same repository as clamav/clamav instead of using clamav/clamav-debian

I think best practice is to use Docker Manifest file and deploy multi-arch images to same docker repository. Ref.

Using separate repositories would force users to create multiple Dockerfile when building on top of current ClamAV images, and other such minor things to handle. Using separate repos is not a dealbreaker, but why complicate matters when docker engine can handle automatically pulling the right architecture image based on machine where build is running.

[polarathene]

Using separate repos is not a dealbreaker, but why complicate matters when docker engine can handle automatically pulling the right architecture image based on machine where build is running.

From what I understand clamav/clamav is the AMD64 only alpine image, while clamav/clamav-debian is the multi-platform debian image.

Using separate repositories would force users to create multiple Dockerfile when building on top of current ClamAV images, and other such minor things to handle.

Not really, you can handle based on platform with FROM --platform if necessary, among other options.

In this case the only benefit of moving clamav/clamav-debian into clamav/clamav is to offer base image variants via the published image tags, a pattern you're probably familiar with elsewhere. However AFAIK the intention is to deprecate the alpine images in favor of the debian images, but if they decide to continue maintaining the alpine one, they might just offer clamav/clamav:debian (same tags but with a debian- prefix or suffix).

[polarathene]

Are these working and supported? Didn't find anything about it in the docs.

Docs seem to be here, although they still seem to imply clamav/clamav-debian may become clamav/clamav in future? (git blame shows quotes last updated Aug-Sep 2023_)

https://github.com/rsundriyal/clamav-docker/blob/main/README.md

clamav-debian: This is a multi-arch image for amd64, arm64, and ppc64le. This may eventually replace the Alpine-based image.

https://github.com/rsundriyal/clamav-docker/blob/main/clamav/README-debian.md

IMPORTANT: This readme is for the Debian-based clamav-debian Docker image which is a work-in-progress that may eventually replace the Alpine-based clamav Docker image.

clamav-debian images are multi-arch images with supported platforms.

[peschee]

@micahsnyder is there an expected date from the maintainers for an arm-based image?

[polarathene]

an arm-based image?

https://hub.docker.com/layers/clamav/clamav-debian/latest/images/sha256-9df75ebf8017cf0c3fe8cff1d4e654afacf87528c54caab467d1b7e41cd6ad89?context=explore

[micahsnyder]

@peschee, all:

It seems we forgot to update this after we started publishing debian-based multi-arch images.

You can now find arm64 images under clamav/clamav-debian: https://hub.docker.com/r/clamav/clamav-debian/tags

[polarathene]

You can now find arm64 images under clamav/clamav-debian

The README files I linked above are still unchanged. Are there still plans to stop building the Alpine image?

Will clamav/clamav-debian remain updated or will it become clamav/clamav in future? And if so is there a tracking issue to subscribe to for when that would happen?

I am fine without any change, just double-checking given the README quotes above. I just recently switched to the debian variant as base image (only used with COPY --link for the database, multi-arch to avoid a redundant warning about the Alpine AMD64 image being used for ARM64).

[micahsnyder]

FYI your links are pointing to one of our developer's forks. But readme in the official repo hasn't changed, either.

We should remove "work-in-progress" from the Readme, for sure.

Personally, I'd like to drop the Alpine-based image to reduce the amount that we have to maintain. The team hasn't made a decision on that however. If that changes, we'll send an announcement to the clamav-announce mailer, clamav-users mailer, and the Discord.