2 ms·

It’s the cattle not pets mindset. In most organizations the sysadmin team is really undersized. Not uncommon to have one admin per several hundred systems. In s

It’s the cattle not pets mindset. In most organizations the sysadmin team is really undersized. Not uncommon to have one admin per several hundred systems. In such places, there is no time to care for individual servers. If a server is misbehaving we blow it away and spin up a clean replacement. Declarative scripts make it easy to manage a fleet.

OJFord 2y ago
I think that's.. perhaps not orthogonal, but has some orthogonal component - you could certainly have something like: for i in range(100): ip = cidrhost(subnet, i) if exists := get_server(ip): continue create_server(ip=ip) and so on. I don't like it, but because it's procedural/imperative, not because it's particularly more 'petty' than the Terraform (or equivalent) would be. For me it's more about what I'm doing, conceptually. I want a server to exist, it to have access to this S3 bucket, etc. - the logic of how to interface with the APIs to make that happen, to manage their lifecycle and check current state etc. isn't what I'm thinking about. (In Terraform terms, that belongs in the provider.) When I write the above I'm just thinking I want 100 servers, so: resource "cloud_server" "my_servers" { count = 100 ip = cidrhost(subnet, count.index) # and so on } comes much more naturally.
- linuxdude314 2y ago
  This fails completely even at small scale when the script is interrupted before finishing. The difference between just using some Python vs Terraform is idempotency. TF isn’t going to touch the nodes the script succeeded on; if you have to start your for-loop script it will, which may not be desirable. Frankly these days configuration management is a bit dated… You’re much better off in most cases using a tool like Packer with whatever system you want to bake an image, then use a simple user-data script for customization. It’s very hard to scale continuous config management to thousands of servers.
  - OJFord 2y ago
    Eh, any way you do it could leave it in an unfinished state if interrupted, I'm not too bothered about that. (But it does sound like you think I was speaking in favour of doing it in a procedural python script sort of way? I was not.) Packer and Terraform do different jobs (they're both by Hashicorp!) - you can bake an immutable image all you like, you still need to get a server, put the image on it, give it that S3 bucket it needs, IAM, etc.
    - jacobr1 2y ago
      They work together to produce immutable cattle. The alternative is managing a pool of servers where you are doing things like in-place patch upgrades, vs a teardown of the old infra and replacing it with the newly baked servers.
      - OJFord 2y ago
        I'm well aware, I just don't see what 'use Packer' has to do with choice of programming paradigm for Terraform or other tool in that role.

OJFord 2y ago

I think that's.. perhaps not orthogonal, but has some orthogonal component - you could certainly have something like: for i in range(100): ip = cidrhost(subnet, i) if exists := get_server(ip): continue create_server(ip=ip) and so on. I don't like it, but because it's procedural/imperative, not because it's particularly more 'petty' than the Terraform (or equivalent) would be. For me it's more about what I'm doing, conceptually. I want a server to exist, it to have access to this S3 bucket, etc. - the logic of how to interface with the APIs to make that happen, to manage their lifecycle and check current state etc. isn't what I'm thinking about. (In Terraform terms, that belongs in the provider.) When I write the above I'm just thinking I want 100 servers, so: resource "cloud_server" "my_servers" { count = 100 ip = cidrhost(subnet, count.index) # and so on } comes much more naturally.

linuxdude314 2y ago
This fails completely even at small scale when the script is interrupted before finishing. The difference between just using some Python vs Terraform is idempotency. TF isn’t going to touch the nodes the script succeeded on; if you have to start your for-loop script it will, which may not be desirable. Frankly these days configuration management is a bit dated… You’re much better off in most cases using a tool like Packer with whatever system you want to bake an image, then use a simple user-data script for customization. It’s very hard to scale continuous config management to thousands of servers.
- OJFord 2y ago
  Eh, any way you do it could leave it in an unfinished state if interrupted, I'm not too bothered about that. (But it does sound like you think I was speaking in favour of doing it in a procedural python script sort of way? I was not.) Packer and Terraform do different jobs (they're both by Hashicorp!) - you can bake an immutable image all you like, you still need to get a server, put the image on it, give it that S3 bucket it needs, IAM, etc.
  - jacobr1 2y ago
    They work together to produce immutable cattle. The alternative is managing a pool of servers where you are doing things like in-place patch upgrades, vs a teardown of the old infra and replacing it with the newly baked servers.
    - OJFord 2y ago
      I'm well aware, I just don't see what 'use Packer' has to do with choice of programming paradigm for Terraform or other tool in that role.