WO with docker and kubernetes
WO with docker and kubernetes
- Subject: WO with docker and kubernetes
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Sun, 7 Jun 2020 13:44:32 -0400
Has anyone used WO with containers and orchestration tools such as docker and
kubernetes? If so, how’d you like it?
I ran into an issue last week and have started deep diving into this realm
thinking it might be a smart play especially since kubernetes appears to have
won the crown for being the goto orchestration solution. Nearly all cloud
players provide managed kubernetes these days.
I noticed Wolfy has some experience with it:
https://hub.docker.com/u/rentzsch <https://hub.docker.com/u/rentzsch>
Quick definitions for the uninitiated:
Container - a self-contained app piece but not your entire app. You’d have a
container for your DB, another for your webserver, another for your WOA, and
another for open-office to do PDF conversion. In this example you’d have four
containers for a web application that converts files to PDF. You’d probably
want additional containers for each of WOTaskd and JavaMonitor (one container
for each one). A container is a bit like a VM (virtual machine) but it is
slimmed down and often doesn’t have a whole OS but it is isolated and
protected. You can pass containers around as if they were a .zip or .dmg
archive and run them everywhere with a high degree of confidence that they will
work elsewhere (not just your computer). The most popular container system is
Docker and the bedding is linux. So if your host is linux you don’t need to
make your bed but if it is something else like a Mac, FreeBSD, or Windows then
Docker makes a linux vm to host the containers for you.
Orchestration - you need a way to compose your containers and this is it. An
orchestration solution will allow you to place your containers and setup rules
for making sure they have a heartbeat and are not overburdened. If they are
stressed they will automatically grow (make more containers) during peak usage
and automatically de-provision containers when they are not needed. One of the
first well known orchestration tools was Amazon’s Elastic Beanstalk but that
was proprietary. Kubernetes is the open-source alternative and it appears to be
the de-facto standard now. Even Amazon has a managed version of Kubernetes
called EKS, they’ve jumped on the bandwagon. Docker used to have an
orchestration of its own called “swarm” but it, too, has now defaulted to
Kubernetes. If you download the docker desktop one-click installer for Mac
(.dmg) from Docker’s website, it comes pre-installed with Kubernetes but you
need to enable it in the settings panel.
Great, that’s the definitions, but what problems is it trying to solve, what is
it used for?
1) You can run old software and new software side-by-side on the same hardware.
You can run multiple versions of tools on the same hardware. That was my
initial pickle point last week. If I upgraded a library I’d break something I
didn’t want to muck with (something old but working). If I don’t upgrade the
library I can’t start the new project that depends on it. I had a choice, setup
two computers, each with different configuration, and coordinate them… or…
learn about containers and stop thinking about individual computers. With
containers I can have old in one and new in another. I can run both containers
on the same hardware. If I want additional computers I can think of them as
“nodes” that are only there to populate additional containers during times of
high stress.
2) Stop recompiling stuff and reinstalling stuff. It’s always a pain to rebuild
“mod webobjects” and every few months we see posts about this. It’s also a pain
to setup a new computer. Many of us have crib sheets about how to do it but
it’s still a pain. We need to write scripts to build a container. Those scripts
serve as both a crib sheet but also nets us a container that runs everywhere.
As an example we could probably grab Wolfy’s container and run on any computer
right away without worrying about how to compile:
https://hub.docker.com/r/rentzsch/apache-webobjects
<https://hub.docker.com/r/rentzsch/apache-webobjects>
3) “Works on my computer” - don’t you hate that? it works here but not there.
It’s nearly impossible to avoid without containers. You have some pain in
slowing down and thinking about how to make the container but once you do, you
gain the benefit of knowing it will work on a new developer’s computer AND in
production.
4) Auto-scaling - the ability to be hands-off and let the system spin up and
down containers for your app as they are needed. Only pay more when you need
more. Maintain your apps by restarted them if they crash or become unresponsive
in a generic open-source supported way. I believe we all have a love/hate
relationship with wotaskd and JavaMonitor. It basically works and was cool in
1995 but starts to fail when you have lots of instances. There is black voodoo
at times with discoverability too. And while you can provision multiple
instances of your app with JavaMonitor, you cannot set it to auto scale. You
also have to setup each computer individually with wotaskd if you want to scale
in a big way. There is a lot of manual effort and it is only for your java app.
Any horizontal scaling of your web server or DB server is totally different
exercise. With kubernetes you can scale your app, scale your db server, etc and
be hands off. So far all the examples I’ve been trying this weekend are with
Node and MongoDB but I’m pretty sure it can be done for java apps, I just
haven’t wrapped my head around that yet.
5) Better package manager - On Mac Apple never gave us a package manager (no
idea why) so we have to pick either Fink, MacPorts, or Homebrew. Each of them
have various issues. Some of it is app availability (they don’t have the latest
port of something like maybe Postgres). Other times it’s upgrade X but then you
break Y (the dependency trees are never perfect and even if they are, there are
inevitable incompatibilities. Homebrew also installs things where Apple likes
to and that causes grief sometimes. Anyway… with docker they have a repo where
you can pull pretty much anything and it just works. When you want to get rid
of something (like maybe MongoDB) you can trash it and it doesn’t leave rabbit
droppings all over your host OS. Docker might be used as a better package
manager. Look at what apps are out there:
https://hub.docker.com/search?q=&type=image
<https://hub.docker.com/search?q=&type=image>
I figure this can work for WO with respect to 1, 2, & 3 but I’m not sure yet
about 4. Even so, if I cannot do #4, that still seems like a win.
What are your thoughts? Have you been down this rabbit hole?
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e: email@hidden <mailto:email@hidden> t: (301) 956-2319
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden