mr_ndrsn

This looks very cool!

Please consider adding a user agent string with a link to the repo or some Google-able name to your curl call, it can help site operators get in touch with you if it starts to misbehave somehow.

Yup, use an accessory for that. I used it to setup a Minecraft server for our last company meetup.

I agree, there should be a way to have the primary app be an image that doesn’t get built/pushed.

I'm a Lead SRE on the Ops team. We've got a fantastic bunch of folks, they're amazing to work with!

I was at the company when it happened. I'm currently at the company. I'm in ops and work on all of the mrsk/de-clouding efforts.

Zero, which is why we're not using k8s on-prem. Our team is already handling the on-prem hardware/software environment, and this will consolidate our apps on a single platform methodology, allowing us to keep the same team size. Using mrsk allows us reduce the complexity of our servers, moving that into the Dockerfile.

If we had gone down the k8s on-prem rabbit-hole, I suspect we would have required more folks to manage those components and complexity.

Yes, they did. This is not a debatable fact. IIRC, it was 30%+ of the company.

I mean, mrsk has a different feature set than ECS, sure. But we don't want to pay AWS for ECS anywhere. We're trying to get off big tech where we can. I'm sure you've heard David talk about that.

This tool covers our use cases so far, and is easy to reason about. Ergonomically, it's very similar to Capistrano, which we're all familiar with.

> I move companies between clouds and on-prem to cloud, cloud to on-prem (even though a bit bigger one than 37singnals) and I could use tools like Ansible and Terraform.

Where did anyone say we don't use other tools? Chef + Terraform are wonderful and still in use for us.

> Could you share the comparison chart of tools that you considered? What thought process led you to believe that this is an unsolved problem and requires a new tool? Genuinely interested.

Your phrasing here and in your previous quoted reply leads me to believe you're not genuinely interested. Our environment is not your environment, our experiences are not your experiences. No, I can't share a chart of other tools that were considered, but off the top of my head, Capistrano, various CI integrations, Github Actions, etc.

We're a rails shop. We're going to look at tools in that area. We're not going to go dig into dagger or garden.io or something that causes us to have to conform our dev/deploy environment to a mental model that adds more friction for our developers.

> How should I judge it by than? Reading the code? Figuring out how to hold it right myself?

It's not that complicated of code, only about 2k, total, IIRC? I mean, you could read it. I'm baffled that you're choosing to compare a structural design flaw like the iPhone antennae issue to the fact that a configuration example in a new tool used an IP address. Go off, king.

We did! And it did work. And there are def some great things that I (we) love about k8s. Personally, the declarative aspect of it was chef's kiss. "I want 2 of these and 3 of these, please", and it just happens.

Which is the primary reason why we did investigate k8s on-prem. We had already done the work to k8s-ify the apps, let's not throw that away. But running k8s on-prem is different than running your own k8s in the cloud is different than running on managed k8s in the cloud.

Providing all of the bits k8s needs to really work was going to really stretch our team, but we figured with the right support from a vendor, we could make it work. We worked up a spike of harvester + rancher + longhorn and had something that we could use as if it were a cloud. It was pretty slick.

Then we got the pricing on support for all of that, and decided to spend that half million elsewhere.

We own our hardware, we rent cabs and pay for power & network. We've got a pretty simple pxeboot setup to provision hardware with a bare OS that we can use with chef to provide the common bits needed.

It's not 'ultimately flexible in every way', but it's 'flexible enough to meet the needs of our workloads'.

Negative. No external tool/company has ssh access. GHA is strictly for CI, which is decoupled from the actual deploy.

If we do decide to tie it in, it will be using the GH Deployment API to inform the local tool on CI status or something.

mrsk doesn't require rails. It makes no assumptions about what you're running, we deploy a golang service with it.

mrsk does require a ruby install on your machine, tho.

IP addresses are easy to use in the configurations that inspired mrsk. Small apps that are fairly static. There are two main problems that mrsk is trying to solve.

1. Moving our stuff out of the cloud without going back to static hosts. 2. Giving new rails devs a tool where they can deploy their application easily, in a modern fashion.

Both of these are not so large or complex that you must use hostnames in configs instead of IP addresses. I will note, that most of our internal configs, do in fact, use hostnames rather than IP's. But judging a tool because an example used an IP address seems shortsighted.

There are plenty of things in mrsk to discuss without fixating on that.