docker-compose.yml

services:
  boulder:
    # The `letsencrypt/boulder-tools:latest` tag is automatically built in local
    # dev environments. In CI a specific BOULDER_TOOLS_TAG is passed, and it is
    # pulled with `docker compose pull`.
    image: &boulder_tools_image letsencrypt/boulder-tools:${BOULDER_TOOLS_TAG:-latest}
    build:
      context: test/boulder-tools/
      # Should match one of the GO_CI_VERSIONS in test/boulder-tools/tag_and_upload.sh.
      args:
        GO_VERSION: 1.27.3
    environment:
      # To solve HTTP-01 and TLS-ALPN-01 challenges, change the IP in FAKE_DNS
      # to the IP address where your ACME client's solver is listening. This is
      # pointing at the boulder service's "public" IP, where challtestsrv is.
      FAKE_DNS: 64.112.117.122
      BOULDER_CONFIG_DIR: test/config
      USE_VITESS: false
      GOCACHE: /boulder/.gocache/go-build
    volumes:
      - .:/boulder:cached
      - ./.gocache:/root/.cache/go-build:cached
      - ./test/certs/.softhsm-tokens/:/var/lib/softhsm/tokens/:cached
      - pkimetal-socket:/var/run/pkimetal
    networks:
      bouldernet:
        ipv4_address: 10.77.77.77
      publicnet:
        ipv4_address: 64.112.117.122
      publicnet2:
        ipv4_address: 64.112.117.134
    # Use consul as a backup to Docker's embedded DNS server. If there's a name
    # Docker's DNS server doesn't know about, it will forward the query to this
    # IP (running consul).
    # (https://docs.docker.com/config/containers/container-networking/#dns-services).
    # This is used to look up service names via A records (like ra.service.consul) that
    # are configured via the ServerAddress field of cmd.GRPCClientConfig.
    # TODO: Remove this when ServerAddress is deprecated in favor of SRV records
    # and DNSAuthority.
    dns: 10.77.77.10
    extra_hosts:
      # Allow the boulder container to be reached as "ca.example.org", so we
      # can put that name inside our integration test certs (e.g. as a crl
      # url) and have it look like a publicly-accessible name.
      # TODO(#8215): Move s3-test-srv to a separate service.
      - "ca.example.org:64.112.117.122"
      # Allow the boulder container to be reached as "integration.trust", for
      # similar reasons, but intended for use as a SAN rather than a CRLDP.
      # TODO(#8215): Move observer's probe target to a separate service.
      - "integration.trust:64.112.117.122"
    ports:
      - 4001:4001 # ACMEv2
      - 4003:4003 # SFE
    depends_on:
      bmariadb:
        condition: service_started
      bproxysql:
        condition: service_started
      bvitess:
        condition: service_healthy
      bredis_1:
        condition: service_started
      bredis_2:
        condition: service_started
      bconsul:
        condition: service_started
      bjaeger:
        condition: service_started
      bpkimetal:
        condition: service_started
      bseaweedfs-configure:
        condition: service_completed_successfully
      bsunlight:
        condition: service_started
    entrypoint: test/entrypoint.sh
    working_dir: &boulder_working_dir /boulder

  bsetup:
    image: *boulder_tools_image
    volumes:
      - .:/boulder:cached
      - ./.gocache:/root/.cache/go-build:cached
      - ./test/certs/.softhsm-tokens/:/var/lib/softhsm/tokens/:cached
    entrypoint: test/certs/generate.sh
    working_dir: *boulder_working_dir
    profiles:
      # Adding a profile to this container means that it won't be started by a
      # normal "docker compose up/run boulder", only when specifically invoked
      # with a "docker compose up bsetup".
      - setup

  bmariadb:
    image: mariadb:10.11.13
    volumes:
      - ./sa/db:/docker-entrypoint-initdb.d
    networks:
      bouldernet:
        aliases:
          - boulder-mariadb
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "yes"

  bproxysql:
    image: proxysql/proxysql:2.7.2
    # The --initial flag force resets the ProxySQL database on startup. By
    # default, ProxySQL ignores new configuration if the database already
    # exists. Without this flag, new configuration wouldn't be applied until you
    # ran `docker compose down`.
    entrypoint: proxysql -f --idle-threads -c /test/proxysql/proxysql.cnf --initial
    volumes:
      - ./test/:/test/:cached
    depends_on:
      - bmariadb
    networks:
      bouldernet:
        aliases:
          - boulder-proxysql

  bredis_1:
    image: redis:7.0.15
    volumes:
      - ./test/:/test/:cached
    command: redis-server /test/redis-ratelimits.config
    networks:
      bouldernet:
        ipv4_address: 10.77.77.4

  bredis_2:
    image: redis:7.0.15
    volumes:
      - ./test/:/test/:cached
    command: redis-server /test/redis-ratelimits.config
    networks:
      bouldernet:
        ipv4_address: 10.77.77.5

  bconsul:
    image: hashicorp/consul:1.22.6
    volumes:
     - ./test/:/test/:cached
    networks:
      bouldernet:
        ipv4_address: 10.77.77.10
    command: "consul agent -dev -config-format=hcl -config-file=/test/consul/config.hcl"

  bjaeger:
    image: jaegertracing/all-in-one:1.76.0
    networks:
      - bouldernet

  bpkimetal:
    image: ghcr.io/pkimetal/pkimetal:v1.41.0
    volumes:
      - pkimetal-socket:/var/run/pkimetal
      - ./test/pkimetal-config.yaml:/config/config.yaml:ro
    network_mode: none

  bvitess:
    # The `letsencrypt/boulder-vtcomboserver:latest` tag is automatically built
    # in local dev environments. In CI a specific BOULDER_VTCOMBOSERVER_TAG is
    # passed, and it is pulled with `docker compose pull`.
    image: letsencrypt/boulder-vtcomboserver:${BOULDER_VTCOMBOSERVER_TAG:-latest}
    build:
      context: test/vtcomboserver/
    volumes:
      - ./:/boulder/
    environment:
      # By specifying KEYSPACES vttestserver will create the corresponding
      # databases on startup.
      KEYSPACES: boulder_sa,incidents_sa,boulder_sa_next,incidents_sa_next,mtcmeta_44947_4_1_0_44
      NUM_SHARDS: 1,1,1,1,1
    healthcheck:
      # Make sure the service is up and the tables are created. Use `serials` because it happens
      # to be last in the SQL initialization files, so if it exists the other tables do too.
      # Note that the mysql command issues some queries on startup that result in this spurious
      # logging from bvitess:
      #   You have an error in your SQL syntax; check the manual that corresponds to your MySQL
      #   server version for the right syntax to use near '$$ from dual limit 10001'
      test: [ "CMD", "mysql", "-h", "127.0.0.1", "-P", "33577", "-D", "boulder_sa",
                "-e", "SELECT 1 FROM serials"]
      interval: 2s
      timeout: 30s
      retries: 10
      start_period: 10s
      start_interval: 2s
    networks:
      bouldernet:
        aliases:
          - boulder-vitess

  bseaweedfs:
    image: chrislusf/seaweedfs:4.47
    # Sunlight connects to its S3 backend as `<bucket>.<host>`. That means
    # SeaweedFS needs to know its `<host>` name so it can parse the Host header
    # to extract the bucket name.
    command: mini -dir=/data -s3.domainName=boulder-seaweedfs -s3.config=/etc/seaweedfs/seaweedfs.json
    healthcheck:
      test: ["CMD", "sh", "-c", "nc -z localhost 9333 && nc -z localhost 8888"]
      interval: 2s
      retries: 30
    environment:
      AWS_ACCESS_KEY_ID: boulderseaweeduser
      AWS_SECRET_ACCESS_KEY: boulderseaweedpassword
      S3_BUCKET: boulder-mtc-tiles,boulder-sunlight
    volumes:
      - mtc-data:/data
      - ./test/seaweedfs/:/etc/seaweedfs/
    networks:
      bouldernet:
        aliases:
          - boulder-seaweedfs
          # See note above: sunlight uses `<bucket>.<host>` as its S3 backend.
          - boulder-sunlight.boulder-seaweedfs

  # SeaweedFS only fsyncs writes to paths it has been told to. That is a runtime
  # setting, so this applies it once SeaweedFS is up. Objects live under
  # /buckets/, so this covers every bucket.
  bseaweedfs-configure:
    image: chrislusf/seaweedfs:4.47
    command: shell fs.configure -locationPrefix=/buckets/ -fsync -apply
    environment:
      SHELL_MASTER: boulder-seaweedfs:9333
      SHELL_FILER: boulder-seaweedfs:8888
    depends_on:
      bseaweedfs:
        condition: service_healthy
    networks:
      - bouldernet

  bsunlight:
    image: letsencrypt/boulder-sunlight:${BOULDER_SUNLIGHT_TAG:-latest}
    build:
      context: test/sunlight/
    depends_on:
      bseaweedfs-configure:
        condition: service_completed_successfully
    volumes:
      - .:/boulder:cached
      - mtc-data:/sunlight-data
    environment:
      AWS_ACCESS_KEY_ID: boulderseaweeduser
      AWS_SECRET_ACCESS_KEY: boulderseaweedpassword
    networks:
      bouldernet:
        aliases:
          - boulder-sunlight

volumes:
  mtc-data:
  # Shared between bpkimetal (which listens on a unix socket here) and any
  # boulder container that needs to reach pkimetal. Owned by uid 1001 so
  # the default pkimetal user in the container can create the socket.
  pkimetal-socket:
    driver: local
    driver_opts:
      type: tmpfs
      device: tmpfs
      o: "uid=1001,gid=1001,mode=0755"

networks:
  # This network represents the data-center internal network. It is used for
  # boulder services and their infrastructure, such as consul, mariadb, and
  # redis.
  bouldernet:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 10.77.77.0/24
          # Only issue DHCP addresses in the top half of the range, to avoid
          # conflict with static addresses.
          ip_range: 10.77.77.128/25

  # This network represents the public internet. It uses a real public IP space
  # (that Let's Encrypt controls) so that our integration tests are happy to
  # validate and issue for it. It is used by challtestsrv, which binds to
  # 64.112.117.122:80 and :443 for its HTTP-01 challenge responder.
  #
  # TODO(#8215): Put s3-test-srv on this network.
  publicnet:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 64.112.117.0/25

  # This network is used for two things in the integration tests:
  #  - challtestsrv binds to 64.112.117.134:443 for its tls-alpn-01 challenge
  #    responder, to avoid interfering with the HTTPS port used for testing
  #    HTTP->HTTPS redirects during http-01 challenges. Note: this could
  #    probably be updated in the future so that challtestsrv can handle
  #    both tls-alpn-01 and HTTPS on the same port.
  #  - test/v2_integration.py has some test cases that start their own HTTP
  #    server instead of relying on challtestsrv, because they want very
  #    specific behavior. For these cases, v2_integration.py creates a Python
  #    HTTP server and binds it to 64.112.117.134:80.
  #
  # TODO(#8215): Deprecate this network, replacing it with individual IPs within
  # the existing publicnet.
  publicnet2:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 64.112.117.128/25