Provision evap via vbox and docker

[fidoriel]

vagrant up --provider=docker` can now be used to provision docker on e.g. macOS Monterey (Intel and M1) where vbox can currently not run.

[richardebeling]

A few thoughts:

• I like our current provisioning script. It's simple and easy to understand. It only makes a minimal set of assumptions about the system it's running on. Basically, it could be used to set up a development environment in any linux environment. I'd like to keep it unaware of where it's running.
• The canonical way to start an interactive shell in a docker container is docker exec [...] -it bash, not SSH into it. Setting up a SSH server seems overkill to me, even if this means that vagrant ssh will not work. Note that if we set up SSH servers for users, we are somewhat responsible for their security.
• We have vagrant as a tool to provide us with some kind of virtualized linux environment, and the shell script to set up this environment. This should be complete, so I'd like to not add a third file (Dockerfile).

I've tried to come up with the minimal modifications needed for this, resulting in a total of 7 additional relevant lines, not counting comments and readme entries: richardebeling@7c08e93

No SSH server means users will not be able to vagrant ssh and vagrant will not be able to automatically provision the container on the first vagrant up. The workflow for users would thus be (as written in the readme):

vagrant up --provider docker  # to start the container
vagrant docker-exec -it -- /evap/deployment/provision_vagrant_vm.sh   # to set up the environment (once)
vagrant docker-exec -it -- sudo -H -u evap bash  # to run an interactive shell

now I'd say this would be perfect if we somehow could tell vagrant how to do provisioning with this setup, and if we could provide some kind of vagrant shell command that either executes vagrant ssh or starts a shell in the docker container. Since the Vagrantfile is written in ruby, it would make perfect sense to just script this there in a few lines, but it seems that custom provisioners and custom commands can only be done with plugins, which I'd consider overkill again.

Overall, I'd vote in favor of going this approach: Get some "VM"-like container with as little configuration as possible, run the provisioning script in there, profit. What do you think?

[richardebeling]

A few more thoughts:

• We can't be the only ones who use vagrant to set up a dev environment and now want to support M1 macs, right? What we'd need for that is a docker image that has a ssh sever set up for vagrant -- but I wouldn't want to maintain that in the scope of this project. There are quite a few images on docker hub, but none of them is by a reputable publisher, and none of them allows us to use ubuntu 18.04. The most polished one, out of these, seems to be https://hub.docker.com/r/rofrano/vagrant with the corresponding github repo at https://github.com/rofrano/vagrant-docker-provider.
• With Provision evap via vbox and docker #1726 (comment), vagrant only does port forwarding and file system mounting for us -- we might get away without it, maybe simply giving users a few aliases (evap up, evap provision, evap shell, evap halt, evap destroy).
• Vagrant has issue from 2016 https://github.com/hashicorp/vagrant/issues/8145 about using docker-exec instead of ssh with docker containers. This would solve all our SSH-related problems, but there's no indication that this will be implemented soon.
• Vagrant provides not only Commands, but also Aliases and Triggers. Triggers can be used to work-around ssh not being available with docker as long as 8145 is still open, like this: richardebeling@742ec0d

[richardebeling]

Updated code with your latest changes at He3lixxx:docker / c762ccf

I did some more refactoring. You should be able to test locally with:

vagrant destroy
git remote add He3lixxx git@github.com:He3lixxx/EvaP.git
git fetch He3lixxx
git switch -d He3lixxx/docker
vagrant up --provider docker

[richardebeling]

(note: chome headless won't start inside docker container, because it can not sandbox itself. Reproduce with ./manage.py ts test)

[richardebeling]

Another thing is that the postgresql and redis-server services will not auto-start on vagrant up, so if you do vagrant halt && vagrant up && vagrant ssh, you will have to manually start them again (service postgresql start && service redis-server start).

I couldn't find a "clean" way to auto-start them. It's a bit complicated, since starting them will only work after provisioning was done. We could add the commands that start them to bash.rc or similar.

Edit: Added service postgresql start && service redis-server start to .bashrc.

[niklasmohrin]

About chromium, docker and macos: @FranzSw noticed that on his m1 mac, the npm installation fails because of puppeteer something and then chromium something. This, interestingly, results in npx tsc running a different (outdated?) package, because the right one didn't get installed, very awkward. Adding a sudo apt-get install -y chromium-browser fixed this and we only have the normal sandbox errors again.

We could mark puppeteer as an optional dependency, so that the current script doesn't fail - that would mean that one has to run npm ci before ts test and precommit work. We could also install chromium in the provision script. @he3lixxx What do you think?

[richardebeling]

I think that an actual error message and/or full provisioning log would help :P If there are bugs with puppeteer on M1, I'm pretty sure they would have an open issue, possible with a workaround or solution -- I'd say we should do whatever that is.