Most container tools concentrate on developers
Most container work concentrated on developer
docker build, docker commit
Standardization of OCI Image Format
New tools to build container images can arise
We don't care how you build a OCI Container image
Don’t care as long as the output is an OCI Image!
Where do they get the storage?
COWs have some problems.
DeviceMapper, BTRFS Break Shared Memory
10 containers using huge Java JRE - 10 JRE’s in memory!
Fixes Shared Memory
SELinux support in Fedora coming soon to RHEL
Not a posix compatible file system
Write performance suffers, especially at larger scales
In production, most images should be immutable
Read/Only images offer better security
No support network storage.
Each container server downloads gigabytes of images
Shared file systems.
Run same images on multiple servers
Instantaneous Updates, containers running same code
Get rid of COW file systems when not necessary?
Service watching for container images arriving at registry
Explode image onto ostree disk
Atomic Scan image for vulnerabilities
Approve or Block image for sharing for docker pull
Share exploded image via network protocol NFS, Cephs, Gluster, Ostree?
On atomic host, software shipped as container image
kubernetes requires etcd, flanneld
etcd, flanneld start before docker to setup network
These containers can be run with read/only images
docker has problems with container priority
atomic command installs system containers
Uses skopeo to pull image from registry
Uses ostree to store image layers on disk
Create systemd unit file and uses runc to run container
Optionally use runc to wrap processes in a container
Run as a chroot? Or just use system containers to install content on host
atomic install --system etcd systemctl enable etcd systemctl start etcd atomic install --system flannel systemctl enable flannel systemctl start flannel
atomic install --system system-docker systemctl enable system-docker systemctl start system-docker
Allow users to PGP sign images in look-aside cache
Multiple people/companies can sign same image
Signatures can be stored in Atomic/OpenShift Registry
Signatures can be stored in any web server
Allow user to "sign" content from docker.io
Build policy/rules engine to control which images/registries are trusted
atomic CLI, skopeo and docker only pulls containers that you trust
Container image transport
Storage of Images/COW
Open Container Initiative Runtime
Container Management API
Greek for remote viewing
Used by atomic CLI
View container image json data on registry
Added ability to pull and push images from registry
Pull/Verify "Simple Signing” signatures
Worked with CoreOS splitting out go library from CLI.
CoreOS investigating using it with RKT?
projectatomic/docker uses library for verification os simple signing
atomic mount fedora /mnt
Allow other tools to work with storage besides docker
graphc, graphtool, cowman, storetool
Create docker graphdriver code independent library/CLI
Add support OStree and Network storage (NFS, Gluster, Ceph)
CoreOS potentially use storage for its back end.
Furthest along feature of OCID
runc - default implementation
support other runtimes as the develop
docker 1.11 uses runc as the default back end
OCI runtime specification tools
ocitool generate a specification/launch runc
Open Container Initiative Daemon
(I prefer to call it OCD :^).
Renamed to CRI-O
Implements Kubelet Container Runtime Interface
Kubernetes server interface launching/running pods
OpenShift tells Kubernetes to execute pod
Kubernetes communicates with ocid
ocid pull image using skopeo/image
ocid stores image on disk using storage
ocid runs container/pod using runc
Standards based alternative to docker/rkt
kpod - management tools for adminstrating CRI-O storage and pods
Plan to move OpenShift to OCID by default
ocid package now available in Fedora Rawhide (f26)