Siren installation improvement #7404
Conversation
| @@ -43,32 +70,35 @@ We recommend running Siren's container next to your beacon node (on the same ser | |||
| 1. You can now start Siren with: | |||
|
|
|||
| ```bash | |||
| docker run --rm -ti --name siren --env-file $PWD/.env --net host sigp/siren | |||
| docker run -ti --name siren --env-file $PWD/.env -p 443:443 sigp/siren | |||
There was a problem hiding this comment.
I am not sure if this will still work, without the --net host. @antondlr and I have discussed about this before. Because there are users running BN and VC not using docker (e.g., systemd), so --net host is somehow required
There was a problem hiding this comment.
oh, I guess maybe its the container trying to access local instances. I use the docker compose for this and it works fine.
I guess @antondlr will have to chime in for --net host. My understanding is that it's not needed, but I might be missing something.
There was a problem hiding this comment.
yes, age is 100% right. --net=host is dangerous and should not be used lightly.
the problem is, a LOT of our users have setup their nodes with the somer esat guides, which runs CL/EL though systemd and limits the api ports to 127.0.0.1 ... which is not accessible through docker.
a solution for that is to use --add-host=host.docker.internal:host-gateway on linux hosts, buuuutttt that doesn't work when Docker was installed as a Snap (which used to be default on Ubuntu but I think it no longer is?)
I'm not sure how --net=host ever became the default, almost recommended way to run Siren... it should be a last resort fix, and only for people who understand the implications.
There was a problem hiding this comment.
For those running BN and VC without docker (systemd), without --net=host, will it work? I get how --net host is no good, is there another way to get around?
There was a problem hiding this comment.
I run BN and VC without docker using systemd and what I've written here works perfectly fine.
I think the only case is if they set their HTTP IP in the CLI of BN and VC to 127.0.0.1 then it won't work.
There was a problem hiding this comment.
I've added a comment about handling this edge case. I dont think we need --net host. People just need to expose their HTTP API I guess, or add the flag that anton said.
I've commented on this in the docs now.
There was a problem hiding this comment.
@antondlr could you chime in on this? We discussed before that without --net host, those running systemd will not be able to connect to Siren. Changing the BEACON_URL to http://docker.host.internal:5052 or adding --add-host=host.docker.internal:host-gateway sigp/siren also doesn't work
There was a problem hiding this comment.
we discussed this in detail at devcon, and it is indeed as age says:
either expose the api on 0.0.0.0 (or, their specific IP, or anything else more broad than 127.0.0.1 really), or run Siren with --net=host.
Changing the BEACON_URL to http://docker.host.internal:5052 or adding --add-host=host.docker.internal:host-gateway sigp/siren also doesn't work
you'd have to do both, simultaneously, and this only works for regular docker installs iirc, not for "snap" installs (like you have on your server?). (and it's host.docker.internal not docker.host.internal but that's just a typo I assume?)
I can help debug / find a way for a specific setup like yours but there are no magic solutions here that preserve max security. the tradeoff is between exposing the BN/VC API more broadly, or running Siren with net=host, that will always be the crux of it for setups where Lighthouse doesn't run in Docker.
which of those is "best" is a personal choice; we landed on (ab)using net=host to unblock people because that way, no change to people's running Lighthouse instance would be necessary, but it's definitely not without downsides.
lmk if you want to go over it again why and how this all happens; I can explain in a call but typing it all out would be a course in itself :-)
There was a problem hiding this comment.
Yes, I remember, the "lesser of the two evils" - either exposing the API or using --net host
So long as it works, then it's good.
There was a problem hiding this comment.
For the record, this doesn't have anything do with Systemd. I run lighthouse with systemd and without. I don't use the net=host and everything works fine. It is only for users who are not exposing their API, i.e have not set --http-address to .
I expose my HTTP API so I can access it and query things, its only accessible on my internal LAN.
Co-authored-by: chonghe <[email protected]>
Co-authored-by: chonghe <[email protected]>
|
I'm going to merge this, because I think its an improvement and users who are starting to use Siren might see an immediate benefit. Happy to do more PRs to resolve the |
|
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 5b25a48 |
michaelsproul
added
docs
|
@Mergifyio refresh |
✅ Pull request refreshed |
I think its cleaner and easier to use the docker-compose setup we have in Siren.
I also think it's not great to recommend using
docker run --rmas the container will be nuked when it closes.I've added installation instructions for docker compose and modified the docker run command.
This should work once sigp/siren#371 is merged to stable.