node-vault-client/docker-compose.yml at master · namecheap/node-vault-client · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
# Vault version is overridable so CI can run the e2e suites against more than one
# server line, and so you can reproduce a CI failure locally:
#
#   docker compose up -d --wait                                 # default, latest 1.x
#   VAULT_IMAGE=hashicorp/vault:2.0 docker compose up -d --wait  # 2.0.x
#   VAULT_IMAGE=hashicorp/vault:2.1 docker compose up -d --wait  # latest 2.x
#
# The tag is the minor line (`1.21`), not a patch (`1.21.4`), on purpose: the
# minor tag follows the newest patch in that line, so security and bug-fix
# releases are picked up with no change here. That is what stops this pin
# rotting the way the previous `vault:1.13.3` one did. Only a new *minor* line
# (1.22, 2.2) needs a human, and it needs one in two places -- this default and
# the matrix in .github/workflows/pipeline.yaml.
#
# Note the image also moved from the deprecated Docker Hub `vault` repository,
# which stopped receiving updates after 1.13.x, to `hashicorp/vault`.

services:
  # Both services are ephemeral dev-mode servers for the e2e suites.
  #
  # VAULT_DEV_ROOT_TOKEN_ID is a throwaway dev-mode credential: it only ever
  # unlocks an in-memory, localhost-bound test instance and is committed on
  # purpose so the tests can authenticate. Never reuse these values (or this
  # pattern) for a real Vault deployment.

  # KV v1 server, used by test/e2e/e2e.test.mjs (npm run test:e2e).
  # Note: -dev-kv-v1 implicitly enables dev mode.
  vault-server:
    image: ${VAULT_IMAGE:-hashicorp/vault:1.21}
    environment:
      VAULT_DEV_ROOT_TOKEN_ID: 8274d2a1-c80c-ff56-c6ed-1b99f7bcea78
      # for the `vault status` health check below, not the server itself
      VAULT_ADDR: http://127.0.0.1:8200
    command: [ "server", "-dev-kv-v1" ]
    cap_add:
      - IPC_LOCK
    ports:
      - 127.0.0.1:8200:8200
    # `docker compose up -d --wait` only waits for "running" unless a health
    # check exists, and neither this compose file nor the image defined one, so
    # the e2e jobs raced the server's startup. It was masked in CI because
    # `npm ci` runs afterwards and takes long enough for Vault to come up;
    # locally, tests started immediately and failed with "SocketError: other
    # side closed". `vault status` exits 0 only once the server answers and is
    # unsealed, which is exactly the readiness this suite needs.
    healthcheck:
      test: ["CMD", "vault", "status"]
      interval: 2s
      timeout: 3s
      retries: 20
      start_period: 2s

  # KV v2 server (dev mode mounts secret/ as KV v2 by default), used by
  # test/e2e/e2e.kv2.test.mjs (npm run test:e2e:kv2).
  vault-server-kv2:
    image: ${VAULT_IMAGE:-hashicorp/vault:1.21}
    environment:
      VAULT_DEV_ROOT_TOKEN_ID: 34c9c953-4ff5-368a-ac5c-a1e1a8e13a52
      VAULT_ADDR: http://127.0.0.1:8200
    command: [ "server", "-dev" ]
    cap_add:
      - IPC_LOCK
    ports:
      - 127.0.0.1:8202:8200
    # `docker compose up -d --wait` only waits for "running" unless a health
    # check exists, and neither this compose file nor the image defined one, so
    # the e2e jobs raced the server's startup. It was masked in CI because
    # `npm ci` runs afterwards and takes long enough for Vault to come up;
    # locally, tests started immediately and failed with "SocketError: other
    # side closed". `vault status` exits 0 only once the server answers and is
    # unsealed, which is exactly the readiness this suite needs.
    healthcheck:
      test: ["CMD", "vault", "status"]
      interval: 2s
      timeout: 3s
      retries: 20
      start_period: 2s