Closed rolandweber closed 4 years ago
IBM Cloud provides a free, single-node Kubernetes cluster: https://cloud.ibm.com/docs/containers?topic=containers-faqs#faq_free
I could use a websphere-liberty container image as base: https://cloud.ibm.com/docs/containers?topic=containers-getting-started#deploy-app The Pityoulish servers aren't JEE, so a regular openjdk base image might be better. https://hub.docker.com/_/openjdk?tab=tags
I haven't decided yet whether I'll build container images publicly, or just on my machine. That affects the hosting choices for the images. GitHub packages support container images ("Dockerfile" format), the build could be integrated with GitHub actions. https://docs.github.com/en/packages https://github.com/marketplace/actions/build-and-push-docker-images
In the long run, it would be interesting to turn the server side into a collection of twelvish factor apps: different client-facing protocols, a common message board, asynchronous communication on the server, persistence through a database service, real authentication with oauth, separate source repos for each app, and so on.
For the upcoming lectures, I'll be happy to just get the current server code working in an online setting.
Both server implementations automatically shut down after one hour... nice error situation in the classroom, but shouldn't happen when hosted online. Unless I wanted to implement automatic restarts, which I don't.
The JRMI server needs two ports exposed, one for the registry, the other for the calls to the target objects. Or maybe I can map the target objects to the same port. Currently, an ephemeral port is chosen for the target objects. That won't work, I need to know the port in advance to map it when starting the pod.
Implement the pod-specific behavior through environment variables, or as a separate class for starting the servers? Actually, I'd like to start both servers in the same JVM, with a single message board shared between them. A dedicated entry point seems reasonable for that.
Depending on where I'll host the server, maybe I can open a website that shows the log output, and share that on my screen.
Alright, I've got server code that exposes Java RMI and the binary TLV protocol against the same message board and ticket manager. Still missing:
I'll have to figure out where and how to host the image before handling the hostname. The hostname will probably be set in an environment variable, so I can pick it up from there when launching Java.
There's a starter-workflow for a GitHub action that builds an image and runs it in Kubernetes on IBM Cloud. https://github.com/actions/starter-workflows/blob/3ba9eeb432e0b1b40be20d0f82b7a481bb8b1c89/ci/ibm.yml
The image gets pushed to IBM Cloud Registry in that example. I'm not sure whether the IBM Kubernetes service could use images directly from another registry, or how tricky it might become to set up credentials for that.
I'll host the container image(s) on GitHub packages. They're automatically pushed there from a GitHub workflow. This should make it simple for interested students to pull the image, if they want to run the server themselves.
I'm not planning on keeping legacy images around though.
While IBM Cloud provides a free, single-node Kubernetes cluster, it doesn't do so with a lite account. I'll have to upgrade to a pay-as-you-go account and put in credit card details.
Google and Amazon have a minimum charge for Kubernetes clusters. Azure free accounts are limited to 12 months. Did I miss one of the big providers?
Looks like IBM Cloud wins for my use case.
Grmpf. While the cluster is free, there may be costs for network traffic. Haven't found info yet whether there is some small, free bandwidth available with the free cluster. Not that I'd mind paying a few cents, but it would be nice to know in advance.
Maybe they're throttling the bandwidth or total volume for free clusters, which should be OK. I don't expect GB of traffic, except maybe for the container image itself. In which case I should upload it to the IBM registry as well as GitHub packages.
I've got the server running in IBM Cloud, see instructions at src/pod/DeployOnKubernetes.md.
There are GitHub workflows for building the image, and pushing it to the IBM Cloud Container Registry. Public access: https://github.com/users/rolandweber/packages/container/pityoulish%2Fserver/45642 Note that I might delete old versions at any time. Don't rely on a specific version to remain available.
Still need to reduce log output for follow-the-board clients, see #88.
With the ongoing Corona virus pandemic, there will be no classroom sessions this year. Figure out how to take the debugging exercises online. So far, they were heavily based on me walking through the classroom and looking over student's shoulders. Also, the visual feedback during debugging depends on a projector showing output of the server. Last but not least, I cannot set up an isolated WLAN with an old FritzBox for an online version of the exercises.
kubectl logs -f <pod>
and the follow-the-board client on my shared screen.