Forum: JRuby [ANN] Introducing SyncWrap, a provisioning and deployment tool

18bacf315805a25fe9dd18037c9306c7?d=identicon&s=25 David Kellum (Guest)
on 2014-03-24 17:57
(Received via mailing list)
Docs: http://rdoc.gravitext.com/syncwrap/
Source: http://github.com/dekellum/syncwrap
Background: http://gravitext.com/2014/03/20/syncwrap-for-engineers.html
More Examples:
http://gravitext.com/2014/03/19/provision-programming.html

While I've also made a more general introduction on ruby-talk, I think
of particular interest here for JRuby users:

(1) Unlike some alternatives in this space, SyncWrap is tested and
actually runs well on JRuby.

(2) I maintain several JRuby applications in production environments,
and SyncWrap includes provisioning for an entire "system" JRuby
installation with some nice if opinionated refinements. Even if you are
not particularly excited about yet-another provisioning/deployment tool,
if you have a disposable VM or an Amazon WS account, you might find it
interesting to spin up a host and see what it looks like:

Just a system JRuby on a local (CentOS or Ubuntu) VM:

https://github.com/dekellum/syncwrap/blob/dev/exam...

Combine with the following for EC2:

https://github.com/dekellum/syncwrap/blob/dev/exam...

And with working EC2 setup keys per above, the following deploys the
Iyyov process monitor which in turn launches a gem packaged Sinatra app
(a Geminabox private gem server), 100% on JRuby:

gem install syncwrap
curl -O https://github.com/dekellum/syncwrap/raw/dev/test/...
syncwrap -C basic:myhost -v

Oh and change those jruby 1.7.10 references to 1.7.11 please.

Disclaimer: This is Apache licensed software, no warranties, your AWS or
other usage and expense is entirely your own responsibility. Deployment
tools don't kill people, people kill people.

I would greatly appreciate any direct feedback, questions, or pull
requests!

--David
Caa2df9372ffa0a9e95b2bab1e8fea34?d=identicon&s=25 Karol Bucek (Guest)
on 2014-03-25 07:40
(Received via mailing list)
Congrats David, looks really handy ...

K.
C0cb3aadb9a66d00df16686f4a1fc312?d=identicon&s=25 Tim Uckun (Guest)
on 2014-03-25 21:37
(Received via mailing list)
Reminds me a little of a tool called Automateit
http://automateit.org/which I used a while ago. It was really nice but
got abandoned for some
reason.
18bacf315805a25fe9dd18037c9306c7?d=identicon&s=25 David Kellum (Guest)
on 2014-03-26 02:36
(Received via mailing list)
Thanks to all for taking a look.

I was not familiar with Automateit. Thanks for the reference.  As a
project it looks like it went much farther than SyncWrap has as yet.

Python's Fabric, which remains live and well, is evidence of potential
viability for SyncWrap: Similar if independent design, functionality,
but Ruby developers will prefer to automate in Ruby not Python.

I started SyncWrap (1.x) as a set of mixin modules to get some
provisioning/deployment reuse, originally under Vlad
(rake-remote_task).  This kind of worked but was rather ugly, as would
any attempt to reimpose class-scope around Rake task Procs! Capistrano
didn't work on JRuby at that time, and continues to be headed away from
the provisioning problem. SyncWrap 2.x is a structural rewrite and is
much improved.

As the Background post suggests, I have not been able to humor the
complexity and other shortcomings of tools like Chef or Puppet; and I
believe I am not the only one.  Commonly seen provisioning with
Capistrano demonstrates that. SyncWrap is already a better tool for
provisioning and with some community interest and collaboration, could
also be a better tool for Rails deployments, including JRuby
Rails-deployments.

--David
C0cb3aadb9a66d00df16686f4a1fc312?d=identicon&s=25 Tim Uckun (Guest)
on 2014-03-26 13:43
(Received via mailing list)
I hacked away on Automateit for a bit myself. I kind of used it to roll
my
own system which worked slightly different but used all the base
components
of it.  It had the same idea as yours which is a linear approach to
provisioning. First you do this, then you do that.  Each operation was
idempotent.  You may want to crib some of their code. They used a very
object oriented approach and it was really easy to extend it.

Having used both puppet and chef I kind of agree with you about the
complexity but I guess some of that complexity is needed if you have
convoluted dependencies and if you don't want to keep restarting
services
(delayed processing).  Chef especially has become a ball of yarn with
knife, test-kitchen, berkshelf or librarian etc.  It's powerful but very
complex at times.  Igal who wrote Automateit ended up being a
contributor
to both Chef and Puppet if I recall correctly.

Anyway congratulations on your project and good luck. It's an
interesting
field and I for one think there is room for improvement.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.