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 containers. This said, GsDevKit will setup the above three roles on a single host which will suit development and deployment of any small application. Cheers, J [1] https://github.com/GsDevKit/GsDevKit_ansible <https://github.com/GsDevKit/GsDevKit_ansible> [2] https://downloads.gemtalksystems.com/docs/GemStone64/3.4.x/GS64-SysAdminGuide-3.4/GS64-SysAdminGuide-3.4.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.4.x/GS64-SysAdminGuide-3.4/5-Distributed.htm <https://downloads.gemtalksystems.com/docs/GemStone64/3.4.x/GS64-SysAdminGuide-3.4/GS64-SysAdminGuide-3.4.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.4.x/GS64-SysAdminGuide-3.4/5-Distributed.htm>
