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: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
