github/linuxkit
1
0
Fork 0
mirror of https://github.com/linuxkit/linuxkit.git synced 2026-04-09 03:25:36 +00:00
Code Issues Projects Releases Wiki Activity

add pinata modified boot2docker until replaced by real Moby

Browse Source 
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit is contained in:
Justin Cormack
2015-11-27 11:46:27 +00:00
parent 0fa1e68dc6
commit 5b99c08596
50 changed files with 6734 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
boot2docker/doc/AUTOMATED_SCRIPT.md Normal file
View File

@@ -0,0 +1,49 @@
Automated script
===========
## Overview
The document describes the "automated script" functionality and some use cases. I assume
you have basic knowledge of iPxe/pxe booting. Please see the following link for more documentaion regarding iPxe:
http://ipxe.org/
## Summary
Automated script allows you to run an arbitrary script as a boot parameter. The script
parses `/proc/cmdline` for `script` variable and download the script if its either
an ftp or http uri. This method is used by Archlinux to install unattendedly. Please see the
following link for reference:
https://projects.archlinux.org/archiso.git/tree/configs/releng/airootfs/root/.automated_script.sh
## Usecase
Lets say you want to run boot2docker on multiple physical machines and you want run hashicorp/consul
on all machines. You boot the machine via ipxe and add `script` as a parameter. The script you
use could take information from the host as an identifier and announce itself using that information.
## Extracting initrd and vmlinuz64
You mount the iso and the files are located in `/boot`.
## Extracting boot parameters
Extracting the parameters and adjusting these will help you boot and provision using iPxe. It will also
help you understand how boot2docker is being run currently.
```
root@896569876a97:/# cat /proc/cmdline
loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10:LABEL=boot2docker-data base initrd=/boot/initrd.img BOOT_IMAGE=/boot/vmlinuz64
```
## iPxe example
```
#!ipxe
set script http://192.168.3.3:4321/repo/script.sh
set append loglevel=3 user=docker console=ttyS0 console=tty nomodeset norestore base script=${script}
set kernel http://192.168.3.3:4321/repo/vmlinuz64
set initrd http://192.168.3.3:4321/repo/initrd.img
imgfree
kernel ${kernel} ${append}
initrd ${initrd}
boot
```

48
boot2docker/doc/BUILD.md Normal file
View File

@@ -0,0 +1,48 @@
How to build boot2docker.iso locally
================================
The boot2docker.iso is built with Docker, via a Dockerfile.
During `docker build` we
* fetch, patch with AUFS support and build the 3.15.3 Linux Kernel with Tiny Core base configuration
* build the base rootfs for boot2docker (not complete)
* build the rootfs, download the latest Docker release and create the `.iso` file on `/` of the container.
Running the resultant image will cat the iso file to STDOUT.
So the full build process goes like this:
```console
# you will need more than 2GB memory
$ docker build -t boot2docker . && docker run --rm boot2docker > boot2docker.iso
```
Now you can install the iso to a USB drive, SD card, CD-Rom or hard-disk. The image contains
a Master Boot Record, and a partition table, so can be written to a raw device.
```console
$ sudo dd if=boot2docker.iso of=/dev/sdX
```
Making your own customised boot2docker ISO
==========================================
The `boot2docker.iso` release process takes advantage of Docker Hub's
[Automated Builds](https://index.docker.io/u/boot2docker/) so
rather than modifying the `Dockerfile` and re-building from scratch,
you can make a new ``Dockerfile`` that builds ``FROM boot2docker/boot2docker``
and then run that to generate your `boot2docker.iso` file:
```console
$ sudo docker pull boot2docker/boot2docker
$ echo "FROM boot2docker/boot2docker" > Dockerfile
$ echo "ADD . $ROOTFS/data/" >> Dockerfile
$ echo "RUN somescript.sh" >> Dockerfile
$ echo "RUN /make_iso.sh" >> Dockerfile
$ echo 'CMD ["cat", "boot2docker.iso"]' >> Dockerfile
$ sudo docker build -t my-boot2docker-img .
$ sudo docker run --rm my-boot2docker-img > boot2docker.iso
```

164
boot2docker/doc/FAQ.md Normal file
View File

@@ -0,0 +1,164 @@
# FAQ
## I've just installed a new Boot2Docker and I get `client and server don't have the same version`
There's a good chance that your Boot2Docker virtual machine existed before you
upgraded your Docker client - what you need to run, is `boot2docker upgrade`.
For example, on Windows, having just installed using the 1.6.0 installer, I
had the following:
```
export DOCKER_TLS_VERIFY=1
You can now use `docker` directly, or `boot2docker ssh` to log into the VM.
Welcome to Git (version 1.9.4-preview20140929)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
svend_000@BIG ~
$ docker info
FATA[0000] Error response from daemon: client and server don't have same version
(client : 1.18, server: 1.17)
svend_000@BIG ~
$ boot2docker.exe upgrade
boot2docker is up to date (v1.6.0), skipping upgrade...
Latest release for github.com/boot2docker/boot2docker is v1.6.0
Downloading boot2docker ISO image...
Success: downloaded https://github.com/boot2docker/boot2docker/releases/download
/v1.6.0/boot2docker.iso
to C:\Users\svend_000\.boot2docker\boot2docker.iso
Waiting for VM and Docker daemon to start...
...............ooo
Started.
Writing C:\Users\svend_000\.boot2docker\certs\boot2docker-vm\ca.pem
Writing C:\Users\svend_000\.boot2docker\certs\boot2docker-vm\cert.pem
Writing C:\Users\svend_000\.boot2docker\certs\boot2docker-vm\key.pem
To connect the Docker client to the Docker daemon, please set:
export DOCKER_CERT_PATH='C:\Users\svend_000\.boot2docker\certs\boot2docker-v
m'
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://192.168.59.103:2376
svend_000@BIG ~
$ docker info
Containers: 0
Images: 6
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 6
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.18.11-tinycore64
Operating System: Boot2Docker 1.6.0 (TCL 5.4); master : a270c71 - Thu Apr 16 19:
50:36 UTC 2015
CPUs: 8
Total Memory: 1.961 GiB
Name: boot2docker
ID: JGXX:ZFVX:WNJX:SSNB:QHU6:FP7P:VFDJ:EE3J:ZRYU:X3IR:6BD2:BEWM
Debug mode (server): true
Debug mode (client): false
Fds: 11
Goroutines: 16
System Time: Tue Apr 28 01:52:11 UTC 2015
EventsListeners: 0
Init SHA1: 9145575052383dbf64cede3bac278606472e027c
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
```
## What are the specs of the VM?
* CPU Cores: same as host (physical, not logical)
* 40gb HDD (auto-initialized at first boot)
* 2GB memory
* Autoboots to Boot2Docker
* `virtio` high performance networking
* NAT networked (Docker `2375->2375` and SSH `22->2022` are forwarded to the host)
## How can I solve my problems with SSH?
If `ssh` complains about the keys:
```
$ ssh-keygen -R '[localhost]:2022'
```
## Login as root
Run `sudo -s` as the docker user.
## What is the Boot2Docker distribution based on?
It is based on a stripped down [Tiny Core Linux](http://tinycorelinux.net).
## Why not CoreOS?
I got asked that question a lot, so I thought I should put it here once and for
all. [CoreOS](http://coreos.com/) is targeted at building infrastructure and
distributed systems. I just wanted the fastest way to boot to Docker.
## Persistent partition choice
Boot2Docker will first try to mount a partition labeled ``boot2docker-data``, if
that doesn't exist, it will pick the first ``ext4`` partition listed by ``blkid``.
## Local Customisation (with persistent partition)
Changes outside of the `/var/lib/docker` and `/var/lib/boot2docker` directories
will be lost after powering down or restarting the boot2docker VM. However, if
you have a persistence partition (created automatically by `boot2docker init`),
you can make customisations that are run at the end of boot initialisation by
creating a script at ``/var/lib/boot2docker/bootlocal.sh``.
From Boot2Docker version 1.6.0, you can also specify steps that are run before
the Docker daemon is started, using `/var/lib/boot2docker/bootsync.sh`.
You can also set variables that will be used during the boot initialisation (after
the automount) by setting them in `/var/lib/boot2docker/profile`
For example, to download ``pipework``, install its pre-requisites (which you can
download using ``tce-load -w package.tcz``), and then start a container:
```
#!/bin/sh
if [ ! -e /var/lib/boot2docker/pipework ]; then
curl -o /var/lib/boot2docker/pipework https://raw.github.com/jpetazzo/pipework/master/pipework
chmod 777 /var/lib/boot2docker/pipework
fi
#need ftp://ftp.nl.netbsd.org/vol/2/metalab/distributions/tinycorelinux/4.x/x86/tcz/bridge-utils.tcz
#and iproute2 (and its friends)
su - docker -c "tce-load -i /var/lib/boot2docker/*.tcz"
#start my management container if its not already there
docker run -d -v /var/run/docker.sock:/var/run/docker.sock $(which docker):$(which docker) -name dom0 svens-dom0
```
Or, if you need to tell the Docker daemon to use a specific DNS server, add the
following to ``/var/lib/boot2docker/profile``:
```
EXTRA_ARGS="--dns 192.168.1.2"
```
## What is the development process
We are implementing the same process as [Docker merge approval](
https://github.com/dotcloud/docker/blob/master/CONTRIBUTING.md#merge-approval),
so all commits need to be done via pull requests, and will need 2 or more LGTMs.
## Is boot2docker only for VirtualBox?
There are two parts of Boot2Docker: the ISO image, and the `boot2docker` management
tool to set up and manage a VM. The management tool only works with VirtualBox,
but the ISO image is designed to also be used with physical hardware. There
are no plans to make separate ISO images for different configurations.

131
boot2docker/doc/WORKAROUNDS.md Normal file
View File

@@ -0,0 +1,131 @@
Workarounds
===========
## Connection Issues
There are currently a few connections issues in Boot2docker. If you see
Couldn't connect to Docker daemon
or something like
FATA[0000] An error occurred trying to connect: Get https://192.168.59.107:2376/v1.18/containers/json?all=1: x509: certificate is valid for 127.0.0.1, 10.0.2.15, not 192.168.59.107
it could be one of many issues reported recently. Try this
boot2docker ssh sudo /etc/init.d/docker restart
and run `docker ps` to see if you can connect. If not, then try deleting the keys
boot2docker ssh sudo rm /var/lib/boot2docker/tls/server*.pem
boot2docker ssh sudo /etc/init.d/docker restart
boot2docker shellinit
and run `docker ps` to see if you can connect. If that doesn't work:
- `boot2docker restart`
- `docker ps` # Should see some output, not errors.
## Port forwarding
> **Note**: these instructions are for TCP only, not UDP. If you need to port forward
> UDP packets, the commands are similar. Please see the [VirtualBox
> NAT documentation](https://www.virtualbox.org/manual/ch06.html#network_nat)
> for more details.
Let's say your Docker container exposes the port 8000 and you want access it from
your other computers on your LAN. You can do it temporarily, using `ssh`:
Run following command (and keep it open) to use ssh to forward all accesses
to your OSX/Windows box's port 8000 to the Boot2Docker virtual machine's port
8000:
```sh
$ boot2docker ssh -vnNTL *:8000:localhost:8000
```
or you can set up a permanent VirtualBox NAT Port forwarding:
```sh
$ VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port8000,tcp,,8000,,8000";
```
If the vm is already running, you should run this other command:
```sh
$ VBoxManage controlvm "boot2docker-vm" natpf1 "tcp-port8000,tcp,,8000,,8000";
```
Now you can access your container from your host machine under `localhost:8000`.
## Port forwarding on steroids
If you use a lot of containers which expose the same port, you have to use docker dynamic port forwarding.
For example, running 3 **nginx** containers:
- container-1 : 80 -> 49153 (i.e. `docker run -p 49153:80 ...`)
- container-2 : 80 -> 49154 (i.e. `docker run -p 49154:80 ...`)
- container-3 : 80 -> 49155 (i.e. `docker run -p 49155:80 ...`)
By using the `VBoxManage modifyvm` command of VirtualBox you can forward all 49XXX ports to your host. This way you can easily access all 3 webservers in you browser, without any ssh localforwarding hack. Here's how it looks like:
``` sh
# vm must be powered off
for i in {49000..49900}; do
VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port$i,tcp,,$i,,$i";
VBoxManage modifyvm "boot2docker-vm" --natpf1 "udp-port$i,udp,,$i,,$i";
done
```
This makes `container-1` accessible at `localhost:49153`, and so on.
In order to reverse this change, you can do:
``` sh
# vm must be powered off
for i in {49000..49900}; do
VBoxManage modifyvm "boot2docker-vm" --natpf1 delete "tcp-port$i";
VBoxManage modifyvm "boot2docker-vm" --natpf1 delete "udp-port$i";
done
```
## BTRFS (ie, mkfs inside a privileged container)
Note: AUFS on top of BTRFS has many, many issues, so the Docker engine's init script
will autodetect that `/var/lib/docker` is a `btrfs` partition and will set `-s btrfs`
for you.
```console
docker@boot2docker:~$ docker pull debian:latest
Pulling repository debian
...
docker@boot2docker:~$ docker run -i -t --rm --privileged -v /dev:/hostdev debian bash
root@5c3507fcae63:/# fdisk /hostdev/sda # if you need to partition your disk
Command: o
Command: n
Select: p
Partition: <enter>
First sector: <enter>
Last sector: <enter>
Command: w
root@5c3507fcae63:/# apt-get update && apt-get install btrfs-tools
...
The following NEW package will be installed:
btrfs-tools
...
Setting up btrfs-tools (...) ...
root@5c3507fcae63:/# mkfs.btrfs -L boot2docker-data /hostdev/sda1
...
fs created label boot2docker-data on /hostdev/sda1
...
root@5c3507fcae63:/# exit
docker@boot2docker:~$ sudo reboot
```