- Architect solutions to be scalable and reilient
- Business requirements involve lowering costs / enhancing user experience
- Keep an eye on technical needs during development and operation
- Where is the company coming from
| #!/bin/bash | |
| set -x | |
| function setenv-all-pods() { | |
| echo | |
| DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o jsonpath='{.items[*].metadata.name}') | |
| echo "Set Log4J setting for all pods by overriding LOG4J_FORMAT_MSG_NO_LOOKUPS with true." | |
| for deployment_name in $DEPLOYMENT_LIST; do | |
| kubectl -n $1 set env deployment $deployment_name LOG4J_FORMAT_MSG_NO_LOOKUPS="true" | |
| done |
This gist provides a summary on how to accomplish the following tasks:
| I had a bit of trouble figuring out how to use bitnami's [sealed secrets](https://github.com/bitnami-labs/sealed-secrets) with [helm](https://helm.sh) | |
| Here's a definition of done to help you see what I was trying to achieve. | |
| **Definition of done** | |
| - Single secret available for a release in a namespace, listing all secret variables | |
| - Regular helm workflow, with no extra kubeseal commands for developers | |
| - Encrypted secrets clearly visible in git | |
| - Sealedsecret managed by helm |
There's several existing strategies for deploying and managing development work and release. They each have their own opinions, but roughly cover a few major situations:
You can use this diagram as a template to create your own git branching diagrams. Here's how:
https://gist.githubusercontent.com/bryanbraun/8c93e154a93a08794291df1fcdce6918/raw/bf563eb36c3623bb9e7e1faae349c5da802f9fed/template-data.xml