Most computer operating systems suffer from some variant of "DLL hell" - a Windows term, of course, but the concept applies across the board. Consider doing embedded development which usually takes some specialized equipment. You write your embedded system code, ship it, and forget about it for a few years. Then, the end user wants a change. Too bad the compiler you used requires some library that has changed so it no longer works. Oh, and the device programmer needs an older version of the USB library. Python build tools use Python 2 but your system has moved on. If the tools you need are no longer on the computer, you may have trouble finding the install media and getting it working. Worse if you don't even have the right kind of computer for it.
One way to address this is to encapsulate all your development projects in one virtual machine. You can then save the virtual machine and it includes an operating system, all the right libraries, and basically a snapshot of how the project was that you can reorganize at any time and on almost any computer.
In theory, that's great, but it's a lot of work and a lot of storage. You need an operating system and all the tools installed. Sure, you can get a tool image, but if you work on multiple projects, you'll have a bunch of copies of the same thing cluttering things up. You'll also need to keep all those copies up-to-date in case you need to update things that - granted - are the kind you're probably trying to avoid, but sometimes you must. should do.
Docker is slightly lighter weight than Virtual Machine. You still run your system's normal kernel, but essentially you can have a virtual environment running on top of that kernel. What's more, Docker only stores the differences between things. So if you have ten copies of the operating system, you will be storing it only once and small differences for each instance.
The downside is that it's a bit hard to configure. You need to map the storage and set up networking, among other things. I recently got Doc. ran into a project called It tries to simplify the common cases so that you can quickly spin up a Docker instance to do some work without any real configuration. I made some minor changes to it and Project forkedBut, for now, the original is out of sync with my fork so you can stick with the original link.
documentation
The documentation on the GitHub pages is a bit sparse, but the author has A nice page of instructions and videos, On the other hand, it is very easy to start. Create a directory and move to it (or move to an existing directory). Run "docker" and you'll get a spun-up Docker container named after the directory. The directory itself will be mounted inside the container and you will have an ssh connection to the container.
By default, that container will have some nice tools, but I wanted different tools. No problem; You can install whatever you want. You can also set up an image that you like and name it as the default in the configuration files. You can also name a specific image file on the command line if you wish. This means it is possible for new machines to have multiple setups. You can say that you want an image configured in this directory for Linux development and another for ARM development, for example. Lastly, you can also name the container if you do not want it to be associated with the current directory.
Images
This requires some special Docker images that the system knows to install automatically. There are setups for Ubuntu, Python, Perl, Ruby, Rust and some network and database development environments. Of course, you can optimize any of these and commit them to a new image that you can use as long as you don't mess up the things the tool depends on (eg. for, an SSH server).
If you want to change the default image, you can do so in ~/.dockrc. That file also contains a prefix that the system removes from container names. This way, a directory named Hackaday will not end up with a container named Hackaday.alw.home, but only Hackaday. For example, since I have all my work in /home/alw/projects , I should use that as a prefix, so I don't have the word project in each container name, but - as you can see in the accompanying screenshot. I can see that the container does wind up as Hackaday.projects.
options and aliases
You can see the options available on the help page. You can select a user, mount additional storage volumes, set certain container options, and more. I haven't tried it, but it looks like there is a $DEFAULT_MOUNT_OPTIONS Variables to add other directories to all containers.
My fork adds a few extra options that aren't absolutely necessary. For one, -h will give you a short help screen, while -U will give you a longer help screen. In addition, unknown options trigger the help message. I also added the -I option to write the appropriate source line to add to your shell profile to get an alternate alias.
These alternate aliases are useful to you, but the Dock doesn't use them so you don't need to install them. These do things like listing Docker images or making a commit without having to remember the full Docker syntax. Of course, if you prefer, you can still use regular Docker commands.
try it!
To start, you need to have Docker installed. Usually, by default, only root can access Docker. Some setups have a special group you can join if you want to access it with your user ID. It's easy to set up if you want. For example:
sudo usermod -aG docker $(whoami)
newgrp docker
sudo systemctl unmask docker.service
sudo systemctl unmask docker.socket
sudo systemctl start docker.service
From there, follow the setup on the project page, and be sure to edit your ~/.dockrc file. you need to make sure that DOCK_PATH, IGNORED_PREFIX_PATHAnd DEFAULT_IMAGE_NAME Among other things, the variables are set correctly.
Once set up, create a test directory, type dock And enjoy your new kind of virtual machine. If you have set an alias, use dc To show you the container. you can use dcs either dcr To turn off or remove the "Virtual Machine". If you want to save the current container as an image, try dcom To commit the container.
Sometimes you want to enter the fake machine as root. you can use dock-r as a shorthand for dock -u root Assuming that you have set up aliases.
It's hard to imagine how easy it could be. Since the whole thing is written as a bash script, it's easy to add options (like I did). It seems like it would be much easier to adapt existing Docker images to be installed to be compatible with Docker. Don't forget, that you can commit a container to be used as a template for future containers.
If you want more background on Docker, Ben James has a good write up, You can also use docker Simplify Retrocomputing,
0 Comments