This chart is intended for simple Java microservices.
We will take small PRs and small features to this chart but more complicated needs should be handled in your own chart.
NOTE: /health/readiness and /health/liveness exposed by spring boot 2.3.0 actuator are used for readiness and liveness checks.
This chart adds below templates from chart-library based on the chosen configuration:
- Deployment
- Keyvault Secrets
- Horizontal Pod Auto Scaler
- Ingress
- Pod Disruption Budget
- Service
- Deployment Tests
applicationPort: 8080
environment:
REFORM_TEAM: cnp
REFORM_SERVICE_NAME: rhubarb-backend
REFORM_ENVIRONMENT: preview
ROOT_APPENDER: CNP
CONFIG_TEMPLATE: "{{ .Release.Name }}-config"
configmap:
VAR_A: VALUE_A
VAR_B: VALUE_B
secrets:
ENVIRONMENT_VAR:
secretRef: some-secret-reference
key: connectionString
ENVIRONMENT_VAR_OTHER:
secretRef: some-secret-reference-other
key: connectionStringOther
disabled: true #ENVIRONMENT_VAR_OTHER will not be set to environment
keyVaults:
"cmc":
secrets:
- smoke-test-citizen-username
- smoke-test-user-password
"s2s":
secrets:
- microservicekey-cmcLegalFrontend
applicationInsightsInstrumentKey: "some-key"
If you wish to use pod identity for accessing the key vaults instead of a service principal you need to set a flag aadIdentityName: <identity-name>
e.g.
aadIdentityName: cmc
keyVaults:
"cmc":
usePodIdentity: true
secrets:
- smoke-test-citizen-username
- smoke-test-user-password
Startup probes are defined in the library template and should be configured for slow starting applications. The default values below (defined in the chart) should be sufficient for most applications but can be overriden as required.
startupPath: '/health/liveness'
startupDelay: 5
startupTimeout: 3
startupPeriod: 10
startupFailureThreshold: 3
To configure startup probes for a slow starting application:
- Set the value of
(startupFailureThreshold x startupPeriodSeconds)
to cover the longest startup time required by the application - If
livenessDelay
is currently configured, set the value to0
The below example will allow the application 360 seconds to complete startup.
java:
livenessDelay: 0
startupPeriod: 120
startupFailureThreshold: 3
Also see example pull request.
To adjust the number of pods in a deployment depending on CPU utilization AKS supports horizontal pod autoscaling. To enable horizontal pod autoscaling you can set the autoscaling section.
autoscaling: # Default is true
enabled: true
maxReplicas: 5 # Optional setting, will use the value of replicas + 2 if not set
minReplicas: 2 # Optional setting, will use the value of replicas if not set
targetCPUUtilizationPercentage: 80 # Default is 80% target CPU utilization
If you need to use a Postgresql database for testing then you can enable it by setting the following flag in your application config with:
java:
environment:
DB_HOST: "{{ .Release.Name }}-postgresql"
DB_USER_NAME: "{{ .Values.postgresql.auth.username}}"
DB_PASSWORD: "{{ .Values.postgresql.auth.password}}"
postgresql:
#Whether to deploy the Postgres Chart or not
enabled: true
From version 2.15.0 of this chart you can configure your functional and smoke tests to run just after deployment or at scheduled times as cron jobs.
java:
testsConfig:
keyVaults:
cmc:
excludeEnvironmentSuffix: false
secretRef: "kvcreds"
secrets:
smoke-test-citizen-username: SMOKE_TEST_CITIZEN_USER
smoke-test-user-password: SMOKE_TEST_CITIZEN_PASS
environment:
TEST_URL: http://plum-recipe-backend-java
SLACK_CHANNEL: "platops-build-notices"
SLACK_NOTIFY_SUCCESS: "true"
CLUSTER_NAME: "aat-01-aks"
smoketests:
image: hmctspublic.azurecr.io/spring-boot/template-test
enabled: true
environment:
TEST_URL: http://plum-recipe-backend-java-overridden
functionaltests:
image: hmctspublic.azurecr.io/spring-boot/template-test
enabled: true
smoketestscron:
image: hmctspublic.azurecr.io/spring-boot/template-test
enabled: true
environment:
TEST_URL: http://plum-recipe-backend-java-overridden2
functionaltestscron:
image: hmctspublic.azurecr.io/spring-boot/template-test
enabled: true
environment:
TEST_URL: http://plum-recipe-backend-java-overridden2
SOME_ENV: some-val
Default configuration (e.g. default image and ingress host) is setup for preview. This is suitable for local development and testing.
- Ensure you have logged in with
az cli
and are usingpreview
subscription (useaz account show
to display the current one). - For local development see the
Makefile
for available targets. - To execute an end-to-end build, deploy and test run
make
. - to clean up deployed releases, charts, test pods and local charts, run
make clean
helm test
will deploy a busybox container alongside the release which performs a simple HTTP request against the service health endpoint. If it doesn't return HTTP 200
the test will fail. NOTE: it does NOT run with --cleanup
so the test pod will be available for inspection.
Builds are run against the 'nonprod' AKS cluster.
A build is triggered when pull requests are created. This build will run helm lint
, deploy the chart using ci-values.yaml
and run helm test
.
Triggered when the repository is tagged (e.g. when a release is created). Also performs linting and testing, and will publish the chart to ACR on success.
We use semantic versioning via GitHub releases to handle new releases of this application chart, this is done via automation called Release Drafter. When you merge a PR to master, a new draft release will be created. More information is available about the release process and how to create draft releases for testing purposes in more depth