Devconf.cz 2018
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
# https://pagure.io/fedora-kickstarts/blob/a8e3bf46817ca30f0253b025fcd829a99b1eb708/f/fedora-docker-base.ks#_22
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
Permissions
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}"
Running
$ atomic run cgwalters/fdev
Avoid confusion by using gnome-terminal profiles
cat ~/.config/systemd/user/default.target.wants/verbum-terminal@Containers.service
[Service]
Type=simple
ExecStart=/usr/libexec/gnome-terminal-server --class %I --app-id org.verbum.terminal.%I
[Install]
WantedBy=default.target
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.
Downsides
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!
atomic-devel@lists.projectatomic.io
Let's change the default bash prompt!
Terminal GUI app for shells in containers
A named, polished project for pet containers