sebastiandaschner news

saturday, february 10, 2018

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.

 

What’s new

 

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:

$> 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 hello-world-credentials.

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.

The 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 --namespace or -n, or by simply requesting --all-namespaces.

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>

For 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>

Finally, kubectl config get-contexts lists the contexts from the kubectl configuration.

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:

All opinions are my own and do not reflect those of my employer or colleagues.