I like kotlin SpringBoot apps deployed to k8s. Go apps for custom k8s operators/controllers.
I prefer Sealed Secrets over sops since it has the namespace scoping element and can also be stored in repo (once encrypted). I also generally prefer having a controller deployed rather than forcing devs to learn kustomize (which we don’t widely use yet) so I guess less of a support burden for me.
I can’t believe I haven’t seen external secrets before. Sealed secrets are cool, but such a pain as you described. Gonna be setting up external secrets next week sounds like. Thanks for the great post
Im a bit late to the show, but I personally feel like you are heading down the wrong path. Unless you are trying to completely host locally, but for some reason want your backups in the cloud, and not simply on separate local server, you are mixing your design for seemingly no reason. If you are hosting locally, you should back up to a separate local instance.
If you indeed are cloud based, you SHOULD NOT be hosting a DB separately. Since you specified S3, you are using AWS, and you should rather use RDS managed mySQL and should use the snapshot feature built in. ref
Laughs in object
I am not as familiar with Cloud Native DevOps Newsletter but I do enjoy the podcast
I believe in GitHub branch protection rules, you can set required review by a code owner, as well as set an amount of reviews required.
You are also able to structure codeowner files and assign codeowners to certain paths within the repo that they “own”, rather than all or nothing.
You are able to set bypass rules for certain individuals, and as repo admin there is a little checkbox on PRs that will appear by default to allow you to ignore the requirements, although it is generally not recommended, but I won’t harp on the reasons others have already pointed out.
disclaimer: I mainly work on a GHES instance, which may be function slightly different than public GH
I prefer a similar workflow.
I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of “doing it all in one place”.
CD is where things get dirty, and it really depends on how/what/where you are deploying.
Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).
Thanks for sharing! I will need to look deeper into build kit. Containers aren’t my main artifacts, unfortunately, so I am still building them the ways of old, sounds like.
Be really careful when building images that require secrets for build configuration. Secrets can be passed in as build args, but you MUST UNSET THEM IN THE DOCKERFILE and then repass them in as environment variables at runtime (or else you are leaking your secrets with your image).
Also, image != container. Image is the thing you publish to a registry (e.g. dockerhub). Container is an instance of an image.
AutheNtication vs. AuthoriZation, I believe
not production ready vs. production ready
Thanks for sharing! I definitely hadn’t seen that plugin. We definitely use helm, even though I hate it lol. I will take a look when I get around to looking at external secrets since I still haven’t had a chance to (you know how it goes… priorities made up by some random PM or whatever)