Welcome to my 21st newsletter — half of 42 ;-)
One more week until I’m traveling again. January and the beginning of February was comparably quiet, what allowed me to prepare a few new topics and workshops, mainly on the topics of architecture and design patterns, cloud native technology, such as Kubernetes and Istio, and enterprise testing. I’m already looking forward to the next speaking occasions. The first one will be Index in San Francisco, with the DevNexus conference right afterwards. I would love to meet a few of you there!
The EE4J / EE.next story continues as well. In the last days, we got the announcement that the Enterprise Java community can now vote on one of the options “Jakarta EE” or “Enterprise Profile”. I encourage all of you to participate in the voting which is still open until Feb 23rd. David Blevins of the awesome Tomitribe company wrote an interesting blog post explaining how “Jakarta EE” emerged. I loved to read that story — Jakarta EE was also what I voted for. But, I don’t want to influence your decision ;-)
As a preview for my Index conference presentation I was interviewed by DZone CodeTalk about “Containers, the Java EE Way” and my opinion on the current state of Java and Java Enterprise in the cloud native world. I enjoyed giving that interview and hopefully you’ll enjoy listening to it.
Display information of a running OpenJDK JVM
If you quickly want to access the runtime information of an OpenJDK JVM, for example the actual system properties or maximum heap size,
jinfo is an experimental but handy tool which ships with the OpenJDK.
You can display system properties, the effective JVM command line flags and arguments.
First, find the PID of your application, for example using
$> jps 26986 Jps 26060 my-app.jar $> jinfo 26060 Java System Properties: #Sat Feb 10 16:16:09 CET 2018 [...] VM Flags: -XX:CICompilerCount=3 -XX:MaxHeapSize=5228199936 [...] VM Arguments: jvm_args: java_command: my-app.jar [...]
Of course, this is only one way of accessing runtime JVM information. JConsole or JVisualVM provide much deeper insights into applications.
Inject multiple Kubernetes volumes to the same directory
Kubernetes config maps and secrets allow use to inject configuration files into containers. If we want multiple config entries that originate from different config maps or secrets to be injected into the same location, we are required to specify a sub path:
kind: Deployment apiVersion: apps/v1 metadata: name: hello-world spec: replicas: 1 template: metadata: labels: app: hello-world spec: containers: - name: hello-world image: docker.example.com/app:1 volumeMounts: - name: hello-world-config-volume mountPath: /config/application.properties subPath: application.properties readOnly: true - name: hello-world-credentials-volume mountPath: /config/credentials.properties subPath: credentials.properties readOnly: true volumes: - name: hello-world-config-volume configMap: name: hello-world-config - name: hello-world-credentials-volume secret: secretName: hello-world-credentials
This example will create two volumes from the contents of the config map
hello-world-config and the secret
Imagine, these resources have the following contents:
kind: ConfigMap apiVersion: v1 metadata: name: hello-world-config data: application.properties: | greeting=Hello name=World --- kind: Secret apiVersion: v1 metadata: name: hello-world-credentials data: credentials.properties: <base64> type: Opaque
The example will mount the file contents of the key
application.properties of the config map to a file with the same name under
/config/ and will mount the secret value
credentials.properties as the second file under that directory.
The application will be able to access both files read-only.
subPath declaration also allows to mount a single volume into the pod multiple times with different sub paths.
Kubernetes set default namespace
And we stay in the world of Kubernetes.
Per default, the
kubectl command line will return the resources of the
default namespace, for commands such as
kubectl get pods.
We can specify the desired namespace with
-n, or by simply requesting
If we work in a single namespace for a longer time, it’s easier and safer to switch the context to use a different “default” namespace for the current context with:
kubectl config set-context <context> --namespace <namespace>
kubectl config current-context displays the current context name, we can combine these commands to switch to another namespace in the current contexts:
kubectl config set-context $(kubectl config current-context) --namespace <namespace>
kubectl config get-contexts lists the contexts from the
Happy Kubernetes hacking!
Thanks a lot for reading and see you next time!
Did you like the content? You can subscribe to the newsletter for free: