Note: The Spotguides feature mentioned in this post is outdated and not available anymore. In case you are interested in a similar feature, contact us for details.

To do that we've chosen this Spring Boot example project.

Note: in order to follow along, you'll need a Pipeline Control Plane running on a cloud provider. Check this post and this post for information on how to launch a control plane in one of the supported providers like AWS, Google and Azure, or BYOC. You'll also need a dedicated s3 bucket to store the application's artifacts (the Spring Boot Application archive).

CI/CD series: CI/CD flow for Zeppelin notebooks CI/CD for Kubernetes, through a Spring Boot example Deploy Node.js applications to Kubernetes

Goals

Setup

The desired Spring Boot deployment looks like this:

Clone (or fork) the GitHub repository

git clone git@github.com:spring-guides/gs-spring-boot.git

Create the Banzai Cloud Pipeline CI/CD flow descriptor

Create the flow descriptor file in the root folder of the freshly checked out project:

Note: the name of the file must be .pipeline.yml

cat << EOF > .pipeline.yml
pipeline:

  create_cluster:
    image: banzaicloud/plugin-pipeline-client:0.3.0
    cluster_name: "[[cluster-name]]"
    cluster_provider: "gcloud"
    google_project: "[[google-project-id]]"
    secrets: [plugin_endpoint, plugin_token]

  remote_checkout:
    image: banzaicloud/plugin-k8s-proxy:latest
    original_image: plugins/git

  remote_build:
    image: banzaicloud/plugin-k8s-proxy:latest
    original_image: maven:3.5-jdk-8
    original_commands:
      - mvn -f complete/pom.xml -DskipTests clean package

  remote_publish_s3:
    image: banzaicloud/plugin-k8s-proxy:latest
    original_image:  plugins/s3
    bucket: [[s3-bucket]]
    source: complete/target/gs-spring-boot-0.1.0.jar
    strip_prefix: complete/target
    region: eu-west-1
    acl: public-read
    secrets: [plugin_access_key, plugin_secret_key]

  delete_app:
    image: banzaicloud/plugin-pipeline-client:0.3.0
    deployment_name: "banzaicloud-stable/springboot"
    deployment_release_name: "springboot"
    deployment_state: "deleted"
    secrets: [plugin_endpoint, plugin_token]

  deploy_app:
    image: banzaicloud/plugin-pipeline-client:0.3.0
    deployment_name: "banzaicloud-stable/springboot"
    deployment_release_name: "springboot"
    deployment_values:
      artifactUrl: "https://s3-eu-west-1.amazonaws.com/[[s3-bucket]]/gs-spring-boot-0.1.0.jar"
#      env:
# Java options
#        - name: JAVA_OPTS
#          value: "-Dserver.port=8080"
# Application arguments
#        - name: ARGS
#          value: ""
    secrets: [plugin_endpoint, plugin_token]
EOF

The .pipeline CI/CD descriptor explained

• create_cluster
  • creates a Kubernetes cluster for the flow (if the cluster with the given name exists, it will be reused). This step may vary according to your chosen cloud provider. Take a look at our example projects, in which we provide templates for every supported cloud provider.
  • this step can be altered to delete an existing cluster by adding the property cluster_state: deleted line to the block
• remote checkout
  • checks the code in a previously created Kubernetes cluster against the persistent volume
• remote_build
  • builds the application, and stores its artifacts on the persistent volume
  • this step (or a separate one) can also be used to run unit tests and, eventually, to generate reports
• remote_publish_s3
  • uploads the built artifact (the Spring Boot application archive) to dedicated s3 storage. The jar will have public-read acls. This is important, since the archive will be downloaded into the Kubernetes cluster when the application is deployed. It can use custom/restricted ACLs as well.
• delete_app
  • this step is necessary because the Kubernetes cluster may be reused, and the Spring Boot application is deployed using Helm charts - with this step we make certain that the application is redeployed.
• deploy_app
  • the application is deployed. Deployments are done using Helm charts, which you can find in our GitHub charts repository.

The progress can be followed on the user interface available on the Control Plane.

Check the application

curl --request GET \
  --url 'http://{{CP-ip}}/pipeline/api/v1/clusters/{{cluster_id}}/endpoints' \
  --header 'Authorization: Bearer {{token}}' \
  --header 'Content-Type: application/x-www-form-urlencoded'

We've created a Postman collection with many useful Pipeline API calls; check those out to find more ways of managing those clusters and deployments managed by the Pipeline instance on the Control Plane

Helm chart for supporting Spring Boot applications

The chart sets up the following components in the Kubernetes cluster:

• the Spring Boot application is started in a Kubernetes Pod
• the embedded tomcat is exposed as a Kubernetes Service
• the service is further exposed through an Ingress resource

Monitoring

• Connect to an exposed JMX port of the JVM (not recommended)
• Java agent version (recommended)

For the agent version, you'll have three configuration options:

• the Jar file location
• the port for the http(s) interface, where the metrics will be available to be scraped, which is already in a Prometheus friendly format
• additional configuration options

An example looks like this:

-javaagent:/opt/jmx-exporter/jmx_prometheus_javaagent-0.3.1-SNAPSHOT.jar=9020:/etc/jmx-exporter/config.yaml

Benefits