Once you start messing around with desktop containers, you end up doing a lot of things 'because you can' and not because they're a particularly good idea. For example, I need to run multiple Firefox instances under different profiles in order to maintain various social media accounts, such as the @projectatomic twitter feed. Now, I could do that by launching Firefox with various -P flags, but that would be no fun at all. Instead, I'm going to launch Firefox in a container.

• Docker Linux Download
• Docker Firefox Vnc
• Firefox Docker Container
• Docker Linux Install
• Docker Linux
• Docker Hub Firefox

The above dockerfile contains the sequence of instructions to create an Ubuntu base image, runs an apt update on it, installs Xauth and Firefox. It then exposes port 8887 and runs Firefox. Xauth simply allows Docker Containers to access the Display Servers. Copying the Cookie to connect X Server Displays. When executing docker run for an image that contains a browser please either mount -v /dev/shm:/dev/shm or use the flag -shm-size=2g to use the host's shared memory. Always use a Docker image with a full tag to pin a specific browser and Grid version. See Tagging Conventions for details.

1. Follow the steps to run firefox(GUI App) on the top of docker:. 1) Create a Dockerfile that consist firefox as an application. Instructions used:-FROM centos:8; RUN yum install firefox -y.
2. Docker build -t username/firefox. Next we need to make sure that the docker container is allowed to run X11 apps on your desktop machine, so that Firefox can run inside the container but be displayed on your desktop. This is a simple command, allowing anyone on localhost to run X apps: xhost + 127.0.0.1.

Mind you, if you're a webdev or a desktop hacker, this would be a good way to launch various hacked versions of Firefox without messing with the browser you need every day. There's four basic steps here:

1. build a Firefox image
2. authorize X11 connections from containers
3. enable Firefox connections in SELinux
4. run the container

First, build the Firefox image. This is fairly standard except that you need to tailor it to the UID and GID of your desktop user so that you don't have to jump through a lot of hoops to get SELinux to authorize connecting from the container to your desktop X server. I use a Dockerfile like this one:
#!/bin/bash
FROM fedora
# install firefox
RUN dnf install -y firefox
# install dependancies
RUN dnf install -y libcanberra-gtk3 PackageKit-gtk3-module
dbus dbus-devel dbus-x11
RUN dbus-uuidgen --ensure

# make uid and gid match inside and outside the container
# replace 1000 with your gid/uid, find them by running
# the id command
RUN export uid=1000 gid=1000 &&
mkdir -p /home/firefox &&
echo 'firefox:x:${uid}:${gid}:Developer,:/home/firefox:/bin/bash' >> /etc/passwd &&
echo 'firefox:x:${uid}:' >> /etc/group &&
echo 'firefox ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers &&
chmod 0440 /etc/sudoers &&
chown ${uid}:${gid} -R /home/firefox

#remove cache from the image to shrink it a bit
RUN dnf clean all

# set up and run firefox
USER firefox
ENV HOME /home/firefox
CMD /usr/bin/firefox -no-remote

Finally, your Firefox container should be ready to go. Except you need to add some flags, due to the need to share the X11 socket between the container and the desktop. Here's what I use:
docker run -it -e DISPLAY --net=host jberkus/firefox
This should bring up Firefox in a window on your desktop, under a profile and cache which exists only in the container. If you want to always dispose of this Firefox without saving anything, add an --rm flag to the above.
If you don't want to paste all of the above from a blog (and really, who does?) I've put up some scripts on Github.
Now, if only I could figure out why fonts aren't rendering correctly in Firefox run this way. Ideas?

TaskCluster Docker images are defined in the source directory undertaskcluster/docker. Each directory therein contains the name of animage used as part of the task graph.

Organization¶

Each folder describes a single docker image. We have two types of images that can be defined:

1. Task Images (build-on-push)

2. Docker Images (prebuilt)

These images depend on one another, as described in the FROM line at the top of theDockerfile in each folder.

Images could either be an image intended for pushing to a docker registry, orone that is meant either for local testing or being built as an artifact whenpushed to vcs.

Task Images (build-on-push)¶

Images can be uploaded as a task artifact, indexed undera given namespace, and used in other tasks by referencing the task ID.

Important to note, these images do not require building and pushing to a docker registry, and arebuilt per push (if necessary) and uploaded as task artifacts.

The decision task that is run per push will determineif the image needs to be built based on the hash of the context directory and if the imageexists under the namespace for a given branch.

As an additional convenience, and a precaution to loading images per branch, if an imagehas been indexed with a given context hash for mozilla-central, any tasks requiring that imagewill use that indexed task. This is to ensure there are not multiple images built/usedthat were built from the same context. In summary, if the image has been built for mozilla-central,pushes to any branch will use that already built image.

To use within an in-tree task definition, the format is:

Context Directory Hashing¶

Decision tasks will calculate the sha256 hash of the contents of the imagedirectory and will determine if the image already exists for a given branch and hashor if a new image must be built and indexed.

Note: this is the contents of only the context directory, not theimage contents.

The decision task will:

1. Recursively collect the paths of all files within the context directory

2. Sort the filenames alphabetically to ensure the hash is consistently calculated

3. Generate a sha256 hash of the contents of each file

4. All file hashes will then be combined with their path and used to update thehash of the context directory

This ensures that the hash is consistently calculated and path changes will resultin different hashes being generated.

Task Image Index Namespace¶

Images that are built on push and uploaded as an artifact of a task will be indexed under thefollowing namespaces.

• gecko.cache.level-{level}.docker.v2.{name}.hash.{digest}

• gecko.cache.level-{level}.docker.v2.{name}.latest

• gecko.cache.level-{level}.docker.v2.{name}.pushdate.{year}.{month}-{day}-{pushtime}

Not only can images be browsed by the pushdate and context hash, but the ‘latest’ namespaceis meant to view the latest built image. This functions similarly to the ‘latest’ tagfor docker images that are pushed to a registry.

Docker Registry Images (prebuilt)¶

*Warning: Registry images are only used for ``decision`` and``image_builder`` images.*

Docker Linux Download

These are images that are intended to be pushed to a docker registry and usedby specifying the docker image name in task definitions. They are generallyreferred to by a <repo>@<repodigest> string:

Example:

Such images must always be referred to with both a version and a repo digest.For the decision image, the repo digest is stored in the HASH file in theimage directory and used to refer to the image as above. The version for bothimages is in VERSION.

The version file serves to help users identify which image is being used, and makes oldversions easy to discover in the registry.

The file taskcluster/docker/REGISTRY specifies the image registry to whichthe completed image should be uploaded.

Docker Hashes and Digests¶

There are several hashes involved in this process:

Docker Firefox Vnc

• Image Hash – the long version of the image ID; can be seen withdockerimages--no-trunc or in the Id field in dockerinspect.

• Repo Digest – hash of the image manifest; seen when running dockerpush or dockerpull.

• Context Directory Hash – see above (not a Docker concept at all)

The use of hashes allows older tasks which were designed to run on an olderversion of the image to be executed in Taskcluster while new tasks use the newversion. Furthermore, this mitigates attacks against the registry as dockerwill verify the image hash when loading the image.

(Re)-Building images¶

Generally, images can be pulled from the Docker registry rather than builtlocally, however, for developing new images it’s often helpful to hack on themlocally.

To build an image, invoke machtaskcluster-build-image with the name of thefolder (without a trailing slash):

This is a wrapper around dockerbuild-t$REGISTRY/$FOLDER:$VERSION.

It’s a good idea to bump the VERSION early in this process, to avoiddockerpush-ing over any old tags.

For task images, test your image locally or push to try. This is all that isrequired.

Docker Registry Images¶

Landing docker registry images takes a little more care.

Begin by bumping the VERSION. Once the new version of the image has beenbuilt and tested locally, push it to the docker registry and make note of theresulting repo digest. Put this value in the HASH file for thedecision image and in taskcluster/taskgraph/transforms/docker_image.pyfor the image_builder image.

The change is now safe to use in Try pushes.

Firefox Docker Container

Note that image_builder change can be tested directly in try pushes withoutusing a registry, as the in-registry image_builder image is used to build atask image which is then used to build other images. It is referenced by hashin taskcluster/taskgraph/transforms/docker_image.py.

Special Dockerfile Syntax¶

Docker Linux Install

Dockerfile syntax has been extended to allow any file from thesource checkout to be added to the image build context. (Traditionallyyou can only ADD files from the same directory as the Dockerfile.)

Simply add the following syntax as a comment in a Dockerfile:

e.g.

# %include mach# %include testing/mozharness

The argument to #%include is a relative path from the root level ofthe source directory. It can be a file or a directory. If a file, only thatfile will be added. If a directory, every file under that directory will beadded (even files that are untracked or ignored by version control).

Docker Linux

Files added using #%include syntax are available inside the buildcontext under the topsrcdir/ path.

Docker Hub Firefox

Files are added as they exist on disk. e.g. executable flags should bepreserved. However, the file owner/group is changed to root and themtime of the file is normalized.

Here is an example Dockerfile snippet: