4 ms·

> If you're running on a single host anyways, why not just use init scripts or unit files? You're absolutely right. Init scripts and systemd unit files could d

by Kalium 7y ago

> If you're running on a single host anyways, why not just use init scripts or unit files? You're absolutely right. Init scripts and systemd unit files could do every single thing here. With that said, might there be other reasons? The ability to have multiple applications running simultaneously on a host without having to know about or step around each other is nice. This gets rid of a major headache, especially when you didn't write the applications and they might not all be well-behaved in a shared space. Having services automatically restart and having their dependent services handled is also a nice bonus, including isolating one instance of a service from another in a way that changing a port number won't go around. Personally, I've also found that init scripts aren't always easy to learn and manage either. But YMMV.

falcolas 7y ago
> The ability to have multiple applications running simultaneously on a host without having to know about or step around each other is nice. If you're running containers, you get that for free. You can run containers without running Kubernetes. And unit/init files are no harder (for simple cases like this, it's probably significantly easier) than learning the Kubernetes YAML DSL. The unit files in particular will definitely be simpler, since systemd is container aware.
- Kalium 7y ago
  I'm extremely cynical about init scripts. I've encountered too many crusty old systems where the init scripts used some bizarre old trick from the 70s. Anyway. Yes, you're once more absolutely correct. Every thing here can be done with unit scripts and init scripts. Personally, I've not found that the YAML DSL is more complex or challenging than the systemd units. At one point I didn't know either, but I definitely had bad memories of managing N inter-dependent init scripts. I found it easier to learn something I could use at home for an rpi and at work for a fleet of servers, instead of learning unit scripting for my rpi and k8s for the fleet. It's been my experience that "simple" is generally a matter of opinion and perspective.
  - jen20 7y ago
    > I've encountered too many crusty old systems where the init scripts used some bizarre old trick from the 70s. Scripts sure - but modern Linux systems use systemd units, not shell scripts for this.
    - Kalium 7y ago
      Even here on HN, one need not look far to find someone who resents everything about systemd and insists on using a non-systemd distro. Such people run systems in real life, too.
      - falcolas 7y ago
        Should you run into such a system, you're still just writing code, and interacting with a daemon that takes care of the hardest parts of init scripts for you. There are no pid files. There are no file locks. There is no "daemonization" to worry about. There is no tracking the process to ensure it's still alive. Just think about how you would interact with the docker daemon to start, stop, restart, and probe the status of a container, and write code to do exactly that. Frankly, Docker containers are the simplest thing you could ever have to write an init script for.
      - aganame 7y ago
        Do you have evidence that they run real systems?
        Kalium 7y ago
        Evidence I'm comfortable citing in public? No. Experience suggesting that at least one such person runs at least one real system? Yes.
  - falcolas 7y ago
    Let's get concrete. Here's about as complex of a unit file as you will find for running a docker container: [Unit] Description=My Container After=docker.service Requires=docker.service [Service] Restart=always ExecStart=/usr/bin/docker start mycontainer ExecStop=/usr/bin/docker stop mycontainer 75% of this is boilerplate, but there's not a lot of repetition and most of it is relevant to the service itself. The remaining lines describes how you interact with Docker normally. In comparison, here's a definition to set up the same container as a deployment in Kubernetes. apiVersion: v1 kind: Deployment metadata: name: mycontainer labels: app: myapp spec: replicas: 1 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: my-container image: mycontainer Almost 90% of this has meaning only to Kubernetes, not even to the people who will have to view this object later. There's a lot of repetition of content (namely labels and nested specs), and the "template" portion is not self-explanatory (what is it a template of? Why is it considered a "template"?) This is not to say that these abstractions are useless, particularly when you have hundreds of nodes and thousands of pods. But for a one host node, it's a lot of extra conceptual work (not to mention googling) to avoid learning how to write unit files.

by Kalium 7y ago

falcolas 7y ago

> The ability to have multiple applications running simultaneously on a host without having to know about or step around each other is nice. If you're running containers, you get that for free. You can run containers without running Kubernetes. And unit/init files are no harder (for simple cases like this, it's probably significantly easier) than learning the Kubernetes YAML DSL. The unit files in particular will definitely be simpler, since systemd is container aware.

Kalium 7y ago
I'm extremely cynical about init scripts. I've encountered too many crusty old systems where the init scripts used some bizarre old trick from the 70s. Anyway. Yes, you're once more absolutely correct. Every thing here can be done with unit scripts and init scripts. Personally, I've not found that the YAML DSL is more complex or challenging than the systemd units. At one point I didn't know either, but I definitely had bad memories of managing N inter-dependent init scripts. I found it easier to learn something I could use at home for an rpi and at work for a fleet of servers, instead of learning unit scripting for my rpi and k8s for the fleet. It's been my experience that "simple" is generally a matter of opinion and perspective.
- jen20 7y ago
  > I've encountered too many crusty old systems where the init scripts used some bizarre old trick from the 70s. Scripts sure - but modern Linux systems use systemd units, not shell scripts for this.
  - Kalium 7y ago
    Even here on HN, one need not look far to find someone who resents everything about systemd and insists on using a non-systemd distro. Such people run systems in real life, too.
    - falcolas 7y ago
      Should you run into such a system, you're still just writing code, and interacting with a daemon that takes care of the hardest parts of init scripts for you. There are no pid files. There are no file locks. There is no "daemonization" to worry about. There is no tracking the process to ensure it's still alive. Just think about how you would interact with the docker daemon to start, stop, restart, and probe the status of a container, and write code to do exactly that. Frankly, Docker containers are the simplest thing you could ever have to write an init script for.
    - aganame 7y ago
      Do you have evidence that they run real systems?
      - Kalium 7y ago
        Evidence I'm comfortable citing in public? No. Experience suggesting that at least one such person runs at least one real system? Yes.
- falcolas 7y ago
  Let's get concrete. Here's about as complex of a unit file as you will find for running a docker container: [Unit] Description=My Container After=docker.service Requires=docker.service [Service] Restart=always ExecStart=/usr/bin/docker start mycontainer ExecStop=/usr/bin/docker stop mycontainer 75% of this is boilerplate, but there's not a lot of repetition and most of it is relevant to the service itself. The remaining lines describes how you interact with Docker normally. In comparison, here's a definition to set up the same container as a deployment in Kubernetes. apiVersion: v1 kind: Deployment metadata: name: mycontainer labels: app: myapp spec: replicas: 1 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: my-container image: mycontainer Almost 90% of this has meaning only to Kubernetes, not even to the people who will have to view this object later. There's a lot of repetition of content (namely labels and nested specs), and the "template" portion is not self-explanatory (what is it a template of? Why is it considered a "template"?) This is not to say that these abstractions are useless, particularly when you have hundreds of nodes and thousands of pods. But for a one host node, it's a lot of extra conceptual work (not to mention googling) to avoid learning how to write unit files.