4 ms·

Containers are not a meme What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. > a sysadmin Sure, f

Containers are not a meme What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. > a sysadmin Sure, for the deployment of stuff containers are very good. But you know people were using stuff like chroots before that right? I don't think I'm deploying this debugging system in a webserver.

calineczka 4y ago
> creating a container for any minor thing like npm + some js project I am backend engineer with a non-JS background and to me that's a a very useful thing. I really don't want to install specific node version, yarn version, etc to run some node/JS application. If I can just docker-compose up that's much easier to me and I know it does not affect anything globally. So removing it after playing around is easy and non-risky.
- rixthefox 4y ago
  I think the point he was making was too many people and projects are turning towards containers as a sort of "end all" where we're abandoning local system dependencies by shipping applications with their own bundled versions of libraries. My biggest problem with this shift is I'm seeing is people are running their distribution updates and containers are still shipping with vulnerable versions of libraries. So a server admin updates his servers thinking he's all good, No, No he's not because $DEV hasn't updated their container dependencies and now that server gets pwned because here's yet another layer of dependencies I have to deal with on top of the ones I'm maintaining with the OS. So no, please don't make containers on everything just because you can, because more often than not the container you never intended to be used in production WILL be used in production because someone was lazy and didn't want to deal with the dependencies. Additionally, to your point, specific node versions? specific yarn versions? Is it really that unreasonable to demand libraries be backwards compatible with warnings on software saying a method is being depreciated? Like I can understand for major revision changes but seriously. I should be able to run the latest version of node and that code still work with warnings telling me that the code I've written will eventually stop working in later versions due to changes in the underlying setup. My point being, don't weigh on containers as a crutch for badly coded software. Operating systems have moved towards rolling releases, it's about time libraries and programming languages followed suit.
  - dotancohen 4y ago
    In what scenario does compromising a container pwn the server? If the server is running just for that container's application, then the server admin knows it is there and needs updating.
    - rixthefox 4y ago
      Container escapes are a very real security threat that need to be taken seriously. Just like you wouldn't let all your users have a remote shell on your machines even if they are locked down. Just because they can't get anywhere doesn't mean they can't find ways out of that. If you're on the machine and can run whatever code you want, it's not a matter of if, it's when. The admin may know what applications they are running in the container but I can bet you they don't know every library that container is shipping and I hold very little faith that these admins are going to pin a laundry list of every single container they run along with all the different versions of libraries each container is bringing and constantly checking that list for CVEs. This problem increases for every single container you bring onto that server. Edit: I love containers, don't get me wrong. I've seen first-hand how incredible it is to be able to set up an application inside a container and then remove that application and have no residual packages containing the libraries and dependencies that program needed. I get it. I just don't like how dependent we've become on them. Now I'm a network engineer first, and server admin second. I don't want to spend a majority of my time pinging container maintainers to update their dependencies when an updated version of a library comes out. I expect to be able to update my local copy of that library and get on with my day and not have to worry about when this library is going to get patched in each of those containers.
      - dotancohen 4y ago
        I agree with every word, well stated.
  - raverbashing 4y ago
    Thanks, you got my point! And might I add, some people are shipping containers with full unoptimized Ubuntu (or other large distros) for running projects that are kilobytes in size
piaste 4y ago
> What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. You couldn't have picked two more different examples. Go apps are generally pretty clean statically-linked, native binaries and will be happy to just run from their directory without touching anything else. Containerization is usually unneeded, though if you already have a container ecosystem then they will fit in with no fuss, since the container images are basically glorified tarballs (COPY app/ . RUN foo). Node.js apps on the other side combine an interpreted language, a messy package management ecosystem, and a fragile and persnickety toolchain that will happily leave dirty stuff in your filesystem and/or your PATH, in order to maximize the risk of dependency-related screwups. Containerization is an absolute godsend for them.
- raverbashing 4y ago
  > Go apps are generally pretty clean statically-linked, I know, that's why I put it as an example (of something that doesn't need docker) > and a fragile and persnickety toolchain that will happily leave dirty stuff in your filesystem and/or your PATH Docker existing shouldn't be an excuse for npm behaving like this ;) But I agree, for deployment it is good. But you can still run npm projects without it
  - yjftsjthsd-h 4y ago
    > Docker existing shouldn't be an excuse for npm behaving like this ;) I don't care about the direction of causality, I just want the stupid thing to run on my computer and not pollute my home directory,and docker solves that and solves it well. Edit: Although actually about the only time I'm touching node is to ship it in a container image for deployment on a cluster somewhere, which is even more compelling.
    - sedachv 4y ago
      There are much better tools for doing that, such as Guix profiles and nix-shell, which also happen to be better tools for making container images. Linux container images are a distribution mechanism that does not do anything to address package and dependency management other than shifting the problem somewhere else.
__MatrixMan__ 4y ago
Sure they are. Or rather, their pattern of use is. Wearing your seatbelt is also a meme. Just because something is a meme doesn't mean it's not useful.

calineczka 4y ago

> creating a container for any minor thing like npm + some js project I am backend engineer with a non-JS background and to me that's a a very useful thing. I really don't want to install specific node version, yarn version, etc to run some node/JS application. If I can just docker-compose up that's much easier to me and I know it does not affect anything globally. So removing it after playing around is easy and non-risky.

rixthefox 4y ago
I think the point he was making was too many people and projects are turning towards containers as a sort of "end all" where we're abandoning local system dependencies by shipping applications with their own bundled versions of libraries. My biggest problem with this shift is I'm seeing is people are running their distribution updates and containers are still shipping with vulnerable versions of libraries. So a server admin updates his servers thinking he's all good, No, No he's not because $DEV hasn't updated their container dependencies and now that server gets pwned because here's yet another layer of dependencies I have to deal with on top of the ones I'm maintaining with the OS. So no, please don't make containers on everything just because you can, because more often than not the container you never intended to be used in production WILL be used in production because someone was lazy and didn't want to deal with the dependencies. Additionally, to your point, specific node versions? specific yarn versions? Is it really that unreasonable to demand libraries be backwards compatible with warnings on software saying a method is being depreciated? Like I can understand for major revision changes but seriously. I should be able to run the latest version of node and that code still work with warnings telling me that the code I've written will eventually stop working in later versions due to changes in the underlying setup. My point being, don't weigh on containers as a crutch for badly coded software. Operating systems have moved towards rolling releases, it's about time libraries and programming languages followed suit.
- dotancohen 4y ago
  In what scenario does compromising a container pwn the server? If the server is running just for that container's application, then the server admin knows it is there and needs updating.
  - rixthefox 4y ago
    Container escapes are a very real security threat that need to be taken seriously. Just like you wouldn't let all your users have a remote shell on your machines even if they are locked down. Just because they can't get anywhere doesn't mean they can't find ways out of that. If you're on the machine and can run whatever code you want, it's not a matter of if, it's when. The admin may know what applications they are running in the container but I can bet you they don't know every library that container is shipping and I hold very little faith that these admins are going to pin a laundry list of every single container they run along with all the different versions of libraries each container is bringing and constantly checking that list for CVEs. This problem increases for every single container you bring onto that server. Edit: I love containers, don't get me wrong. I've seen first-hand how incredible it is to be able to set up an application inside a container and then remove that application and have no residual packages containing the libraries and dependencies that program needed. I get it. I just don't like how dependent we've become on them. Now I'm a network engineer first, and server admin second. I don't want to spend a majority of my time pinging container maintainers to update their dependencies when an updated version of a library comes out. I expect to be able to update my local copy of that library and get on with my day and not have to worry about when this library is going to get patched in each of those containers.
    - dotancohen 4y ago
      I agree with every word, well stated.
- raverbashing 4y ago
  Thanks, you got my point! And might I add, some people are shipping containers with full unoptimized Ubuntu (or other large distros) for running projects that are kilobytes in size

piaste 4y ago

> What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. You couldn't have picked two more different examples. Go apps are generally pretty clean statically-linked, native binaries and will be happy to just run from their directory without touching anything else. Containerization is usually unneeded, though if you already have a container ecosystem then they will fit in with no fuss, since the container images are basically glorified tarballs (COPY app/ . RUN foo). Node.js apps on the other side combine an interpreted language, a messy package management ecosystem, and a fragile and persnickety toolchain that will happily leave dirty stuff in your filesystem and/or your PATH, in order to maximize the risk of dependency-related screwups. Containerization is an absolute godsend for them.

raverbashing 4y ago
> Go apps are generally pretty clean statically-linked, I know, that's why I put it as an example (of something that doesn't need docker) > and a fragile and persnickety toolchain that will happily leave dirty stuff in your filesystem and/or your PATH Docker existing shouldn't be an excuse for npm behaving like this ;) But I agree, for deployment it is good. But you can still run npm projects without it
- yjftsjthsd-h 4y ago
  > Docker existing shouldn't be an excuse for npm behaving like this ;) I don't care about the direction of causality, I just want the stupid thing to run on my computer and not pollute my home directory,and docker solves that and solves it well. Edit: Although actually about the only time I'm touching node is to ship it in a container image for deployment on a cluster somewhere, which is even more compelling.
  - sedachv 4y ago
    There are much better tools for doing that, such as Guix profiles and nix-shell, which also happen to be better tools for making container images. Linux container images are a distribution mechanism that does not do anything to address package and dependency management other than shifting the problem somewhere else.

__MatrixMan__ 4y ago

Sure they are. Or rather, their pattern of use is. Wearing your seatbelt is also a meme. Just because something is a meme doesn't mean it's not useful.