Re: WO with docker and kubernetes
Re: WO with docker and kubernetes
- Subject: Re: WO with docker and kubernetes
- From: Tim W via Webobjects-dev <email@hidden>
- Date: Mon, 8 Jun 2020 11:25:43 -0700
Hey Aaron:
Good thoughts - and its nice to see that Wolfy has some things out there
already. I haven’t stuck my toe in this yet with regard to deployment but I
have been using the Docker tools locally to do development against - db, httpd.
I really love the convenience of these tools. And I’m super attracted to the
idea that deployment targets could be identical to the local dev targets - just
move the container.
I started down the road of learning the scripting/build tools in kubernetes -
with the main roadblock being time away from the "normal work.”
I do think that moving a lot of the base toolset into containers is a great way
to keep the barrier low to our beloved WO. As you noted, there’s always someone
popping back up struggling to get the toolchain setup or the deployment
environment right, or apache 2.2 vs. 2.4 adapter - whatever it may be.
Tim
> On Jun 7, 2020, at 10:44 AM, Aaron Rosenzweig via Webobjects-dev
> <email@hidden> wrote:
>
> 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
_______________________________________________
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