I’ve copied this to the GemStone list to continue the discussion.

> I wouldn't. The excellent work of Norbert was later 
> inspired/continuated/extended officially by GemStone under a much bigger 
> project called GsDevKit [1]
> [1] https://github.com/GsDevKit/GsDevKit_home 
> <https://github.com/GsDevKit/GsDevKit_home>
+1 GsDevKit - it’s excellent for use in both development and deployment.

There’s also an ansible project [1] which may offer some guidance.

If you were planning to build containers for GemStone, there are a bunch of 
possible roles a single host might play in larger systems, but as a minimum:

1. Stone - where the repository (image) is physically managed. Typically only 
one per deployment (or more for warm failover)
2. Gem - where the VM’s run your application or services. Instances scale with 
your application.
3. Shared Page Cache - essentially shared memory access to the image that can 
be deployed in many ways to turn your applications. 

There’s a rundown on connecting distributed systems in the GS System Admin 
Guide [2]. There are likely many other roles right down to transaction logs and 
repository extents (the physical files on disc where your image is persisted), 
it just depends on how far you want to go with the flexibility of the docker 

This said, GsDevKit will setup the above three roles on a single host which 
will suit development and deployment of any small application.


[1] https://github.com/GsDevKit/GsDevKit_ansible 

Reply via email to