# Running StatelyDB as a sidecar is a good choice when you expect the resource
# usage of StatelyDB to scale exactly the same as the service pods. It can also
# be nice if your cluster has some pods that need Stately and some that don't.
# Each pod gets their own private Stately instance, so they don't have to share.
# The downside is you may end up running more StatelyDB instances than you need
# - it's pretty efficient, but splitting it up means you can't share caches
# between the pods like you would in a daemonset deployment.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mycoolservice
  labels:
    app: mycoolservice
spec:
  selector:
    matchLabels:
      app: mycoolservice
  template:
    metadata:
      labels:
        app: mycoolservice
    spec:
      serviceAccountName: statelydb-data-plane
      # How long to wait for the pod to terminate before forcefully killing it.
      # This should be synced with the service's shutdown timeout.
      terminationGracePeriodSeconds: 120
      containers:
        - name: mycoolservice
          image: mycoolservice:latest
          # This is just a placeholder for the customer's service.
          env:
            # Tell the SDK where to look for StatelyDB. All containers in the
            # same pod share a network. TODO: Actually implement this
            - name: STATELY_ENDPOINT
              value: http://localhost:3030
            # REGION is only needed if Pod Identity is not in use - otherwise
            # it's passed automatically by the eks-pod-identity-agent as
            # AWS_REGION.
            # - name: REGION
            #   value: us-west-2
            # ACCOUNT_ID is just to help our logging, and to autoselect "Dev"
            # stage for this test.
            - name: ACCOUNT_ID
              value: "509869530682"

        # In this configuration we run a single private instance of StatelyDB per pod.
        - name: statelydb
          # Whoever runs this needs credentials to pull from this registry.
          image: public.ecr.aws/stately/dataplane:latest # <image-name>@<digest> # TODO: Template in our config, use a digest?
          ports:
            # TODO: I'm not clear on how other things on the box will access this service. I think I need to expose a nodePort?
            # This is just documentation, the service will manage the port it
            # listens on.
            - containerPort: 3030
              name: h2c # HTTP/2 cleartext
          env:
            # Read the access key from a secret. This is a bad way to store them
            # - perhaps the user has a better secrets management solution?
            - name: STATELY_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: statelydb-secret
                  key: STATELY_ACCESS_KEY
            # REGION and ACCOUNT_ID are only needed if your instances do not
            # have the IMDSv2 service properly configured. You need to have the
            # HttpPutResponseHopLimit set to 2.
            - name: REGION
              value: us-west-2
            - name: ACCOUNT_ID
              value: "509869530682"
          # These resource requests/limits serve to "reserve" some space on a
          # host. The service will use the entire memory limit, but no more. You
          # will want to adjust them based on your expected workload.
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
          # The liveness probe must succeed for the pod to be considered
          # healthy. If it fails, the pod will be restarted.
          livenessProbe:
            httpGet:
              path: /health
              port: 3030
            initialDelaySeconds: 5
            periodSeconds: 10
