# Question
Title: Spacelift - external state access - cannot create a workspace error
I am trying to use Spacelift's external state access however I get the following error:

```
Error: Error loading state error
│
│ with module.service.data.terraform_remote_state.environment,
│ on ../modules/service/ecs.tf line 79, in data "terraform_remote_state" "environment":
│ 79: backend = "remote"
│
│ error loading the remote state: Error creating workspace test-stack: cannot
│ create a workspace

```

My block looks like:

```
 data "terraform_remote_state" "environment" {
  backend = "remote"

  config = {
    hostname     = "spacelift.io"
    organization = "<organizationname>"

    workspaces = {
      name = "test-stack"
    }
  }
}

```

I have external state access enabled on the stack but still get this error.

# Answer
Check if the caller stack is set to Administrative.
> 1 votes

---
Tags: terraform, continuous-integration, cicd, spacelift
---


# Question
Title: Is there any way to trigger a different pipeline inside of a pipeline in Azure Dev Ops
If I create a variable like IsTrigger and the default value of this variable is false and this value can be set at queque time.

I wonder what happens if I give this variable true as value when I run a pipeline.

Can I trigger a different pipeline based on the value of this variable?

for example:

```
    eq(variables['IsTrigger', true]

```
* do trigger different pipeline

# Answer
> 0 votes
You can do this with the Trigger Build Task available from VS Marketplace.

Or using REST API methods Run pipeline. For example via Invoke REST API task or with bash (script) task:

```
- bash: |
    curl \
      -H "Authorization: Bearer ${SYSTEM_ACCESSTOKEN}" \
      -X POST https://dev.azure.com/{organization}/{project}/_apis/pipelines/{pipelineId}/runs?api-version=7.0

  displayName: Trigger another pipeline
  condition: eq(variables['IsTrigger', true])
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

```

# Answer
> 0 votes
you can do by adding a trigger to the pipeline that you want to be triggered like

```

resources:
  'pipelines:
  - pipeline: MyCIAlias
    source: MainPipeline
    trigger:
      stages:
      - MyStage

```

This will be triggered when the stage "MyStage" in your pipeline "MainPipeline" has completed.

In the MainPipeline on the MyStage you can set a condition that will skip the stage unless your "IsTrigger" variable is set to true, like

<pre><code>- stage: MyStage
  dependsOn:
  - Build
  displayName: Checklist Pre Production Release
  condition: |
    eq(variables.IsTrigger, 'true')
    ```
</code></pre>

# Answer
> 0 votes
You could also use the `az` commandline tool and the built-in AccessToken, when you need to trigger a Pipeline inside Azure DevOps on the same Organization.

```
- job:
  displayName: "Run Pipeline"
  steps:
  - bash: |
      az pipelines run --project 'PROJECT' --id 123456 --branch 'main'
    displayName: 'Trigger Pipeline 123456'
    env:
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)

```

`az pipelines run` can also set parameters for a pipeline you want to trigger:
`az pipelines run --project 'PROJECT' --id 123456 --branch 'main' --parameters 'param1=VALUE'`
(The ones when you click "Run Pipeline" and can set/select in the UI in the Browser)
Documentation: https://learn.microsoft.com/en-us/cli/azure/pipelines?view=azure-cli-latest#az-pipelines-run

To find the ID of a pipeline:
`az pipelines list -p "ProjectName" | ConvertFrom-Json | Select-Object -Property Id, Name, queueStatus | Where-Object { $_.Name -eq "PipelineName" }`

---
Tags: azure-devops
---


# Question
Title: GitLab CI: How to properly push file to a repo using ci file?
I'm trying to setup a GitLab CI pipeline which runs a script (`convert-inventory-format.sh`) that update a yaml file. I would then like to commit that file to a Git repository and push it.

However, the pipeline fails with the error:

```
remote: You are not allowed to upload code.

```

The user provided works when trying this process outside of a CI pipeline

this is my gitlab-ci file:

```
stages:
  - update_yaml

update_yaml:
  tags:
    - git
  stage: update_yaml
  script:
    - chmod +x $CI_PROJECT_DIR/convert-inventory-format.sh
    - $CI_PROJECT_DIR/convert-inventory-format.sh
    - ls
    - echo "Deploying to Git repository"
    - git config user.email "xxx"
    - git config user.name "xxx"
    - git add $CI_PROJECT_DIR/wiki_inventory.yaml
    - git status
    - git commit -m "Update formatted YAML"
    - git push origin InventoriesWiki
  variables:
    GIT_STRATEGY: fetch
    GIT_CHECKOUT: "false"
    GIT_PUSH_OPTS: "--force"
    GIT_USER: XXX
    GIT_PASSWORD: xxx

```

i'm not sure why this pipeline fails, what is the best practice for running git commits in a gitlab ci pipeline?

I appericiate your help

# Answer
Are you attempting to push to the same git repo that the CI is running against? If so, GitLab CI jobs do not have permission to write to their respective repo, at least not by default.

If you really need to do this, you can add the necessary credentials to a CI variable. Go to **Settings → CI/CD → Variables** in either the Project or Group — you need to be a Maintainer or owner to do this. In your script you'll then need to apply these credentials when you run git (they'll be passed in as environment variables).

Beware of infinite recursion: if pushing to the repo causes CI to run again and push to the repo again... it would be bad.
> 1 votes

# Answer
From https://docs.gitlab.com/ee/ci/jobs/ci\_job\_token.html:

> You can’t use a job token to push to a repository, but issue 389060 proposes to change this behavior.

Project/group scoped access tokens are popular solutions for the problem.

Also, as Laurence mentioned look into using `git push -o ci-skip ...` or `[skip ci]` in the commit message to avoid triggering CI again.
> 1 votes

---
Tags: continuous-integration, gitlab, cicd, gitlab-ci-runner, pipeline
---


# Question
Title: Why is my private worker crashing on Spacelift?
I am using a private worker on Spacelift but my run keeps failing with the error "worker crashed".

This is only happening on one stack, any suggestions?

# Answer
> 1 votes
The most common reason is that it has run out of memory.

It is worth checking the CPU and memory usage of the workers, this can happen with really big stacks that are using an EC2 instance (or equivalent) with not enough memory to handle it.

If you are using Terraform, you could also add the env var TF\_LOG = DEBUG to get more verbose logging which may give clues.

Thank you!

---
Tags: terraform, spacelift
---


title: Spacelift - local run - is it possible

text:
# Question
Title: Spacelift - local run - is it possible
I am trying to run my Spacelift stack with my files from a local folder, but using all the context / env vars etc that are present in my Spacelift stack, is this possible?

# Answer
> 0 votes
You could preview uncommitted local changes by using the local-preview subcommand of our API client, named spacectl :

```
spacectl stack local-preview --id <STACK ID>

```

---
Tags: terraform, spacelift
---


# Question
Title: Tekton Kaniko build - gives push permissions errors
When running a pipeline with a **Kaniko build task**, I see the following error message:

> ```
> E0105 13:50:28.345758      19 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain.
> Deprecated.
>   For verbose messaging see aws.Config.CredentialsChainVerboseErrors
> error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try
> again: checking push permission for
> "docker.io/xyz/myimage": POST
> https://index.docker.io/v2/xyz/myimage/blobs/uploads/:
> UNAUTHORIZED: authentication required; [map[Action:pull Class:
> Name:xyz/myimage Type:repository] map[Action:push Class:
> Name:xyz/myimage Type:repository]]
>
> ```

First I created a secret by generating a Docker hub access token. The secret is created using this command:

> ```
> k create secret docker-registry docker-credential
> --docker-username=xyz --docker-password=generated-docker-access-token --docker-email=xyz@mail.com --namespace=default
>
> ```

An alternative way is: getting the docker config info:

```
$ cat ~/.docker/config.json | base64 -w0

```

Using this info in a secret:

```
apiVersion: v1
kind: Secret
metadata:
  name: docker-credential
data:
  .dockerconfigjson: <base-64-encoded-json-here>
type: kubernetes.io/dockerconfigjson

```

Then I installed the Tekton Kaniko task with:

> kubectl apply -f https://api.hub.tekton.dev/v1/resource/tekton/task/kaniko/0.6/raw

I run the pipeline in my local Docker Desktop Kubernets environment with a local Gitea repo, which works fine.

Before showing the pipeline(run): I tried all kinds of solutions, like using the Docker hub password (iso token), use a Secret with the Docker credentials, etc. Nothing helps, yet.

Finally I created and ran a pipeline(run):

```
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: buildpacks-kaniko-pipeline
spec:
  params:
    - name: SOURCE_URL
      type: string
      description: A git repo url where the source code resides.
    - name: SOURCE_REVISION
      description: The branch, tag or SHA to checkout.
      default: ""
  workspaces:
    - name: source-workspace
    - name: dockerconfiginput
  tasks:
    - name: fetch-repository
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: source-workspace
      params:
        - name: url
          value: "$(params.SOURCE_URL)"
        - name: revision
          value: "$(params.SOURCE_REVISION)"
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
    - name: build-kaniko
      taskRef:
        name: kaniko
      runAfter:
        - fetch-repository
      params:
        - name: IMAGE
          value: docker.io/solvedshared/kanikodemo
        - name: DOCKERFILE
          value: ./Dockerfile
        - name: CONTEXT
          value: ./
      workspaces:
        - name: source
          workspace: source-workspace
        - name: dockerconfig
          workspace: dockerconfiginput
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: buildpacks-kaniko-pipeline-run
spec:
  pipelineRef:
    name: buildpacks-kaniko-pipeline
  workspaces:
    - name: source-workspace
      persistentVolumeClaim:
        claimName: source-kaniko-pvc
    - name: dockerconfiginput
      secret:
        secretName: docker-credential
  serviceAccountName: build-bot
  params:
    - name: SOURCE_URL
      value: http://gitea-gitea-http.default.svc.cluster.local:3000/gituser/kaniko-demo.git
    - name: SOURCE_REVISION
      value: master

```

I also tried to use another BUILD\_IMAGE:

```
    - name: BUILDER_IMAGE
      value: bitnami/kaniko:1.19.2

```

This time I go this error message:

> ```
> error checking push permissions -- make sure you entered the correct
> tag name, and that you are authenticated correctly, and try again:
> checking push permission for "docker.io/xyz/myimage": POST
> https://index.docker.io/v2/xyz/myimage/blobs/uploads/:
> UNAUTHORIZED: authentication required; [map[Action:pull Class:
> Name:xyz/myimage Type:repository] map[Action:push Class:
> Name:xyz/myimage Type:repository]]
>
> ```

# Answer
> 0 votes
First generate the secrets file like this:

```
$ kubectl create secret docker-registry docker-credential
--docker-username=xyz --docker-password=xyzpassword --docker-email=xyz@mail.com --namespace=default

```

Write the secret to a new yaml:

```
$ kubectl get secret docker-credential -o yaml > key-alt.yaml

```

Edit the file so it looks like (I could have left the docker-registry out):

```
apiVersion: v1
data:
  config.json: ewoJImF1***SIKCQl9Cgl9Cn0=
kind: Secret
metadata:
  name: docker-credential-3
  namespace: default

```

Create the secret:

```
$ kubectl apply -f key-alt.yaml

```

The 'red herring' was that you normally generate a docker secret using the type 'docker-registry'. It will create the secret with the key '.dockerconfig'. The Tekton task uses a different route: it requires the 'config.json' as the key of the Secret resource.

---
Tags: kubernetes
---


title: Deploy a Redis cluster with Docker

text:
# Question
Title: Deploy a Redis cluster with Docker
I need to create a Redis cluster using Docker (with Kubernetes afterwards) and didn't find any official documentation on that matter. Could I have guidance on that subject ?

I have the below yaml content but I am not sure if it follows the best practices:

```
version: '3'

networks:
  redis-cluster-compose:
    driver: bridge

services:
  redis-node-1:
    image: redis:latest
    ports:
      - 7000:7000
    networks:
      - redis-cluster-compose
    hostname: redis-node-1
    volumes:
      - ./7000:/redis
    command: redis-server /redis/redis.conf
  redis-node-2:
    image: redis:latest
    ports:
      - 7001:7001
    networks:
      - redis-cluster-compose
    hostname: redis-node-2
    volumes:
      - ./7001:/redis
    command: redis-server /redis/redis.conf

  redis-node-3:
    image: redis:latest
    ports:
      - 7002:7002
    networks:
      - redis-cluster-compose
    hostname: redis-node-3
    volumes:
      - ./7002:/redis
    command: redis-server /redis/redis.conf

  redis-node-4:
    image: redis:latest
    ports:
      - 7003:7003
    networks:
      - redis-cluster-compose
    hostname: redis-node-4
    volumes:
      - ./7003:/redis
    command: redis-server /redis/redis.conf

  redis-node-5:
    image: redis:latest
    ports:
      - 7004:7004
    networks:
      - redis-cluster-compose
    hostname: redis-node-5
    volumes:
      - ./7004:/redis
    command: redis-server /redis/redis.conf

  redis-node-6:
    image: redis:latest
    ports:
      - 7005:7005
    networks:
      - redis-cluster-compose
    hostname: redis-node-6
    volumes:
      - ./7005:/redis
    command: redis-server /redis/redis.conf

  redis-cluster-creator:
    image: redis:latest
    ports:
      - 6999:6999
    networks:
      - redis-cluster-compose
    command: redis-cli -p 7000 --cluster create redis-node-1:7000 redis-node-2:7001 redis-node-3:7002 redis-node-4:7003 redis-node-5:7004 redis-node-6:7005 --cluster-replicas 1 --cluster-yes
    depends_on:
      - redis-node-1
      - redis-node-2
      - redis-node-3
      - redis-node-4
      - redis-node-5
      - redis-node-6

```

# Answer
To begin with, note the following text from the Redis documentation:

> Currently, Redis Cluster does not support NATted environments and in general environments where IP addresses or TCP ports are remapped.
>
> Docker uses a technique called port mapping: programs running inside Docker containers may be exposed with a different port compared to the one the program believes to be using. This is useful for running multiple containers using the same ports, at the same time, in the same server.
>
> To make Docker compatible with Redis Cluster, you need to use Docker's host networking mode. Please see the --net=host option in the Docker documentation for more information.

If your goal is to expose the redis cluster outside of your compose environment, then you're going to need to run everything with `network_mode: host`. When running in host network mode, you cannot use port publishing, so you'll need to (a) get rid of the `ports` section in your services and (b) ensure that each instance is listening on a different port.

A second problem is that your `redis-cluster-creator` service runs before any of your redis containers are ready. The legacy form the `depends_on` option...

```
depends_on:
  - redis-node-1
  - redis-node-2
  - redis-node-3
  .
  .
  .

```

...is effectively useless; it only waits for the *container* to start; it doesn't know anything about the state of the application running inside the container. We can (a) add a healthcheck to the containers and then (b) use the extended form of depends\_on to wait until redis is actually up before attempting to create the cluster.

Lastly, a bunch of little things:

* You probably don't need an individual configuration file for each node; they should all be using identical configurations, other than the port, which can be set on the command line.
* You probably want to use persistent storage for the redis data directory in `/data`.

Putting all of that together, we get something like this:

```
services:
  redis-cluster-creator:
    command:
      - redis-cli
      - --cluster
      - create
      - localhost:7001
      - localhost:7002
      - localhost:7003
      - localhost:7004
      - localhost:7005
      - localhost:7006
      - --cluster-yes
      - --cluster-replicas
      - '1'
    depends_on:
      redis-node-1:
        condition: service_healthy
      redis-node-2:
        condition: service_healthy
      redis-node-3:
        condition: service_healthy
      redis-node-4:
        condition: service_healthy
      redis-node-5:
        condition: service_healthy
      redis-node-6:
        condition: service_healthy
    image: docker.io/redis:latest
    network_mode: host
  redis-node-1:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7001'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7001'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7001:7000
    volumes:
      - redis-data-1:/data
      - ./redis:/redis
  redis-node-2:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7002'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7002'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7002:7000
    volumes:
      - redis-data-2:/data
      - ./redis:/redis
  redis-node-3:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7003'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7003'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7003:7000
    volumes:
      - redis-data-3:/data
      - ./redis:/redis
  redis-node-4:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7004'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7004'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7004:7000
    volumes:
      - redis-data-4:/data
      - ./redis:/redis
  redis-node-5:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7005'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7005'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7005:7000
    volumes:
      - redis-data-5:/data
      - ./redis:/redis
  redis-node-6:
    command:
      - redis-server
      - /redis/redis.conf
      - --port
      - '7006'
    healthcheck:
      interval: 10s
      retries: '3'
      test:
        - CMD
        - redis-cli
        - -p
        - '7006'
        - -c
        - ping
      timeout: 5s
    image: docker.io/redis:latest
    network_mode: host
    ports:
      - 7006:7000
    volumes:
      - redis-data-6:/data
      - ./redis:/redis
volumes:
  redis-data-1: {}
  redis-data-2: {}
  redis-data-3: {}
  redis-data-4: {}
  redis-data-5: {}
  redis-data-6: {}

```

The contents of `redis/redis.conf` is:

```
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

```

You can see a successful `docker compose up` using this environment here.

There is a lot of repetition in that compose file, so to make my life easier while experimenting I used jsonnet to template things. You can find my complete environment at https://github.com/larsks/redis-cluster-example.
> 0 votes

---
Tags: docker, kubernetes, redis
---


# Question
Title: Is the data shared between two pods database deployment k8s
I have a structure like shown in the image below: cluster with two nodes and service for the database (postgres).

Is the data shared between those two pods of `postgres` images or is it possible to set it to share data?

This is scenario which I want the answer to:

* Connect to database with host `db.domain.com` (load balancer point me to `node1`)
* Insert 1 (and only) record in table
* Disconnect
* Connect to database again with host `db.domain.com` (load balancer points me to other node)
* List items in table
* Will I get the inserted row from `node1`?

Also if I scale up to 10 nodes, 10 instances of same service will be deployed, so 10 images of `posgres`, do the all share data?

# Answer
> 1 votes
> Is the data shared between those two pods of postgres images or is it possible to set it to share data?

Each pod has its own filesystem; there is no sharing between pods by default.

With the right storage driver in your Kubernetes clusters, you can create persistent volumes that are shared between pods. However, this is usually not appropriate for a database, which typically requires exclusive access to its storage directory.

To achieve your goal of having two database instances with the same content, you will need to set up postgres replication. In this model, your database instances form a cluster and writes to the primary server are automatically replicated to secondary servers. You can only *write* to the master, but you can *read* (i.e., perform `select` queries) from any of the replicas.

There are a number of operators that will help set up postgres clusters in Kubernetes. For example:

---
Tags: kubernetes, postgresql
---


# Question
Title: How to deploy an nginx ingress to a kubeadm cluster
I'm attempting to set up my own bare-metal Kubernetes cluster composed of a control plane (VPS 149.62.186.95) and a worker node (VPS 149.62.189.139). Both my VPS are running Ubuntu 22.04 with 2 vCPUs and 4GB vRAM.

After installing Kubernetes (`kubeadm`) on both, I ran the following commands on my control plane:

```
kubeadm init

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Weave deamonset
kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

# baremetal nginx ingress
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/baremetal/deploy.yaml

```

I edited my DNS records as follows:

* registry.rottigni.tech -\> 149.62.186.95 (control plane)
* sandbox.rottigni.tech -\> 149.62.186.95 (control plane)

I generated SSL certs for these domains on my control plane and stored them in Kubernetes secrets.

Then, I applied my changes using kubectl apply -R -f . inside my repository. Here's the most relevant file, ingress.yml:

```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-ingress-class
spec:
  controller: k8s.io/ingress-nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: lr-labs-ingress
  namespace: lr-labs
  annotations:
    # cert-manager.io/issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx-ingress-class
  tls:
    - hosts:
        - registry.rottigni.tech
      secretName: registry-ssl
    - hosts:
        - sandbox.rottigni.tech
      secretName: sandbox-ssl

  rules:
    - host: registry.rottigni.tech
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: registry-rottigni
                port:
                  number: 5000

    - host: sandbox.rottigni.tech
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: sandbox-rottigni
                port:
                  number: 80

```

At this point, everything seems to be working on the kubectl side, according to the following output:

```
Every 2.0s: kubectl get pods,deploy,svc,ing,endpoints,node -A

NAMESPACE       NAME                                                READY   STATUS      RESTARTS        AGE
ingress-nginx   pod/ingress-nginx-admission-create-wn7xr            0/1     Completed   0               7h58m
ingress-nginx   pod/ingress-nginx-admission-patch-dtzxf             0/1     Completed   0               7h58m
ingress-nginx   pod/ingress-nginx-controller-86968d59df-vdv9f       1/1     Running     0               6h52m
kube-system     pod/coredns-5dd5756b68-h4jwb                        1/1     Running     0               7h58m
kube-system     pod/coredns-5dd5756b68-jrsdq                        1/1     Running     0               7h58m
kube-system     pod/etcd-epsilon-rottigni-tech                      1/1     Running     0               7h58m
kube-system     pod/kube-apiserver-epsilon-rottigni-tech            1/1     Running     0               7h58m
kube-system     pod/kube-controller-manager-epsilon-rottigni-tech   1/1     Running     0               7h58m
kube-system     pod/kube-proxy-4v8bc                                1/1     Running     0               7h58m
kube-system     pod/kube-proxy-8hpjj                                1/1     Running     0               7h57m
kube-system     pod/kube-scheduler-epsilon-rottigni-tech            1/1     Running     0               7h58m
kube-system     pod/weave-net-gvzk5                                 2/2     Running     1 (7h58m ago)   7h58m
kube-system     pod/weave-net-tbr92                                 2/2     Running     0               7h57m
lr-labs         pod/registry-rottigni-5c6cfd877f-qqxsw              1/1     Running     0               7h54m
lr-labs         pod/sandbox-rottigni-9668f7447-dv7js                1/1     Running     0               7h54m

NAMESPACE       NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx   deployment.apps/ingress-nginx-controller   1/1     1            1           7h58m
kube-system     deployment.apps/coredns                    2/2     2            2           7h58m
lr-labs         deployment.apps/registry-rottigni          1/1     1            1           7h54m
lr-labs         deployment.apps/sandbox-rottigni           1/1     1            1           7h54m

NAMESPACE       NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
default         service/kubernetes                           ClusterIP   10.96.0.1        <none>        443/TCP                      7h58m
ingress-nginx   service/ingress-nginx-controller             NodePort    10.108.71.135    <none>        80:32095/TCP,443:30221/TCP   7h58m
ingress-nginx   service/ingress-nginx-controller-admission   ClusterIP   10.107.203.218   <none>        443/TCP                      7h58m
kube-system     service/kube-dns                             ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       7h58m
lr-labs         service/registry-rottigni                    NodePort    10.106.231.17    <none>        5000:31673/TCP               7h54m
lr-labs         service/sandbox-rottigni                     NodePort    10.111.173.239   <none>        80:31607/TCP                 7h54m

NAMESPACE   NAME                                        CLASS                 HOSTS                                          ADDRESS          PORTS     AGE
lr-labs     ingress.networking.k8s.io/lr-labs-ingress   nginx-ingress-class   registry.rottigni.tech,sandbox.rottigni.tech   149.62.189.139   80, 443   7h54m

NAMESPACE       NAME                                           ENDPOINTS                                            AGE
default         endpoints/kubernetes                           149.62.186.95:6443                                   7h58m
ingress-nginx   endpoints/ingress-nginx-controller             10.44.0.2:443,10.44.0.2:80                           7h58m
ingress-nginx   endpoints/ingress-nginx-controller-admission   10.44.0.2:8443                                       7h58m
kube-system     endpoints/kube-dns                             10.32.0.2:53,10.32.0.3:53,10.32.0.2:53 + 3 more...   7h58m
lr-labs         endpoints/registry-rottigni                    10.44.0.3:5000                                       7h54m
lr-labs         endpoints/sandbox-rottigni                     10.44.0.1:80                                         7h54m

NAMESPACE   NAME                         STATUS   ROLES           AGE     VERSION
            node/epsilon-rottigni-tech   Ready    control-plane   7h58m   v1.28.2
            node/zeta-rottigni-tech      Ready    <none>          7h57m   v1.28.2

```

One strange thing is that my ingress has IP 149.62.189.139, which is my worker node IP (not control plane IP). Is this the correct behavior?

Despite this, I'm unable to reach my services from the public DNS through my nginx ingress controller. I can, however, correctly reach both services using NodePort from my control plane and worker node SSH sessions, eliminating any application errors.

It appears that my ingress isn't facing the internet on the correct IP. I also checked my ingress-nginx-controller logs, which seem fine:

```
-------------------------------------------------------------------------------
NGINX Ingress controller
  Release:       v1.9.5
  Build:         f503c4bb5fa7d857ad29e94970eb550c2bc00b7c
  Repository:    https://github.com/kubernetes/ingress-nginx
  nginx version: nginx/1.21.6

-------------------------------------------------------------------------------

W0105 14:11:47.972914       7 client_config.go:618] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0105 14:11:47.973187       7 main.go:205] "Creating API client" host="https://10.96.0.1:443"
I0105 14:11:47.983447       7 main.go:249] "Running in Kubernetes cluster" major="1" minor="28" git="v1.28.5" state="clean" commit="506050d61cf291218dfbd41ac93913945c9aa0da" platform="linux/amd64"
I0105 14:11:48.470371       7 main.go:101] "SSL fake certificate created" file="/etc/ingress-controller/ssl/default-fake-certificate.pem"
I0105 14:11:48.511293       7 ssl.go:536] "loading tls certificate" path="/usr/local/certificates/cert" key="/usr/local/certificates/key"
I0105 14:11:48.529226       7 nginx.go:260] "Starting NGINX Ingress controller"
I0105 14:11:48.539963       7 event.go:298] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"ingress-nginx", Name:"ingress-nginx-controller", UID:"a5edeb27-12a0-4576-ab70-19d8cffb4dfe", APIVersion:"v1", ResourceVersion:"338", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap ingress-nginx/ingress-nginx-controller
I0105 14:11:49.635029       7 store.go:440] "Found valid IngressClass" ingress="lr-labs/lr-labs-ingress" ingressclass="nginx-ingress-class"
I0105 14:11:49.636090       7 event.go:298] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"lr-labs", Name:"lr-labs-ingress", UID:"5663167b-9b94-4cb6-8670-5e5e1076bfaa", APIVersion:"networking.k8s.io/v1", ResourceVersion:"1159", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
I0105 14:11:49.638242       7 backend_ssl.go:67] "Adding secret to local store" name="lr-labs/registry-ssl"
I0105 14:11:49.641278       7 backend_ssl.go:67] "Adding secret to local store" name="lr-labs/sandbox-ssl"
I0105 14:11:49.731218       7 nginx.go:303] "Starting NGINX process"
I0105 14:11:49.731681       7 leaderelection.go:245] attempting to acquire leader lease ingress-nginx/ingress-nginx-leader...
I0105 14:11:49.732611       7 nginx.go:323] "Starting validation webhook" address=":8443" certPath="/usr/local/certificates/cert" keyPath="/usr/local/certificates/key"
I0105 14:11:49.733509       7 controller.go:190] "Configuration changes detected, backend reload required"
I0105 14:11:49.736538       7 status.go:84] "New leader elected" identity="ingress-nginx-controller-685dff585b-2s8jp"
I0105 14:11:49.849528       7 controller.go:210] "Backend successfully reloaded"
I0105 14:11:49.849813       7 controller.go:221] "Initial sync, sleeping for 1 second"
I0105 14:11:49.850019       7 event.go:298] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-86968d59df-vdv9f", UID:"7ac8215f-175f-4496-90a1-dd63d6acad4e", APIVersion:"v1", ResourceVersion:"6819", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
I0105 14:12:41.662980       7 status.go:84] "New leader elected" identity="ingress-nginx-controller-86968d59df-vdv9f"
I0105 14:12:41.663007       7 leaderelection.go:255] successfully acquired lease ingress-nginx/ingress-nginx-leader
10.32.0.1 - - [05/Jan/2024:14:36:35 +0000] "GET / HTTP/1.1" 400 248 "-" "curl/7.81.0" 81 0.000 [] [] - - - - 479859864f23ba0523fb9c29c1932d56
10.32.0.1 - - [05/Jan/2024:14:38:30 +0000] "GET / HTTP/1.1" 308 164 "-" "curl/7.81.0" 85 0.000 [lr-labs-sandbox-rottigni-80] [] - - - - e262c16d9495ef00f412f0ba73dbb453
10.32.0.1 - - [05/Jan/2024:15:25:27 +0000] "GET / HTTP/1.1" 308 164 "-" "curl/7.81.0" 85 0.000 [lr-labs-sandbox-rottigni-80] [] - - - - 9b662b33bb59be1846863af658f251ab
10.32.0.1 - - [05/Jan/2024:16:08:32 +0000] "GET / HTTP/1.1" 308 164 "-" "curl/7.81.0" 85 0.000 [lr-labs-sandbox-rottigni-80] [] - - - - a54eda51703800c9a1726a9e1187988d

```

I even see some manually initiated curl requests for debugging directly to the nginx service using the Host HTTP header.

Additionally here my working curl commands to my cluster service resources:

```
root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s# kubectl get svc -A
NAMESPACE       NAME                                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
default         kubernetes                           ClusterIP   10.96.0.1        <none>        443/TCP                      8h
ingress-nginx   ingress-nginx-controller             NodePort    10.108.71.135    <none>        80:32095/TCP,443:30221/TCP   8h
ingress-nginx   ingress-nginx-controller-admission   ClusterIP   10.107.203.218   <none>        443/TCP                      8h
kube-system     kube-dns                             ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       8h
lr-labs         registry-rottigni                    NodePort    10.106.231.17    <none>        5000:31673/TCP               8h
lr-labs         sandbox-rottigni                     NodePort    10.111.173.239   <none>        80:31607/TCP                 8h
root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s# curl 10.106.231.17:5000
root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s# curl 10.108.71.135:80
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s# curl 10.108.71.135:443
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s# curl 10.111.173.239:80
<html>
  <head>
    <style>
      html {
        background: url(./Cheddar.jpg) no-repeat center center fixed;
        -webkit-background-size: cover;
        -moz-background-size: cover;
        -o-background-size: cover;
        background-size: cover;
      }

      h1 {
        font-family: Arial, Helvetica, sans-serif;
        background: rgba(187, 187, 187, 0.5);
        width: 6em;
        padding: 0.5em 1em;
        margin: 1em;
      }
    </style>
  </head>
  <body>
    <h1>Cheddar</h1>
  </body>
</html>root@epsilon-rottigni-tech:~/k8s.rottigni.tech/k8s#

```

Could someone please help me debug this problem? Am I missing an important step for this kind of production deployment?

Thank you everybody!

---

UPDATE:

Given the following situation:

```
kubectl get svc,ing -A
NAMESPACE       NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
default         service/kubernetes                           ClusterIP   10.96.0.1        <none>        443/TCP                      23h
ingress-nginx   service/ingress-nginx-controller             NodePort    10.108.71.135    <none>        80:32095/TCP,443:30221/TCP   23h
ingress-nginx   service/ingress-nginx-controller-admission   ClusterIP   10.107.203.218   <none>        443/TCP                      23h
kube-system     service/kube-dns                             ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       23h
lr-labs         service/registry-rottigni                    NodePort    10.106.231.17    <none>        5000:31673/TCP               23h
lr-labs         service/sandbox-rottigni                     NodePort    10.111.173.239   <none>        80:31607/TCP                 23h

NAMESPACE   NAME                                        CLASS                 HOSTS                                          ADDRESS          PORTS     AGE
lr-labs     ingress.networking.k8s.io/lr-labs-ingress   nginx-ingress-class   registry.rottigni.tech,sandbox.rottigni.tech   149.62.189.139   80, 443   23h

```

I am able to reach nginx from internet like this:

But I can't like this:

# Answer
Basically you did everything correctly. The chosen way to make your service reachable from the outside does not allow you to use specific, low, ports in order to keep isolation between services. You have two options:

1. use a service of type LoadBalancer which will allocate a separate IP for the service, providing isolation between services and allowing you a specific port like 80 or 443
2. modify the ingress deployment and use a `hostPort` for the nginx containers, you can then use the node IPs where a pod is running. This can lead to a lot of headaches (f.e. when updating the deployment) but might be an easy solution to get started
> 0 votes

---
Tags: kubernetes, kubectl, kubeadm, ingress-nginx
---


# Question
Title: How to see the full command used to run a container in a Kubernetes pod?
In Docker we can see the full command used to run a container using

```
docker ps --no-trunc

```

In case of containers inside pods in a Kubernetes cluster, how to find this same info?

I also tried to describe a pod using `kubectl describe pods test-77f45b7bd7-hqvqh -n somenp` but it doesn't show that information:

```
Containers:
  data-exploration:
    Container ID:   docker://XXXXXXXXXXXXXXXXXXXXXXXXXX
    Image:          docker_uri
    Image ID:       docker-pullable://docker_uri
    Port:           3002/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 22 Dec 2023 10:37:25 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  5Gi
    Requests:
      cpu:     500m
      memory:  1Gi
    Environment:

```

# Answer
> 0 votes
Kubernetes by default runs the command specified in container image. You can override that command using `command` and `args` in pod spec (see doc).

So the only way to find the command is either to exec into the pod or inspect the container image.

---
Tags: docker, kubernetes
---


# Question
Title: How do I stop all users from creating branches on GitLab and force Merge Requests?
My company wants to create a policy where only one person can create a new branch, and not every developer on a project. The only method of contribution that they want is merge-requests. How can we accomplish this?

# Answer
The definition of the role "developer" is a contributor that can create branches. If you don't want this permission, you'll have to revoke that role.

Anyone with visibility to the project can pull from it including Guests and Reports (which are inferior roles). A "developer" is a "role" that carries the permission of "Create new branches", "Force push to non-protected branches".
> 1 votes

---
Tags: gitlab
---


# Question
Title: How can I put some set of machines to a group in an ansible inventory dynamically using the add_host ansible module?
I am trying to dynamically populate an inventory group called cloned\_group in my current inventory . I passed the hostnames through the survey by the following names clone\_machine\_1, clone\_machine\_2, clone\_machine\_3. I used the ansible module add\_host.The tasks were executed successfully but I did not see the expected hostnames in my inventory.

```
---
- name: Stage source vm
  hosts: localhost
  gather_facts: false
  vars_files:
    - common-vars.yml
  vars:
    localusername: testlocal

  tasks:
    - name: Add host to the cloned group from the survey list
      ansible.builtin.add_host:
        name: "{{ item }}"
        groups: cloned_group
      with_items:
        - "{{ clone_machine_1 }}"
        - "{{ clone_machine_2 }}"
        - "{{ clone_machine_3 }}"

```

and the output takes the below pattern

```
changed: [localhost] => (item=x.y.s) => {
    "add_host": {
        "groups": [
            "cloned_group"
        ],
        "host_name": "x.y.s",
        "host_vars": {}
    },
    "ansible_loop_var": "item",
    "changed": true,
    "item": "x.y.s"
}

```

# Answer
The add\_host task works as expected. For example (simplified a bit), given the list of the groups

```
  my_groups: [cloned_group]

```

```
    - add_host:
        name: "{{ item }}"
        groups: "{{ my_groups }}"
      loop: [cm_1, cm_2, cm_3]

```

will create the inventory group *cloned\_group*. Let's take a look

```
    - debug:
        var: groups.cloned_group

```

gives as expected

```
  groups.cloned_group:
  - cm_1
  - cm_2
  - cm_3

```

See the special variable group. Quoting:

> A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it

---

<sup>

Example of a complete playbook for testing

```
- hosts: localhost

  vars:

    my_groups: [cloned_group]

  tasks:

    - add_host:
        name: "{{ item }}"
        groups: "{{ my_groups }}"
      loop: [cm_1, cm_2, cm_3]

    - debug:
        var: groups.cloned_group

```
</sup>

---

Q: ***"No hosts added to the cloned\_group in the inventory."***

A: If you by "in the inventory" mean "in the inventory file" then this is correct. No hosts will be added to an inventory file.

For example, given the below inventory file

```
shell> cat hosts
[test]
test_01
test_02
test_03

[test:vars]
ansible_user=admin
ansible_become=true
ansible_python_interpreter=/usr/local/bin/python3.8
ansible_perl_interpreter=/usr/local/bin/perl

```

If you want to update the inventory file:

* Get the path to the file. See the special variable ansible\_inventory\_sources. There might be more files in the list, hence take the first one

```
  my_file: "{{ ansible_inventory_sources.0 }}"

```

gives

```
  my_file: /scratch/tmp1/test-024/hosts

```
* Create the block with your group(s)

```
  my_inventory: |
    {% for group in my_groups %}
    [{{ group }}]
    {% for host in groups[group] %}
    {{ host }}
    {% endfor %}
    {% endfor %}

```

gives

```
  my_inventory: |-
    [cloned_group]
    cm_1
    cm_2
    cm_3

```
* Backup the inventory file

```
    - command:
        cmd: "cp {{ my_file }} {{ my_file }}.backup"
        creates: "{{ my_file }}.backup"

```
* Update the inventory file

```
    - blockinfile:
        path: "{{ my_file }}"
        block: "{{ my_inventory }}"

```

gives what you (probably) want

```
shell> cat hosts
[test]
test_01
test_02
test_03

[test:vars]
ansible_user=admin
ansible_become=true
ansible_python_interpreter=/usr/local/bin/python3.8
ansible_perl_interpreter=/usr/local/bin/perl
# BEGIN ANSIBLE MANAGED BLOCK
[cloned_group]
cm_1
cm_2
cm_3
# END ANSIBLE MANAGED BLOCK

```

---

<sup>

Example of a complete playbook for testing

```
- hosts: localhost

  vars:

    my_file: "{{ ansible_inventory_sources.0 }}"
    my_groups: [cloned_group]
    my_inventory: |
      {% for group in my_groups %}
      [{{ group }}]
      {% for host in groups[group] %}
      {{ host }}
      {% endfor %}
      {% endfor %}

  tasks:

    - add_host:
        name: "{{ item }}"
        groups: "{{ my_groups }}"
      loop: [cm_1, cm_2, cm_3]

    - debug:
        var: groups.cloned_group

    - debug:
        var: ansible_inventory_sources
    - debug:
        var: my_file
    - debug:
        var: my_inventory

    - command:
        cmd: "cp {{ my_file }} {{ my_file }}.backup"
        creates: "{{ my_file }}.backup"

    - blockinfile:
        path: "{{ my_file }}"
        block: "{{ my_inventory }}"

```
</sup>
> 2 votes

---
Tags: ansible
---


title: How to monitor k3s/rancher pods?

text:
# Question
Title: How to monitor k3s/rancher pods?
The problems I'm facing are these pods crash out of nowhere and I'm unable to debug why it happened. How can I monitor them?

# Answer
> 0 votes
Keep a shell open with `watch kubectl get events` and observe the output when pods start/restart.

---
Tags: kubernetes, k3s
---


# Question
Title: How do you get to to the admin area of GitLab?
Ever since Gitlab changed their UI, I can never find out how to get to the admin area? How do you do it?

# Answer
> 0 votes
The UI is bad. And it's getting worse.

```
https://gitlab.acme.net/admin/

```

Is the easy way.

The other more complex way,

* Click on your Gravatar in the Left Bar.
* Click your User Name in the popup menu. This should take you to, https://gitlab.acme.net/myusername
* Click on the far right the profile icon to go to the admin area.

# Answer
> 1 votes
* In the left bar click on `Search or go to...`
* In the dialog click on `Admin Area`

---
Tags: gitlab
---


# Question
Title: How to allow an application outside GCP to consume a GCP Vertex AI endpoint?
A Vertex AI endpoint has been created in the Google Cloud Platform project *gcp-project-A*.

As a devops I want to authorize an external application *outside-gcp-app-B* to consume it. This application is outside GCP (example: Postman).

What is the best way to do it ?

# Answer
> 1 votes
User-manager Service Accounts (SA) are identity that a GCP application can use to run API requests on your behalf.

If you created a custom SA dedicated to the external application and share keys with it (**SA keys never expire**), it should be allowed to consume the Vertex AI endpoint.

Here is a 6-step process:

1. Open a cloud shell console at the top-right  and create a user-managed SA with the following command (need iam.serviceAccounts.create permission)

```
gcloud iam service-accounts create sa-name-app-b \
    --description "Service account dedicated to the external application B to consume Vertex AI endpoint" \
    --display-name "Vertex AI consumption for app B"

```
2. If it does not exist, create a custom role with a *aiplatform.endpoints.predict* permission (need iam.roles.create permission)

```
gcloud iam roles create vaeEndpointConsumer  \
    --project gcp-project-A \
    --title "Vertex AI endpoint consumer" \
    --description "This role is allowed to consume Vertex AI endpoints" \
    --permissions aiplatform.endpoints.predict

```
3. Attach this custom role to the created SA (need iam.serviceAccounts.add-iam-policy-binding permission)

```
gcloud iam service-accounts add-iam-policy-binding sa-name-app-b@gcp-project-A.iam.gserviceaccount.com \
  --member 'serviceAccount:sa-name-app-b@gcp-project-A.iam.gserviceaccount.com' \
  --role 'projects/gcp-project-A/roles/vaeEndpointConsumer'

```
4. Create a private key for the created SA (need iam.serviceAccountKeys.create permission). The resulting private key will be written in a file called *sa\_private\_key.json* in the gcloud console disk

```
gcloud iam service-accounts keys create sa_private_key.json \
    --iam-account sa-name-app-b@gcp-project-A.iam.gserviceaccount.com

```
5. Download key to your desktop and remove it from the gcloud console

```
cloudshell download sa_private_key.json
rm sa_private_key.json

```
6. Securely share *sa\_private\_key.json* to the *outside-gcp-app-B* owner and let it configure authentication with the protocol of its choice (OAuth 2.0 for example)

---
Tags: google-cloud-platform, gcp, api, authentication, iam
---


# Question
Title: Bitbucket REST API to set 'Branch deletion on merge'
I know that 'Branch deletion on merge' can be set at both project and repo level via UI.

What I am looking for the the REST API endpoint for doing this. Similar endpoints for branching model, etc. exist but I could not find an endpoint for setting 'Branch deletion on merge' at project level.

Using Atlassian Bitbucket v7.17.1

# Answer
You have `/rest/branch-utils/latest/projects/{project_key}/delete-after-merge`
> 0 votes

---
Tags: bitbucket, bitbucket-server
---


# Question
Title: Jenkin "unable to find valid certification path to requested target" getting error while installing plugin
We are trying to set up jenkins. When we trying to install plugin getting the below error. We also tried to import the trusted certificate into the JVM directly still getting same error.

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Can anyone please suggest me solution?

# Answer
I was able to get round the certificate error by downloading the skip-certificate-check plugin to my laptop and manually installing it in the `Deploy Plugin` section in the Jenkins UI (at `/manage/pluginManager/advanced`). This is just for a development instance though, for a production instance you're probably better following some of the other suggestions for fixing certificate issues properly.
> 0 votes

---
Tags: jenkins, jenkins-pipeline, jenkins-plugins, installation, jenkins-blueocean
---


# Question
Title: Using route and proxy with a NGINX virtualserver K8s config
I have a kinda weird set up where I have a general url(www.example.com) that terminates on an F5 that points to a nginx VS on an EKS cluster that has a localized domain(www.ue1.example.com).

So the flow is user --\>\> www.example.com --\> F5 --\> F5 xforwards host header of www.ue1.example.com --\> nginx vs --\> web service that is licenses for www.example.com.

nginx needs a host of www.ue1.example.com but then convert it to www.example.com before sending it to the web service.

So is there a way to route to a virtulserverroute AND proxy the host header as well. Here are the relevant configs. Not sure where to put the proxy information.

```
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: example
spec:
  host: example.ue1.eexchange.com
  routes:
    - path: /
      route: example/example

apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
  name: example
spec:
  upstreams:
    - name: example-service
      service: example
      port: 80
  subroutes:
    - path: /
      action:
        pass: example-service

```

# Answer
> 0 votes
The solution was to apply this to the vsr.

```
  subroutes:
    - path: /
      action:
        proxy:
          upstream: example-service
          requestHeaders:
            set:
            - name: Host
              value: <target fqdn>
            - name: Origin
              value: http://<target fqdn>

```

---
Tags: kubernetes, ingress-nginx
---


# Question
Title: metrics-server on EKS - no metrics to server
I am attempting to setup metrics-server to server my 'horizon pod autoscaling' and manage my app pods scaling based on CPU. I am unable to get the metrics-server to run properly which fails with **Failed probe" probe="metric-storage-ready" err="no metrics to serve**. You can tell I am using EKS and managing the cluster using Terraform. Can anyone offer any insights?

```
Versions
  - EKS 1.27
  - Helm 3.12.0

```

This is my terraform script showing this specific piece of my cluster:

```
resource "kubernetes_namespace" "metric-server" {
  metadata {
    name = "${var.cluster_name}-metric-server"
  }
}

resource "helm_release" "metric_server" {
  name       = "metric-server"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "metric-server"
  namespace  = "${var.cluster_name}-metric-server"

  values = [
    "${file("./values/metrics-server.yaml")}"
  ]
}

```

The contents of ./values/metrics-server.yaml as follows.

```
spec:
  containers:
  - arg:
      - --metric-resolution=18s

```

This is my cluster (kube-system)

```
kubectl get po -n kube-system
NAME                                  READY   STATUS    RESTARTS       AGE
NAMESPACE                 NAME                                     READY   STATUS      RESTARTS        AGE
default                   reloader-reloader-7568f766fb-mkdzh       1/1     Running     0               3d8h
kube-system               aws-node-8w7lc                           2/2     Running     0               4d5h
kube-system               aws-node-927jv                           2/2     Running     0               4d5h
kube-system               aws-node-hhj66                           2/2     Running     0               4d5h
kube-system               aws-node-hpb57                           2/2     Running     0               4d5h
kube-system               aws-node-ng7nc                           2/2     Running     0               4d5h
kube-system               coredns-79b5589f65-fb64k                 1/1     Running     0               52d
kube-system               coredns-79b5589f65-fkkrw                 1/1     Running     0               52d
kube-system               ebs-csi-controller-77fcc9d855-55555      6/6     Running     9 (3d8h ago)    21d
kube-system               ebs-csi-controller-77fcc9d855-crrrr      6/6     Running     0               21d
kube-system               ebs-csi-node-d2qsw                       3/3     Running     0               21d
kube-system               ebs-csi-node-flw5z                       3/3     Running     0               21d
kube-system               ebs-csi-node-p5r5n                       3/3     Running     0               21d
kube-system               ebs-csi-node-tmdzd                       3/3     Running     0               21d
kube-system               ebs-csi-node-xpq88                       3/3     Running     0               21d
kube-system               efs-csi-controller-6f7f5f5787-ccccc      3/3     Running     0               52d
kube-system               efs-csi-controller-6f7f5f5787-xxxxx      3/3     Running     0               52d
kube-system               efs-csi-node-7zgx2                       3/3     Running     0               52d
kube-system               efs-csi-node-8hcmx                       3/3     Running     0               52d
kube-system               efs-csi-node-mhr9m                       3/3     Running     0               21d
kube-system               efs-csi-node-mzbfq                       3/3     Running     0               52d
kube-system               efs-csi-node-w859z                       3/3     Running     0               21d
kube-system               kube-proxy-28s6c                         1/1     Running     0               52d
kube-system               kube-proxy-4fjdc                         1/1     Running     0               21d
kube-system               kube-proxy-h47q6                         1/1     Running     0               52d
kube-system               kube-proxy-h5sjf                         1/1     Running     0               21d
kube-system               kube-proxy-pg5fx                         1/1     Running     0               52d
kube-system               metrics-server-5b787c6cf8-21356          1/1     Running     0               6h40m
dev-opensearch            opensearch-cluster-master-0              1/1     Running     0               52d
dev-opensearch            opensearch-cluster-master-1              1/1     Running     0               52d
dev-opensearch            opensearch-cluster-master-2              1/1     Running     0               52d
dev-rabbitmq              rabbitmq-0                               1/1     Running     0               9d
dev-rabbitmq              rabbitmq-1                               1/1     Running     0               9d
dev-rabbitmq              rabbitmq-2                               1/1     Running     0               9d
dev-redis                 redis-master-0                           1/1     Running     0               10d
dev-redis                 redis-replicas-0                         1/1     Running     0               3d8h
dev-redis                 redis-replicas-1                         1/1     Running     0               3d8h
dev-app                   app-app-enterprise-0                     2/2     Running     0               3d8h
dev-app                   app-app-enterprise-1                     2/2     Running     0               3d8h
dev                       example-97f846598-hl6cc                  1/1     Running     0               28h
dev                       example-cron-28418300-d6xmw              0/1     Completed   0               12m
dev                       example-cron-28418305-c9hhj              0/1     Completed   0               7m4s
dev                       example-cron-28418310-chbfl              0/1     Completed   0               2m4s
dev                       example-post-upgrade-hlpmg               0/1     Completed   0               32h
dev                       ubuntu                                   1/1     Running     1 (3d11h ago)   10d
zero-trust                cloudflared-65bcdff7c6-gnp29             1/1     Running     0               2d13h
zero-trust                cloudflared-65bcdff7c6-grnmw             1/1     Running     0               2d13h

```

This is my hpa:

```
kubectl get hpa --all-namespaces
NAMESPACE   NAME      REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
dev      example   Deployment/example   <unknown>/25%   1         11        1          24h

```

When I check my cluster logs:

```
kubectl describe hpa --all-namespaces
Name:                                                  example
Namespace:                                             dev
Labels:                                                app.kubernetes.io/instance=example
                                                       app.kubernetes.io/managed-by=Helm
                                                       app.kubernetes.io/name=example
                                                       helm.sh/chart=example-23.0.1
Annotations:                                           meta.helm.sh/release-name: example
                                                       meta.helm.sh/release-namespace: dev
CreationTimestamp:                                     Thu, 11 Jan 2024 17:57:10 +0000
Reference:                                             Deployment/example
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 25%
Min replicas:                                          1
Max replicas:                                          11
Deployment pods:                                       1 current / 0 desired
Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)
Events:
  Type     Reason                   Age                   From                       Message
  ----     ------                   ----                  ----                       -------
  Warning  FailedGetResourceMetric  19s (x5776 over 24h)  horizontal-pod-autoscaler  failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io)

```

metrics-server logs:

```
kubectl logs deployment/metrics-server -n kube-system
I0112 15:51:32.519856       1 serving.go:342] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
I0112 15:51:32.996832       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I0112 15:51:32.996894       1 shared_informer.go:240] Waiting for caches to sync for RequestHeaderAuthRequestController
I0112 15:51:32.996976       1 configmap_cafile_content.go:201] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::client-ca-file"
I0112 15:51:32.997058       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0112 15:51:32.997119       1 configmap_cafile_content.go:201] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
I0112 15:51:32.997164       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0112 15:51:32.997877       1 dynamic_serving_content.go:131] "Starting controller" name="serving-cert::apiserver.local.config/certificates/apiserver.crt::apiserver.local.config/certificates/apiserver.key"
I0112 15:51:32.998109       1 secure_serving.go:267] Serving securely on [::]:8443
I0112 15:51:32.998136       1 tlsconfig.go:240] "Starting DynamicServingCertificateController"
W0112 15:51:33.000474       1 shared_informer.go:372] The sharedIndexInformer has started, run more than once is not allowed
I0112 15:51:33.002798       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:51:33.097938       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0112 15:51:33.097937       1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController
I0112 15:51:33.097969       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0112 15:51:33.939463       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:51:37.866094       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:51:47.866103       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:51:57.866445       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:52:07.867043       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:52:17.865920       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"
I0112 15:52:27.866276       1 server.go:187] "Failed probe" probe="metric-storage-ready" err="no metrics to serve"

```

Further queries yield no metrics

```
kubectl top pod -A
error: Metrics API not available
kubectl top pods -n kube-system
error: Metrics API not available

```

Checking the metrics API, shows nothing:

```
$kubectl api-versions | grep metrics
external.metrics.k8s.io/v1beta1

```

# Answer
I resolved this by using a different helm chart. I believe my original problem was caused by a version incompatibility.

```
resource "helm_release" "metrics_server" {
  name       = "metrics-server"
  repository = "https://kubernetes-sigs.github.io/metrics-server"
  chart      = "metrics-server"
  namespace  = "kube-system"
}

```
> 0 votes

---
Tags: kubernetes, terraform, helm, eks
---


# Question
Title: Test reports for Gitlab CI when multiple modules exist
I am trying to setup build scripts for Gitlab CI for a Java/ project with Gradle. The project has three different modules `A`, `B` and `C`, with modules `B` and `C` being dependent on the module `A`.

All three have a build.gradle file and unit tests inside them. There is also a build.gradle file in the root of the project. I am trying to have test reports available in GitLab CI when a new push is made. I managed to have the test executed with ease by executing the `check` gradle command with a script similar to this one:

```
test:
  stage: test
  script:
    - ./gradlew check

```

THis, however, does not provide any test reports. In the logs I only see something like this:

```
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :compileJava NO-SOURCE
> Task :processResources NO-SOURCE
> Task :classes UP-TO-DATE
> Task :compileTestJava NO-SOURCE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE
> Task :test NO-SOURCE
> Task :check UP-TO-DATE
> Task :A:compileJava
> Task :A:processResources NO-SOURCE
> Task :A:classes
> Task :A:jar
> Task :B:compileJava
> Task :B:processResources NO-SOURCE
> Task :B2:classes
> Task :B:compileTestJava
> Task :B:processTestResources
> Task :B:testClasses
> Task :B:test
> Task :B:check
> Task :A:compileTestJava
> Task :Ar:processTestResources NO-SOURCE
> Task :A:testClasses
> Task :A:test
> Task :A:check
BUILD SUCCESSFUL in 42s

```

It is good that the build fails if the test fails, but I don't have any indication to what tests were executed, what tests failed or any other information.

Can anyone help with some resources or hints on how to solve this.

# Answer
> 1 votes
The Ci.CD pipeline allows having a list of artifacts:

```
test:
  stage: test
  script:
    - ./gradlew test
  artifacts:
    when: always
    reports:
      junit:
        - a/build/test-results/test/**/TEST-*.xml
        - b/build/test-results/test/**/TEST-*.xml
        - c/build/test-results/test/**/TEST-*.xml

```

# Answer
> 0 votes
You can use following to capture test results from all submodules:

```
  artifacts:
    when: always
    reports:
      junit: "**/build/test-results/test/**/TEST-*.xml"

```

---
Tags: gitlab, gitlab-ci-runner
---


# Question
Title: Github Actions : Reusable workflow across multiple organizations
I have a query in regards with Github workflows.

Consider the below scenario :

* Github Organization 1 : **sample\_one**
* Github Organization 2 : **sample\_two**
* sample\_one organization has one repository called : **one\_repo**
* sample\_two organization has one repository called : **two\_repo**

**Problem Statement :**

one\_repo has a reusable workflow that needs to be called by two\_repo (that is in different organization) - How do I do this?

Note :

The reusable workflow from one\_repo maybe updated from time to time.

Can someone help me with the workflow calls for the same as to how can a repo from some other organization be able to call the resuable workflow from another organization.

# Answer
First, you must permit the reusable workflow to be called from another organization.
For that, go to *Organization settings -\> Actions -\> General*. Under the policies, select the "**Allow all actions and reusable workflows**" option to use the workflow outside the organization.

**NOTE**: You have to keep the repositories public so that the other organizations can access them.

**Now to the work:**

1. Create a reusable workflow in the GitHub Organization 1: ***sample\_one***.
2. Now create a trigger workflow in ***two\_repo*** to call the workflow in ***one\_repo*** under ***sample\_one*** organization.
3. Now add the trigger parameter under the ***jobs*** section inside the workflow and mention the reusable workflow of ***one\_repo***.

```
name: Scan, Build and Deploy
on:
  push:
    branches: [ "main" ]

jobs:
  trigger:
    uses: sample_one/one_repo/.github/workflows/reusable-workflow.yml@main

```

Edit the following line according to the location of the reusable workflow.

That's it! So when the workflow runs in the ***two\_repo***, the reusable workflow in the ***one\_repo*** will be used.
> 0 votes

---
Tags: cicd, github, build-pipeline, github-actions
---


# Question
Title: Need to understand the career path for DevOps
I am a frontend developer, planning to gain hands on experience in DevOps. However, I'm not sure of if only DevOps or DevSecOps.

Recently I tried learning Jenkins while last year took an Udemy course on AWS. I am pretty much aware of Shared hosting & have practical experience on this.

My question is what career/learning path I should choose?

# Answer
> 1 votes
Given your background as a front-end developer with experience in Jenkins and AWS, you already have a good foundation.

For a career path in **DevOps**, you can consider the following steps:

* **Continue with Jenkins**: Since you've already started learning Jenkins, deepen your knowledge and explore advanced features. Jenkins is a widely used automation tool in the DevOps ecosystem.
* **AWS Skills**: Continue building on your AWS skills. Understanding cloud services is crucial in a DevOps role, and AWS is a prominent cloud platform.
* **Learn Version Control**: Familiarize yourself with version control systems like Git. Proficiency in Git is essential for collaborative development and continuous integration.
* **Containerization**: Explore containerization technologies like Docker. Containerization is a fundamental aspect of modern DevOps practices.
* **Infrastructure as Code (IaC)**: Learn Infrastructure as Code tools like Terraform or AWS CloudFormation. This helps in managing and provisioning infrastructure in an automated and scalable way.
* **Continuous Integration/Continuous Deployment (CI/CD)**: Build on your Jenkins knowledge to understand and implement CI/CD pipelines. This is a key aspect of DevOps, ensuring continuous delivery and deployment.

**DevSecOps** stands for development, security, and operations. It is an extension of the DevOps practice. Each term defines different roles and responsibilities of software teams when they are building software applications. Some of the skill sets that you need to incorporate to achieve this through the DevOps process are:

* **Security Fundamentals**: Gain a solid understanding of security fundamentals, including threat modeling and risk assessment.
* **Security in CI/CD**: Learn about integrating security checks into the CI/CD pipeline. Tools like SonarQube or Checkmarx can help in static code analysis.
* **Container Security**: Understand how to secure containers, especially if you're using Docker. Learn about tools like Clair for vulnerability scanning.
* **Infrastructure Security**: Extend your knowledge to secure infrastructure as code. This involves implementing security measures in your IaC scripts.
* **Compliance and Auditing**: Learn about compliance standards and how to implement auditing in your DevOps processes.

Ultimately, the choice between DevOps and DevSecOps depends on your interests. DevSecOps is gaining prominence as organizations prioritize security throughout the development lifecycle. You can learn more about the path and the platforms that you need to learn in Roadmap.sh

# Answer
> 1 votes
DevOps is more than just a CI/CD tool. A really important aspect is culture. If you would google you can find a lot of information about that. Regarding the technical knowledge, it could be a good idea to take a look at https://roadmap.sh/devops, or in your case maybe the beginners version: https://roadmap.sh/devops?r=devops-beginner. But notice that everyone's path is different. The roadmap really focuses on the linux/docker stack ecosystem, while my current customer is a Microsoft house, meaning that my knowledge of PowerShell, C# and Bicep is really useful. Good luck and please ask for more details if needed.

---
Tags: jenkins, amazon-web-services, azure-devops, azure, devsecops
---


# Question
Title: Unable to connect to my EventStore docker container
This is my first attempt at setting up docker containers. I've managed to create a SQL Server container that I can connect to, but I've been struggling for more than a month to get my EventStore connected.

The site only provides instructions for a Linux image, so I had to create my own. I downloaded Eventstore, and created my image with this command :

`docker build -t eventstore_5.0.10:latest .`

I then created docker-compose.yaml with this configuration :

```
version: '3.4'

services:
  eventstore.db:
    image: eventstore/eventstore:release-v5
    environment:
      - EVENTSTORE_CLUSTER_SIZE=1
      - EVENTSTORE_RUN_PROJECTIONS=All
      - EVENTSTORE_START_STANDARD_PROJECTIONS=True
      - EVENTSTORE_DB=/var/lib/eventstore-data
      - EVENTSTORE_INDEX=/var/lib/eventstore-index
      - EVENTSTORE_LOG=/var/log/eventstore
      - EVENTSTORE_EXT_TCP_PORT=1113
      - EVENTSTORE_EXT_HTTP_PORT=2113
    ports:
      - "1113:1113"
      - "2113:2113"
    volumes:
      - type: volume
        source: eventstore-volume-data
        target: /var/lib/eventstore-data
      - type: volume
        source: eventstore-volume-index
        target: /var/lib/eventstore-index
      - type: volume
        source: eventstore-volume-logs
        target: /var/log/eventstore

volumes:
  eventstore-volume-data:
  eventstore-volume-index:
  eventstore-volume-logs:

```

When I spin up the container, EventStore starts up fine :

```
[01288,01,07:43:33.783]
2024-01-15 09:43:33 "ES VERSION:"             "5.0.10.0" ("oss-v5.0.10"/"6b9af2bc4fcd85c12c01fb115110ff6ccc5d3bfd", "Thu, 11 Mar 2021 14:39:
2024-01-15 09:43:33 08 +0100")
2024-01-15 09:43:33 MODIFIED OPTIONS:
2024-01-15 09:43:33
2024-01-15 09:43:33         EXT HTTP PORT:            2114 (Command Line)
2024-01-15 09:43:33         EXT TCP PORT:             1114 (Command Line)
2024-01-15 09:43:33
2024-01-15 09:43:33 DEFAULT OPTIONS:
2024-01-15 09:43:33
2024-01-15 09:43:33         HELP:                     False (<DEFAULT>)
2024-01-15 09:43:33         VERSION:                  False (<DEFAULT>)
2024-01-15 09:43:33         LOG:                      C:\EventStore\logs (<DEFAULT>)
2024-01-15 09:43:33         CONFIG:                   <empty> (<DEFAULT>)
2024-01-15 09:43:33         DEFINES:                  <empty> (<DEFAULT>)
2024-01-15 09:43:33         WHAT IF:                  False (<DEFAULT>)
2024-01-15 09:43:33         START STANDARD PROJECTIONS: False (<DEFAULT>)
2024-01-15 09:43:33         DISABLE HTTP CACHING:     False (<DEFAULT>)
2024-01-15 09:43:33         MONO MIN THREADPOOL SIZE: 10 (<DEFAULT>)
2024-01-15 09:43:33         INT IP:                   127.0.0.1 (<DEFAULT>)
2024-01-15 09:43:33         EXT IP:                   127.0.0.1 (<DEFAULT>)
2024-01-15 09:43:33         INT HTTP PORT:            2112 (<DEFAULT>)
2024-01-15 09:43:33         INT TCP PORT:             1112 (<DEFAULT>)
2024-01-15 09:43:33         INT SECURE TCP PORT:      0 (<DEFAULT>)
2024-01-15 09:43:33         EXT SECURE TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         EXT SECURE TCP PORT:      0 (<DEFAULT>)
2024-01-15 09:43:33         EXT IP ADVERTISE AS:      <empty> (<DEFAULT>)
2024-01-15 09:43:33         EXT TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         EXT HTTP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         INT IP ADVERTISE AS:      <empty> (<DEFAULT>)
2024-01-15 09:43:33         INT SECURE TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         INT TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         INT HTTP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:43:33         INT TCP HEARTBEAT TIMEOUT: 700 (<DEFAULT>)
2024-01-15 09:43:33         EXT TCP HEARTBEAT TIMEOUT: 1000 (<DEFAULT>)
2024-01-15 09:43:33         INT TCP HEARTBEAT INTERVAL: 700 (<DEFAULT>)
2024-01-15 09:43:33         EXT TCP HEARTBEAT INTERVAL: 2000 (<DEFAULT>)
2024-01-15 09:43:33         GOSSIP ON SINGLE NODE:    False (<DEFAULT>)
2024-01-15 09:43:33         CONNECTION PENDING SEND BYTES THRESHOLD: 10485760 (<DEFAULT>)
2024-01-15 09:43:33         CONNECTION QUEUE SIZE THRESHOLD: 50000 (<DEFAULT>)
2024-01-15 09:43:33         STREAM INFO CACHE CAPACITY: 100000 (<DEFAULT>)
2024-01-15 09:43:33         FORCE:                    False (<DEFAULT>)
2024-01-15 09:43:33         CLUSTER SIZE:             1 (<DEFAULT>)
2024-01-15 09:43:33         NODE PRIORITY:            0 (<DEFAULT>)
2024-01-15 09:43:33         MIN FLUSH DELAY MS:       2 (<DEFAULT>)
2024-01-15 09:43:33         COMMIT COUNT:             -1 (<DEFAULT>)
2024-01-15 09:43:33         PREPARE COUNT:            -1 (<DEFAULT>)
2024-01-15 09:43:33         ADMIN ON EXT:             True (<DEFAULT>)
2024-01-15 09:43:33         STATS ON EXT:             True (<DEFAULT>)
2024-01-15 09:43:33         GOSSIP ON EXT:            True (<DEFAULT>)
2024-01-15 09:43:33         DISABLE SCAVENGE MERGING: False (<DEFAULT>)
2024-01-15 09:43:33         SCAVENGE HISTORY MAX AGE: 30 (<DEFAULT>)
2024-01-15 09:43:33         DISCOVER VIA DNS:         True (<DEFAULT>)
2024-01-15 09:43:33         CLUSTER DNS:              fake.dns (<DEFAULT>)
2024-01-15 09:43:33         CLUSTER GOSSIP PORT:      30777 (<DEFAULT>)
2024-01-15 09:43:33         GOSSIP SEED:              <empty> (<DEFAULT>)
2024-01-15 09:43:33         STATS PERIOD SEC:         30 (<DEFAULT>)
2024-01-15 09:43:33         CACHED CHUNKS:            -1 (<DEFAULT>)
2024-01-15 09:43:33         READER THREADS COUNT:     4 (<DEFAULT>)
2024-01-15 09:43:33         CHUNKS CACHE SIZE:        536871424 (<DEFAULT>)
2024-01-15 09:43:33         MAX MEM TABLE SIZE:       1000000 (<DEFAULT>)
2024-01-15 09:43:33         HASH COLLISION READ LIMIT: 100 (<DEFAULT>)
2024-01-15 09:43:33         DB:                       C:\EventStore\data (<DEFAULT>)
2024-01-15 09:43:33         INDEX:                    <empty> (<DEFAULT>)
2024-01-15 09:43:33         MEM DB:                   False (<DEFAULT>)
2024-01-15 09:43:33         SKIP DB VERIFY:           False (<DEFAULT>)
2024-01-15 09:43:33         WRITE THROUGH:            False (<DEFAULT>)
2024-01-15 09:43:33         UNBUFFERED:               False (<DEFAULT>)
2024-01-15 09:43:33         CHUNK INITIAL READER COUNT: 5 (<DEFAULT>)
2024-01-15 09:43:33         RUN PROJECTIONS:          None (<DEFAULT>)
2024-01-15 09:43:33         PROJECTION THREADS:       3 (<DEFAULT>)
2024-01-15 09:43:33         WORKER THREADS:           5 (<DEFAULT>)
2024-01-15 09:43:33         PROJECTIONS QUERY EXPIRY: 5 (<DEFAULT>)
"024-01-15 09:43:33         FAULT OUT OF ORDER PROJECTIONS: False (<DEFAULT>)
2024-01-15 09:43:33         INT HTTP PREFIXES:        <empty> (<DEFAULT>)
2024-01-15 09:43:33         EXT HTTP PREFIXES:        <empty> (<DEFAULT>)
2024-01-15 09:43:33         ENABLE TRUSTED AUTH:      False (<DEFAULT>)
2024-01-15 09:43:33         ADD INTERFACE PREFIXES:   True (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE STORE LOCATION: <empty> (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE STORE NAME:   <empty> (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE SUBJECT NAME: <empty> (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE THUMBPRINT:   <empty> (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE FILE:         <empty> (<DEFAULT>)
2024-01-15 09:43:33         CERTIFICATE PASSWORD:     <empty> (<DEFAULT>)
[01284,01,07:45:54.938]
2024-01-15 09:45:55 "ES VERSION:"             "5.0.10.0" ("oss-v5.0.10"/"6b9af2bc4fcd85c12c01fb115110ff6ccc5d3bfd", "Thu, 11 Mar 2021 14:39:
2024-01-15 09:45:55 08 +0100")
2024-01-15 09:45:55 MODIFIED OPTIONS:
2024-01-15 09:45:55
2024-01-15 09:45:55         EXT HTTP PORT:            2114 (Command Line)
2024-01-15 09:45:55         EXT TCP PORT:             1114 (Command Line)
2024-01-15 09:45:55
2024-01-15 09:45:55 DEFAULT OPTIONS:
2024-01-15 09:45:55
2024-01-15 09:45:55         HELP:                     False (<DEFAULT>)
2024-01-15 09:45:55         VERSION:                  False (<DEFAULT>)
2024-01-15 09:45:55         LOG:                      C:\EventStore\logs (<DEFAULT>)
2024-01-15 09:45:55         CONFIG:                   <empty> (<DEFAULT>)
2024-01-15 09:45:55         DEFINES:                  <empty> (<DEFAULT>)
2024-01-15 09:45:55         WHAT IF:                  False (<DEFAULT>)
2024-01-15 09:45:55         START STANDARD PROJECTIONS: False (<DEFAULT>)
2024-01-15 09:45:55         DISABLE HTTP CACHING:     False (<DEFAULT>)
2024-01-15 09:45:55         MONO MIN THREADPOOL SIZE: 10 (<DEFAULT>)
2024-01-15 09:45:55         INT IP:                   127.0.0.1 (<DEFAULT>)
2024-01-15 09:45:55         EXT IP:                   127.0.0.1 (<DEFAULT>)
2024-01-15 09:45:55         INT HTTP PORT:            2112 (<DEFAULT>)
2024-01-15 09:45:55         INT TCP PORT:             1112 (<DEFAULT>)
2024-01-15 09:45:55         INT SECURE TCP PORT:      0 (<DEFAULT>)
2024-01-15 09:45:55         EXT SECURE TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         EXT SECURE TCP PORT:      0 (<DEFAULT>)
2024-01-15 09:45:55         EXT IP ADVERTISE AS:      <empty> (<DEFAULT>)
2024-01-15 09:45:55         EXT TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         EXT HTTP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         INT IP ADVERTISE AS:      <empty> (<DEFAULT>)
2024-01-15 09:45:55         INT SECURE TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         INT TCP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         INT HTTP PORT ADVERTISE AS: 0 (<DEFAULT>)
2024-01-15 09:45:55         INT TCP HEARTBEAT TIMEOUT: 700 (<DEFAULT>)
2024-01-15 09:45:55         EXT TCP HEARTBEAT TIMEOUT: 1000 (<DEFAULT>)
2024-01-15 09:45:55         INT TCP HEARTBEAT INTERVAL: 700 (<DEFAULT>)
2024-01-15 09:45:55         EXT TCP HEARTBEAT INTERVAL: 2000 (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP ON SINGLE NODE:    False (<DEFAULT>)
2024-01-15 09:45:55         CONNECTION PENDING SEND BYTES THRESHOLD: 10485760 (<DEFAULT>)
2024-01-15 09:45:55         CONNECTION QUEUE SIZE THRESHOLD: 50000 (<DEFAULT>)
2024-01-15 09:45:55         STREAM INFO CACHE CAPACITY: 100000 (<DEFAULT>)
2024-01-15 09:45:55         FORCE:                    False (<DEFAULT>)
2024-01-15 09:45:55         CLUSTER SIZE:             1 (<DEFAULT>)
2024-01-15 09:45:55         NODE PRIORITY:            0 (<DEFAULT>)
2024-01-15 09:45:55         MIN FLUSH DELAY MS:       2 (<DEFAULT>)
2024-01-15 09:45:55         COMMIT COUNT:             -1 (<DEFAULT>)
2024-01-15 09:45:55         PREPARE COUNT:            -1 (<DEFAULT>)
2024-01-15 09:45:55         ADMIN ON EXT:             True (<DEFAULT>)
2024-01-15 09:45:55         STATS ON EXT:             True (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP ON EXT:            True (<DEFAULT>)
2024-01-15 09:45:55         DISABLE SCAVENGE MERGING: False (<DEFAULT>)
2024-01-15 09:45:55         SCAVENGE HISTORY MAX AGE: 30 (<DEFAULT>)
2024-01-15 09:45:55         DISCOVER VIA DNS:         True (<DEFAULT>)
2024-01-15 09:45:55         CLUSTER DNS:              fake.dns (<DEFAULT>)
2024-01-15 09:45:55         CLUSTER GOSSIP PORT:      30777 (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP SEED:              <empty> (<DEFAULT>)
2024-01-15 09:45:55         STATS PERIOD SEC:         30 (<DEFAULT>)
2024-01-15 09:45:55         CACHED CHUNKS:            -1 (<DEFAULT>)
2024-01-15 09:45:55         READER THREADS COUNT:     4 (<DEFAULT>)
2024-01-15 09:45:55         CHUNKS CACHE SIZE:        536871424 (<DEFAULT>)
2024-01-15 09:45:55         MAX MEM TABLE SIZE:       1000000 (<DEFAULT>)
2024-01-15 09:45:55         HASH COLLISION READ LIMIT: 100 (<DEFAULT>)
2024-01-15 09:45:55         DB:                       C:\EventStore\data (<DEFAULT>)
2024-01-15 09:45:55         INDEX:                    <empty> (<DEFAULT>)
2024-01-15 09:45:55         MEM DB:                   False (<DEFAULT>)
2024-01-15 09:45:55         SKIP DB VERIFY:           False (<DEFAULT>)
2024-01-15 09:45:55         WRITE THROUGH:            False (<DEFAULT>)
2024-01-15 09:45:55         UNBUFFERED:               False (<DEFAULT>)
2024-01-15 09:45:55         CHUNK INITIAL READER COUNT: 5 (<DEFAULT>)
2024-01-15 09:45:55         RUN PROJECTIONS:          None (<DEFAULT>)
2024-01-15 09:45:55         PROJECTION THREADS:       3 (<DEFAULT>)
2024-01-15 09:45:55         WORKER THREADS:           5 (<DEFAULT>)
2024-01-15 09:45:55         PROJECTIONS QUERY EXPIRY: 5 (<DEFAULT>)
i024-01-15 09:45:55         FAULT OUT OF ORDER PROJECTIONS: False (<DEFAULT>)
2024-01-15 09:45:55         INT HTTP PREFIXES:        <empty> (<DEFAULT>)
2024-01-15 09:45:55         EXT HTTP PREFIXES:        <empty> (<DEFAULT>)
2024-01-15 09:45:55         ENABLE TRUSTED AUTH:      False (<DEFAULT>)
2024-01-15 09:45:55         ADD INTERFACE PREFIXES:   True (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE STORE LOCATION: <empty> (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE STORE NAME:   <empty> (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE SUBJECT NAME: <empty> (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE THUMBPRINT:   <empty> (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE FILE:         <empty> (<DEFAULT>)
2024-01-15 09:45:55         CERTIFICATE PASSWORD:     <empty> (<DEFAULT>)
2024-01-15 09:45:55         USE INTERNAL SSL:         False (<DEFAULT>)
[024-01-15 09:45:55         DISABLE INSECURE TCP:     False (<DEFAULT>)
2024-01-15 09:45:55         SSL TARGET HOST:          n/a (<DEFAULT>)
2024-01-15 09:45:55         SSL VALIDATE SERVER:      True (<DEFAULT>)
2024-01-15 09:45:55         AUTHENTICATION TYPE:      internal (<DEFAULT>)
2024-01-15 09:45:55         AUTHENTICATION CONFIG:    <empty> (<DEFAULT>)
2024-01-15 09:45:55         DISABLE FIRST LEVEL HTTP AUTHORIZATION: False (<DEFAULT>)
2024-01-15 09:45:55         PREPARE TIMEOUT MS:       2000 (<DEFAULT>)
2024-01-15 09:45:55         COMMIT TIMEOUT MS:        2000 (<DEFAULT>)
2024-01-15 09:45:55         UNSAFE DISABLE FLUSH TO DISK: False (<DEFAULT>)
2024-01-15 09:45:55         BETTER ORDERING:          False (<DEFAULT>)
2024-01-15 09:45:55         UNSAFE IGNORE HARD DELETE: False (<DEFAULT>)
2024-01-15 09:45:55         SKIP INDEX VERIFY:        False (<DEFAULT>)
2024-01-15 09:45:55         INDEX CACHE DEPTH:        16 (<DEFAULT>)
2024-01-15 09:45:55         OPTIMIZE INDEX MERGE:     False (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP INTERVAL MS:       1000 (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP ALLOWED DIFFERENCE MS: 60000 (<DEFAULT>)
2024-01-15 09:45:55         GOSSIP TIMEOUT MS:        500 (<DEFAULT>)
[01284,01,07:45:55.891] Opened ongoing "C:\EventStore\data\chunk-000000.000000" as version 3 "0","IntHttpPortAdvertiseAs
[01284,01,07:45:55.906] CACHED TFChunk #0-0 (chunk-000000.000000) in 00:00:00.0047455.
[01284,01,07:45:56.208] Starting MiniWeb for "/web/es/js/projections" ==> "C:\EventStore\projections"
[01284,01,07:45:56.208] Starting MiniWeb for "/web/es/js/projections/v8/Prelude" ==> "C:\EventStore\Prelude"
2024-01-15 09:45:56 [01284,01,07:45:56.224] Starting MiniWeb for "/web" ==> "C:\EventStore\clusternode-web"
2024-01-15 09:45:56 [01284,01,07:45:56.224] Binding MiniWeb to "/web/{*remaining_path}"
2024-01-15 09:45:56 [01284,10,07:45:56.224] ========== [127.0.0.1:2112] SYSTEM INIT...
[01284,11,07:45:56.224] TableIndex initialization...
2024-01-15 09:45:56 [01284,10,07:45:56.239] Starting "Normal" TCP listening on TCP endpoint: 127.0.0.1:1114.
[01284,11,07:45:56.255] ReadIndex building...
[01284,10,07:45:56.271] Starting HTTP server on ["http://localhost:2114/,http://127.0.0.1:2114/"]...
2024-01-15 09:45:56 df60f5a835d}](L=2413,W=18903,C=18903,E3@2191:{5d193532-91ce-4d8f-8fc2-5fd0fb67c25a})".
[01284,06,07:49:45.474] Segments count: 1, buffers count: 20, should be when full: 20 TE, WAITING FOR CHASER TO CATCH UP...
2024-01-15 09:45:56 [01284,10,07:45:56.333] ========== [127.0.0.1:2112] IS MASTER... SPARTA!
2024-01-15 09:45:56 [01284,05,07:45:56.333] Persistent subscriptions received state change to PreMaster. Stopping listening
2024-01-15 09:45:56 [01284,10,07:45:56.333] Searching for incomplete scavenges on node "127.0.0.1:2114".
2024-01-15 09:45:56 [01284,05,07:45:56.333] Persistent subscriptions Became Master so now handling subscriptions
[01284,08,07:45:56.364] === Writing E4@18903:{e90dcaee-48f5-4147-a3c7-f51867b47158} (previous epoch at 2191).
2024-01-15 09:45:56 [01284,10,07:45:56.364] Max age and $ops read permission already set for the "$scavenges" stream.
2024-01-15 09:45:56 [01284,10,07:45:56.364] No incomplete scavenges found on node "127.0.0.1:2114".
2024-01-15 09:45:56 [01284,13,07:45:56.364] PROJECTIONS: Starting Projections Core Coordinator. (Node State : Master)
2024-01-15 09:45:56 [01284,13,07:45:56.364] PROJECTIONS: Starting Projections Manager. (Node State : Master)
2024-01-15 09:45:56 [01284,13,07:45:56.364] PROJECTIONS: Resetting Worker Writer
2024-01-15 09:45:56 [01284,10,07:45:56.364] ========== [127.0.0.1:2112] Sub System '"Projections"' initialized.
2024-01-15 09:45:56 [01284,13,07:45:56.364] PROJECTIONS: SubComponent Started: "EventReaderCoreService"
2024-01-15 09:45:56 [01284,08,07:45:56.364] === Update Last Epoch E4@18903:{e90dcaee-48f5-4147-a3c7-f51867b47158} (previous epoch at 2191).
[01284,05,07:45:56.896] Created stats stream '"$stats-127.0.0.1:2114"', code = WrongExpectedVersion

```

My network section of the inspect :

```
{
    "Id": "ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922",
    "Created": "2024-01-15T07:43:19.5805765Z",
    "Path": "EventStore.ClusterNode.exe",
    "Args": [
        "--ext-http-port",
        "2114",
        "--ext-tcp-port",
        "1114"
    ],
    "State": {
        "Status": "running",
        "Running": true,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 1284,
        "ExitCode": 0,
        "Error": "",
        "StartedAt": "2024-01-15T07:45:53.7466139Z",
        "FinishedAt": "2024-01-15T09:44:33.5226551+02:00"
    },
    "Image": "sha256:c31ae93c602f572270469ed1e09e0f391d6b95147498d617f2fb46230a922ee1",
    "ResolvConfPath": "",
    "HostnamePath": "",
    "HostsPath": "",
    "LogPath": "C:\\ProgramData\\Docker\\containers\\ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922\\ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922-json.log",
    "Name": "/eventstore-node",
    "RestartCount": 0,
    "Driver": "windowsfilter",
    "Platform": "windows",
    "MountLabel": "",
    "ProcessLabel": "",
    "AppArmorProfile": "",
    "ExecIDs": [
        "2c31d86df3bab58cee2594e3897f744d81e1a208c82c0f2b673a7e7a88269a4d"
    ],
    "HostConfig": {
        "Binds": null,
        "ContainerIDFile": "",
        "LogConfig": {
            "Type": "json-file",
            "Config": {}
        },
        "NetworkMode": "default",
        "PortBindings": {
            "1113/tcp": [
                {
                    "HostIp": "",
                    "HostPort": "1113"
                }
            ],
            "2113/tcp": [
                {
                    "HostIp": "",
                    "HostPort": "2113"
                }
            ]
        },
        "RestartPolicy": {
            "Name": "no",
            "MaximumRetryCount": 0
        },
        "AutoRemove": false,
        "VolumeDriver": "",
        "VolumesFrom": null,
        "ConsoleSize": [
            30,
            120
        ],
        "CapAdd": null,
        "CapDrop": null,
        "CgroupnsMode": "",
        "Dns": [],
        "DnsOptions": [],
        "DnsSearch": [],
        "ExtraHosts": null,
        "GroupAdd": null,
        "IpcMode": "",
        "Cgroup": "",
        "Links": null,
        "OomScoreAdj": 0,
        "PidMode": "",
        "Privileged": false,
        "PublishAllPorts": false,
        "ReadonlyRootfs": false,
        "SecurityOpt": null,
        "UTSMode": "",
        "UsernsMode": "",
        "ShmSize": 0,
        "Isolation": "hyperv",
        "CpuShares": 0,
        "Memory": 0,
        "NanoCpus": 0,
        "CgroupParent": "",
        "BlkioWeight": 0,
        "BlkioWeightDevice": [],
        "BlkioDeviceReadBps": [],
        "BlkioDeviceWriteBps": [],
        "BlkioDeviceReadIOps": [],
        "BlkioDeviceWriteIOps": [],
        "CpuPeriod": 0,
        "CpuQuota": 0,
        "CpuRealtimePeriod": 0,
        "CpuRealtimeRuntime": 0,
        "CpusetCpus": "",
        "CpusetMems": "",
        "Devices": [],
        "DeviceCgroupRules": null,
        "DeviceRequests": null,
        "MemoryReservation": 0,
        "MemorySwap": 0,
        "MemorySwappiness": null,
        "OomKillDisable": false,
        "PidsLimit": null,
        "Ulimits": null,
        "CpuCount": 0,
        "CpuPercent": 0,
        "IOMaximumIOps": 0,
        "IOMaximumBandwidth": 0,
        "MaskedPaths": null,
        "ReadonlyPaths": null
    },
    "GraphDriver": {
        "Data": {
            "dir": "C:\\ProgramData\\Docker\\windowsfilter\\ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922"
        },
        "Name": "windowsfilter"
    },
    "Mounts": [],
    "Config": {
        "Hostname": "ea78d3363fc2",
        "Domainname": "",
        "User": "",
        "AttachStdin": true,
        "AttachStdout": true,
        "AttachStderr": true,
        "ExposedPorts": {
            "1113/tcp": {},
            "2113/tcp": {}
        },
        "Tty": true,
        "OpenStdin": true,
        "StdinOnce": true,
        "Env": null,
        "Cmd": [
            "EventStore.ClusterNode.exe",
            "--ext-http-port",
            "2114",
            "--ext-tcp-port",
            "1114"
        ],
        "Image": "eventstore_5.0.10:latest",
        "Volumes": null,
        "WorkingDir": "C:\\EventStore",
        "Entrypoint": null,
        "OnBuild": null,
        "Labels": {}
    },
    "NetworkSettings": {
        "Bridge": "",
        "SandboxID": "ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922",
        "HairpinMode": false,
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "Ports": {
            "1113/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "1113"
                }
            ],
            "2113/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "2113"
                }
            ]
        },
        "SandboxKey": "ea78d3363fc2f9a3cc5e1b67c55772f67e3e63cf724636e691a8210b06c5e922",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null,
        "EndpointID": "",
        "Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "",
        "IPPrefixLen": 0,
        "IPv6Gateway": "",
        "MacAddress": "",
        "Networks": {
            "nat": {
                "IPAMConfig": null,
                "Links": null,
                "Aliases": null,
                "NetworkID": "9b278c35599d8de2a001da51c4ef9fe663f908163861792bba7610bcf7f9c887",
                "EndpointID": "0da7da9dff1d4e7861bf3cb13e91181e56a8797de25de612643ea6437379e3bc",
                "Gateway": "172.29.240.1",
                "IPAddress": "172.29.254.94",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "00:15:5d:7a:a9:ee",
                "DriverOpts": null
            }
        }
    }
}

```

When I run a curl on the container, I get a happy response :

```
C:\EventStore>curl -I localhost:2114
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-Forwarded-Host, X-Forwarded-Prefix, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, ES-RequiresMaster, ES-HardDelete, ES-Resolv
eLinkTos
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location, ES-Position, ES-CurrentVersion
Date: Mon, 15 Jan 2024 08:01:53 GMT

```

When I try curl'ing to the IP from the network section, or localhost on my host, I get the following response :

```
C:\EventStoreDocker>curl -I http://172.29.254.94:2113
curl: (28) Failed to connect to 172.29.254.94 port 2113 after 21028 ms: Couldn't connect to server

C:\EventStoreDocker>curl -I http://localhost:2113
curl: (28) Failed to connect to localhost port 2113 after 21261 ms: Couldn't connect to server

C:\EventStoreDocker>curl -I http://127.0.0.1:2113
curl: (28) Failed to connect to 127.0.0.1 port 2113 after 21052 ms: Couldn't connect to server

```

# Answer
The issue was the docker container was never running in secure mode:

Changing the docker-compose to this fixed the problem :

```
...
- EVENTSTORE_INSECURE=true
- EVENTSTORE_DISABLE_INTERNAL_TCP_TLS=true
- EVENTSTORE_DISABLE_EXTERNAL_TCP_TLS=true
...

```
> 0 votes

# Answer
Why do you need to create your own image?

Try this docker-compose.yml:

```
version: "3.4"

services:
  eventstore.db:
    image: eventstore/eventstore:23.10.0-bookworm-slim
    environment:
      - EVENTSTORE_CLUSTER_SIZE=1
      - EVENTSTORE_RUN_PROJECTIONS=All
      - EVENTSTORE_START_STANDARD_PROJECTIONS=true
      - EVENTSTORE_EXT_TCP_PORT=1113
      - EVENTSTORE_HTTP_PORT=2113
      - EVENTSTORE_INSECURE=true
      - EVENTSTORE_ENABLE_EXTERNAL_TCP=true
      - EVENTSTORE_ENABLE_ATOM_PUB_OVER_HTTP=true
    ports:
      - "1113:1113"
      - "2113:2113"
    volumes:
      - type: volume
        source: eventstore-volume-data
        target: /var/lib/eventstore
      - type: volume
        source: eventstore-volume-logs
        target: /var/log/eventstore

volumes:
  eventstore-volume-data:
  eventstore-volume-logs:

```
> 0 votes

---
Tags: networking, windows
---


# Question
Title: Required permissions to reorder Board items
EDIT: This is a duplicate of https://stackoverflow.com/q/77852519/1637105. I originally posted this question in this "DevOps" community, then I found a Microsoft support article that says to post questions in the main StackOverflow community with the **\[azure-devops\]** tag.

In my organization, I have a user who will serve as "project manager". I want to give her the ability to move items around on the Kanban "Board", assign personnel to user stories and tasks, and generally be in charge of dealing with the DevOps project management artifacts.

I'm trying to figure out the permissions I need to give her in Azure DevOps. I've put her in the **Contributors** project group.

* If I give her **Stakeholder** access level then she can move board items from one column to another, but she cannot move board items up or down within the same column or change the personnel assigned to an item.
* If I give her **Basic** access level then she has full editing access to the board, including the ability to move items up or down within the same column.

Do I really need to give users **Basic** access level for them to be able to serve as project managers, with the ability to add items, edit items, reorder items, assign personnel to items, and otherwise deal with project management features?

# Answer
> 0 votes
Thanks to Daniel Mann (see the comment on this SO post), the docs clearly state that **Basic** access level is required to:

* Change the priority of an item within a board
* Change fields on cards on a board, except for State field

---
Tags: azure-devops
---