There are many tools for handling complex architecture of deploying changes of your applications from the build stage to your cluster, most times the term and process of archiving this is called GitOps only if github is being used as the single source of truth in the scenerio.

when it comes to containerized environment gracefull shutdown, process management and reducing attack surface, i believe we cant leave dumb-init out of it.

When you are preparing your vault environment for production, you would want to implement the end-to-end tls setup as stated in the hashicorp vault production-ready documentation.

Setting resource quotas such as CPU and memory limits/requests is easier said than done.

But why do you need this in the first place?

hello everyone, okay, so I did something recently with GitHub action, re-wrote and optimized a workflow of 900+ lines back to 200+

Hii 👋, I am sure you want peace of mind too, haha

Well, there is no way you would be discussing container supply chain security without talking about the signing of container images.

You probably handling your manifest and deployment secrets in kube like this

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hashicorp-vault-k8s
  name: hashicorp-vault-k8s
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hashicorp-vault-k8s
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hashicorp-vault-k8s
    spec:
      containers:
      - image: busybox
        name:
        env:
        - name: API_KEY
          value: jduhdshieioieiisbbjsb
        - name: AWS_KEY
          value: 96859988gddjjdjds
        - name: WEBHOOK_SECRET
          value: jimjimjimokaynice

Yeah, being doing the CI/CD implementations via github workflow lately and I am also trapped in the process of making commits to trigger the workflows or better still making empty commits, haha.

Almost everyone knows how to use .gitignore, the git file that helps in keeping sensitive files like .env out of the tracking, commit, and pushing process, and also unwanted folders like node_modules and all.

But do you know secrets, hardcoded credentials, and API aren't easy to deal with using a .gitignore file? you don't want to keep your config.js or config.go file out of the commit process, these are essential files to your project.

For someone who just started writing Go, I have no idea about //go:embed feature which came with the released version: 1.16.

A project I was working on recently led to discoveries.