Updating my AWS Lambda Sudoku Solver to generate new puzzles (part 1)

Having spent some time in the past building an implementation of Donald Knuth’s Algorithm X in Java to solve Sudoku Puzzles, I recently wondered what it would take to modify it to generate new puzzles.

If you missed my previous posts on this investigation, see:

It turns out having a working solver is part of the way there to implementing a puzzle generator, because you need to be able to check if a puzzle has a single solution, since valid puzzles only have 1 solution.

When I last wrapped my Solver as an AWS Lambda, I had taken the naive approach to call System.exit() in my Solver code if I detected there was more than 1 solution as a quick way to exit and not get stuck in a loop iterating over finding possible thousands of solutions for a grid that’s not a valid puzzle.

I went back and took another look at this and reworked it so I could pass an upper limit for number of puzzles, and changed the return type to return a List of solutions, and a flag indicating if there was a single solution or not. Latest commits on my repo have these changes, and I’m now ready to move on to building the puzzle generator. More updates coming soon.

Installing Weblogic Portal 10.3.6 on MacOS

There’s a number of things that go wrong when attempting to install Weblogic Portal 10.3.6 on MacOS that I’ve covered a few years ago in posts here and here.

To get round these issues, when installing with the generic installer you’ll need to pass these options:

java -d64 -Dos.name=unix -Dspace.detection=false -Xms1024m -Xmx1024m -jar portal103_generic.jar

Last time I needed to do this these options worked for me, although recently when I needed to do a new install I ran into this Fatal Error:

It seems the generic installer will only succeed on most recent versions of MacOS if you install with Java 6. You can chose a Java 7 install to run Weblogic with as part of the install steps.

This post describes installing with Java 6 (and this one describes the same error). I didn’t need to fake out the additional paths/libs with symlinks etc that this post does, I just needed to set Java 6 to JAVA_HOME, and then it ran through to completion ok.

The Legacy Java 6 installer for MacOS can be downloaded from here: https://support.apple.com/kb/dl1572?locale=en_US

Deploying a simple SpringBoot app to Docker for Mac Kubernetes

Several months back I spent some time playing with Kubernetes but it’s been a while so I need to retrace my steps to get back up to speed.

I’ve already have my Docker for Mac single Kubernetes node running (see here)

Next, I need to run a local Docker repository where I can push my Docker images for testing. I walked through these steps here.

I have a Docker image called examplespringboot that I want to deploy to my local single node Kubernetes cluster, so first up, tag it:

docker tag examplespringboot [ip of your docker machine]:5000/examplespringboot

And then push it:

docker push [ip of your docker machine]:5000/examplespringboot

With my local Kubernetes cluster up:

$ kubectl cluster-info
Kubernetes master is running at https://localhost:6443
KubeDNS is running at https://localhost:6443/api/v1/namespaces/kube-system/services/kube-dns/proxy

I created a deployment.yml for my Docker container using the example here:

apiVersion: apps/v1
kind: Deployment
metadata:
name: exampleservice
labels:
app: exampleservice
spec:
replicas: 1
selector:
matchLabels:
app: exampleservice
template:
metadata:
labels:
app: exampleservice
spec:
containers:
- name: exampleservice
image: 192.168.0.126:5000/examplespringboot
ports:
- containerPort: 8080

This references the Docker image from my local Docker repo.

To create the deployment:

$ kubectl create -f exampleservice-deployment.yml

Now you can describe the pod and the deployment and watch them come up:

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
exampleservice-7b9b4b7db9-c7hx6 1/1 Running 0 9m

At this point the running pod is not exposed outside of the cluster. Following the steps here to expose as a service and assign an external ip:

$ kubectl expose deployment exampleservice --type=LoadBalancer --name=exampleservice

If you describe the service you now see it has a LoadBalancer Ingress assigned on localhost:

$ kubectl describe service exampleservice
Name: exampleservice
Namespace: default
Labels: app=exampleservice
Annotations:
Selector: app=exampleservice
Type: LoadBalancer
IP: 10.98.115.137
LoadBalancer Ingress: localhost
Port: 8080/TCP
TargetPort: 8080/TCP
NodePort: 30718/TCP
Endpoints: 10.1.0.16:8080
Session Affinity: None
External Traffic Policy: Cluster
Events:

Calling localhost:8080/example/hello on my service, now it’s up and responding:

{"message":"hello!"}

Done!