
Show HN: Jetpack, a FreeBSD Jail/ZFS-based container runtime - mpasternacki
https://github.com/3ofcoins/jetpack
======
derpderp1
This looks interesting, I'm still holding my breath to see if Joyent are going
to bring zfs support to docker though. It looks like they're working on
reviving lx branded zones instead which is a bit of a bummer as they are (or
were) pretty terrible.

~~~
bcantrill
We have put (and are putting) a bunch of work into LX branded zones[1], and
are at the point that they are working on an incredibly broad class of apps
(64-bit and with on-the-metal performance). A concrete case in point: we
recently ran the (amazing!) hundred language quine relay[2] in an LX branded
64-bit Ubuntu 14.04 zone on SmartOS.[3]

As for ZFS support and Docker, it will be via sdc-docker[4], our (emerging)
end-point for the Docker Remote API. The progress there has been swift and
everything is being done in the open; expect to see something in production
from us in this first calendar quarter.

[1]
[https://www.youtube.com/watch?v=TrfD3pC0VSs](https://www.youtube.com/watch?v=TrfD3pC0VSs)

[2] [https://github.com/mame/quine-relay](https://github.com/mame/quine-relay)

[3]
[https://twitter.com/bcantrill/status/554076708173643776](https://twitter.com/bcantrill/status/554076708173643776)

[4] [https://github.com/joyent/sdc-docker](https://github.com/joyent/sdc-
docker)

~~~
derpderp1
All looks very interesting.

Am I right to assume then that there isn't going to be a SmartOS/SunOS
'docker' client which can understand zfs+zones / replace vmadm/zoneadm? I had
planned on looking into writing this when they announced the 'new' pluggable
architecture some while ago..

Because, that would freakin' rock...

~~~
bcantrill
We don't plan to do such a thing, but we would (obviously) be supportive. The
challenges for a Docker daemon on SmartOS are several-fold: first, while
clearly sympathetic to cross-platform concerns, Docker itself isn't actually
(yet) cross-platform, and many Linux-isms were found in putatively generic
code. Second, the Docker daemon has a hard dependency on cgo, which is even
nastier than Go itself to get working on non-Linux systems. (We did ultimately
get cgo working on illumos -- albeit arguably at the cost of the sanity of the
engineer who did the work.[1]) Finally, in terms of deploying this into
production, we're not about to take third party code from anyone and run it in
the global zone on production machines.

So for us, it makes much more sense to implement the Docker Remote API on top
of SmartDataCenter, which has the added advantage of virtualizing the concept
of a Docker host to be an entire datacenter. But again, we would be supportive
of any effort to straight-up port Docker to SmartOS, and we are generally
supportive of any container effort that is looking beyond the (mis)design of
Linux containers (including the work linked to here for FreeBSD + ZFS).

[1] [http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-
trash/](http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/)

~~~
jacques_chester
Consider looking at Warden/Garden as alternative. The main backend currently
is for Linux and uses some of the same stuff as Docker. But there's a Windows
backend coming too and (hand-wavey gesture here) I imagine this means it was
written fairly generically.

[https://github.com/cloudfoundry/warden](https://github.com/cloudfoundry/warden)

[https://github.com/cloudfoundry-
incubator/garden](https://github.com/cloudfoundry-incubator/garden)

------
synchronise
I would use this, I really would, but the problem I have with ZFS RAID-Z1 and
2 shares, once you setup the storage pool, you can't dynamically add hard
drives to the pool, you have to set it up weirdly like RAIDZ-1+1. All I want
to do is add more storage to my 5TB pool without having to wipe it all or
change the configuration to something else because I want to add a hard drive.

------
contingencies
I'm still working on a generalized system (not OS specific), with ZFS support
in there and working. Have begun discussions about open sourcing this with
management. In theory it will let people go 'show me this thing on <x>
platform and <y> platform, benchmarked'. Platform strengths will then speak
for themselves, and platform maintainers will have the same
version/build/evaluate loop that regular service developers use.
[http://stani.sh/walter/pfcts/](http://stani.sh/walter/pfcts/)

------
Animats
Please call it something else. Mozilla's plug-in API is called "Jetpack".
Thanks.

~~~
mpasternacki
There's also a WordPress plugin called "Jetpack". Both are so different areas,
that I don't think it matters much. If it happens that either project is
actually bothered by mine and reaches out to me, I'll be happy to talk.

I've checked for name conflicts in related areas, in package repositories
(FreeBSD ports, Debian's and Ubuntu's archives), major open source hosting
services, and haven't found anything related. Let me know if I missed anything
relevant.

~~~
georgestephanis
Howdy!

I'm the team lead of the Jetpack plugin for WordPress. I've passed it upstream
to our in-house counsel just for a cursory review should it conflict with
trademark scope or something.

(What do I know, I'm a dev, not one of those lawyer-types)

(But as the Mozilla Jetpack thing existed before we did, and we both coexist,
I'm not expecting a kerfluffle, but who knows -- I am not a Lawyer!)

~~~
mpasternacki
Thanks for taking care of that! Please let me know if your legal team finds
anything wrong. If you need to contact me, either open a GitHub issue on the
repo, or email me (maciej at 3ofcoins dot net).

------
gaalze
The best alternative:
[http://www.7he.at/freebsd/vps/](http://www.7he.at/freebsd/vps/)

Jails aren't that great:
[https://aboutthebsds.wordpress.com/2013/01/13/freebsd-
jails-...](https://aboutthebsds.wordpress.com/2013/01/13/freebsd-jails-are-a-
huge-security-danger/)

But there is Capsicum too:
[http://lwn.net/Articles/482858/](http://lwn.net/Articles/482858/)

~~~
duaneb
I would be far more willing to entrust a production DB to a jail than a docker
container because it's been audited over the course of >a decade. Furthermore,
aboutthebsds is a well-known linux polemicist blog.

~~~
derpderp1
My main use of Docker is for making application deployment less painful. I've
heard of a few people who say they're running their prod DBs under docker but
I cannot begin to imagine how fucktarded you'd need to be to do this (unless
they have some requirement to spin up lots and lots of short-lived dbs, and
those dbs have very, very low storage performance requirements...)

Would you do that? Why?

~~~
mpasternacki
I don't think that beginning your question with "I cannot begin to imagine how
fucktarded you'd need to be to do this" is going to encourage people to answer
that question…

That aside, my approach with Linux/Docker is to have a "fat" host system that
is open to the outside world, terminates SSL, load balances and proxies the
containers' services (nginx), and provides global services are either shared
between containers (Postfix smarthosting to Sendgrid, DNS cache, rsyslog), or
services that can manage user/service isolation well enough on their own
(PostgreSQL). Containers run mostly applications, or services that I need in
multiple instances or versions.

I do containerize Redis, as it can't be safely shared across multiple services
(no privilege isolation, too easy for one service to DoS the other with a
blocking operation), but then I don't consider Redis to be a database – it's
rather a "shared state server", kind of a more sophisticated memcached.

However, I understand the approach of CoreOS, which minimizes role of the host
OS. In this model, host's only role is to support containers, and every other
process needs to be containerized. From this point of view, Postgres is an
application. This way, I can flexibly run multiple version of Postgres, try to
upgrade it without needing to set up separate host service, and so on.
Personally, I wouldn't feel comfortable with that, but I understand how it
could be useful.

Regarding storage performance, database's data directory would need to be a
volume anyway (to be able to upgrade database without trowing away the data).
A volume is just a `mount --bind`, without any aufs layers, to any point of
the filesystem, so it doesn't seem to me that i/o performance hit would be
noticeable…

