I'm using this guide to Build a Voice Kit with Amazon Lex and a Raspberry Pi, but I need to use Docker. The problem is that the script that the guide curls and runs requires access to /dev/tty. I can grant access to /dev/tty when running docker containers, but I don't know how to do that when building containers.
My Dockerfile looks like this:
FROM resin/rpi-raspbian
WORKDIR /app
ADD . /app
#The script requires these
RUN apt-get update
RUN apt-get install iputils-ping
#The script has to be run with sudo priviliges but not as root
USER root
ADD /sudoers.txt /etc/sudoers
RUN chmod 440 /etc/sudoers
RUN useradd -ms /bin/bash lex
RUN echo 'lex:test' | chpasswd
RUN curl https://get.pimoroni.com/phatdac | bash
USER lex
EXPOSE 80
#Comment the last RUN command and uncomment this
#CMD curl https://get.pimoroni.com/phatdac | bash
And when I try to build the container with
docker build -t raspi1 .
it crashes on the script, because it can't access /dev/tty.
When running a container, I can use this script to grant access to /dev/tty and /dev/snd
#!/bin/sh
docker run -ti --rm \
-v /dev/snd:/dev/snd \
--privileged \
raspi7
and then try to use the script on the startup with CMD in the Dockerfile. But if I do that, then I need to use the script every time when running and I also need to do RUN on other stuff after the script has finished which would be nice to have on the Dockerfile when building.
TLDR; How to grant privileges to /dev/tty and /dev/snd when building a docker image?
What is Docker Privileged Mode? Docker privileged mode grants a Docker container root capabilities to all devices on the host system. Running a container in privileged mode gives it the capabilities of its host machine. For example, it enables it to modify App Arm and SELinux configurations.
The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.
privileged : determines if any container in a pod can enable privileged mode. By default a container is not allowed to access any devices on the host, but a "privileged" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host.
Docker currently doesn't support exposing devices, or for that matter privileged operations when building.
According to @cpuguy83 what you are doing now - building a portable image without access to the host and completing the configuration when the container is first started - is the right thing to do:
Doing this kind of stuff at first container start is exactly the right way to go. It's a runtime configuration it shouldn't be in the image.
See bountysource.
There is also and old but still open moby's issue.
Your problem is probably that /dev/snd doesn't exist inside your docker image. When you run your container, you are actually mounting your host OS /dev/snd inside the container so that your script can be run. Take a look at the following:
[INSERT] > cat Dockerfile
FROM resin/rpi-raspbian
RUN ls /dev && ls /dev/tty && ls /dev/snd
[INSERT] > docker build .
Sending build context to Docker daemon 39.94kB
Step 1/2 : FROM resin/rpi-raspbian
---> d008ca006edc
Step 2/2 : RUN ls /dev && ls /dev/tty && ls /dev/snd
---> Running in 0b738007c71c
core
fd
full
mqueue
null
ptmx
pts
random
shm
stderr
stdin
stdout
tty
urandom
zero
/dev/tty
/bin/ls: cannot access /dev/snd: No such file or directory
The command '/bin/sh -c ls /dev && ls /dev/tty && ls /dev/snd' returned a non-zero code: 2
As you can see, /dev/tty exists, and you have access to it. /dev/snd does not exist, and you aren't inside a running container so you can't mount it as a volume (which you are doing when running the container). I would recommend trying to more fully understand what the script you are running is doing, assess whether it needs access to the host machine's /dev/snd, and if so you may only run the script inside the running container as an image doesn't have any concept of a host machine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With