Document architecture of The Box
meeDamian opened this issue · comments
- Hardware setup
- Setup script
- Wizard
- Apps (see #128; Dockerfiles)
- Interactions between apps (docker-compose)
- Network setup
Going through the stuff that has been built so far.
I don't want to open a 1000 new issues, so let's have a discussion about stuff here, and open issues if we deem the change worthy.
So the first thing GENERATEDRPCAUTH within /home/lncm/bitcoin/bitcoin.conf, it's a good idea to have it if only one set of credentials will ever be added to bitcoin.conf, but if we're aiming at modularity, we should probably have a bit smarter script that generates pairs of credentials per each app requesting access.
The first idea that came to my mind is generating credentials based off container ID of the app requesting access to bitcoind.
The benefits are:
- it's easy to verify if credentials are already added
- it's easy to know which credentials are no longer necessary and remove them
Downside right now would be:
- app upgrade (container ID changes) would necessitate credentials change
docker-compose.yml
- Why are we using
version: '2.1', if the newest is3.7? - If we map port
XtoX, it's enough to use"X"syntax instead of"X:X". - How are IP addresses of containers chosen?
- Should we have some convention for it?
- Should we have a wiki with reference table for them?
- How are container names chosen? Can we use just plain names of apps within instead?
- Should we have a convention for how our Docker images are tagged? (see below)
- Why is
bitcoin.confmounted in the container both in/root/and/home/bitcoin/? Don't we know where it's needed? - I love pendrive mountpoints!
/home/{important,volatile,archive}/makes it super easy to understand 😀! - Should we exposed have ports documented?
- Is it possible to split compose file into multiple files? Would make it nicer for us to do composability.
Docker image naming
To standardise naming, I recommend following the following pattern:
Assuming app lnd at version v0.5.2.
GH repo
github.com/lncm/docker-lnd
With GH tags corresponding to versions. I recommend only following stable releases.
Alternatively all Dockerfiles in one repo, but having them in separate ones would make setting up automated build pipelines easier (trigger upon version tag). But it's probably also doable if all are within the same repo.
Docker
After exploring a few projects, it seems to me that the convention of doing multi-arch builds now is:
- individual and arch-specific containers are not tagged (not yet sure how to push an untagged image yet…),
- each of the built containers is annotated with proper OS and arch, ex:
docker manifest annotate lncm/MANIFEST_NAME:VERSION BUILT_IMAGE_ID1 --os=linux --arch=arm --variant=v6 - after all architectures are built an aggregate manifest is created:
docker manifest create lncm/MANIFEST_NAME:latest BUILT_IMAGE_ID1 BUILT_IMAGE_ID2 - and pushed:
docker manifest push lncm/MANIFEST_NAME:latest
After that we end up with something like:
lncm/lnd:v0.5.1
lncm/lnd:v0.5.2
lncm/lnd:latest
Where executing docker pull lncm/lnd:latest pulls the latest available version in the right architecture!
Bonus question, should we use v in the version string, or skip it?
I see a few files (ex. lightning/config, litecoin/litecoin.conf) that are not used, and should probably never be part of the default setup. I think it makes sense to get rid of them from the initial repo, and only pull them as part of the "app install process", which AFAIU is yet to be designed?
Note to self: add README.md file links to repos/homepages of all projects being used by us.
What for and why exactly is nginx used right now?
Let's not use .gitkeep files, they are not recognised by git in any way, and it's better to use conventional .gitignore in their place.
IDEA: Each installed app gains access to /home/lncm/APP_NAME/ namespace where it can put all initial config files it needs to run.
Can we have one LICENSE file in repo specifying that the licence applies to all files within, unless otherwise specified? Or do we really need to pollute all scripts with the body of the license?
we are mounting as within the container because we can easily invoke commands within the container without specifying a pathfile
we are mounting as within the container because we can easily invoke commands within the container without specifying a pathfile
I don't know what you're replying to.
I wrote a ton of questions and points that should be addressed above, really not sure what this single sentence refers to :).
Replying to the part about pathnames.. they need to work how they are. For ux reasons too
What for and why exactly is nginx used right now?
@meeDamian it’s used for serving WiFi Manager and can proxy port 80 to other endpoints
Sent with GitHawk
docker-compose.yml...
@meeDamian bitcoin.conf directory path appears duplicated to work around bitcoin-cli default path
We can use v in the versions or not, I’m fine with either
Sent with GitHawk
Or we can just not change the default path from /root/.bitcoin/ 🤷♂️
Note: lnd does it, it's simple, consistent and what's the point of having a dedicated bitcoin user within a docker container anyway?
Rebase on top of alpine-3.9.0 and merge in there.
Opened issue: https://github.com/lncm/pi-factory/issues/165 for #129 (comment)
Killing this issue in favor for a few others.