A popular Docker article describes a pattern to initialize stateful container data at runtime. The example uses a Shell script to run the initialization and then pass control to the container’s main command. We can use the same pattern to initialize a Docker Windows container.
Previously we looked at building a Spring Cloud Data Flow on Kubernetes. As a follow up, we’re now looking at deploying to Google Kubernetes Engine. The great thing about Kubernetes you use exactly the same commands to manage a cluster on your laptop as on a server or cloud compute platform. Google has first class support for Kubernetes on the Google Kubernetes Engine so deploying the Primer application was very straightforward.
Spring Cloud Data Flow is a powerful tool for composing and deploying message driven data pipelines. It allows us to compose simple Spring Cloud Stream applications into complex processing pipelines. It also takes care of deploying these pipelines into Kubernetes or into Cloud Foundry.
It’s powerful but has a lot of moving parts. It can be daunting to get a simple pipeline running. This article introduces the Primer demo for SCDF and describes how to deploy it into Kubernetes on a local development machine.
Google App Engine makes it easy to deploy NodeJS applications. The GAE Standard Environment and SDK support NodeJS out of the box. This makes Google App Engine a great choice ahead of competitors such as Heroku, AWS or Microsoft Azure. Unfortunately though, there’s no support for managing secrets in Google App Engine. When I deployed Dog n Bone to GAE, I found this single shortcoming the main source of complexity.
There are however some workarounds. None of them is particularly nice though.
Just sometimes, it’s useful to SSH into a Docker Container. While docker exec or docker attach are usually sufficient to run commands in a container, sometimes you specifically need SSH. For example, to connect directly from a remote machine or when an application needs to run commands on your container. Most Docker images don’t come with the SSHd service installed so it is not possible to SSH to them. This post demonstrates how to install and run the SSHd service to an existing image so that you can connect to it.
A standard unit testing problem is how to unit test code that has a dependency on dates or times. For example a method that returns a greeting according to the time of day:
public String timeOfDayGreeting() {
LocalTime now = LocalTime.now();
if (now.isBefore(LocalTime.NOON)) {
return "Good morning";
} else if (now.isBefore(LocalTime.of(18, 00))) {
return "Good afternoon";
} else {
return "Good evening";
}
}
If we were to call this method from a test fixture (say JUnit), it would return different values depending on when the test was run. This is not ideal. Unit tests should pass or fail consistently.
Here’s a simple solution for testing time based code.
In previous articles, I’ve described how to test System.out with JUnit and how to test log4j with JUnit. This article describes how to test log4j2…
Following a recent article on how to Test System.out with JUnit, here’s a follow up on how to test log4J with JUnit. This article describes a technique to test log4J output in a JUnit test by adding a custom appender. This allows us to verify that log4j output contains expected Strings.
JSPs compile to Java code at run time. This is helpful if we want to test code changes without a build and deploy. However, if errors are introduced, they may not be spotted till it’s too late. A useful compromise is to validate JSPs at build time to verify that they will compile. The validator catches syntax errors before the application deploys and starts. This speeds up our build and test cycle and prevents silly mistakes slipping through to production code.