A software dependency is an external component required for a project or application to build or operate correctly. It may be a downloadable code library, a Terraform provider plugin, or an upstream service such as RabbitMQ. section 2.6.1 section 11.2.8
Manage dependencies deliberately:
- Declare Node.js libraries in package.json; use package-lock.json to track the installed dependency set, with libraries placed under node_modules. section 2.6.1
- Install project dependencies before running a Node.js service, then use its npm start or development script. section 10.5.1
- Fix dependency versions whenever possible; otherwise, automatic upgrades can change behavior and break infrastructure code unpredictably. section 7.8.3
- Treat service dependencies as operational failures too: a microservice may start before RabbitMQ, lose its connection after a crash, or repeatedly restart while the service is unavailable. section 11.2.8
Pinning a Terraform provider
A Terraform project can require the Azure provider from hashicorp/azurerm at version ~> 3.71.0 while requiring Terraform >= 1.5.6. Removing the provider constraint allows Terraform to download the latest release; recording that release afterward restores a fixed dependency version. section 7.8.3
Starting a service with dependencies
From the metadata service directory, run npm install and then npm run start:dev. Configure PORT, DBHOST, DBNAME, and RABBIT before startup so the service can reach its database and RabbitMQ dependencies. section 10.5.1
Listing 11.1 Adding Kubernetes probes for the gateway microservice
apiVersion: apps/v1
kind: Deployment
metadata:
name: gateway
spec:
replicas: 1
selector:
matchLabels:
app: gateway
template:
metadata:
labels:
app: gateway
spec:
containers:
- name: gateway
image: $CONTAINER_REGISTRY/gateway:$VERSION
imagePullPolicy: IfNotPresent
readinessProbe: #1
httpGet:
path: /ready #2
port: {{PORT}}
initialDelaySeconds: 5 #1
livenessProbe: #3
httpGet:
path: /alive #4
port: {{PORT}} #3
env:
- name: PORT
value: "4000"
- name: RABBIT
value: amqp://test:test@rabbit:5672
A Kubernetes Deployment can use readiness and liveness probes to represent service availability and support recovery when an upstream dependency is unavailable. section 11.2.8
