dat
dat copied to clipboard
How to run dat inside kubernetes
Is anyone successfully running dat from inside kubernetes? The following Deployment is currently working for me, but it would be nice to avoid requiring hostNetwork: true
. Also wondering how to best specify the .dat keys. I am currently sharing them from the host which works all right in this scenario, but isn't a very general solution. Also, the node this container is running on essentially has a public ip which might be making this easier. I haven't yet tested it from inside kubernetes on a node without a public ip.
apiVersion: apps/v1
kind: Deployment
metadata:
name: dat-server
labels:
app: dat-server
spec:
replicas: 1
selector:
matchLabels:
app: dat-server
template:
metadata:
labels:
app: dat-server
spec:
volumes:
- name: nfs
hostPath:
path: /mnt/nfs
type: Directory
- name: dat-key
hostPath:
path: /root/.dat
type: Directory
# kubernetes secrets can't have subdirectories so this doesn't work
# - name: dat-key
# secret:
# secretName: dat-key
containers:
- name: dat-server
image: registry/dat:latest
command:
- "dat"
- "share"
- "/mnt/nfs/"
# - "sleep"
# - "300"
volumeMounts:
- name: nfs
mountPath: /mnt/nfs
- name: dat-key
mountPath: /root/.dat
# this gets dat network access, otherwise i get symmetric nat errors from dat doctor
hostNetwork: true
# sort of a hack, run this only on the node running the nfs server
nodeSelector:
nfs: server
# ---
# # I was still unable to access dat with this service
# kind: Service
# apiVersion: v1
# metadata:
# name: dat-server
# spec:
# type: NodePort
# selector:
# app: dat-server
# ports:
# - name: dat-tcp
# protocol: TCP
# nodePort: 30282
# port: 30282
# targetPort: 30282
# - name: dat-udp
# protocol: UDP
# nodePort: 30282
# port: 30282
# targetPort: 30282
I think @ninabreznik and @jam10o were messing around with getting it to work in docker. I'd assume that it'll be hard to get incoming connections to work (or the DHT?), but I don't have hands on experience with it myself.
Thanks, btw I've tested the above solution on nodes that dont have public ips with success. Would still like avoid hostNetwork: true
, but it is running. I've also had it working in docker with udp and TCP ports opened as well.
@dwiel that's great. Can you share your dockerfile to see your configuration and hopefully make it run too?
Thanks @RangerMauve for a ping!
The dockerfile is very simple:
FROM node:11
# https://stackoverflow.com/a/45505787/2093984
RUN npm -g config set user root
RUN npm cache clean --force
RUN npm install -g dat
From another thread here i got the flags for running inside of docker (not kubernetes): -p 3282:3282/udp -p 3282:3282/tcp
Thanks, @dwie. I actually tried this but it somehow doesn't work. Maybe I am missing something else here, but if you want to check my repo that I containerize and run on Digital Ocean, please check it out and if you have any comment/suggestion, please let me know https://github.com/ninabreznik/ethplay
It looks like you are missing udp port 3282. You have to open udp ports independently from tcp ports.
It looks like you are missing udp port 3282. You have to open udp ports independently from tcp ports.
Like this? https://github.com/ninabreznik/ethplay/blob/master/Dockerfile
I tried this and then ran it on Digital Ocean with a command -p 3282:3282/tcp -p 3282:3282/udp
but sadly still nothing :/
Hmm, that looks right. Have you tried running dat doctor
from inside the container? That helped me debug my setup.
The problem is I am running a hypertrie and afaik dat doctor doesn't work with the hypertrie, so I am not sure how to debug this...
On Thu, Oct 31, 2019 at 11:29 AM Zach Dwiel [email protected] wrote:
Hmm, that looks right. Have you tried running dat doctor from inside the container? That helped me debug my setup.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/datproject/dat/issues/1158?email_source=notifications&email_token=AAIGZSY6XXG4CQDA646UCYDQRJNJ5A5CNFSM4JEWDLFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWQ4UY#issuecomment-548212307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIGZS6FHIOTSIQCA5HEDD3QRJNJ5ANCNFSM4JEWDLFA .
--
Nina Breznik, Vision Baker play.ethereum.org wizardamigos.com
Twitter: @ninabreznik
Telegram: +1 510 747 84 39 Gitter: gitter.im/ninabreznik
This is interesting. @ninabreznik you can try add DEBUG=discovery-swarm-web-server
to your npm discovery script, so it would be something like this:
"scripts": {
"start": "node app.js",
"discovery": "DEBUG=discovery-swarm-web-server discovery-swarm-web"
}
If everything is starting OK, the debug should output any connection error. Maybe that could help to debug.
@dpaez That's cool, thanks. Now, I see that there is another problem. And that's the fact that discovery-swarm-web doesn't support hypertrie... Any idea how to fix this? Or how to use hyperswarm in the browser?
@ninabreznik I haven't used hypertrie
directly nor in the browser yet. But I give it a look to the discovery-swarm-web
dependencies and seems like hyperdiscovery
needs an update to be compatible with the latest hypercore-protocol
used by hypertrie
. Withouth that discovery-swarm-web
wont work with hypertries directly. That's my guess.
Thanks @dpaez, looks like something @RangerMauve mentioned too. He'll try to help out and we'll see what needs to be done and how to fix it :)
Thanks a lot for helping out. Will share my findings once I make it work :dancing_women: