Adds extraContainers to integration test elasticsearch

[codefromthecrypt]

this was mighty tricky to figure out!

[codefromthecrypt]

notes

[codefromthecrypt]

there's no good reason for us to have made this mandatory before

[codefromthecrypt]

conditionally guarding is less cluttered.

you can test like..

$ helm template charts/zipkin --values charts/zipkin/ci/elasticsearch-values.yaml
---
# Source: zipkin/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: release-name-zipkin
  namespace: default
  labels:
    helm.sh/chart: zipkin-0.2.0
    app.kubernetes.io/name: zipkin
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "3.0.6"
    app.kubernetes.io/managed-by: Helm
---
# Source: zipkin/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-zipkin
  namespace: default
  labels:
    helm.sh/chart: zipkin-0.2.0
    app.kubernetes.io/name: zipkin
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "3.0.6"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 9411
      targetPort: 9411
      protocol: TCP
      name: http-query
  selector:
    app.kubernetes.io/name: zipkin
    app.kubernetes.io/instance: release-name
---
# Source: zipkin/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-zipkin
  namespace: default
  labels:
    helm.sh/chart: zipkin-0.2.0
    app.kubernetes.io/name: zipkin
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "3.0.6"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: zipkin
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "false"
      labels:
        app.kubernetes.io/name: zipkin
        app.kubernetes.io/instance: release-name
    spec:
      automountServiceAccountToken: false
      serviceAccountName: release-name-zipkin
      securityContext:
        {}
      containers:
        - name: zipkin
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 1000
          image: "openzipkin/zipkin-slim:3.0.6"
          env:
            - name: STORAGE_TYPE
              value: "elasticsearch"
            - name: ES_HOSTS
              value: "http://localhost:9200"
          imagePullPolicy: IfNotPresent
          readinessProbe:
            httpGet:
              path: /health
              port: 9411
            initialDelaySeconds: 5
            periodSeconds: 5
          resources:
            limits:
              cpu: 500m
              memory: 4096Mi
            requests:
              cpu: 100m
              memory: 128Mi
      
        - image: ghcr.io/openzipkin/zipkin-elasticsearch8
          name: elasticsearch
          ports:
          - containerPort: 9200
---
# Source: zipkin/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "release-name-zipkin-test-connection"
  labels:
    helm.sh/chart: zipkin-0.2.0
    app.kubernetes.io/name: zipkin
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "3.0.6"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: get-api-services
      image: 'ghcr.io/openzipkin/alpine:3.19.1'
      command: [ '/bin/sh', '-c' ]
      # Get an arbitrary API endpoint using the ClusterIP and service port
      args: [ 'wget -qO ---spider --header "b3: cafebabecafebabe-cafebabecafebabe-1" http://release-name-zipkin:9411/api/v2/services' ]
  restartPolicy: Never

[codefromthecrypt]

I don't really know why entirely, but you can't inline the expression. it causes an obscure key not found. I poked around and found otel did the same thing to dodge this, but there wasn't an explicit comment why.

[codefromthecrypt]

ct lint isn't smart enough to know we haven't released 0.2.0 yet...

[codefromthecrypt]

reason this works without any other machinery is that zipkin checks its dependencies and doesn't return OK healthcheck until they are ok.

Hence, it can resolve this as you'll see in the logs.. then the wget tests are safe to run. pretty handy

   Warning  Unhealthy  20s                kubelet            Readiness probe failed: Get "http://10.244.0.7:9411/health": dial tcp 10.244.0.7:9411: connect: connection refused
  Warning  Unhealthy  18s                kubelet            Readiness probe failed: Get "http://10.244.0.7:9411/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  11s (x2 over 16s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 503

[codefromthecrypt]

thanks for the look @anuraaga. next I'll add eureka (as that's what I was originally wanting to do), then see about a dependency graph test. The latter is a bit more work as we have to generate recent spans that hit at least 2 things, so.. we can't use self-tracing. I was thinking about trying the example apps as "extraContainers" maybe..