Show HN: Docker-based immutable workstation

This is pretty much exactly my project Darch is/does, except that it is truly completely native.

https://godarch.com/

Here are my recipes: https://github.com/pauldotknopf/darch-recipes

You can use either Ubuntu/Arch/Debian/VoidLinux.

My entire operating system is stored on DockerHub. I run "update-machine" from my terminal, grab a snack, come back, reboot, and my machine is updated.

My entire OS has a tmpfs overlay, meaning I can reak havok, and a simple reboot will wipe everything clean. I use "hooks" to mount disks at certain spots (/home, /var/lib/docker, etc) in the initramfs, before chroot.

Also, you can try it out really quickly in VM with a pre-built image: https://pknopf.com/post/2018-11-09-give-ubuntu-darch-a-quick...

I run the same exact image, bit for bit, natively on 3 machines I have (laptop, home and work). Together, with Darch and my dotfiles, my environment is consistent, wherever I go.

I see some minor grammatical issues with the doc. "dependencies" is spelled wrong, and the final sentence of the "Docker Immutable Workstation" section seems incomplete. Also this line: "a Mac if we are lucky".. expect to be chirped at by non-cultists like myself :)

I do something similar but with a VM instead of a Docker container and it works well. The one thing I like about using a VM is it runs full Ubuntu with an init system, so it's easier to run daemons like Samba. My VM shares its home directory so I can mount it on the host and share files across the barrier (I've always found VM "shared folder" implementations flaky). Files are less an issue with Docker, but you might want to run other daemons within the context of your dev environment. The Docker "one executable per container" idiom really falls apart here, and requires you to hack around it.

To keep things fresh, I just have a couple bash scripts that I run (one for some system packages, one for dev tools, one for dotfiles) on a new Ubuntu VM every few months. I'm sure it would be trivial to automate this with vagrant to even further streamline it but it's been good enough for me.

This is somewhat similar to Jessie Frazelle's setup: https://blog.jessfraz.com/post/ultimate-linux-on-the-desktop...

The talk and slides at the end of that post are worth the time if this sort of thing is interesting to you.

I tried Fedora Silverblue [0] with the release of Fedora 29.

It uses OSTree to manage state, and only allows mutability inside of the home directory and /var.

Overall I was very impressed. Another year or two of rounding out the typical use cases and it will make a fine immutable workstation.

[0] https://silverblue.fedoraproject.org/

Did you consider alternate approaches like using Ansible to give you more native system options as well, or was the goal here truly to have something 100% cross platform on anything? A hybrid might be a good approach too. Personally I think I'd end up backsliding because if I'm using a platform I really like then I want to be able to take advantage of some of its best native software and interface bonuses, so a purely X-based setup will still lead me to some manual setup on my own systems. Once stuff out of the automatic flow crept in feels like it might build up over time since I'm not that disciplined. Some of the playbooks I've seen though could be enhanced further with this, neat project.

Good work! I've written something similar - an SSH server and X desktop (served up via a VNC server) in Docker. It's a reasonable base for building this sort of thing. You can build an image on top of it and throw in whatever GUI applications you need. It's a little light on documentation, but should make up for it by being fairly barebones.

https://github.com/dpedu/docker-desktop

Might be interesting to pair this with something like Fedora Silverblue (read-only /usr managed using rpm-ostree) and fedora-toolbox.

http://silverblue.fedoraproject.org https://github.com/debarshiray/fedora-toolbox/blob/master/fe...

I've built something vaguely similar to give me a virtual desktop that I can access from anywhere over Chrome Remote Desktop: https://github.com/kstenerud/ubuntu-dev-installer/blob/maste...

It installs mate or lubuntu desktop inside an LXC container, allows access via x2go, and pre-downloads chrome remote desktop, which can be configured in less than a minute (run chrome, log in, open remote desktop, enable connections).

It was spawned out of my virtual builders (https://github.com/kstenerud/virtual-builders) project, to allow me to get my Ubuntu development environment installed, configured, and running, from a fresh install even, on any LXD capable machine, in short order.

Even if my dev box dies completely, I can be back up and running on another machine or hard drive within an hour. I can set up as many of these desktops as my machine has CPU and RAM.

I love this idea, and because docker feels so much lighter than vagrant, and doesn't require virtualbox to be installed and updated (like vagrant did on windows when I used it). However on mac and windows, using docker means you're running in a VM.

I wonder if there's any plan on implementing the APIs that would allow docker server to run in WSL, thus abrogating the need for a VM? Edit: theres no evidence of any motion, but here's a uservoice for namespace, cgroups,etc support in WSL: https://wpdev.uservoice.com/forums/266908-command-prompt-con...

Edit2: Actually it looks like docker support is being worked on: https://github.com/Microsoft/WSL/issues/2291#issuecomment-43...

Hi.

You wrote "There is a developer who (I think) works for Docker..."

I believe that you are referring to Jessie Frazelle.

I have been playing with this and am kind of OK with it - would value any feedback about the idea / concept and pointers.

It just came about out of annoyance with yet again trying to rebuild my personal workstation to even barebones level.

It's definitely in the "if you aren't embarrassed you launched too late" category

Was NixOS / Nix considered? Feels like a lot of overlap in the motivations.

@lifeisstillgood - in the spirit of mutual embarrassment...

https://github.com/ramses0/docker-devenv

https://github.com/ramses0/docker-devenv/blob/master/Dockerf...

I found it useful to separate OS configuration out from installing non-OS software (third-party)... it's basically a cue/cost that makes me prefer OS-level installations over "manual" installs.

https://github.com/ramses0/dotfiles

https://github.com/ramses0/dotfiles/blob/master/bash/profile

...lots of hardcoded and ugly stuff in there, but I like the idea of it a lot.

My experience has been mixed, but good overall:

1) docker mounts local host's *.ssh info, and mounts "~/host" dir and "~/Git" dir (promotes some of the host FS to top-level directories) ... this is primarily around me coding / working with Git, so it's the right choice for me. It's nice for the auth story to mostly properly follow me around as I move from computer to computer (primary auth is on local host, this image expects my local auth is properly set up).

2) docker FS isolation is interesting... you can "apt install $foo" in different windows/instances and system level changes are effectively isolated and disposable. It allows near instantaneous install of certain packages (ie: "apt install ffmpeg") and the command will be gone after that particular session (unless I decide it's something I use often enough to be added to the docker recipe). Contrast this the cruft on a 5-year old home linux box which has 1000's of packages installed from running random tutorials from the net.

3) startup time is quick and roughly equivalent to booting an old x86 PC. No matter how much I screw up the (inside the docker) operating system, it's just a quick "reboot" to fix it back to the last known-good state

4) VNC/X11 is "meh" and more of a parlor trick. However, there's interesting use cases to making an "appliance docker image" ... Firefox works OK, and is maybe a good idea for carrying around a "paranoid browser", but it definitely feels a bit uncomfortable.

5) I know the non-OS install stuff (ie: heroku, rustc, etc) can likely be done in the initial Dockerfile step, it forces me to make sure the system stays in a consistent state. When something isn't pulled directly from Debian, it's likely that there's a more compelling story to make sure the software stays installable and up to date (ie: vim plugins, etc). I guess it feels a bit like a local version of homebrew recipes?

6) As a hack, I cobbled together a "build/bake" concept which locks down a particular set of the non-OS stuff as well. When "baked" the image doesn't really auto-update (tough to automate version control against certain random sources/installs), but I have some scripts which try to keep the base OS up-to-date, encouraging you to go through the "build-bake" cycle as time goes on, keeping the box "evergreen".

An example victory is when on a windows box, I can get "real" vim, bash, etc. and operate on windows files from within linux (something that WSL can't officially do).

On the mac-side, I can get "sort -R/--random-sort" when processing random data, as well as the ability to quickly pulldown ffmpeg, or imagemagick... again in a "disposable" environment, without seriously jeopardizing my OSX install and building up cruft.