X11 forwarding from docker is just so cooolll.

I found it very convenient to use docker as development environment, and install multiple software same way I do it on my local machine. Yes, there are lots of limitations compared to local environment. But the benefit of isolating everything related to the specific project in one docker image far outweighs limitations of developing directly inside the docker container. Of course, you would not need this if you are working on one project, one language, one repo, one cloud, one k8s cluster and one environment. But having 2+ projects, repos, clouds, environments etc. makes it inconvenient to switch between them. You need several actions to switch from one environment to another: switch AWS profile, switch between k8s clusters, node/python/ruby environments and so on. When I started developing in docker, switching workspaces is simply docker start/stop... Moving workspaces between laptops is as trivial as commit new image, push to private registry and pull on another machine. I have changed laptop and had all my development environments pulled as docker images same day, no single day lost. I've made public docker image alnoda/ubuntu-workspace with some niceties like zsh, cron, docker in docker, supervisord, nano, vim, git and some stuff set up.

Thanks for sharing.

awersome video, thanx Dan

Are all changes to the container reflected automatically with the host?

neat!

sweet!

I don't see any advantages in running editors, git, etc inside a container on Linux host. Code editor is such a personal thing, there's no way you could agree on which editors should be added to container. The only advantage I see is that there's performance issue in Docker for Mac. But you can't run gvim there. Also, in Mac it's difficult to work with passphrase protected ssh keys, but this approach doesn't solve it.

When I use Docker containers for development I prefer to build single process containers and invoke them via a shell script named the same as the application running in the container via ENTRYPOINT and mounting an internal volume mapped to the current directory om the host. This makes the containerized application, in this case a development tool such as Python, appear to be natively installed on the host. For example, Python, pip, pipenv, and pylint are separate containers but are invoked by the name just as if I installed the actual software on the host computer. Using ENTRYPOINT instead of CMD as the last instruction in the Dockerfile to launch the application inside in container prevents users from modifying the container internals. I realize ENTRYPOINT can be overridden by another ENTRYPOINT with the docker run command so it is not 100% secure either but most users would be unaware of the shell script containing the docker run command.

Dont install too much stuff into your images. They are supposed to be lightweight so instead of installing all the software inside the image, do the work outside the image or use a pre-made image for the software if there is one.