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-passwordStartup 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: 3To 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
livenessDelayis currently configured, set the value to0
The below example will allow the application 360 seconds to complete startup.
java:
livenessDelay: 0
startupPeriod: 120
startupFailureThreshold: 3Also 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 utilizationIf 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: trueFrom 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-valDefault 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 cliand are usingpreviewsubscription (useaz account showto display the current one). - For local development see the
Makefilefor 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