Problem with moby packages when installing docker-ce on CentOS 7

Question

I have a docker image for CentOS 7 which installs docker-ce via the recommended instructions. i.e.

RUN yum-config-manager \
  --add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
RUN yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2
RUN yum update -y
RUN yum install -y docker-ce docker-ce-cli containerd.io

Recently this stopped working and now fails as follows:

--> Processing Conflict: moby-containerd-1.3.6+azure-1.x86_64 conflicts containerd
--> Processing Conflict: moby-runc-1.0.0~rc10+azure-2.x86_64 conflicts runc
--> Finished Dependency Resolution
Error: moby-containerd conflicts with containerd.io-1.2.13-3.2.el7.x86_64
Error: moby-runc conflicts with containerd.io-1.2.13-3.2.el7.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
The command '/bin/sh -c yum install -y docker-ce docker-ce-cli containerd.io' returned a non-zero code: 1

If the install command is replaced with:

yum install -y docker

I get a different error to do with an unsigned package:

Package runc is obsoleted by moby-runc, trying to install moby-runc-1.0.0~rc10+azure-2.x86_64 instead
...
Package moby-runc-1.0.0~rc10+azure-2.x86_64.rpm is not signed

I tried forcing use of a few old versions as below to no avail e.g.

RUN yum install -y docker-1.13.1-102.git7f2769b.el7.centos

Why is this happening? How can I fix it? And how can I prevent similar problems in the future?

---

Update: A critical missing piece of information from this question is the use of Azure. I had the following as aspnetcore is required to publish packages in an Azure devops pipeline:

RUN rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
RUN yum update -y && yum install aspnetcore-runtime-3.1 -y

Answer 1

my repo's needed to be updated --- the following resolved me:

curl https://packages.microsoft.com/config/rhel/7/prod.repo > ./microsoft-prod.repo
sudo cp ./microsoft-prod.repo /etc/yum.repos.d/
yum update -y

https://learn.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software

Answer 2

Related problem in RHEL 8

Seems that azure depends on packages from the container-tools module, and Docker conflicts with these packages.

# dnf remove @container-tools

Answer 3

The Answer from user8475213 worked for me. But I had to run after these commands also:

yum clean metadata

Answer 4

Caveat: Usually disclaimers apply. This is only what I think, I may be mistaken. Please comment / suggest edits if so.

How can I fix it?

This was actually a problem with the baseurl of a repo not the docker-ce repo (though I did originally file a bug report there (see issue #11198).

The moby packages come from "packages-microsoft-com-prod". It seems the baseurl has changed. The correct one is now:

baseurl=https://packages.microsoft.com/rhel/7/prod/

installed via:

RUN curl https://packages.microsoft.com/config/rhel/7/prod.repo >/etc/yum.repos.d/microsoft-prod.repo

The one with the dodgy packages is:

baseurl=https://packages.microsoft.com/centos/7/prod/

Installed via:

RUN rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm

The moby packages exist only in the CentOS repo which is possibly defunct, as Microsoft themselves have changed installation documentation in various places.

There was also a workaround. You can exclude the 'moby' packages until they are really ready as in:

RUN yum install -y docker --exclude=moby-\*

Why is this happening?

I think this is caused by overly aggressive promotion of moby replacements for docker-ce functionality. It is hopefully a transient state while they are working things out.

That the package moby-runc-1.0.0~rc10+azure-2.x86_64.rpm is not signed suggests a problem with the build process used. This package ought only to be available to beta testers. Certainly not in a repository marked "stable".

How can I prevent similar problems in the future?

Contrary to popular myths, using docker does not completely isolate you from changes in the environment. The repositories used by your docker files are themselves part of the environment. If that environment changes, as in this case, then your reproducible build may cease to be reproducible. The only real way to avoid that is to host your own repositories which comes at a high price. Usually external repositories are stable enough that this is not an issue.

You should consider specifying specific versions of packages to install in your dockerfile to avoid getting unexpected upgrades. However, that will not help you in cases like this where a package is obsoleted and replaced.