Octobot is now a Sparq company. For more info read the press release.

Octobot_Logo_A Sparq Company

Running Yeoman in a development instance in Docker

Running Yeoman in a development instance in Docker

We have been testing recently Docker images as our development environments. While trying to update some of our images, we came across an issue regarding Yeoman and permissions inside Docker containers.

				
					/usr/local/lib/node_modules/yo/node_modules/configstore/index.js:53
 throw err;
 ^
Error: EACCES: permission denied, open '/root/.config/configstore/insight-yo.json'
You don't have access to this file.

A good solution came in the issue at Yeoman and involves changing the default user to run commands after the image is created as a non-root user.

For instance, a container with Yeoman, Bower, Grunt and Gulp could look like the following.

				
					FROM node:argon
MAINTAINER Juan Saavedra <jsaavedra@octobot.io>
RUN apt-get update &&\
 apt-get install -y\
 ruby\
 rubygems\
 ruby-dev\
 python3\
 python3-pip &&\
 gem install compass sass
VOLUME /usr/development/app
WORKDIR /usr/development/app
RUN npm install -g yo bower grunt-cli gulp grunt
EXPOSE 9000
CMD ["grunt", "serve"]

The previous Dockerfile would generate an image where containers created upon that, would run commands as root. Which in case of yo creates the problem at hand.

In order to avoid such, you could do the following.

				
					...
RUN npm install -g yo bower grunt-cli gulp grunt
RUN useradd --create-home --shell /bin/bash non-root &&\
 usermod -aG sudo non-root &&\
 chown -R non-root:non-root /usr/development/app
USER non-root
EXPOSE 9000
CMD ["grunt", "serve"]

In that way, any commands you run later on are root-less and you can safely invoke yo

 
				
					$ docker run --rm YOURIMAGE bash
non-root@d61ea18027cb:/usr/development/app#

Another alternative (as of 1.10) could be configuring your local Docker daemon with propper user namespace mapping as seen here.

See related posts