Deploy local-setup on virtual machine using Packer & Vagrant

[lukasz-zimnoch]

Refs #8

Here we introduce some provisioning scripts and Packer & Vagrant configs which can be used to run the local-setup repo on a separate virtual machine. This is a better alternative for manual installation on the local development machine because:

• It provides a separate environment managed by simple commands which don't collide with the host environment
• It always operates on the same OS and one can avoid problems with incompatible tools
• It always uses the same versions of tools for local-setup installation and configuration so one can avoid problems caused by tools updates
• It uses automated scripts for provisioning which is faster, more comfortable and less error-prone compared to manual setup

Provisioning scripts are divided into two directories:

• local-setup-environment: those scripts are responsible to prepare the environment containing all prerequisites needed to install local-setup and run the E2E test scripts. Additionally, this directory contains a packerfile.json which can be used by Packer to build the environment as a reusable Vagrant box or Docker image (this one has limited functionality)
• local-setup-instance: those scripts are responsible to run all auxiliary software and the local-setup installation script itself. Their outcome should be properly configured and ready to work local-setup instance. Additionally, this directory contains a Vagrantfile which can be used by Vagrant to run a provisioned VM automatically.

[Shadowfiend]

🤔 why vagrant and docker-compose rather than reusing the kube work we've already done with a local kube setup? Are we expecting better performance? taking this to the issue, which I see I missed earlier. Sorry!

[lukasz-zimnoch]

We can ignore the CI build here because this branch doesn't contain a CircleCI config.

[pdyraga]

First pass - more to come.

[pdyraga]

If possible, we should do something about node-gyp errors. They are not failing end-to-end test but they are polluting logs and we may skip some important warning/error because we'll get used to ignoring the red ERR!.

[lukasz-zimnoch]

If possible, we should do something about node-gyp errors. They are not failing end-to-end test but they are polluting logs and we may skip some important warning/error because we'll get used to ignoring the red ERR!.

I'll try to do something with those errors. However, if I don't manage to resolve them quickly, I'll open a separate issue for them in order to unblock this PR.

[pdyraga]

and avoid all the problems which occur when doing this manually on local development machines.

Can you please summarize for future-us what those problems are in the PR description?

[lukasz-zimnoch]

The problem with node-gyp is closely coupled with #14. I've found and article about it. We use node 11.15.0 as our main version so an old version of node-gyp is installed at the beginning. Then, when we switch to node 14.3.0 for e2e tests, such an old version of node-gyp is probably not fully compatible with the newer node version. I'll add a point about node-gyp to #14.

[pdyraga]

Some closing thoughts:

• We don't need vagrant for end-to-end test implemented in CircleCI config for E2E tests execution #13. Circle Ubuntu VM is sufficient and that's how the test is implemented in that PR.
• Vagrant is useful for local system testing and should be especially useful when working on integrations, not modifying the code of tBTC or Keep. I can imagine this type of local deployment to be especially useful for tBTC dApp developers (cc @ironng, @r-czajkowski)
• Having vagrant setup, it's very easy to develop and test provisioning scripts for CircleCI config for E2E tests execution #13.

[pdyraga]

I was able to run the end-to-end test using local deployment and vagrant deployment a couple of times 👍

[pdyraga]

Pro-tip. If you ever encounter the problem like:

Monitoring Bitcoin for transaction to address bcrt1qfzqd4j9s6dn4458n6fsuyeguzpxw5hzlq4gu74...
Connecting to electrum server...
onError: [[object Object]]
(node:14472) UnhandledPromiseRejectionWarning: Error: failed to connect: [Error: failed to connect to electrum server: [Error: websocket connection closed: code: [1006], reason: [connection failed]]]
    at file:///home/vagrant/local-setup/tbtc.js/src/lib/ElectrumClient.js:41:13
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at Client.connect (file:///home/vagrant/local-setup/tbtc.js/src/lib/ElectrumClient.js:40:5)
    at Object.withElectrumClient (file:///home/vagrant/local-setup/tbtc.js/src/BitcoinHelpers.js:217:5)
    at Object.findOrWaitFor (file:///home/vagrant/local-setup/tbtc.js/src/BitcoinHelpers.js:286:14)

1. Make sure Electrum is running: sudo docker ps -a,
2. If not, kill the container sudo systemctl kill bitcoin, and wait for a moment until it boots again,
3. Run ./local-setup/deployments/local-setup-instance/provisioning/run-bitcoin.sh,
4. Start end-to-end test one more time.

It happened to me that Electrum shut down with no explanation 🤷