3 ms·

What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currentl

by 9dev 3y ago

What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currently available.

Grimburger 3y ago
Nothing is difficult about them, compose is easy enough that you can grok it in a day. You saw the lament in my comment though and that speaks a deeper truth. If WSL took off quick enough we could have had lxc as the main player rather than the bastardisation of lxc that is docker.com For an open source project they make it incredibly hard to access what are essentially text files for containerisation setups on windows or mac? https://github.com/docker/hub-feedback/issues/1103 https://github.com/docker/hub-feedback/issues/1103
- 9dev 3y ago
  Compose is an open source project entirely separate to hub, though. The compose file specification is versioned separately, and will outlive Docker, probably. So I don’t quite get your criticism?
  - Grimburger 3y ago
    How are you using compose without docker? They are joined at the hip, criticism of one is criticism of the other. The days of cheap money are over, it's inevitable that certain SaaS companies will start tightening the screws on their users to match the returns they can get with cash in a bank. I just wish lxc (which docker was built off) got a chance to gain traction. It's miles ahead in DX and sure they serve different functionalities but can be used the same and the network effects can't be understated.
    - 9dev 3y ago
      No, that isn't true. Compose can absolutely be used with Docker replacements, and there is no reason you couldn't create an implementation for LXC, for example.
      - Grimburger 3y ago
        > Compose can absolutely be used with Docker replacements Can you point to some examples of this? LXC has profiles which can be mixed and matched for containers, it's got far more extensibility, compose files are a one-shot creation that gets copy/pasted/modified all over the place (we're all guilty of this), you need to read every single compose file and reboot unlike additively popping another profile on a linux container while it's running.
        9dev 3y ago
        Using Docker Compose with Podman: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose Using containerd: https://github.com/mc256/containerd-compose https://github.com/mc256/containerd-compose Using nerdctl: https://github.com/containerd/nerdctl https://github.com/containerd/nerdctl I'd really disagree that compose files are somehow one-shot, or blindly modified. To the contrary, really, we have them checked in with the source code. Upon deployment to the cluster, the (running) services will be intelligently updated or replaced (in a rolling manner, causing zero downtime). LXC might be more elegant, but I have no idea what simple, file-based format I could use to let engineers describe the environment their app should run in without compose. I need something that even junior devs can start up with a single command, that can be placed in the VCS along with the code, and that will not require deep Linux knowledge to get running. Open for suggestions here, really.

by 9dev 3y ago

What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currently available.

Grimburger 3y ago

Nothing is difficult about them, compose is easy enough that you can grok it in a day. You saw the lament in my comment though and that speaks a deeper truth. If WSL took off quick enough we could have had lxc as the main player rather than the bastardisation of lxc that is docker.com For an open source project they make it incredibly hard to access what are essentially text files for containerisation setups on windows or mac? https://github.com/docker/hub-feedback/issues/1103 https://github.com/docker/hub-feedback/issues/1103

9dev 3y ago
Compose is an open source project entirely separate to hub, though. The compose file specification is versioned separately, and will outlive Docker, probably. So I don’t quite get your criticism?
- Grimburger 3y ago
  How are you using compose without docker? They are joined at the hip, criticism of one is criticism of the other. The days of cheap money are over, it's inevitable that certain SaaS companies will start tightening the screws on their users to match the returns they can get with cash in a bank. I just wish lxc (which docker was built off) got a chance to gain traction. It's miles ahead in DX and sure they serve different functionalities but can be used the same and the network effects can't be understated.
  - 9dev 3y ago
    No, that isn't true. Compose can absolutely be used with Docker replacements, and there is no reason you couldn't create an implementation for LXC, for example.
    - Grimburger 3y ago
      > Compose can absolutely be used with Docker replacements Can you point to some examples of this? LXC has profiles which can be mixed and matched for containers, it's got far more extensibility, compose files are a one-shot creation that gets copy/pasted/modified all over the place (we're all guilty of this), you need to read every single compose file and reboot unlike additively popping another profile on a linux container while it's running.
      - 9dev 3y ago
        Using Docker Compose with Podman: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose Using containerd: https://github.com/mc256/containerd-compose https://github.com/mc256/containerd-compose Using nerdctl: https://github.com/containerd/nerdctl https://github.com/containerd/nerdctl I'd really disagree that compose files are somehow one-shot, or blindly modified. To the contrary, really, we have them checked in with the source code. Upon deployment to the cluster, the (running) services will be intelligently updated or replaced (in a rolling manner, causing zero downtime). LXC might be more elegant, but I have no idea what simple, file-based format I could use to let engineers describe the environment their app should run in without compose. I need something that even junior devs can start up with a single command, that can be placed in the VCS along with the code, and that will not require deep Linux knowledge to get running. Open for suggestions here, really.