It auto discovers machines/instances/VMs/containers in the mesh and figures out the secure routing on the fly. If you couldn’t ensure a consistent IP from the home address it wouldn’t matter… The service mesh would work it out.
It is probably overkill for this project though… Something to think about…
With Prometheus I would add a section to the scrap config to rewrite the labels attached to each metric. Does such a thing exist for telegraf? I’ve never used it.
Or could you change the grafana query to just aggregate the values for all pods in that deployment?
Istio is a service mesh. You basically run proxies on the vps and the rpi. The apps make calls to localhost and the proxy layer figures out the communication between each proxy.
Duck dns is just a dynamic dns service. It gives you a stable address even if you don’t have a static ip.
This would be nice because I don’t need a static ip and I don’t have to leak my ip address.
How does the VPS know how to find your rpi?
Could you not just use something like duck dns on a cronjob and give out that url?
I would also need to figure out how to supply ejabberd with the correct certificates for the domain. Since it’s running on a different computer than the reverse proxy, would I have to somehow copy the certificate over every time it has to be renewed?
Since the VPS is doing your TLS termination, you would need an encrypted tunnel of some sort. Have you considered something like Istio? That provides mTLS out of the box really… I’ve never seen it for this kind of use case but I don’t see why it wouldn’t work.
Figured this would be one of the responses. Thanks. I don’t interact with node very often. I assumed there was a better option but wasn’t sure which… This is just the first result.
You can do it bro. Dockerfiles are basically just shell scripts with a few extras.
It uses npm to build so start with a node base container. You can find them on docker hub. Alpine-based images are a good starting point.
FROM appdynamics/nodejs-agent:23.5.0-19-alpine
RUN git clone https://github.com/stophecom/sharrr-svelte.git && \
cd sharrr-svelt/ && \
npm run build
If you need to access files from outside of the container, include a VOLUME line. If it needs to be accessible from a specific network port, add an EXPOSE line. Add a CMD line at the end to start whatever command needs to be run to start the process.
Save your Dockerfile and build.
docker build . -t my-sharrr-image
There are build instructions in the readme. What’s stopping you?
Yep. IO.
OP, this might be overkill for you but it might be worth standing up a grafana/prometheus stack… You’d be able to see this stuff a lot faster and potentially narrow in on a root cause.
I think the idea with soft serve us that you use hooks and use a dedicated ci/cd tool. I use adnanh/webhook for lightweight ci/cd on personal projects.
node-0 node-1 node-2 …
Everything runs kubernetes so the names are mostly irrelevant.
Years ago I worked at a company who named everything after WoW characters. I wished murder was legal in those days.
Certbot in cron if you’re still managing servers.
I’m using cert-manager in kube.
I haven’t manually managed a certificate in years… Would never want to do it again either.