#random (2022-07)

Re-write git history and force-push, no one will ever know

+1 as I would be interested in this

(if we can’t find one, lets start one!)

I have one from long ago Slack: devopsSF(7), but not much going on yet. I always thought of CoffeeOps(1020) as a devops(52) place, has more of an audience.

Slack: Chef Community 9,296 members, AWS Users 778 members

Also there are a few on Discord.

To clarify when I say “similar to Indie Hackers”, I mean in the context of the bootrapping startup community. People who aspire to run a small self-funded SaaS business.

Of course there are some devOps/infra businesses in that community, but it would be good to have somewhere where devOps expertise is high

Forums like SweetOps are great, but seems to cater for people who are gainfully employed within a large organization.

Only seeing this now, but I’m working for a small start up, 4th start up job in a row.. and there are definitely others here who also doesn’t work for a corporation.

How about a new channel “business-ideas” on SweetOps?

Happy to create the channel, but it always works best if there’s a group behind it that want to use it. We have a lot of dormant channels.

I’m happy to take responsibility for it if you like. I guess we can see whether it gets any traction and reassess after a few weeks.

Following — I’m very interested to hear another review. Glad to see yours randomly Sheldon.

Currently we store non-secrets in the kustomization.yaml of each micro-services git repository. However some teams are asking if they can exclusively use vault for all configuration. The rationale being that if they ever need to update a value they only have to change it once in vault.

I don’t think that’s the right approach:

• Makes it harder for teams to update configuration if compliance checks are put in place (e.g. only DevOps team are allowed to modify secrets)

• Makes it harder to see at a glance how an application is configured. Probably better to make the teams use something like Parameter Store for non-secret secrets.

Actually another colleague suggested using a common git repo which defines the common config map values and importing that via kustomize.

We use AWS SSM for both secrets and config values. It’s really nice having them in the same place.

same, consul can do something similar and just pull in the vault items behind the scenes I think?

At a previous place, we had non-secrets along side actual secrets in AWS SM. Pro was convenience, but con was what Andy points out along with excess AWS SM costs. You can perhaps use different keys from KMS for actual and non-secrets, but if starting over, we would have separated them and researched a best practice.

cool, I love the drop downs.

so many cli building tools now

• atmos

• choria/app-builder

• ahoy-js

• gum

Yeah — 100%. Everybody needs their own CLI tool nowadays. Would love to hear how ya’ll are using the new atmos CLI commands functionality!

We’re using it for one client I believe and @Andriy Knysh (Cloud Posse) could probably speak more to that.

Here is an example within the atmos.yaml on how to create a custom atmos <subcommand>

https://github.com/cloudposse/atmos/blob/f811a5d14225bbd668dd950da114258c258a608e/examples/complete/atmos.yaml#L66-L67

Very cool.

Just came across this tool and was about to share it in #random but looks like Matt was ahead of the times.

Sharing this content in case others find it helpful: http://youtube.com/watch?v=U8zCHA-9VLA