Live data from Hacker News

ShipBuilder - Open Source PaaS written in Go

github.com

1–10 of 14 posts

Re: ShipBuilder - Open Source PaaS written in Go

#6
post #5

Does this use lxc natively instead of docker? If so, why!?

When we first began creating ShipBuilder several months ago, Docker was too unstable to develop against. We then looked at using bare LXC instead and realized it was very straightforward (basically as simple as: lxc-clone, lxc-start, lxc-stop, and lxc-destroy). In fact, most of the LXC functionality is encapsulated in this 50-line file: https://github.com/Sendhub/shipbuilder/blob/master/src/execu...

I am certainly open to the possibility of adding docker compatibility, especially in the form of a pull-request ;)

Re: ShipBuilder - Open Source PaaS written in Go

#7
post #5

Does this use lxc natively instead of docker? If so, why!?

When we first began creating ShipBuilder several months ago, Docker was too unstable to develop against. We then looked at using bare LXC instead and realized it was very straightforward (basically as simple as: lxc-clone, lxc-start, lxc-stop, and lxc-destroy). In fact, most of the LXC functionality is encapsulated in this 50-line file: https://github.com/Sendhub/shipbuilder/blob/master/src/execu... I am certainly op…

You know what, I kinda like it the way it is now anyway. It's simple, straight-forward, doesn't have too many layers, etc.. I can read it, understand it, hack it, all this quite easily - rare enough to mention.

That's much closer to the kind of stuff I like to use than the pile of layers + apis docker-based solutions are.

Re: ShipBuilder - Open Source PaaS written in Go

#8
post #7

Earlier quoted context omitted.

When we first began creating ShipBuilder several months ago, Docker was too unstable to develop against. We then looked at using bare LXC instead and realized it was very straightforward (basically as simple as: lxc-clone, lxc-start, lxc-stop, and lxc-destroy). In fact, most of the LXC functionality is encapsulated in this 50-line file: https://github.com/Sendhub/shipbuilder/blob/master/src/execu... I am certainly op…

You know what, I kinda like it the way it is now anyway. It's simple, straight-forward, doesn't have too many layers, etc.. I can read it, understand it, hack it, all this quite easily - rare enough to mention. That's much closer to the kind of stuff I like to use than the pile of layers + apis docker-based solutions are.

In docker's defense, it does much more than simply wrap lxc. It also handles logging, port allocation, container versioning, building containers from source code, data persistence, etc. Shipyard will have to re-implement all this (and probably already has, at least partially), and we're definitely not talking about 50 lines.

Not that there anything wrong with that. Docker is quite recent, so it was probably very unstable when shipyard was started, if it was usable at all.

And frankly, even if it weren't: "let he who is without NiH cast the first stone" :)

Re: ShipBuilder - Open Source PaaS written in Go

#10
post #9
post #3

This is a critical part of our high availability infrastructure.

Just curious, what's sendhub's architecture? How many nodes? How many heterogeneous nodes?

We are all SOA, and with ShipBuilder the types of nodes are simplified to: shipbuilder nodes running any kind of desired app servers, databases, load-balancers, and cache servers.
Post reply on HN