Provide Docker option for installation #5
Comments
|
Another 'gotcha' with Docker: it requires root privileges to run. (maybe not always, but for certain things) - I remember the explanation being that because it's possible to run a Docker container that does insecure things (that a normal user could not even do) it should require that you run it "as root" so that you know it may do potentially dangerous things. About the /var file space problem: if users have root privileges, they can work around the limitation by creating a symbolic link /var/lib/docker that points to a folder with sufficient space. How to find out which folder does, and set this up, may not be something we even want to instruct novice users to try. |
|
Candidate Vagrantfile that can do docker or virtualbox provisioning: does not do anything about the problems incurred with Docker running up disk space in /var/lib/docker... Bring up the Docker version with bring up the Virtualbox version with |
|
This may be a showstopper: Using Docker provider instead of Virtualbox, the shared "synced" host folder functionality is crippled. Guest OS does not necessarily have write permissions to host filesystem, it depends on the user & group & permissions of the working folder where 'vagrant up' happens. How can we ensure that this folder is world-writable? We cannot. We want to support people running a myriad of local OS possibilities and environments, including ones where users may not have full write permissions, or root to be able to change them. If we really want to support Docker, we may have to resort to using it directly, in place of Vagrant, which will require a new set of instructions and provisioning directives, e.g. Dockerfile instead of Vagrantfile. This may (to repeat) require users to be root. |
|
In spite of these complaints; Vagrantfile updated to support Docker as a virtualization provider within Vagrant. Use (ubuntu) with: Testers for Windows,Mac needed :) |
|
Tried it - current Vagrantfile, on a fresh Windows 10 computer with Vagrant and Docker installed, actually works! Other things tried: saving the running Docker Container as a Docker Image Saving that image as a tar archive copying that tar archive to a linux host running Docker. loading that image into docker: Giving that image a better name: Starting that image in a way similar to (but without) Vagrant, such that it has a shared host folder (/usr1/er1k/Desktop/DiViMe) mounted in the usual VM place (/vagrant): resulting in: Reasoning: Docker does not map file ownerships across shared host filesystem like Vagrant does, so the Docker Container has to do some things 'as root' and the host filesystem has to be world-writable. |
|
Marking closed, documentation here: https://github.com/srvk/DiViMe/wiki/InstallingWithDocker |
|
Docker is really not a VM, and the more I read about the Docker philosophy, the less inclined I am to believe it's benefits will outweigh it's costs. https://www.linode.com/docs/applications/containers/when-and-why-to-use-docker/#when-not-to-use-docker Yes the philosophy is that Docker containers are 'lightweight, ephemerable, disposable' and should only run 1 process/service. But that's not the philosophy of the Diarization VM, which is to build a somewhat heavy weight, persistent tool, with control over how much hardware (disk, memory, cores) it can use. Re-implementing the entire VM as a Docker build container will not make it any more lightweight. In particular, it might break disk space in ways novice DiViMe users cannot diagnose, control, or fix. I plan to use this space to document problems encountered in constructing a Docker-native (as opposed to Vagrant using Docker as a 'provider') container.
What was the actual error: wrong order of arguments to the
So long as we use it in the way it was intended, for things that are LIGHTWEIGHT, EPHEMERAL, DISPOSABLE... single process, single thread, then throw away the container. Separate containers for separate concerns. Building up a giant "VM" with numerous tools, packages, 3rd party libraries, models etc. - kind of defeats this purpose. |
|
Here's an example of not understanding what is going on with Docker Images piling up, or how to remove them if new ones keep appearing: So I use "docker images" to see some images I've been working on lately. NEW ONES APPEAR So I repeatedly do this, until all the new ones that keep appearing go away. THE DISK USAGE IN /var/lib/docker ACTUALLY IS HIGHER NOW What the heck is going on? |
|
Current issue, a catch-22: Also by default, there is no Turns out one technique is to make the host working directory WORLD WRITABLE with |
|
If you (Maybe there's some way to find a new UUID for a new image that is the result of the previous |
|
Still not sure how to manage space used by Docker on a computer, it seems they want to hide that from you, or make up new, obscure, cryptic ways to do it. So trying one of these ways: |
|
docker/compose#3270 (comment) I don't see how our code can work when it's not free to create and remove files on the host (which it all refers to as WORKAROUND: make working directory world-writable. make subdirectories the same (if they are to be written to) such as |
|
After making much noise on the topic (see above), I have produced and tested (minimally) a Dockerfile that produces a Container that passes the self-test (
|
|
Some more good news:
|
|
A problem with Docker: any scripts intended to run outside the VM (at least the one to get ACLEW Starter data) cannot simply call "vagrant ssh ..." any more, but will need parallel Docker specific commands. It wasn't such a difficulty to make Docker 'see' it's shared host folder as /vagrant and have a user named 'vagrant', but it's definitely getting too Vagrant-centric to have scripts that assume a Vagrant VM is currently running. |
|
This is nearly nearly done, in terms of the Dockerfile. |
The text was updated successfully, but these errors were encountered: