I’ve an existing cluster. To create a cluster on local machine I would recommend using Kind

Install using helm

kubectl create namespace rabbitmq
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install myrmq bitnami/rabbitmq --namespace rabbitmq


RabbitMQ can be accessed within the cluster on port `5672` at `myrmq-rabbitmq.rabbitmq.svc`.

Username : user

Password : kubectl get secret --namespace rabbitmq myrmq-rabbitmq -o jsonpath="{.data.rabbitmq-password}" | base64 --decode

ErLang Cookie : kubectl get secret --namespace rabbitmq myrmq-rabbitmq -o jsonpath="{.data.rabbitmq-erlang-cookie}" | base64 --decode


# Run a debug pod
kubectl run -i --tty --rm debug --image=python:3.10-slim-bullseye --restart=Never -- bash
pip3 install pika# Type python for replpython

# Inside the repl
import pika
credentials = pika.PlainCredentials('user', '<password from credentials above>')
parameters = pika.ConnectionParameters('myrmq-rabbitmq.rabbitmq.svc',5672,'/',credentials)
connection = pika.BlockingConnection(parameters)
channel = connection.channel()
hello_q = channel.queue_declare(queue='hello')
body='Hello W0rld!')

Not able for find springboot jar file when running helm chart for kubernetes pod (deployment) (though the docker container has a copy jar)

use this pattern

- "java"
- "@/opt/foo/ce/conf/stage/java.options"
- "-jar"
- "/opt/foo/ce/ce.jar"
- "--logging.config=/opt/foo/ce/conf/stage/logback.xml"

Forget the past and focus on the present. If you don’t like the present, focus on the future.

If a man in line behind you at the convenience store buys a lottery ticket and wins a million dollars, do you kick yourself for not buying that ticket when it was your turn in line? Life is chaos; pretending things like this are in your control is useless. Punishing yourself for not knowing what you didn’t know in the past is cruel.

Your misery comes from your own self-imprisonement. Happiness will not come from a time machine. Rather you should work on keeping your ego out of the driver’s seat.

docker run -e POSTGRES_USER=build-service -e POSTGRES_PASSWORD=secret -e POSTGRES_DB=build_service -p 54321:5432 postgres:12psql -h localhost -p 54321 -d build_service -U build-service

more info


Create a custom db and grant admin_user permission.

$ psql -h commondb.foo.amazonaws.com -d postgres -U ldev
Password for user ldev:
postgres=> create database commondb;
postgres=> grant all privileges on database commondb to ldev;
$ psql -h commondb.foo.amazonaws.com -d commondb -U ldev
Password for user localdev:

Create another postgres, username and password. Grant all priviledges to postgres user.

from postgres-client pod
$ k exec -it postgres-client -- bash
$ psql --host=postgres-foo.amazonaws.com --dbname postgres -U ldevpostgres=> create database staging;
postgres=> create user stgusr with encrypted password 'spwd';
postgres=> grant all privileges on database staging to stgusr;

How to check the if the user data shell file is rendered correctly

On the terraform user-data shell file add echo statements

for aws,

ssh into the instance,

sudo su# to see echo messages
tail -f /var/log/messages |grep cloud-init

To see the file with interpolated values

less /var/lib/cloud/instance/scripts/part-001

Keep it simple
- function based views
- centralize access to the ORM (avoid fat models, use a service layer)
- responsive bootstrap template with crispy forms
- minimal js
- 12 factor type setup - django-environ or similar
- be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries)
- plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate
- avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar
- use a managed database and managed email service

When one creates a jmeter test after few months in between, capturing csrf token bites us — least it is searching to find the right way to set up X-XSRF-TOKEN header and worst huge time sink

Add the next line to user.properties file (lives in "bin" folder of your JMeter…