I use a local Kubernetes cluster to help me develop microservices. On my 2015 Macbook Pro, the cluster ran inside a Minikube VM using the Hyperkit driver. Replicating this setup on my new 2021 Macbook Pro proved impractical. This is how I made it work.
As a developer, you are familiar with Docker. You push your images to the Hub, use Compose locally and know a thing or two about Kubernetes. Or… Well… To be honest… You don’t. And you are ashamed you don’t know anything about it. You browse the internet and it’s so overwhelming. So you stop looking and continue what you’ve been doing all the time. Deep inside, you still wonder. Can’t anyone not just explain Docker in simple terms? Is it really this hard? Or am I just missing something really obvious?
On OSX and Windows, as you might know, directories are case insensitive. So the directory CaseSensitive and casesensitive are the same on those operating systems. But on Linux, they are different directories.
A year ago Dave Syer posted an excellent, comprehensive overview of how to run Spring Boot applications in Docker. He delves into the various ways to package Spring Boot applications into properly layered Docker images, highlighting the benefits and basic building blocks of each approach.
This post expands on an hint within the corresponding Spring Boot Docker topical guide:
When building a service in gRPC you define the message and service definition in a .proto file. gRPC generates client, server and DTO implementations automatically for you in multiple languages. At the end of this post you will understand how to make your gRPC API also accessible via HTTP JSON by using Envoy as a transcoding proxy. You can test it out yourself by running the Java code in the attached github repo. For a quick introduction on gRPC itself, please read gRPC as an alternative to REST.
Once you have a working gRPC service, you can expose a gRPC service as an HTTP JSON API by simply adding some extra annotations to your service definition. Then you need a proxy that translates your HTTP JSON calls and passes them to your gRPC service. We call this process transcoding. Your service is then accessible via gRPC and via HTTP/JSON. I would prefer using gRPC most of the time because it’s more convenient and safer to work with type-safe generated code that follows the ‘contract’, but sometimes transcoding can come in handy:
Your webapp can talk to your gRPC service using HTTP/JSON calls. https://github.com/grpc/grpc-web is a JavaScript gRPC implementation that can be used from within the browser. This project is promising but is not yet mature.
Because gRPC uses a binary format on the wire, it can be hard to see what is actually being sent and received. Exposing it as an HTTP/JSON API makes it easier to inspect a service by using for example cURL or postman.
If you are using a language for which no gRPC compiler exists, you can access it via HTTP/JSON.
It paves the way for a smoother adoption of gRPC in your projects, allowing other teams to gradually transition.
Some time ago, I was working on a project where I had to fix an issue that was raised by our OWASP Zap scanner, which is a free security tool that runs in the test phase of the Jenkins build of the project. It checks for security vulnerabilities that you want to prevent from going to Production.
With the release of Java 9, and the introduction of Project Jigsaw (the Java Platform Module System), we no longer have the need for a full-blown JRE to run our Java applications. It is now possible to construct a stripped-down Java Runtime, containing the minimum set of required modules. This allows us to create slim Docker containers without excess baggage. The source code belonging to this blog post can be found at: https://github.com/rlippolis/java9-runtime-image
Our example application consists of two Java 9 modules (basically two JARs, with a module-info.java).
We assume the concept of modules is familiar to the reader.
If not, you can learn more about it e.g. here: http://openjdk.java.net/projects/jigsaw/
Firstly, we have a backend module consisting of a class which provides us with a String (to keep it simple).
The backend module has no explicit dependencies on other modules (only an implicit dependency on java.base).
Secondly, we have a frontend module consisting of an executable main class.
This class gets the String from the backend and prints it to System.out (again, very straightforward).
This module has an explicit dependency on backend, and an implicit dependency on java.base.
To see the application in action, build it with Maven (mvn clean package), and run it from the command line:
(or use the provided run-app.sh) The -p option sets the module path (similar to the 'old' classpath).
The -m option specifies the module and class to run.
