Unable to install chromium-browser in docker

[jonathan boudreau]

Steps to reproduce: Create a docker container with the official image "ubuntu:focal". Inside of the container, run "apt-get install chromium-browser".

Expected results: Chromium is installed.

Actual results: Chromium installation fails. The error is telling me that it is unable to reach the snap store (probably because snapd is not running).

[Philip Roche (philroche)]

This does not appear to be docker specific but the chromium package has moved to a snap package.

What is your host OS and kernel version?

Is the snapd service running in the container?

We have added the chromium package to this bug so they can investigate.

[jonathan boudreau (hellomynameisjony)]

I am running Ubuntu 18.04 as the host. "uname -a" output is: "Linux vagrant 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux"

The snapd service is not installed in the cloud image as far as I can tell. Even if it was it wouldn't be running since systemd isn't running as pid 1 normally inside of docker containers.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Olivier Tilloy (osomon)]

It looks like running snapd and snaps inside docker containers doesn't work out of the box.
This looks promising though: https://forum.snapcraft.io/t/running-snaps-inside-docker-containers/869.

[jonathan boudreau (hellomynameisjony)]

The bug report is for the fact that I can't get chromium working out of the box in containers anymore. Please reconsider marking this as invalid.

The forum post linked also recommends not doing this in a production environment. The workaround is not a viable option in my case.

[Tobias Krönke (tobias-kroenke)]

I agree this would just end up in messy workarounds. I see the main culprit in the snap daemon. I don't see a chance, that Ubuntu will switch back from snap to plain deb for this package because it fixes only this 1 snap. A fundamental solution would be to make snaps work in general for containerized applications. However, I have no clue, what the daemon does and if it can be made optional for containers.

[Olivier Tilloy (osomon)]

That's right, the problem lies in the interactions between snapd and docker, it's not specific to chromium.

[jonathan boudreau (hellomynameisjony)]

I fail to see how this is an issue specific to docker. If you wanted to write a snap that depends on chromium (e.g., some webdriver tooling), can you install snaps inside of a snap? I think the idea of installing snaps through apt is going to cause unexpected issues which aren't really resolvable in the short/mid term (meaning this will remain broken for 20.04).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Geoff Kendal (geftactics)]

We use chromium-browser in an 18.04 container for several thousand interactive kiosks.
This bug prevents us from fully updating to the latest LTS version of Ubuntu.

[Ian Johnson (anonymouse67)]

Unfortunately we have no such plans at this time to enable snapd / snaps to work inside docker containers. We recommend using lxd containers instead of docker as snaps are officially supported, secure, and tested to work inside lxd containers.

For a more complete answer about why it is very hard for us to support snapd inside dockerd, see https://forum.snapcraft.io/t/please-remove-systemd-dependency/17580/5

[Tianon Gravi (tianon)]

That's entirely fair, but in that case isn't going snap-only for "chromium-browser" a bit short-sighted, given the constraints on running snaps?

[jonathan boudreau (hellomynameisjony)]

For us the easiest solution is going to be moving to debian. Changing the underlying infra from docker to lxd is way too much effort.

[Fedor Korotkov (fkorotkov)]

Disclaimer: I'm working on a CI system.

Another 2 cents about this issue affecting CI systems, not only our CI-as-a-service solution but most of the modern CIs that embrace Docker containers for reproducibility and isolation of the CI builds. This issue means that people won't be able to run integration tests in browsers as they used to. In our experience this technique is becoming quite popular recently in front-end projects, just check Puppeteer or Playwright projects.

[Launchpad Janitor (janitor)]

[Expired for cloud-images because there has been no activity for 60 days.]

[jonaz__ (jonaz-86)]

This is really bad. Will have to use debian for all our headless pdf generators running in kubernetes :(