A service with a database

Tower → Create → SpringBootApplication

Merge the PR Tower opens, then check the XR:

$ kubectl get springbootapplication flight-api -n app-flight-api-cicd
NAME         SYNCED   READY   COMPOSITION                              AGE
flight-api   True     True    springbootapplications.catalog.idp.io    3m

The source repo starts with a hello-world Application.java, a pom.xml (web and actuator only), an application.properties and a Containerfile. If a previous flight-api was decommissioned, finish decommissioning first (including its Infisical projects).

Declare the environment

envName: dev
rollout: null            # explicit; the deploy stage fills in the image later

components:
  - type: postgresql
    name: flight-db      # the Secret this creates is named flight-db-app
    spec: { size: small, instances: 1, storageSize: 1Gi }

env:
  # Read straight from the Secret the database component creates - no copying into Infisical.
  - { name: DB_HOST,     valueFrom: { secretKeyRef: { name: flight-db-app, key: host } } }
  - { name: DB_PORT,     valueFrom: { secretKeyRef: { name: flight-db-app, key: port } } }
  - { name: DB_NAME,     valueFrom: { secretKeyRef: { name: flight-db-app, key: dbname } } }
  - { name: DB_USER,     valueFrom: { secretKeyRef: { name: flight-db-app, key: username } } }
  - { name: DB_PASSWORD, valueFrom: { secretKeyRef: { name: flight-db-app, key: password } } }
  - { name: SIMULATOR_INTERVAL_MS, value: "30000" }

networkPolicy:
  allowIngressFrom:      # let boarding-api's namespace reach us (section 06)
    - { namespace: app-boarding-api-dev, ports: [8080] }

The database is created before the app runs. With rollout: null there is no workload yet, so the first thing this file produces is the PostgreSQL XR and its cluster, within about a minute:

kubectl get postgresql -n app-flight-api-dev              # READY True
kubectl get cluster.postgresql.cnpg.io -n app-flight-api-dev

Let the pipeline deploy to it

apiVersion: platform/v1
kind: PipelineConfig

build:
  agent: openjdk-21
  script: ./build.sh            # compiles natively in the Java agent (section 04)
  containerfile: ./Containerfile  # thin: just copies the jar in
  unitTest:
    enabled: true         # runs ./test.sh

deploy:
  lowerEnvironments: [dev]

pipelines:
  ci:
    trigger: { source: git, event: push, branch: main }
    steps:
      - stage: build
      - stage: test
        env: dev
      - stage: deploy
        env: dev

Commit both, merge the .tekton PR, push

As in part 1 the deploy stage commits the image straight into platform/envs/dev.yaml on main, so git pull before your next push. The first start is slower than a NodeJS app: the JVM starts, then Flyway waits for the database if it isn't up yet (it retries for about two and a half minutes) and runs the two migrations.

Add health probes

Once the deploy stage has written the image, add probes to the same file. (Adding them earlier would make rollout non-null with no image.)

rollout:
  image: { … }          # keep what the deploy stage wrote
  resources:
    requests: { cpu: 500m, memory: 512Mi }   # a JVM starts CPU-bound
    limits: { memory: 1Gi }                  # memory only: no CPU limit
  readinessProbe:
    httpGet: { path: /actuator/health/readiness, port: 8080 }
    initialDelaySeconds: 30
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 6
  livenessProbe:
    httpGet: { path: /actuator/health/liveness, port: 8080 }   # NOT /readiness
    initialDelaySeconds: 60
    periodSeconds: 20
    timeoutSeconds: 5
    failureThreshold: 6

Readiness is what makes the pod wait for the database: it isn't sent traffic until Postgres answers.

See it

kubectl port-forward -n app-flight-api-dev svc/flight-api 8081:8080
curl -s localhost:8081/api/flights/AC123
curl -s localhost:8081/api/flights/AC123/events

The simulator writes an event about every 30 seconds; watch events grow. And because the component labels everything it creates, one selector finds the app, its database, its Secret and its volume together:

kubectl get all,pvc,secret,networkpolicy -n app-flight-api-dev -l hangar.io/app=flight-api

Copy the updated gate board over part 1's

cd boarding-api
cp /tmp/airframe/examples/skyport/boarding-api/{app.js,index.js,reservations.js} .
cp /tmp/airframe/examples/skyport/boarding-api/public/index.html public/
cp /tmp/airframe/examples/skyport/boarding-api/test/app.test.js test/
npm test                                     # 11 passing

Then add one line to its platform/envs/dev.yaml, commit and push:

env:
  - { name: REDIS_URL, value: "redis://cache-master:6379" }
  - { name: FLIGHT_API_URL, value: "http://flight-api.app-flight-api-dev.svc.cluster.local:8080" }

With FLIGHT_API_URL unset the app falls back to its built-in stand-in, so it still runs anywhere. Set, it never invents an answer: an unknown flight is a 404, and flight-api being down is a 502 that is not cached.

Look up AC123

The source row now says flight-api (Postgres) and there is a status row (ON_TIME, or DELAYED (+15 min) once the simulator has touched it). The first lookup takes tens of milliseconds because it really hit a database; the second is a cache hit.

Now see the problem Phase 2 fixes

curl -s -X PUT -H 'Content-Type: application/json' -d '{"gate":"B2"}' localhost:8081/api/flights/AC123/gate

Look up AC123 on the gate board again: it still shows the old gate, from the cache, and is right only after the three-minute TTL. Waiting for a TTL is the wrong way to keep a gate board accurate. The fix is for flight-api to publish flight.gate-changed and for boarding-api to evict the entry, which is Phase 2 of Skyport. The flight_events table is already there for it.

Declare it and create the environment

Add upperEnvironments: [{ name: staging, cluster: prod }], governance.allowedCommitSigners and a release stage to cicd.yaml (as in part 1), merge the .tekton/ PR, then Tower → Create → ApplicationEnvironment named flight-api-prod-staging. The environment starts as rollout: null, so the database is created first, in app-flight-api-staging.

Configure it in a pull request

rollout:
  replicas: 2
  ports: [{ name: http, containerPort: 8080 }]
  resources:
    requests: { cpu: 500m, memory: 512Mi }
    limits: { memory: 1Gi }
  readinessProbe:
    httpGet: { path: /actuator/health/readiness, port: 8080 }
    initialDelaySeconds: 30
    timeoutSeconds: 5
    failureThreshold: 6
  livenessProbe:
    httpGet: { path: /actuator/health/liveness, port: 8080 }   # NOT /readiness
    initialDelaySeconds: 60
    timeoutSeconds: 5
    failureThreshold: 6

components:
  - type: postgresql
    name: flight-db
    spec: { size: small, instances: 2, storageSize: 5Gi }    # a primary and a replica

env:
  - { name: DB_HOST,     valueFrom: { secretKeyRef: { name: flight-db-app, key: host } } }
  - { name: DB_PORT,     valueFrom: { secretKeyRef: { name: flight-db-app, key: port } } }
  - { name: DB_NAME,     valueFrom: { secretKeyRef: { name: flight-db-app, key: dbname } } }
  - { name: DB_USER,     valueFrom: { secretKeyRef: { name: flight-db-app, key: username } } }
  - { name: DB_PASSWORD, valueFrom: { secretKeyRef: { name: flight-db-app, key: password } } }
  - { name: SIMULATOR_INTERVAL_MS, value: "60000" }

networkPolicy:
  allowIngressFrom:
    - { namespace: app-boarding-api-staging, ports: [8080] }

instances: 2 gives a real failover pair; on a small single-node cluster 1 is fine. The image is not set here: the release pipeline sets it.

Release, then point boarding-api at it

Release as a signed merge, as in part 1. In boarding-api's staging values, set FLIGHT_API_URL to http://flight-api.app-flight-api-staging.svc.cluster.local:8080. Deleting this environment deletes its database and both volumes.