[Glass] GemStone on ubuntu server
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
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>
More information about the Glass
mailing list