Add instructions for creating systemd units

[jmeekhof]

This pull request introduces new containerization and systemd integration options for the dnsscale project, along with comprehensive documentation for running the service under both standard systemd and Podman Quadlet environments. The changes provide example unit files, environment setup instructions, and scripts to streamline installation and deployment.

Containerization and Build Improvements:

• Added a multi-stage Containerfile for building and packaging the dnsscale Go binary using Alpine Linux, enabling easier container-based deployments.
• Added a Podman-compatible Containerfile that clones the repository, caches Go modules, and builds the binary for containerized environments.

Systemd Integration and Documentation:

• Introduced a sample dnsscale.service unit file for user-level systemd, supporting environment files and custom paths for the executable.
• Added a shell script (install_service.sh) to automate installation of the systemd unit file into the correct user configuration directory.
• Provided detailed documentation in systemd/README.md for configuring and running dnsscale as a user service, including environment and configuration file management.

Podman Quadlet Support and Documentation:

• Added systemd/podman/README.md with step-by-step instructions for running dnsscale using Podman Quadlet, including example Quadlet unit files, environment setup, and advanced user management tips.

---

Important

Adds systemd and Podman Quadlet support for dnsscale, including containerization improvements and detailed documentation.

• Containerization:
  • Added multi-stage Containerfile for building dnsscale Go binary using Alpine Linux.
  • Added Podman-compatible Containerfile for cloning, caching, and building the binary.
• Systemd Integration:
  • Introduced dnsscale.service unit file for user-level systemd with environment file support.
  • Added install_service.sh script for automating systemd unit file installation.
  • Documented systemd setup in systemd/README.md.
• Podman Quadlet Support:
  • Added systemd/podman/README.md with instructions for Podman Quadlet setup.
  • Provided example Quadlet unit files and environment setup guidance.

^{This description was created by for 7efa8ee. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 7efa8ee in 2 minutes and 28 seconds. Click for details.

• Reviewed 288 lines of code in 6 files
• Skipped 0 files when reviewing.
• Skipped posting 6 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. systemd/README.md:31

• Draft comment:
  The README example passes '--config=%h/dnsscale.yaml' on ExecStart but the provided unit file (systemd/dnsscale.service) omits it. Please align the examples to avoid confusion.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. systemd/podman/Containerfile:9

• Draft comment:
  Similar to the main Containerfile, consider explicitly providing an output flag (e.g. -o dnsscale) in the 'go build' command and ensure the ENTRYPOINT format is consistent.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The current code works fine without the explicit -o flag since Go will use the package name by default. The COPY command on line 12 shows it's already finding the binary correctly. The ENTRYPOINT format looks standard and correct. This seems like a style preference rather than a necessary change. Maybe there's a good reason to be explicit about the output location that I'm missing? The reference to "main Containerfile" suggests there might be consistency concerns across files. Even if there's another Containerfile with different conventions, this file works correctly as is. Being explicit about the output location doesn't add meaningful value here. The comment suggests a style change that doesn't improve functionality or clarity, and makes an unclear reference to ENTRYPOINT format issues that don't appear to exist.

3. systemd/podman/README.md:142

• Draft comment:
  Minor grammatical correction: change 'allows' to 'allow' in the instructions regarding .bashrc.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and suggests a minor grammatical correction. It doesn't provide a code suggestion or address a potential issue in the code. According to the rules, purely informative comments should be removed.

4. systemd/podman/README.md:29

• Draft comment:
  Consider standardizing configuration file paths between the systemd and Podman examples. The README for systemd uses '%h/dnsscale.yaml' while the Podman example mounts '%h/dnsscale/conf/dnsscale.yaml' to '/root/.dnsscale.yaml'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The inconsistency is real and could be confusing to users. However, there may be valid reasons for the different paths - Podman containers often need different file organization than native systemd services. The comment doesn't indicate a clear problem that needs fixing, just points out a difference. Per the rules, we should not make purely informative comments without a clear action needed. The paths being different might actually be intentional due to the different needs of containerized vs native services. Am I being too quick to assume this is a real issue? Good point - without understanding the architectural reasons for the different paths, this comment may be premature and potentially misleading. The comment should be deleted as it only points out a difference without clear evidence that standardization is needed or beneficial.

5. systemd/podman/README.md:3

• Draft comment:
  Typo: In "using Quadlet's to manage services.", the apostrophe is likely unintentional. Suggest changing "Quadlet's" to "Quadlets".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the grammar, it's a very minor issue in documentation. The meaning is still clear despite the typo. The rules state we should not make purely informative comments or unimportant ones. This seems to fall into that category. The incorrect apostrophe could be seen as affecting readability and professional appearance of the documentation. Documentation quality is important. While documentation quality matters, this is an extremely minor issue that doesn't impact understanding. The rules specifically say not to make comments about obvious or unimportant issues. This comment should be deleted as it addresses a trivial grammatical issue that doesn't materially impact the documentation's usefulness.

6. systemd/podman/README.md:143

• Draft comment:
  Typo: The phrase "This will allows the user" contains an unnecessary 's'. Consider changing it to "This will allow the user".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the grammar error is real, our rules emphasize focusing on code logic and important issues. Grammar fixes in documentation, while correct, are very minor and could be seen as noise in the review process. This is especially true in a README file where the meaning is still perfectly clear despite the minor grammatical error. The comment is technically correct, but am I being too strict by suggesting we remove a valid correction just because it's minor? The rules explicitly state to avoid obvious or unimportant comments. This grammatical fix, while correct, doesn't impact understanding or functionality. We should remove this comment as it's too minor and doesn't affect code functionality or documentation clarity.

Workflow ID: wflow_CBkUApvA00uK4XfW

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Consider specifying the output binary name (using -o) and using the exec array form for ENTRYPOINT (as in the Podman variant) for consistency and to avoid shell issues.

Suggested change

	RUN GOARCH=$TARGETARCH go build
	RUN GOARCH=$TARGETARCH go build -o dnsscale

[ellipsis-dev]

Consider including a restart policy (e.g. Restart=on-failure) in the service file to improve resilience.

[ellipsis-dev]

Typo: change "Quadlet's" to "Quadlets" to use the correct plural form.

Suggested change

	If you're running Podman, you also have the option of using Quadlet's to manage services.
	If you're running Podman, you also have the option of using Quadlets to manage services.