Start full container in Docker? - docker

According to this github issue it should be possible to start a full container with Upstart, cron etc. with Docker 0.6 or later but how do I do that?
I was expecting that
docker run -t -i ubuntu /sbin/init
would work just like
lxc-start -n ubuntu /sbin/init
and I would get a login screen, but instead it displays nothing. I also tried to access it using ssh, but no luck. I'm using the default ubuntu image from Docker index.

docker run ubuntu /sbin/init appears to work flawlessly for me with 0.6.6. You won't get a login screen because Docker only manages the process. Instead, you can use docker ps -notrunc to get the full lxc container ID and then use lxc-attach -n <container_id> run bash in that container as root. sshd isn't installed in the container, so you can't ssh to it.

You can use the ubuntu-upstart image:
docker run -t -i ubuntu-upstart:14.04 /sbin/init
Although this solution is unfortunately deprecated, it is good enough if you need a full OS container that 'drives' like a normal Ubuntu 12.04, 14.04 or 14.10 (change the :14.04 bit) system today. If no version is specified it defaults to 14.04. I have not used it heavily, and had some issues installing more complicated packages (e.g. dbus!), but it might work for you.
Alas Ubuntu has switched to systemd in more recent releases. Googling reveals that there seems to be ongoing work to make systemd work in a docker container without requiring elevated privileges, but it does not seem to be quite ready for prime-time. Hopefully it will be ready when 16.04 becomes LTS.
Another option is of course to use phusion/baseimage, but it has it's own approach for starting services. Seems better suited to minimal multi-process containers.

Related

How can I implement Docker outside of Docker setup for Jenkins using Docker Desktop for Windows?

I'm trying to create a CI/CD infrastructure using Jenkins. Considering recoverability, performance and maintainability topics I decided to handle both Jenkins and agents as Docker containers.
There are some certain restrictions that I cannot workaround:
Cannot build this setup on Linux environment (IT policy)
Cannot use WSL2 on Windows (I don't know when IT department will release regarding Windows update that supports WSL2)
Security is a very high priorty topic
As far as I see, Docker outside of Docker setup is the proper way to implement. If I run the container as root using the command below, I can bind the docker.sock file and Jenkins jobs can create containers from Dockerfiles as agents:
docker run --name dood `
-d -u root --restart on-failure `
-p "8080:8080" -p "50000:50000" `
-v //var/run/docker.sock:/var/run/docker.sock `
-v /usr/local/bin/docker:/usr/bin/docker `
jenkins/jenkins:lts
However, it doesn't work if Jenkins container is run with non-root user. This is not acceptable as it creates vulnerability. Suggested way is to run the container without root user and assign "jenkins" user to "docker" group:
groupadd docker
usermod -a -G docker jenkins
newgrp docker
Unfortunately, it doesn't work. "Got permission denied..." error occurs when Jenkins jobs try to create agent containers. I restarted Docker Desktop and container but result is the same. I am not sure but possible reason might be the Windows environment. This may work in Linux environment.
As a final effort, I tried the solution that is described in a stackoverflow topic. I noticed "setfacl" command does not work when Docker runs with Hyper-V. If I switch to WSL2 on my demo PC then the commands below solve the problem:
gpasswd -a jenkins docker
apt-get install acl
setfacl -m user:jenkins:rw /var/run/docker.sock
Unfortunately, target Windows environment does not support WSL2 so I cannot use this solution. Moreover, setfacl command is not persistent but this is another story.
An alternative solution might be activating "Expose daemon on tcp://localhost:2375 without TLS" option. However, this is not acceptable in security point of view so I cross it out.
I am curious if it is even possible to implement Docker outside of Docker setup for Jenkins on Docker Desktop for Windows. Considering the named restrictions, I am open to alternative setups/solutions as well.
I am quite new to Docker and not very experienced with Jenkins. If I use wrong terminology or approach please let me know.

Can I use docker for installing ubuntu on a Mac?

I'm using a Mac, but I want to learn and use Ubuntu for development and I don't care about the GUI. I used to use Vagrant and ssh to the machine, but it consumes much of my machine resources. Can I use docker for the same purpose while also having the isolation (when I mess things up) of a VM?
First install Docker Desktop for Mac.
Then in a terminal window run: docker run -it --name ubuntu ubuntu:xenial bash
You are in a terminal with ubuntu and can do whatever you like.
Note: If you are using an ubuntu version bionic (18.04) or newer (ubuntu:bionic or ubuntu:latest), you
must run the command unminimize inside the container so the tools
for human interaction be installed.
To start again after a reboot:
docker start ubuntu
docker exec -it ubuntu bash
If you want save your changes:
docker commit ubuntu
docker images
See the unnamed image and:
docker tag <imageid> myubuntu
Then you can run another container using your new image.
docker run -it --name myubuntu myubuntu bash
Or replace the former
docker stop ubuntu
docker rm ubuntu
docker run -it --name ubuntu myubuntu bash
Hope it helps
This is one of the few scenarios I wouldn't use Docker for :)
Base images like Ubuntu are heavily stripped down versions of the full OS. The latest Ubuntu image doesn't have basic tools like ping and curl - that's a deliberate strategy from Canonical to minimise the size of the image, and therefore the attack vector. Typically you'd build an image to run a single app process in a container, you wouldn't SSH in and use ordinary dev tools, so they're not needed. That will make it hard for you to learn Ubuntu, because a lot of the core stuff isn't there.
On the Mac, the best VM tool I've used is Parallels - it manages to share CPU without hammering the battery. VirtualBox is good too, and for either of them you can install full Ubuntu Server from the ISO - 5GB disk and 1GB RAM allocation will be plenty if you're just looking around.
With any hypervisor you can pause VMs so they stop using resources, and checkpoint them to save the image so you can restore back to it later.
Yes, you can.
Try searching docker hub for ubuntu containers of your choice (version and who is supporting the image)
Most of them are very well documented on what was used to build it and also how to run and access/expose resources if needed.
Check the official one here: https://hub.docker.com/_/ubuntu/

How to access the VM created by docker's HyperKit?

Docker for Mac uses a Linux VM created by HyperKit for storing and running containers on Mac.
With Docker Toolbox, I can just open VirtualBox and access the docker-machine VM. But with Docker for Mac, how do I access the VM created by HyperKit?
Update 2019-01-31, thanks to ru10's update, now there is a better way:
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
Original Answer:
After a while, I found following way to get a shell of the VM that was created by HyperKit:
Run from terminal:
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
You will see an empty screen, then type enter, you will get a login prompt. Login as root and hit enter, you will get a shell (no password), you will gett the shell:
To exit the session, type Ctrl-A k (then y to confirm).
It is a little bit hacky, but it seems to work for now (Sep 2016) (Sep 2017).
Mac OS High Sierra Docker version 18.06.0-ce-mac70 (26399)
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
instead of
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
According to this GitHub issue comment by a Docker maintainer, the recommended way to access the VM is through a privileged docker container.
Try logging into the VM: (I recommend this instead of using screen on the TTY)
$ docker run -it --privileged --pid=host justincormack/nsenter1
In fact, the answer from augurar is the only working as of 2021 as smammy says, the other options are deprecated.
So:
$ docker run -it --privileged --pid=host justincormack/nsenter1
was the right answer and worked for me in MacOS Big Sur as of July 2021.
I'm using docker desktop 4.7.1 on Mac. As mentioned, some of the good solutions proposed above does not work on newer docker desktop (tty link is gone).
I preferred the solution of Smammy which does not involve using image from unverified publisher (image: justincormack/nsenter1, though the image comes from a docker maintainer and the repository has a lot of stars), especially when it needs to run the docker with '--privileged' flag which grant the docker full access to the host machine.
This worked for me (using busybox image, which contains nsenter utility):
docker run -it --rm --privileged --pid=host busybox nsenter -t1 -m -u -i -n
you can find explanation of the command at
https://www.bretfisher.com/docker-for-mac-commands-for-getting-into-local-docker-vm/ (and similar suggestion, using debian image instead of busybox)
another solution proposed there (but less convenient, as it does not have auto-completion) is to use netcat
nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock

Setting absolute limits on CPU for Docker containers

I'm trying to set absolute limits on Docker container CPU usage. The CPU shares concept (docker run -c <shares>) is relative, but I would like to say something like "let this container use at most 20ms of CPU time every 100ms. The closest answer I can find is a hint from the mailing list on using cpu.cfs_quota_us and cpu.cfs_period_us. How does one use these settings when using docker run?
I don't have a strict requirement for either LXC-backed Docker (e.g. pre0.9) or later versions, just need to see an example of these settings being used--any links to relevant documentation or helpful blogs are very welcome too. I am currently using Ubuntu 12.04, and under /sys/fs/cgroup/cpu/docker I see these options:
$ ls /sys/fs/cgroup/cpu/docker
cgroup.clone_children cpu.cfs_quota_us cpu.stat
cgroup.event_control cpu.rt_period_us notify_on_release
cgroup.procs cpu.rt_runtime_us tasks
cpu.cfs_period_us cpu.shares
I believe I've gotten this working. I had to restart my Docker daemon with --exec-driver=lxc as I
could not find a way to pass cgroup arguments to libcontainer. This approach worked for me:
# Run with absolute limit
sudo docker run --lxc-conf="lxc.cgroup.cpu.cfs_quota_us=50000" -it ubuntu bash
The necessary CFS docs on bandwidth limiting are here.
I briefly confirmed with sysbench that this does seem to introduce an absolute limit, as shown below:
$ sudo docker run --lxc-conf="lxc.cgroup.cpu.cfs_quota_us=10000" --lxc-conf="lxc.cgroup.cpu.cfs_period_us=50000" -it ubuntu bash
root#302e651c0686:/# sysbench --test=cpu --num-threads=1 run
<snip>
total time: 90.5450s
$ sudo docker run --lxc-conf="lxc.cgroup.cpu.cfs_quota_us=20000" --lxc-conf="lxc.cgroup.cpu.cfs_period_us=50000" -it ubuntu bash
root#302e651c0686:/# sysbench --test=cpu --num-threads=1 run
<snip>
total time: 45.0423s

Not enough entropy to support /dev/random in docker containers running in boot2docker

Running out of entropy in virtualized Linux systems seems to be a common problem (e.g. /dev/random Extremely Slow?, Getting linux to buffer /dev/random). Despite of using a hardware random number generator (HRNG) the use of a an entropy gathering daemon like HAVEGED is often suggested. However an entropy gathering daemon (EGD) cannot be run inside a Docker container, it must be provided by the host.
Using an EGD works fine for docker hosts based on linux distributions like Ubuntu, RHEL, etc. Getting such a daemon to work inside boot2docker - which is based on Tiny Core Linux (TCL) - seems to be another story. Although TCL has a extension mechanism, an extension for an entropy gathering daemon doesn't seem to be available.
So an EGD seems like a proper solution for running docker containers in a (production) hosting environment, but how to solve it for development/testing in boot2docker?
Since running an EGD in boot2docker seemed too difficult, I thought about simply using /dev/urandom instead of /dev/random. Using /dev/urandom is a litte less secure, but still fine for most applications which are not generating long-term cryptographic keys. At least it should be fine for development/testing inside boot2docker.
I just realized, that it is simple as mounting /dev/urandom from the host as /dev/random into the container:
$ docker run -v /dev/urandom:/dev/random ...
The result is as expected:
$ docker run --rm -it -v /dev/urandom:/dev/random ubuntu dd if=/dev/random of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00223239 s, 459 kB/s
At least I know how to build my own boot2docker images now ;-)
The most elegant solution I've found is running Haveged in separate container:
docker pull harbur/haveged
docker run --privileged -d harbur/haveged
Check whether enough entropy available:
$ cat /proc/sys/kernel/random/entropy_avail
2066
Another option is to install the rng-tools package and map it to use the /dev/urandom
yum install rng-tools
rngd -r /dev/urandom
With this I didn't need to map any volume in the docker container.
Since I didn't like to modify my Docker containers for development/testing I tried to modify the boot2docker image. Luckily, the boot2docker image is build with Docker and can be easily extended. So I've set up my own Docker build boot2docker-urandom. It extends the standard boot2docker image with a udev rule found here.
Building your own boot2docker.iso image is simple as
$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso
To replace the standard boot2docker.iso that comes with boot2docker you need to:
$ boot2docker stop
$ boot2docker delete
$ mv boot2docker.iso ~/.boot2docker/
$ boot2docker init
$ boot2docker up
Limitations, from inside a Docker container /dev/random still blocks. Most likely, because the Docker containers do not use /dev/random of the host directly, but use the corresponding kernel device - which still blocks.
Alpine Linux may be a better choice for a lightweight docker host. Alpine LXC & docker images are only 5mb (versus 27mb for boot2docker)
I use haveged on Alpine for LXC guests & on Debian for docker guests. It gives enough entropy to generate gpg / ssh keys & openssl certificates in containers. Alpine now has an official docker repo.
Alternatively build a haveged package for Tiny Core - there is a package build system available.
if you have this problem in a docker container created from a self-built image that runs a java app (e.g. created FROM tomcat:alpine) and don't have access to the host (e.g. on a managed k8s cluster), you can add the following command to your dockerfile to use non-blocking seeding of SecureRandom:
RUN sed -i.bak \
-e "s/securerandom.source=file:\/dev\/random/securerandom.source=file:\/dev\/urandom/g" \
-e "s/securerandom.strongAlgorithms=NativePRNGBlocking/securerandom.strongAlgorithms=NativePRNG/g" \
$JAVA_HOME/lib/security/java.security
the two regex expressions replace file:/dev/random by file:/dev/urandom and NativePRNGBlocking by NativePRNG in the file $JAVA_HOME/lib/security/java.security which causes tomcat to startup reasonably fast on a vm. i haven't checked whether this works also on non alpine-based openjdk images, but if the sed command fails, just check the location of the file java.security inside the container and adapt the path accordingly.
note: in jdk11 the path has changed to $JAVA_HOME/conf/security/java.security

Resources