7 ms·

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.

by 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.
- Kalium 7y ago
  That's a great example! Thank you very much for sharing. That said, it's been my experience that a modern docker application is only occasionally a single container. More often it's a heterogeneous mix of three or more containers, collectively comprising an application. Now we've got multiple unit files, each of which handles a different aspect of the application, and now this notion of a "service" conflates system-level services like docker and application-level things like redis. There's a resulting explosion of cognitive complexity as I have to keep track of what's part of the application and what's a system-level service. Meanwhile, the Kubernetes YAML requires an extra handful of lines under the "containers" key. Again, thank you for bringing forward this concrete example. It's a very kind gesture. It's just possible that use-cases and personal evaluations of complexity might differ and lead people to different conclusions.

by Kalium 7y ago

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.

Kalium 7y ago
That's a great example! Thank you very much for sharing. That said, it's been my experience that a modern docker application is only occasionally a single container. More often it's a heterogeneous mix of three or more containers, collectively comprising an application. Now we've got multiple unit files, each of which handles a different aspect of the application, and now this notion of a "service" conflates system-level services like docker and application-level things like redis. There's a resulting explosion of cognitive complexity as I have to keep track of what's part of the application and what's a system-level service. Meanwhile, the Kubernetes YAML requires an extra handful of lines under the "containers" key. Again, thank you for bringing forward this concrete example. It's a very kind gesture. It's just possible that use-cases and personal evaluations of complexity might differ and lead people to different conclusions.