DEV Community: Ahmad Bayhaqi

What Docker Image Tag Should You Actually Use?

Ahmad Bayhaqi — Tue, 25 Nov 2025 07:15:59 +0000

I’ve been working with containerized applications for a while, and one thing that always confused me in the beginning was Docker image tagging.
Nobody explained it properly.

I just followed whatever the team did, pushed images, and hoped things worked.

But over time.. especially when handling multi-tenant apps, shared registries, and too many deployments. I started to see how bad tagging decisions can break everything.

So here’s my experience and what I learned the hard way.

The moment I realized “latest” is a trap

When I first started using Docker, I thought:

“Ah, just push it with latest. Simple.”

Until one day, a tenant’s production environment suddenly rolled back to a previous version.
Why?

Because someone else on the team pushed a new image with the same latest tag. The registry replaced it silently. The cluster pulled it automatically. Chaos.

That’s the moment I understood:

latest is not a version
latest is not safe
latest will eventually hurt you

But I didn’t stop there. I kept experimenting with different tagging styles.

The Semantic Versioning Phase

After the latest catastrophe, we switched to semantic versioning:

v1.2.3
v1.2.4
v1.3.0

And honestly... it felt clean.

Every release had a meaning.

We knew which version fixed what.

Rollback was easy — just redeploy the previous version.

But then reality hit:

My team was not disciplined enough.
People forgot to update the version.
Someone tagged two different builds with the same version.
And sometimes we just wanted to test something quickly, but bumping semantic version felt “too heavy”.

Semantic versioning worked well for production, but not so much for day-to-day development.

Branch-Based Tagging: Easy but Dangerous

Then we tried a simpler approach:

dev
staging
production

It felt nice.

Our CI/CD pipeline was clean.

Each environment had its own tag.

But later, when our application grew into a multi-tenant product, things got messy.

Imagine this scenario:

Tenant A and Tenant B both use development tag
You push a new feature for Tenant A
Cluster for Tenant B also pulls the new development image (because it’s the same tag)
Tenant B breaks

This happened to us more times than I’m proud of.
And again, older images became “untagged” when new ones reused the same tag.

No trace.
git-revert rollback.
I knew we needed something safer.

Finally: Branch + Commit Hash

This was the game changer.
Instead of just development, we started tagging like this:

development-a1b2c3d
development-f39e2a1
production-c41e162

Just 7 characters of the commit hash, unique, simple, and enough to avoid collisions.

Suddenly:

Every image had a unique identity
Rollbacks became extremely easy
Multi-tenant setup was safe
Nothing accidentally overwrote something else

The only downside?!

Registry will populate a lot of different tags

Our container registry filled up fast.
We had to implement retention policies.

But honestly, compared to breaking tenants?

I will happily pay for storage.
This tagging style solved everything semantic versioning and branch tagging couldn’t.

So what do I actually recommend?

From my own experience,

For development:
Use branch + commit hash

Example:

development-7f92c3a

It keeps things safe, traceable, and rollback-friendly. cover frequently changes on development.

Tips
keep latest image (e.g. development-latest). you may push alternative tag on single commit.
dont worry it doesn't take your storage, just tag. it will help you to trace which latest tag quickly

For production:
Use semantic versioning

Example:

v1.4.0

Clean, stable, professional.

For personal or hobby projects:
Just use latest or dev.
No need to over-engineer.

Azure: How to Configure SSL Using Cert-Manager with (AGIC) Application Gateway Ingress Controller

Ahmad Bayhaqi — Mon, 03 Apr 2023 06:10:25 +0000

Kubernetes has a lot of support and open-source tools to contribute to the cloud-native project. one of the scopes is the ingress, k8s has a support ingress, you might concern nginx ingress that a very famous ingress in k8s. azure has ingress to work well with an azure cloud environment, that is Application Gateway. The Application Gateway Ingress Controller allows Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service aka AKS cluster.

In this guide, you'll learn how to configure Secure HTTP with Cert-Manager and AGIC. Before getting starting you should have the following requirements.

AKS Cluster
Azure Subscriptions
kubectl installed on your local machine

Step 1 -- Create application gateway

Create public ip to used by application gateway as front end IP.

az network public-ip create -n myPublicIp -g myResourceGroup --allocation-method Static --sku Standard

Create new subnet within AKS vnet.

az network vnet subnet create -g MyResourceGroup --vnet-name MyVnet -n MySubnet --address-prefixes 10.226.0.0/24

Create Application gateway within AKS vnet, with different subnet. this guide you will create application gateway with Tier Standard, which is isn't act as WAF.

az network application-gateway create -n myApplicationGateway -l eastus -g myResourceGroup --sku Standard_v2 --public-ip-address myPublicIp --vnet-name myVnet --subnet mySubnet --priority 100

Step 2 -- Enable add-ons to AKS

after success create app gateway, you need to enable the application gateway with AKS cluster,

appgwId=$(az network application-gateway show -n myApplicationGateway -g myResourceGroup -o tsv --query "id") 
az aks enable-addons -n myCluster -g myResourceGroup -a ingress-appgw --appgw-id $appgwId

Step 2 -- Deploy sample app

Create deployment and service app, you will deploy sample HTML 5 game.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: clumsy-bird
  name: clumsy-bird
spec:
  selector:
    matchLabels:
      app: clumsy-bird
  replicas: 2
  template:
    metadata:
      labels:
        app: clumsy-bird
    spec:
      containers:
      - name: clumsy-bird
        image: bayhaqisptr/clumsy-bird:latest
        ports:
        - containerPort: 8001
---
apiVersion: v1
kind: Service
metadata:
  name: clumsy-service
  labels:
    run: clumsy-service
spec:
  type: ClusterIp
  ports:
  - port: 8001
    protocol: TCP
  selector:
    app: clumsy-bird

Step 3 -- Create Ingress

Create ingress, you might notice the annotations kubernetes.io/ingress.class make sure its use azure/application-gateway to tell AKS to use application gateway as Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: clumsy-agic
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  tls:
  - hosts:
    - appgw-test.example.test
    secretName: clumsy-tls
  rules:
  - host: appgw-test.example.test
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: clumsy-service
            port:
              number: 8001

Step 4 -- Create Issuer (Staging)

Create Issuer staging with Let's Encrypt with cert-manager

apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-staging
   spec:
     acme:
       # The ACME server URL
       server: https://acme-staging-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: user@example.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-staging
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class:  azure/application-gateway

Step 5 -- Create Issuer (Prod)

Create Issuer staging with Let's Encrypt with cert-manager

apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-prod
   spec:
     acme:
       # The ACME server URL
       server: https://acme-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: user@example.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-prod
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class: azure/application-gateway

Step 6 -- Ingress TLS

after success create issuer with cert-manager, you can enable https connection to handle acme challenge.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mokita-agic
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    cert-manager.io/issuer: letsencrypt-prod-agic
    cert-manager.io/acme-challenge-type: http01
    acme.cert-manager.io/http01-edit-in-place: "true"
spec:
  tls:
  - hosts:
    - appgw-test-16769.southeastasia.cloudapp.azure.com
    secretName: mokita-agic
  rules:
  - host: appgw-test-16769.southeastasia.cloudapp.azure.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mokita-service
            port:
              number: 80

Conclusion

In Cloud Native world has many project available to explore. for example k8s has many ingress support to use, link nginx ingress, ingress nginx, kong, agic, etc.

This guide cover some step to configure let's encrypt with agic ingress

Rolling update in Kubernetes

Ahmad Bayhaqi — Wed, 15 Feb 2023 08:42:07 +0000

Rolling Update is a way of updating your application running in Kubernetes without causing downtime. It gradually replaces the old version with the new version one by one, so that users can still access the application while the update is happening. This makes updates more reliable and easier to manage, and helps ensure that your application remains available and responsive to users.

Step 1 -- Create deployment and Service

create file named rolling-app.yaml

cat > rolling-app.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 namespace: rolling
spec:
 replicas: 5
 selector:
   matchLabels:
     app: my-app
 template:
   metadata:
     labels:
       app: my-app
   spec:
     containers:
       - name: nginx
         image: bayhaqisptr/nginx-canary:v1
         ports:
           - name: http
             containerPort: 80
         resources:
           requests:
             cpu: 100m
             memory: 50Mi
           limits:
             cpu: 200m
             memory: 100Mi
---
apiVersion: v1
kind: Service
metadata:
 name: my-app
 namespace: rolling
 labels:
   app: my-app
spec:
 type: NodePort
 ports:
 - name: http
   port: 80
   targetPort: http
 selector:
   app: my-app
EOF

Create namespace rolling

kubectl create ns rolling

and apply rolling-app.yaml

kubectl apply -f rolling-app.yaml

Step 2 -- Set image with another version tag

use command kubectl set image to set image in existing deployment

kubectl set image deployment.v1.apps/my-app my-app=bayhaqisptr/nginx-canary:v2

see rollout status with following command

kubectl rollout status deployments/my-app

show available changes that made

➜  rolling kubectl rollout history deployment.apps/my-app -n rolling                               
deployment.apps/my-app 
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

check service will be responses with version 2

access app with node ip and node port has been created

➜ curl 172.23.0.5:31374 
<html>
<h1>Hello World!</h1>
<p>This is version 2</p>
</html>

Step 3 -- Rollback deployment

rolling back to one previous version

kubectl rolling undo deployment/my-app

rolling back to specific revisions

kubectl rolling undo deployment/my-app --revision=2

How to recreate MONs out of quorum on Ceph

Ahmad Bayhaqi — Fri, 10 Feb 2023 03:16:41 +0000

MONs are recommended to ensure fault tolerance and maintainability. If a cluster's MONs cannot form a quorum, which happens if not enough of the provisioned MONs are up, then new clients won't be able to connect to the system.

quorum is fundamental to all consensus algorithms that are designed to
access information in a fault-tolerant distributed system. Minimum number of votes achieve consensus among a set of nodes called quorum.

Sometime you had Ceph MONs are down, and return out of quorum status. This tutorial you will learn How to recreate MON daemon on Ceph.

Step 1 -- Remove MONs

first step you need to see the status of cluster. based on the information below, you have 1/3 mons down, and return out of quorum status and everything else is safe.

$ sudo ceph status
  cluster:
    id:     4664a822-3fac-11ed-b14c-5bcb09093cfa
    health: HEALTH_WARN
            1/3 mons down, quorum pod-bayhaqisptr04-ceph1,pod-bayhaqisptr04-ceph2

  services:
    mon: 3 daemons, quorum pod-bayhaqisptr04-ceph1,pod-bayhaqisptr04-ceph2 (age 0.343641s), out of quorum: pod-bayhaqisptr04-ceph3
    mgr: pod-bayhaqisptr04-ceph1.ufgzyk(active, since 3d), standbys: pod-bayhaqisptr04-ceph2.qcmvuo
    osd: 6 osds: 6 up (since 117m), 6 in (since 117m)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   105 MiB used, 30 GiB / 30 GiB avail
    pgs:     1 active+clean

you should remove mon from the ceph cluster. you can type with command below.

sudo ceph mon remove pod-bayhaqisptr04-ceph3

Info

ID of MONs is ussually the host name that are provisioned daemon.

after successful remove mon from cluster you need check again health. The Health will be OK. Because no one MONs down, you already remove it. health are OK but MON decrease 2 daemon in cluster

sudo ceph status
  cluster:
    id:     4664a822-3fac-11ed-b14c-5bcb09093cfa
    health: HEALTH_OK

  services:
    mon: 2 daemons, quorum pod-bayhaqisptr04-ceph1,pod-bayhaqisptr04-ceph2 (age 3s)
    mgr: pod-bayhaqisptr04-ceph1.ufgzyk(active, since 3d), standbys: pod-bayhaqisptr04-ceph2.qcmvuo
    osd: 6 osds: 6 up (since 2h), 6 in (since 2h)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   105 MiB used, 30 GiB / 30 GiB avail
    pgs:     1 active+clean

Step 2 -- Make sure daemon are removed on Node

MONs might removed from cluster, but what about the Node itself? you need to checkout to host.

$ ssh ceph3
$ sudo cephadm ls | grep mon
        "name": "mon.pod-bayhaqisptr04-ceph3",
        "systemd_unit": "ceph-4664a822-3fac-11ed-b14c-5bcb09093cfa@mon.pod-bayhaqisptr04-ceph3",
        "service_name": "mon",

if you see like this output that means daemon was stopped but daemon still registered on cephadm host. to remove it you can use rm-daemon subcommand on cephadm.

sudo cephadm rm-daemon --name mon.pod-bayhaqisptr04-ceph3 --fsid 35de853b-3a4e-4568-b698-f223c8382bb8 --force

after success remove, check again that are still available or not.

sudo cephadm ls | grep mon

to get your fsid use this command to grep you cluster id

sudo ceph status | awk '/id:/ {print $2}'

it might take a few minutes to update entire database of cephadm before you can redeploy new Ceph MON

Step 3 -- Redeploy Ceph MON

after daemon are removed you need to redeploy daemon. to reliaze it you can set mon to unmanaged mode

sudo ceph orch apply mon --unmanaged

and redeploy new daemon with given spesific host and address

$ sudo ceph orch daemon add mon pod-bayhaqisptr04-ceph3:10.9.9.30

Deployed mon.pod-bayhaqisptr04-ceph3 on host 'pod-bayhaqisptr04-ceph3'

verify its work properly

$ sudo ceph status

student@pod-bayhaqisptr04-ceph1:~$ sudo ceph status
  cluster:
    id:     4664a822-3fac-11ed-b14c-5bcb09093cfa
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum pod-bayhaqisptr04-ceph1,pod-bayhaqisptr04-ceph2,pod-bayhaqisptr04-ceph3 (age 55s)
    mgr: pod-bayhaqisptr04-ceph1.ufgzyk(active, since 3d), standbys: pod-bayhaqisptr04-ceph2.qcmvuo
    osd: 6 osds: 6 up (since 2h), 6 in (since 2h)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   105 MiB used, 30 GiB / 30 GiB avail
    pgs:     1 active+clean

Congrats! you have recreate and bringing up you Ceph MON.

Conclusion

The ceph cluster uses several daemons to build its system. and registered on cluster and host itself. ceph mon is responsible for ensuring all daemons are in good working order.

This guide cover some common cephadm command to operate remove daemon cephadm rm-daemon, and also learn how to recreate it ceph orch daemon add. the link below might be as useful reference