Deploy local-setup on virtual machine using Packer & Vagrant - Githubissues

keep-network / local-setup

Allow to easily set up tBTC and Keep locally for development and test purposes.

MIT License

8 stars 16 forks source link

Deploy local-setup on virtual machine using Packer & Vagrant #12

Closed lukasz-zimnoch closed 4 years ago

lukasz-zimnoch commented 4 years ago

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 commented 4 years ago

~~🤔 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 commented 4 years ago

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

pdyraga commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Some closing thoughts:

We don't need vagrant for end-to-end test implemented in https://github.com/keep-network/local-setup/pull/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 #13.

pdyraga commented 4 years ago

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

pdyraga commented 4 years ago

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)

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

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