Aug 06, 2014
Ken Sipe
D2iQ
2 min read
Deprecated: Deimos is now deprecated. See our tutorial on launching a Docker container with Mesosphere for the current instructions.
Using Docker repositories requiring login credentials is possible with Mesosphere's Deimos on Mesos, however it commonly requires extra configuration on the slave. This post describes the details of what is needed and how to configure Mesosphere to use a private Docker repository.
Docker Config File
When you want to run containers from a private Docker repository, it is necessary to be signed in to that repository. Authentication sessions are stored in a file called ~/.dockercfg and are created by sudo docker login. The technical location the file is created in is defined by the system environment variable $HOME. The Docker code specifically uses golang's os.Getenv("HOME") making the availability of $HOME essential.
Deimos Environment
Deimos is an Apache Mesos external containerizer. When configured on a Mesos slave, the slave will use Docker images as the container technology. Deimos is configured at the slave using the --containerizer_path=/usr/local/bin/deimos --isolation=external configuration. Deimos environment is defined by the environment of the Mesos slave process.
It is common to run the Mesos slave as root. When running as root, it is common for $HOME to not be set. When launching Docker images that are pulled from a private repository using Deimos, it is essential that the $HOME be set.
Solution: Pre-Install the Docker Config File on Your Slave
The current way to handle this situation is to copy the .dockercfg file from where ever it was originally created to a specific path on each of your slaves and exporting $HOME for either root or the start of mesos-slave. Example: With .dockercfg in /, set the $HOME for root export HOME=/. The consequence is that you will need to preconfigure each slave and that the private repositories used for Mesos frameworks will be limited to those defined in the .dockercfg.
On the roadmap is the ability to have a .dockercfg defined as part of the job description, removing this extra provisioning step.
