Introduction

This project aims to :

Host the Helm index repository of our Spring Boot examples and their released chart.tgz files,
Propose best practices to design charts and resolve problems such as: How to deal with RBAC.

Repository

This repository uses GitHub Pages to publish the Helm charts index at this address: http://snowdrop.github.io/helm. To use it locally, you need to execute:

$ helm repo add snowdrop https://snowdrop.github.io/helm

And confirm that the snowdrop repository is listed:

$ helm repo list
NAME           	URL                               
snowdrop	    https://snowdrop.github.io/helm

List of charts available

Chart Name	Description	Source
spring-boot-example-app	Chart to be used to create a Spring Boot application	repository/spring-boot-example-app
spring-boot-example-rest-http	Chart to deploy the Snowdrop Spring Boot REST HTTP example	https://github.com/snowdrop/rest-http-example
spring-boot-example-cache	Chart to deploy the Snowdrop Spring Boot Cache example	https://github.com/snowdrop/cache-example
spring-boot-example-crud	Chart to deploy the Snowdrop Spring Boot CRUD example	https://github.com/snowdrop/crud-example
spring-boot-example-configmap	Chart to deploy the Snowdrop Spring Boot ConfigMap example	https://github.com/snowdrop/configmap-example
spring-boot-example-health-check	Chart to deploy the Snowdrop Spring Boot Health Check example	https://github.com/snowdrop/health-check-example
spring-boot-example-circuit-breaker	Chart to deploy the Snowdrop Spring Boot Circuit Breaker example	https://github.com/snowdrop/circuit-breaker-example
spring-boot-example-messaging-queue	Chart to deploy the Snowdrop Spring Boot Messaging Queues example	https://github.com/snowdrop/messaging-work-queue-example

Usage

Requirements:

Connected/logged to a Kubernetes/OpenShift cluster
Have installed the Helm command line

spring-boot-example-app

This chart deploys and exposes a Spring Boot application on Kubernetes or OpenShift.

For Kubernetes: To use it on Kubernetes, the image of the Spring Boot application needs to be published on an images registry where you have access and be logged. In this example, we'll use the image quay.io/user/my-app:latest. To install it, you need to execute the following command:

$ helm install my-spring-boot-app snowdrop/spring-boot-example-app --set name=app --set docker.image=quay.io/user/my-app:latest --set ingress.host=<your kubernetes domain>

note: if you want to expose your application on Kubernetes, you need to provide the ingress.host property.

For OpenShift, to install it, you need to execute the following command:

$ helm install my-spring-boot-app snowdrop/spring-boot-example-app --set name=app --set s2i.source.repo=http://github.com/org/repo --set s2i.source.ref=main --set route.expose=true

When you install the chart on OpenShift, a pod is created to build the Spring Boot application using as source the GIT repository cloned and the maven tool. The jar file generated will be copied to an image and pushed to a registry.

note: Properties like the S2i base image are defined in the default values.yaml file. You can override these values using the --set option.

You can watch the progression of the build and deployment using a watch command:

$ watch oc get pods
app-1-build     0/1     Completed   0          7m30s
app-1-deploy    0/1     Completed   0          5m27s
app-1-j5jk5     1/1     Running     0          5m25s

note: OpenShift may take a bit to download the images before triggering the S2i build.

The pod with name app-1-build is automatically triggered by S2i to build the Spring Boot application. After the build is finished, the pod app-1-deploy will create the image that then will be used by the pod app-1-j5jk5 to deploy the application.

As soon as status of the pods app-1-build and app-1-deploy are completed and that the status of the app-1-j5jk5 is running, we can now execute the following command get the route of the Service to access it:

$ oc get routes
NAME            HOST/PORT                                       PATH   SERVICES        PORT   TERMINATION   WILDCARD
app             app-xxxx.containers.appdomain.cloud             /      app             8080                 None

Finally, our application will be available at app-xxxx.containers.appdomain.cloud.

Using `spring-boot-example-app` as dependency in custom charts

Let's see how to create a custom chart that deploys one or more Spring Boot applications at once by using the chart spring-boot-example-app as dependency.

Our custom chart will deploy two Spring Boot applications at once. To start with, we will first deploy one Spring Boot application and then we'll see how to deploy the second Spring Boot application.

You first need to generate a chart directory using the following command:

$ mkdir my-custom-chart
$ cd my-custom-chart

Now, let's create the Chart.yaml file under the my-custom-chart/ folder with your Chart information:

apiVersion: v2
name: my-custom-chart
version: 0.0.1
description: A chart that deploys multiple Spring Boot applications

And let's also create an empty file with name values.yaml under the my-custom-chart/ folder:

$ touch values.yaml

At this point, your chart directory my-custom-chart should have the following structure:

my-custom-chart
│   Chart.yaml
│   values.yaml

Now, we're going to deploy the first Spring Boot application by adding the spring-boot-example-app chart as dependency. We need to append the dependencies section within the my-custom-chart/Chart.yaml file:

apiVersion: v2
name: my-custom-chart
version: 0.0.1
description: A chart that deploys multiple Spring Boot applications
# Chart dependencies:
dependencies:
  - alias: firstApp
    name: spring-boot-example-app
    version: 0.0.4
    repository: http://snowdrop.github.io/helm

When done, execute this command to download the dependency:

$ helm dependency update

After doing this, helm will download the spring-boot-example-app chart from the repository http://snowdrop.github.io/helm and will copy the Chart tallball spring-boot-example-app-0.0.3.tgz at my-custom-chart/charts/.

As the build is taking place on the cluster using OpenShift - see usage section, then we have to configure the s2i fields defined within the my-custom-chart/values.yaml file:

firstApp: # match with the alias name
  name: my-first-app
  version: 0.0.1
  route:
    expose: true
  s2i:
    source:
      repo: http://github.com/org/repo
      ref: main

If you are using Kubernetes, then you would need to build and publish the docker image and next configure the docker.image field within the my-custom-chart/values.yaml:

firstApp: # match with the alias name
  name: my-first-app
  version: 0.0.1
  ingress:
    host: <your cluster domain>
  docker:
    image: quay.io/user/my-app:latest

Let's install our custom chart by executing the following command:

$ helm install my-custom-chart .

Helm will deploy the Spring Boot application and expose the application.

Now, we're going to update our custom chart to deploy the second Spring Boot application. For doing this, we need to declare another dependency within the my-custom-chart/Chart.yaml file:

apiVersion: v2
name: my-custom-chart
version: 0.0.1
description: A chart that deploys multiple Spring Boot applications
# Chart dependencies:
dependencies:
  - alias: firstApp
    name: spring-boot-example-app
    version: 0.0.3
    repository: http://snowdrop.github.io/helm
  - alias: secondApp
    name: spring-boot-example-app
    version: 0.0.3
    repository: http://snowdrop.github.io/helm

And, again, we need to edit the my-custom-chart/values.yaml file and provide the correct configuration for the second application. For example, for OpenShift this file would look like as:

firstApp:
  name: my-first-app
  version: 0.0.1
  route:
    expose: true
  s2i:
    source:
      repo: http://github.com/org/repo
      ref: main
secondApp:
  name: my-second-app
  version: 0.0.1
  route:
    expose: true
  s2i:
    source:
      repo: http://github.com/org/another-repo
      ref: main

Let's update our custom chart to deploy both Spring Boot applications by executing the following command:

$ helm upgrade my-custom-chart .

After the deployment is finished, we will see two Spring Boot applications up and running.

spring-boot-example-rest-http

This chart deploys the example from the repository. This example shows how to map business operations to a remote procedure call endpoint over HTTP using a REST framework. This corresponds to Level 0 in the Richardson Maturity Model. Creating an HTTP endpoint using REST and its underlying principles to define your API lets you quickly prototype and design the API flexibly.

Using Ingress Host:

helm install rest-http snowdrop/spring-boot-example-rest-http --set app.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install rest-http snowdrop/spring-boot-example-rest-http --set app.route.expose=true

spring-boot-example-cache

This chart deploys the example from the repository. This example demonstrates how to use a cache to increase the response time of applications.

Using Ingress Host:

helm install cache snowdrop/spring-boot-example-cache --set greeting-service.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install cache snowdrop/spring-boot-example-cache --set greeting-service.route.expose=true

spring-boot-example-crud

This chart deploys the example from the repository. This example expands on the REST API Level 0 application to provide a basic example of performing create, read, update and delete (CRUD) operations on a PostgreSQL database using a simple HTTP API. CRUD operations are the four basic functions of persistent storage, widely used when developing an HTTP API dealing with a database.

Using Ingress Host:

helm install crud snowdrop/spring-boot-example-crud --set app.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install crud snowdrop/spring-boot-example-crud --set app.route.expose=true

spring-boot-example-configmap

This chart deploys the example from the repository. This example uses a ConfigMap to externalize configuration.

Using Ingress Host:

helm install configmap snowdrop/spring-boot-example-configmap --set app.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install configmap snowdrop/spring-boot-example-configmap --set app.route.expose=true

spring-boot-example-health-check

This chart deploys the example from the repository. This example demonstrates the health check pattern through the use of probing. Probing is used to report the liveness and readiness of an application.

Using Ingress Host:

helm install health-check snowdrop/spring-boot-example-health-check --set app.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install health-check snowdrop/spring-boot-example-health-check --set app.route.expose=true

spring-boot-example-circuit-breaker

This chart deploys the example from the repository. This example demonstrates a generic pattern for reporting the failure of a service and then limiting access to the failed service until it becomes available to handle requests. This helps prevent cascading failure in other services that depend on the failed services for functionality.

Using Ingress Host:

Build and push a new image in your container registry:

CONTAINER_REGISTRY=<your container registry: for example "quay.io/user">
## Name service:
NAME_IMAGE=circuit-breaker-name:latest
docker build ./name-service -t $NAME_IMAGE
docker tag $NAME_IMAGE $CONTAINER_REGISTRY/$NAME_IMAGE
docker push $CONTAINER_REGISTRY/$NAME_IMAGE

## Greeting service:
GREETING_IMAGE=circuit-breaker-greeting:latest
docker build ./greeting-service -t $GREETING_IMAGE
docker tag $GREETING_IMAGE $CONTAINER_REGISTRY/$GREETING_IMAGE
docker push $CONTAINER_REGISTRY/$GREETING_IMAGE

note: Make sure both images circuit-breaker-name:latest and circuit-breaker-greeting:latest are public

helm install circuit-breaker snowdrop/spring-boot-example-circuit-breaker --set name-service.docker.image=$CONTAINER_REGISTRY/$NAME_IMAGE --set greeting-service.docker.image=$CONTAINER_REGISTRY/$GREETING_IMAGE --set name-service.ingress.host=<your cluster domain> --set greeting-service.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install circuit-breaker snowdrop/spring-boot-example-circuit-breaker --set name-service.route.expose=true --set name-service.s2i.source.repo=https://github.com/snowdrop/circuit-breaker-example --set name-service.s2i.source.ref=<branch-to-use> --set greeting-service.route.expose=true --set greeting-service.s2i.source.repo=https://github.com/snowdrop/circuit-breaker-example --set greeting-service.s2i.source.ref=<branch-to-use>

note: Replace <branch-to-use> with one branch from https://github.com/snowdrop/circuit-breaker-example/branches/all.

spring-boot-example-messaging-queue

This chart deploys the example from the repository. This example demonstrates how to dispatch tasks to a scalable set of worker processes using a message queue. It uses the AMQP 1.0 message protocol to send and receive messages.

Using Ingress Host:

Build and push a new image in your container registry:

CONTAINER_REGISTRY=<your container registry: for example "quay.io/user">
## Worker service:
WORKER_IMAGE=messaging-worker:latest
docker build ./worker -t $CUTE_NAME_IMAGE
docker tag $WORKER_IMAGE $CONTAINER_REGISTRY/$WORKER_IMAGE
docker push $CONTAINER_REGISTRY/$WORKER_IMAGE

## Frontend service:
FRONTEND_IMAGE=messaging-frontend:latest
docker build ./frontend -t $FRONTEND_IMAGE
docker tag $FRONTEND_IMAGE $CONTAINER_REGISTRY/$FRONTEND_IMAGE
docker push $CONTAINER_REGISTRY/$FRONTEND_IMAGE

note: Make sure both images messaging-worker:latest and messaging-frontend:latest are public

helm install messaging snowdrop/spring-boot-example-messaging-queue --set worker.docker.image=$CONTAINER_REGISTRY/$CUTE_NAME_IMAGE --set worker.ingress.host=<your cluster domain> --set frontend.docker.image=$CONTAINER_REGISTRY/$GREETING_IMAGE --set frontend.ingress.host=<your cluster domain>

Using Routes (only on OpenShift):

helm install messaging snowdrop/spring-boot-example-messaging-queue --set frontend.route.expose=true --set frontend.s2i.source.repo=https://github.com/snowdrop/messaging-work-queue-example --set frontend.s2i.source.ref=<branch-to-use> --set worker.route.expose=true --set worker.s2i.source.repo=https://github.com/snowdrop/messaging-work-queue-example --set worker.s2i.source.ref=<branch-to-use>

note: Replace <branch-to-use> with one branch from https://github.com/snowdrop/messaging-work-queue-example/branches/all.

Development/Release a new Chart

To add a new chart to the repository, follow these steps:

Add the new chart folder under repository/<new chart name>
Update the Makefile file to add the new repository name in the CHARTS array
Run make release from the root repository folder

Release a new version of Spring Boot examples

Run make release-examples branch=<SPRING BOOT EXAMPLE BRANCH> chartVersion=<NEW CHART VERSION> from the root repository folder. Example: make release-examples branch=sb-2.5.x chartVersion=2.5.8

Testing

Expose the repository locally using Docker and ChartMuseum (utility to serve Helm repositories locally):

$ docker run --rm -u 0 -it -d -p 8080:8080 -e DEBUG=1 -e STORAGE=local -e STORAGE_LOCAL_ROOTDIR=/charts -v $(pwd)/charts:/charts chartmuseum/chartmuseum:latest

The helm repository should be now available at http://localhost:8080.

Add the local repository using helm repo add local http://localhost:8080. Verify that the local chart is in the local repository helm search repo local.
Finally, update the rest-http/Chart.yaml file to register the dependency:

apiVersion: v2
name: rest-http
description: A Helm chart for Kubernetes
# Chart dependencies:
dependencies:
  - name: spring-boot-example-app
    version: 0.0.1
    repository: http://localhost:8080 # Helm local repository

Now, use the chart as stated in the usage section.

Templates

RBAC

To generate the files using the template command

$ helm template rbac ./rbac --dry-run --output-dir ./generated

Name		Name	Last commit message	Last commit date
Latest commit History 19 Commits
.idea		.idea
charts		charts
rbac		rbac
repository/spring-boot-example-app		repository/spring-boot-example-app
.gitignore		.gitignore
.nojekyll		.nojekyll
Makefile		Makefile
README.md		README.md
index.yaml		index.yaml
robots.txt		robots.txt

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

Table of Contents

Introduction

Repository

List of charts available

Usage

spring-boot-example-app

Using `spring-boot-example-app` as dependency in custom charts

spring-boot-example-rest-http

spring-boot-example-cache

spring-boot-example-crud

spring-boot-example-configmap

spring-boot-example-health-check

spring-boot-example-circuit-breaker

spring-boot-example-messaging-queue

Development/Release a new Chart

Release a new version of Spring Boot examples

Testing

Templates

RBAC

About

Releases

Packages

Contributors 2

Languages

snowdrop/helm

Folders and files

Latest commit

History

Repository files navigation

Table of Contents

Introduction

Repository

List of charts available

Usage

spring-boot-example-app

Using spring-boot-example-app as dependency in custom charts

spring-boot-example-rest-http

spring-boot-example-cache

spring-boot-example-crud

spring-boot-example-configmap

spring-boot-example-health-check

spring-boot-example-circuit-breaker

spring-boot-example-messaging-queue

Development/Release a new Chart

Release a new version of Spring Boot examples

Testing

Templates

RBAC

About

Resources

Stars

Watchers

Forks

Releases

Packages 0

Contributors 2

Languages

Using `spring-boot-example-app` as dependency in custom charts

Packages