Sanja Bonic, Colin Walters

Project Atomic is about containers

How does that apply to the desktop?

How can containers help my development work flow?

What can I containerize and how?

What about container-based OSes?

Atomic {Host,Workstation}, CoreOS, QubesOS, etc?

Atomic is RPMs from {Fedora,RHEL,CentOS}

Fedora Atomic {Host,Workstation} is Fedora

Atomic Host ~= CoreOS

Atomic Workstation != CoreOS + desktop apps in Docker

Atomic Workstation (containers) != QubesOS (strong virt)

Why would you want desktop containers?

Keep dev environment separate from desktop, like Microsoft Bash Shell, OS X homebrew

"But Linux has package managers!"

Keeping desktop secure is important; don't require updating firefox and git in one transaction

Containers allow isolating (security, multiversions) from host

Avoid package management disasters

Trimming desktop apps

Distribution flatpaks are coming

yum remove desktop apps, replace with flatpak

Up to you, and not the primary subject of this talk

Setting up a dev/pet container: tech + install

Use container tech of your choice - I use docker,nspawn,bwrap

My "fdev" Dockerfile

sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf
yum -y install bash-completion yum-utils tmux sudo powerline \
    gcc clang ccache ... gdb rust ...
dnf builddep -y glib2 systemd ostree rpm-ostree

dev container: sharing data + permissions

Share data between containers and host: git repos, etc

sudo chcon -R -h -t container_file_t /var/srv


USER user
ENTRYPOINT ["/usr/bin/tmux", "-l"]
LABEL RUN "docker run --init -ti --privileged -v /srv:/srv:rslave --net=host
           --name \${NAME} --env CONTAINER_NAME=\${NAME} \${IMAGE}"


$ atomic run cgwalters/fdev

Avoid confusion by using gnome-terminal profiles

cat ~/.config/systemd/user/
ExecStart=/usr/libexec/gnome-terminal-server --class %I --app-id org.verbum.terminal.%I


oc cluster vs pet containers

Kubernetes: All about services; run your web app, database, push local container to public cluster

pet/dev container is for not-services

Testing a new version of git: how not to do it

Build a local image in oc and oc rsh: Awkward

Pull image from Docker Hub: Ehhh no

Rebase host to Fedora rawhide: No!

Start a rawhide VM: No!

Fedora modularity/SCLs: Whole Big Topic

Testing a new version of git via containers

yum --enablerepo=rawhide install git in dev container: Sure

Build git from git master: Now we're talking

Your pet container can easily access host git repos:
Use new git "for real"

Developing the host userspace

systemd, rpm-ostree, gnome-shell, flatpak, NetworkManager

Container: Generate RPM or:
make install DESTDIR=/srv/tmp/rootfs

On host: ostree admin unlock (traditional: snapshot?)

On host: Install RPM, rsync -rlv /srv/tmp/rootfs/usr/ /usr/

Developing the host: Or virtualization!

install virt-manager, vagrant-libvirt, etc.


Now you have (at least) two things to keep updated

Script yum update in container, and (or) periodic host-side rebuilds

Context switching a lot, IDEs may not understand how to exec in containers

GNOME Builder does flatpak...but not other containers

Security is hard

The /srv approach is OK but now you have two ~/.bash_history

Sharing /home means container can write ~/.bashrc:
Game Over

I found it hard to do non-privileged container

Wishlist and the future

How are you containerizing? Let's collaborate!

Let's change the default bash prompt!

Terminal GUI app for shells in containers

A named, polished project for pet containers