| 27 Feb 2025 |
 Arian | We (mercury.com) are about to open source some terraform modules that we use for deploying NixOS using SSM | 20:41:06 |
| Arian | we basically have an SSM Document that does a nixos-rebuild switch | 20:41:23 |
| Arian | i can probably get that published tomorrow | 20:42:25 |
|  pykee03 joined the room. | 21:24:49 |
 drewhaven | This'll be a new type of deployment for me. I'm used to k8s clusters where it's easy to just start new stuff. Been decades since I had to manage an actual system. :D | 23:22:44 |
| Arian | Why do you wanna use AWS SSM though? Do you have other AWS infra to integrate with? | 23:25:09 |
| Arian | It's only kind of worth it if you have other AWS infra. Otherwise I'd just use ssh :") | 23:25:30 |
| drewhaven | We have a decent amount of AWS stuff for our cloud stuff, though we aren't super heavy on all their infra services. | 23:26:43 |
| drewhaven | Just lots of S3, some k8s clusters, a few important ec2 instances. | 23:27:08 |
| drewhaven | Probably the main thing is that we already have the access controls set up. | 23:27:27 |
| drewhaven | A former SRE was going to use it for this, but never got around to it. Now I'm taking a crack at it. | 23:28:02 |
| drewhaven | I'm evaluating options atm. | 23:28:10 |
| drewhaven set a profile picture. | 23:29:15 |
| 28 Feb 2025 |
 adamcstephens | ssh is superior to ssm, except for the fact that ssm can use sso through aws. | 00:07:22 |
| adamcstephens | not that you can't get sso with regular linux, but the setup ease of ssm is probably hard to beat. | 00:08:25 |
| adamcstephens | SSH/SSM/SSO, are there other such acronyms? | 00:09:07 |
| drewhaven | Don't forget SSL | 00:14:32 |
 commiterate | SSM's main benefit is not needing to open up any security group or VPC rules to allow SSH ingress. I'd only use it for quick debugging though. | 00:29:32 |
| commiterate | The console terminal gets a bit annoying to use for anything more complicated. | 00:30:01 |
| commiterate | * The browser WebSockets terminal gets a bit annoying to use for anything more complicated. | 00:30:14 |
| drewhaven | That's the main use-case here, being able to run some commands on the deployed fleet and occasionally connect if something seems off. Our current system has an awkward setup where each box has it's own OpenVPN connection to a central EC2 instance. | 00:34:05 |
| drewhaven | The local network is unmanaged and untrusted. | 00:34:26 |
| drewhaven | * The local network for the deployed boxes is unmanaged and untrusted. | 00:34:34 |
| commiterate | yup SSM seems perfect then. It's significantly easier than trying to stand up your own bastion hosts | 00:44:05 |
| commiterate | * yup SSM seems perfect then. It's significantly easier than trying to stand up your own bastion/ops hosts | 00:45:30 |
| commiterate | you don't have to use the system update features of SSM so it can work with immutable stuff | 00:48:58 |
| commiterate | that's basically how AWS use it themselves internally | 00:49:32 |
| commiterate | bake an immutable Amazon Linux AMI with the SSM agent then only use it for the occasional deeper debug (assuming CW metrics + logs don't have enough info) | 00:50:07 |
| commiterate | * bake an immutable Amazon Linux AMI with the SSM agent then only use it for the occasional deeper debug (when the CW metrics + logs don't have enough info) | 00:52:39 |
| drewhaven | Exactly. The goal is to make the system so simple that the vast majority of issues can be fixed with a reboot or rollback. | 01:02:19 |
