[Glass] GemStone on ubuntu server

Mon Jan 9 11:01:42 PST 2017

Hello Sebastian,

You've asked some fairly broad questions here and I'm hoping that other 
developers will chime in with some details about the approaches that 
they've taken (those that have worked and those that haven't).

For the production and staging servers, you will probably need to some 
sort of process monitoring.

On http://ss3.gemtalksystems.com/, which is running Ubuntu 12.04, I use 
daemontools[1] for automatic restart of gems, monit[2] for ensuring that 
the running seaside servers are actually responding, and custom scripts 
in /etc/init.d for starting the system when the server reboots.

The ss3 installation predates my GsDevKit_home work, but today I would 
base the ss3 installation on GsDevKit_home.

I know that Paul DeBruicker has been doing work with integrating 
daemontools into the GsDevKit_home environment[4] and building some 
ansible[6] scripts that are aimed at deplying GsDevKit_home 
environments[5] ... I know that these are currently a work in progress, 
but perhaps Paul can provide some additional pointers?

=======

In the following section, I want to dive a little deeper into some of 
the GsDevKit_home features that may apply to the management of your 
dev/stagin/production servers.

If you look at at GsDevKit_home installation, you will note that the 
directory structure under $GS_HOME/sys/local is a separate github 
project GsDevKit_sys_local. $GS_HOME/sys/local is where you store your 
local GsDevKit_home customization. For your system, you can add your 
personal git projects so that they will be managed consistently by both 
the $GS_HOME/bin/updateGsDevKit and the tODE `project list`.

The $GS_HOME/sys/default/gsdevkit_bin repository management scripts[10] 
(called by $Gs_HOME/bin/updateGsDevKit) can be customized by putting 
local versions of the scripts into the $GS_HOME/sys/local/gsdevkit_bin 
directory. The tODE build scripts[11] can be customized by putting 
customized copies of the scripts into $GS_HOME/sys/local/client, or 
adding your own client scripts.

For an example of tying into the $GS_HOME/bin/updateGsDevKit, you can 
look at how I customize the GsDevKit_home travis test environment[7]. 
The  tODE build scripts[8] are customized to remove the backup step and 
the update scripts[9] are customized to control which branch of the 
shared git projects should be used.

The $GS_HOME/sys/local/server/home directory is where shared tODE 
scripts can be stored ... a tODE script stored here will be seen in the 
/home node in all stones. The $GS_HOME/sys/local/server/projects 
directory is where shared project entries are stored ... a project entry 
store here will be seen the `project list` and /projects node for all 
stones ....

Since the $GS_HOME/sys/local is a separate git project it is easy for 
you to manage your git clone and share it between your 
dev/staging/production machines... the project entries and gsdevkit_bin 
scripts are likely to differ between each of the systems, but that can 
be managed by keeping three or 4 different branches: one branch for each 
of the systems scripts ... depending upon how you want to manage things, 
a 4th branch can be used for the common entities ...

========

For building customized stones, I would point to the Tugrik[18] and 
Gt4Gemstone[19] as good examples. In both of these cases an URL is used 
to access the project entry for the project, but in you case you can 
reference a local project entry. See the gh-pages branch of 
GsDevKit_home[20] for additional project entry examples.

Once you've created a custom stone, you can use $GS_HOME/bin/todeIt to 
trigger stone update by running the `project load` tODE command:

   $GS_HOME/bin/todeIt <stone-name> project load <project-name>

If you want to run a tODE script from bash, then you can do the following:

   $GS_HOME/bin/private/gsDevKitTodeCommandLine todeIt <stone-name> << EOF

     project load <project-name-1>

     projet load <project-name-2>

     # additional tODE commands

   EOF

If you prefer/need to run Smalltalk from bash then the following can be 
used:

   $GS_HOME/bin/startTopaz <stone-name> -l << EOF

   login

   run

   "arbitrary smalltalk"

   %

   commit

   exit 0

   EOF

========

With regards to triggering automatic updates, there is nothing out of 
the box for doing this... GitHub has the WebHooks service[12] where an 
url is hit with an http post[13] allowing the server to take whatever 
action is needed ... I haven't looked into this in detail, but I've 
always figured that it would be interesting to eventually hook into this 
service. There are a couple of Pharo projects[14] and [15] that 
implement the GitHub API[16] as well.

The WebHooks server could be implemented in either Pharo or GemStone. 
GsDevKit_home uses Pharo already for implementing some of the 
GsDevKit_home scripts[17], so Pharo "is aware" of the GsDevKit_home 
directory structure and scripts.

========

Hope this helps you get started,

Dale

[1] https://github.com/Monty/GemStone_daemontools_setup

[2] https://www.mmonit.com/monit/

[3] https://github.com/GsDevKit/GsDevKit_sys_local

[4] https://github.com/GsDevKit/GsDevKit_daemontools

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

[6] https://www.ansible.com/

[7] https://github.com/GsDevKit/GsDevKit_home/tree/master/tests/sys/local

[8] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/tests/sys/local/client/tode-scripts

[9] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/tests/sys/local/gsdevkit_bin

[10] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/sys/default/gsdevkit_bin

[11] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/sys/default/client

[12] https://developer.github.com/webhooks/

[13] https://developer.github.com/webhooks/#wildcard-event

[14] https://github.com/astares/GitHub-API

[15] https://github.com/Balletie/GitHub

[16] https://developer.github.com/v3/

[17] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/shared/repos/todeClient

[18] https://github.com/dalehenrich/Tugrik#install-gsdevkit_home

[19] https://github.com/feenkcom/gt4gemstone#installation

[20]https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages

On 1/9/17 9:03 AM, Sebastian Sastre via Glass wrote:
> Hi guys,
>
> I wonder how should I install GemStone on ubuntu. Let me give you 
> context so I can better ask you for your advice:
>
> We are developing the beta version of a SaaS and we have a setup that 
> has 3 parts:
>
> 1. local develop environment (macOS)
> 2. staging server (publishes automated updates when pushing to the 
> develop branch)
> 3. production server (this is a different physical host than staging 
> and publishes automated updates when pushing to master branch)
>
> I’m thinking in doing an installation of gemstone in the staging host 
> and another in the production host. Both have ubuntu 16.04 and I think 
> the best is each to have 1 stone of its own.
>
> So far I’m good with my local dev setup, so now I wonder a bit on how 
> I’d do the devops for the GemStone part.
>
> So questions:
>
> 1. What’s the recommended way to install a small stone with seaside 
> REST and NeoJSON for those hosts
> 2. How can I use MockGemstone on Pharo, save the packages and get them 
> into the stone? can be automated?
> 3. Do you have any suggestion to make a CI to trigger an update on the 
> server when I push a commit to develop or master? (I can make it at 
> the beginning no problem but I’d try to be automated instead of human 
> intervention on those updates)
>
> Thanks!
>
> sebastian <https://about.me/sebastianconcept>
>
> o/
>
> LinkedIn: http://www.linkedin.com/in/sebastiansastre
> github: https://github.com/sebastianconcept
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170109/67b7df4b/attachment.html>