| FROM ubuntu | |
| RUN apt-get update -y | |
| RUN apt-get install -y gcc | |
| RUN gcc -o /src/myapp /src/myapp.c | |
| IN /target { | |
| FROM busybox | |
| ENTRYPOINT /myapp | |
| } | |
| RUN cp /src/myapp /target/myapp | |
| PUBLISH /target |
| from busybox | |
| run touch /foo | |
| run touch /bar | |
| cmd echo hello world! |
| 10:57 shykes: lastly, we have 2 big limitations for real-world use: logging and reboots | |
| 10:57 klizhentas: shykes: can you elaborate on logging? | |
| 10:57 shykes: klizhentas: several people have asked me how to integrate their docker setup into syslog or another logging system | |
| 10:57 shykes: it's not practical | |
| 10:58 shykes: 1) I can't just get a firehose of every container's logs (let alone of a smart subset of them) | |
| 10:59 tobstarr: shykes: I would like to have at least some syslog forwarded booted in each container | |
| 10:59 backjlack: systemd allows you to do this. | |
| 11:00 shykes: 2) it's hard to get a stream of a container's logs in a way that is both reliable and continuous | |
| 11:00 fkautz: so, is the problem that they can't hook into syslogd or that it's impracticle for us to provide syslogd support? | |
| 11:00 klizhentas: isn't that app specific - so I can tell my container to talk to whatever loggin daemon out there? |
| REDIS=$(docker run -d crosbymichael/redis) | |
| docker run -link $REDIS:6379:redis -t -i 71cba4d74d62 bash | |
| root@7c1879d423b6:/# cat app.py | |
| import docker | |
| from redis import Redis | |
| ip, port = docker.require('redis') | |
| r = Redis(host=ip, port=int(port)) |
| func TestTree(t *testing.T) { | |
| tree := NewTree("/path/to/db") | |
| // List all root containers | |
| names, _ := tree.List("/") | |
| for _, name := range names { | |
| fullPath := path.Join("/", name) | |
| id, _ := tree.Get(fullPath) | |
| fmt.Printf("%s is a link to %s\n", fullPath, id) |
Links are a way of expressing a relationship between one container and another. When you link a container, you create a parent/child relationship between the two. As a side effect links also allow you to name containers and reference them by name. Containers can be references by more than one name.
Initially links will be expressed by injecting the child's data into the parent's environment accessible via namespaced variables:
####Examples
REDIS_ENV_{key}={value}REDIS_PORT={value}
| interface GraphBackend { | |
| Init(home string) error | |
| Nuke() error | |
| Create(img *Image, layer Archive) error | |
| Delete(img *Image) error | |
| Mount (img *Image, dest string) error | |
| UnmountAll (img *Image) error | |
| DiffList(*Image, dest string) ([]Change, error) | |
| DiffLayer(*Image, dest string) (Archive, error) | |
| } |
| type Driver interface { | |
| Create(id, parent string) error | |
| Remove(id string) error | |
| Get(id string) (dir string, err error) | |
| Diff(id string) (archive.Archive, error) | |
| DiffSize(id string) (bytes int64, err error) | |
| Changes(id string) ([]Change, error) |
The Simple Ambassador Container (let's just call it the ambassador) is a reusable container which can be added to your stack to represent a remote service. Using an ambassador your application can discover remote services using docker's standard links features.
Example usage:
REDIS_REMOTE_IP=1.2.3.4
I hereby claim:
To claim this, I am signing this object: