Launch Spring-Boot JAR From Different Main Class

I found this very useful stack overflow:

It shows you how to start a spring-boot JAR from a different main class.  It’s a quirky solution, but it worked great.  Here’s a slightly more obvious/cleaner copy of the command (mostly for my own future reference):

java -cp presto-ws-3.2.2.jar org.springframework.boot.loader.PropertiesLauncher

AWS EC2 Varying Generation and Linear Cost Example

Due to increased query sizes on our presto clusters (causing aggregation failures), I’m in the middle of evaluating moving from 16 core 64GB RAM general purpose EC2 machines (m4.4xlarge) to 64 core 256GB RAM general purpose machines  (a 4x increase in power/RAM).

Here is the list of m4 and m5 models for 16-core/64GB and 64-core/256GB specs.  Below, we’ll see how they compare to each other and what the best option is.

Type vCPU ECU Memory (GiB) Instance Storage (GB) Linux/UNIX Usage
m4.4xlarge 16 53.5 64 GiB EBS Only $0.80 per Hour
m4.16xlarge 64 188 256 GiB EBS Only $3.20 per Hour
m5.4xlarge 16 70 64 GiB EBS Only $0.768 per Hour
m5.16xlarge 64 256 256 GiB EBS Only $3.072 per Hour

For reference:

EC2 uses the EC2 Compute Unit (ECU) term to describe CPU resources for each instance size where one ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

There are a few good things to notice here:

  • For m4.4xlarge to m4.16xlare, we are getting 4x the resources for exactly  4x the cost  ($.80 x 4 = $3.20).  The one exception is we get less than 4x the ECU  units (so technically less than 4x the processing power).  So, compute roughly scales linearly within a model it seems.
  • Pretty much the exact same situation holds true for the m5 models; going from xlarge to 16xlarge is exactly a 4x increase in cost and resources except for ECUs which are a little less than 4x.
  • The m5 models have more ECUs than their m4 counterparts and they  also cost less, so they are a better deal both  performance and cost wise.

So, we’ll go with  m5.16xlarge instances which cost $3.072 an hour.  This comes out to $2,211 a month.

Kubernetes Ingress Service 60 Second Timeout

Kubernetes has multiple levels of timeouts for calls, including at the load balancer, inbound to the ingress itself, and at the individual ingress resources.

Assuming you have the first two configured and are still hitting a timeout on your  app, this is the annotation you need to add to your service’s ingress resource to boost its timeout: "3600"

This will change it up to 1 hour from 1 minute.

Bash xargs – Use Anywhere in Your Command

If you want to use the xargs command to build a new command and place the standard input from your stream wherever you like (or in multiple places), here is an example:

Let’s say we have a hosts file:

We can take out the first column with awk (the IP column), and we can pipe it to xargs and use -I. Then we can use the % sign to both ssh to the IP and to display a message with the IP written from the host.

This is obviously very flexible and useful for pretty much any command you’re building from earlier inputs :).

cat dynamic_hosts | awk '{print $1}' | xargs -I % ssh % "echo hi from %"

Use wget with self-signed certificate and output to stdout

Not much of an article here… but if you want to use WGET to validate a spring boot app with a self-signed certificate, for example, and you don’t want to bother outputting the results to file, you can do this:

wget -q -O – –no-check-certificate

The output would be right inline and would avoid the certificate validation:

# wget -q -O – –no-check-certificate
{“status”:”UP”} #

You could achieve this with curl as well I’m sure – but it isn’t installed on alpine it seems and I didn’t want to install extra tools.


Kubernetes View NGINX Ingress Config File

When you are using the (nginx) ingress resource in kubernetes, you may want to view the actual configuration it is running, even though you are fairly abstracted from it. It can be very useful for debugging complex issues.

You can run these two lines to get the config file into a local nginx.conf file for inspection when you need to:

POD=$(kubectl get pods -n kube-system | grep ingress | awk '{print $1}')
kubectl exec -it -n kube-system ${POD} cat /etc/nginx/nginx.conf > nginx.conf

Generate a Self-Signed p12 (pfx) certificate File (Automated / Scripted)

Here is a brief script to generate a self-signed p12 (pfx) certificate file with no interactive input.

You can parameterize the three inputs and use them to run this from a CI pipeline/etc as required.

#! /bin/bash

# Set some variables for ease/re-use (can be parameterized).

# Generate cacert.pem and cakey.pem.  The private key is encrypted.
openssl req -newkey rsa:2048 -x509 -keyout ${NAME_PREFIX}-cakey.pem -out ${NAME_PREFIX}-cacert.pem -days 3650 -subj "/C=US/ST=New York/L=New York/CN=${DNS_NAME}" -passout pass:${PASSPHRASE}

# Get a decrypted copy of the private key.
openssl rsa -in ${NAME_PREFIX}-cakey.pem -out ${NAME_PREFIX}-cakey-decrypted.pem -passin pass:${PASSPHRASE}

# Generate the p12 file from the private key and certificate.
openssl pkcs12 -export -out ${NAME_PREFIX}.p12 -inkey ${NAME_PREFIX}-cakey-decrypted.pem -in ${NAME_PREFIX}-cacert.pem -passout pass:${PASSPHRASE}

# Remove the decrypted private key.
rm ${NAME_PREFIX}-cakey-decrypted.pem