External Timer Backing Store about skyring HOT 6 CLOSED

So you have a couple of options for this

1. if you are using the docker images off of quay, the storage path is set to and exposed volume at /var/data/skyring. You could set the storage backend to leveldown( NODE_ENV=production storage__backend=leveldown ) and mount this from the container to the target host.

What I've done in the past is tag / label a number of hosts for running skyring instances and the skyring containers only get deployed to those hosts labled as such. It doesn't really matter which instance gets deployed to which host at that point as long as they all mount the same directory path, everything is fine.

2. wrap the project and use one of the leveldown compatible modules. I just released 5.0.2 that fixed a bit of a problem with the level package, but this works just fine.

$ mkdir skyring-mongo
$ cd skyring-mongo
$ npm init
$ npm install skyring mongodown

$ docker run -d --name=mongo -p 27017:27017 mongo

'use strict'

const Skyring = require('skyring')

const server = new Skyring({
  storage: {
    backend: 'mongodown'
  }
})

server.load().listen(process.env.PORT || 3000, (err) => {
  if(err) {
    process.exitCode = 1;
    console.error(err);
    throw err;
  }
  console.log('server listening');
});

function onSignal() {
  server.close(()=>{
    console.log('shutting down');
  });
}
process.once('SIGINT', onSignal);
process.once('SIGTERM', onSignal);

run it like so:

node . --storage:path=skyring-1 --channel:port=3456 --seeds=localhost:3456
node . --storage:path=skyring-2 --channel:port=3455 --seeds=localhost:3456

I picked a backed at random from here https://github.com/Level/levelup/wiki/Modules#storage
This mongo backend seems to use the storage path as the database name, so you can still keep data for each node isolated. But I can't speak much it's performance metrics.

Technically anything you can make conform to the leveldown api, you can use as a backend. Ill do a little more clean up / testing in the storage code and try a few more backends this week

@TheConnMan was there a backend in particular you had in mind?
I'd be interested to explore swappable backends more. I haven't tried many out side of memdown, leveldown and now mongodown

from skyring.

Awesome, that's exactly what I'm looking for. Hadn't heard of leveldown before looking at this project. No backend in particular (though I'm drawn to a serverless backend like DynamoDB so I don't have to run a DB myself).

I was planning on using the quay images, though when using ECS or Kubernetes (maybe less so with Kubernetes pods) if a container goes down it may not show up again on the same host, so I wouldn't want to mount the Docker volume to the host if it's only going to work part of the time.

I'll test out DynamoDB and see how it performs.

from skyring.

@TheConnMan I've have an alpha out for v6 that enables some better options handling for storage backends. I have included a working example for mongodb. I'll be adding more examples & docs for external storage in the coming weeks. This example uses a single mongo DB where each node gets it's own collection.

I'd like to get a couple more working examples & tutorials for v6. maybe redis and a sql store. Since dynamo was your first use case. I can look into that too.

Back to your original point of ECS / Kubernetes. One thing you might want to be mindful of is where seed nodes end up. Seed nodes are used be non-seed nodes to find everything else in the cluster when starting up. There isn't really anything special about them other then they need to be at the specified location when other nodes are looking for them. I'm pretty sure this is solvable w/ kubernetes DNS & a separate deployment for seed & non-seed nodes, but I have not really tried with that kind of a setup as of yet.

from skyring.

Awesome, I'm looking forward to trying out some of the examples. If you can get Mongo working I'm sure I can get Dynamo working as well.

As far as Kuberbetes I got pretty close to getting it working without explicit seen nodes. Kubernetes deployments have an internal DNS entry which is populated with all IPs of running nodes. My idea is when the cluster comes up I can set the seed node to be this IP. The first container which comes up will resolve this to nothing and will seed the cluster. The next node will come up and see the first node and register with it. Then all other nodes come up seeded by existing nodes.

I'm learning Kubernetes along the way, so lots of moving parts, but I hope I can get a fully running cluster without defining explicit IPs for anyone. Match that with an external backing store and I'll have a fully durable, container based cluster.

from skyring.

@TheConnMan I've added another example using ScyllaDb

are you having any luck with K8s? I don't have much personal experience, but we Use it a great deal @ help.com. Maybe if you layout what you're are trying to do I put together a working setup for minikube or something like that.

from skyring.

@esatterwhite I didn't have any luck with K8, but when creating an example Upring project I think I learned why. Upring uses SWIM directly and can be bootstrapped with a base SWIM container. I tried running this directly on K8 using the service DNS name as the bootstrap, but nothing took. Even running against a base SWIM container service didn't work. Finally I tried running a single base SWIM container deployment and used that deployment's internal IP to bootstrap and it works.

I came to the conclusion that SWIM really needs a direct IP address for each seed container, which a K8 service DNS entry will never provide. After seeding, though, everything worked well. I think that's good enough for me.

For this project I would need to run a single Skyring node as that seed deployment, then run a cluster backed by it.

from skyring.