I was hoping I was the DevOps/Platform/SRE plugin for my agents!
hangrybear666 27 minutes ago [-]
Humor is what keeps me going too lol
jablongo 20 minutes ago [-]
Why do you need a plug-in for this? You can just ask the agents to do all this stuff and it works fine in my experience.
bealesh 1 minutes ago [-]
dig into the repo and you'll find libraries of opentofu that are quite opinionated - the point of the plugin is to inject opinions that the agents don't have.
jablongo 19 minutes ago [-]
I guess it makes the behavior more predictable?
measurablefunc 18 minutes ago [-]
Plugins are just a collection of prompts & shell scripts.
It should be compatible yeah - ponytail was the inspiration for this - ideally one could use ponytail for application code and neckbeard for infra.
shermantanktop 48 minutes ago [-]
Also:
suspenders, for resilience
unixbeard, for documentation
roundglasses, for observation
dnd, for chaos testing
upcoming-sesame 9 minutes ago [-]
I'm not sure if this is a joke or not
2 hours ago [-]
hangrybear666 2 hours ago [-]
It does sound cool and as an infra nerd myself it reads sensible, I just don't see why I would want another abstraction layer between my cloud deployments being rolled out and the tf/hcl files that I maintain. Why would I want to install another interface between me, the planfile and the running environment? Genuine question
bealesh 2 hours ago [-]
It’s opinionated and built around a reference architecture- think it kind of like using rails or phoenix instead of just writing ruby or elixir. LLM’s are fantastic syntax generators, but they have no real opinions on architecture or finops.
hangrybear666 1 hours ago [-]
Oh so more an orchestration interface with sane defaults for an LLM to use as a reference when implementing deployment changes, especially new rollouts?
It seems to be aimed at small to medium sized cloud deployments and more as a starting point to get customers up and running?
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
bealesh 1 hours ago [-]
Exactly - and it's pretty much aimed at 'built this cool TS app on vercel and supabase and want to scale it' or the like. I build my career migrating rails apps off heroku, and this is kind of inspired by a lot of what I learned.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
hangrybear666 44 minutes ago [-]
Oh that's neat. Yeah I got started on heroku too. Fly.io also comes to mind.
We run our own gitlab instance in a central AWS account that has some infra buckets containing modularized Terraform packaged into tarballs that are then fanned out to a couple hundred aws accounts across the teams and environments (prod, qual, dev).
Its all deployed via gitlab ci cd pipelines (which are just ec2 instances spawned at pipeline invocation) in multiple layers. The first layer is a foundation laying the networking rules and the IAM roles, permissions, policies and boundaries, some logging and monitoring.
The second layer then assigns team specifics such as budget and maps people's accounts to roles depending on their access level (maintainer, developer, reporter). This layer can also be used to customize firewall rules like opening ports to the company internal IP ranges. The third and final layer is then all of the application infrastructure of the teams, so all their persistence, compute, load balancing, dns routing and serverless stuff. My prior teammates did a lot by hand in the aws console but I told them to stop and retain everything as IaC code. Besides Terraform, in my team we use Packer to build reusable "golden" machine images but also Ansible to configure live machines.
I'm still surprised nobody bothered us to change to Opentofu, it's not even been mentioned yet lol.
bealesh 4 minutes ago [-]
I've worked in similar shops - I'm a big fan of less pipelines and layers and more environment variables.
llama052 24 minutes ago [-]
This seems like a great way to wake up and have your cloud spend skyrocket because an LLM assumed wrong.
bealesh 20 minutes ago [-]
did you read the part where it doesn't let the LLM do that?
manlymuppet 1 hours ago [-]
The real Gilfoyle would self-host.
bealesh 1 hours ago [-]
do as neckbeard says, not as neckbeard does.
piterrro 54 minutes ago [-]
> The same reference app (HTTP service + worker + cron + Postgres), smallest tier, all three environments, live prices via Infracost:
Hetnzer server for 25usd/month and you have plenty more space to do more stuff and scale
bealesh 33 minutes ago [-]
Hetnzer is next on my list to add! Feel free to PR it if you're feeling froggy!
hangrybear666 15 minutes ago [-]
Hetzner is awesome, I prefer it to aws for personal projects, feel free to analyze my modularized instance setup with an LLM and rip out what you need, it's all hand built, most of the engineering went into cloud-init and network security - before machines could generate the same in hours lul
suspenders, for resilience
unixbeard, for documentation
roundglasses, for observation
dnd, for chaos testing
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
We run our own gitlab instance in a central AWS account that has some infra buckets containing modularized Terraform packaged into tarballs that are then fanned out to a couple hundred aws accounts across the teams and environments (prod, qual, dev).
Its all deployed via gitlab ci cd pipelines (which are just ec2 instances spawned at pipeline invocation) in multiple layers. The first layer is a foundation laying the networking rules and the IAM roles, permissions, policies and boundaries, some logging and monitoring. The second layer then assigns team specifics such as budget and maps people's accounts to roles depending on their access level (maintainer, developer, reporter). This layer can also be used to customize firewall rules like opening ports to the company internal IP ranges. The third and final layer is then all of the application infrastructure of the teams, so all their persistence, compute, load balancing, dns routing and serverless stuff. My prior teammates did a lot by hand in the aws console but I told them to stop and retain everything as IaC code. Besides Terraform, in my team we use Packer to build reusable "golden" machine images but also Ansible to configure live machines.
I'm still surprised nobody bothered us to change to Opentofu, it's not even been mentioned yet lol.
Hetnzer server for 25usd/month and you have plenty more space to do more stuff and scale
https://github.com/fiscalismia/fiscalismia-infrastructure/tr...