3 ms·

What value is added by swapping Docker out for an alternative on ECS? It's (at least as I understand it) basically an implementation detail, and well beneath th

by dmw_ng 3y ago

What value is added by swapping Docker out for an alternative on ECS? It's (at least as I understand it) basically an implementation detail, and well beneath the "covered by AWS support, don't touch" surface

user3939382 3y ago
You're right in a way, I really don't care what AWS does under the hood. The bigger issue is that I don't want any avoidable discrepancies between what I'm testing with on local and what I'm deploying. Obviously it's never 1:1 because my local isn't an AWS cloud infrastructure, but up til now the container engine isn't a variable.
- acdha 3y ago
  I mean, that’s a worthy goal but it’s not necessary: discrepancies like that are uncommon and since there are many other potential differences between your desktop and the server environment you need to have a robust test suite in any case to make sure you aren’t accidentally over-coupling your code to your development system.
  - user3939382 3y ago
    > discrepancies like that are uncommon Are you saying differences between Podman and Docker are uncommon? My untested assumption is that they're not uncommon just given how new Podman is. Testing is nice but you don't want to have to wait for that to run to find issues that you could make immediately obvious without it.
    - acdha 3y ago
      Yes. I’ve been using Podman for ages and a lot of the Kubernetes world is no longer using dockerd, and it generally just works. You can shoot yourself in the foot with policy choices but there’s a 0% chance that the ECS team would ship something like that without heavy testing. It’s also not something you need instant feedback on continuously while you work. The kind of things switching container runtimes will expose are unlikely to get caught by your local tests anyway so you’re most likely to only find it on your servers with lots of data and higher activity anyway.

by dmw_ng 3y ago

user3939382 3y ago

You're right in a way, I really don't care what AWS does under the hood. The bigger issue is that I don't want any avoidable discrepancies between what I'm testing with on local and what I'm deploying. Obviously it's never 1:1 because my local isn't an AWS cloud infrastructure, but up til now the container engine isn't a variable.

acdha 3y ago
I mean, that’s a worthy goal but it’s not necessary: discrepancies like that are uncommon and since there are many other potential differences between your desktop and the server environment you need to have a robust test suite in any case to make sure you aren’t accidentally over-coupling your code to your development system.
- user3939382 3y ago
  > discrepancies like that are uncommon Are you saying differences between Podman and Docker are uncommon? My untested assumption is that they're not uncommon just given how new Podman is. Testing is nice but you don't want to have to wait for that to run to find issues that you could make immediately obvious without it.
  - acdha 3y ago
    Yes. I’ve been using Podman for ages and a lot of the Kubernetes world is no longer using dockerd, and it generally just works. You can shoot yourself in the foot with policy choices but there’s a 0% chance that the ECS team would ship something like that without heavy testing. It’s also not something you need instant feedback on continuously while you work. The kind of things switching container runtimes will expose are unlikely to get caught by your local tests anyway so you’re most likely to only find it on your servers with lots of data and higher activity anyway.