Fossil SCM
Grammar and spelling fix pass on the new nspawn material in the containers doc.
Commit
5405aa57389ef9670b0bbafc57149f0072060de8f90316925144b6c0d83cb982
Parent
4ddd8847097118d…
1 file changed
+7
-7
+7
-7
| --- www/containers.md | ||
| +++ www/containers.md | ||
| @@ -852,11 +852,11 @@ | ||
| 852 | 852 | ``` |
| 853 | 853 | |
| 854 | 854 | You would also need to un-drop the `CAP_NET_BIND_SERVICE` capability |
| 855 | 855 | to allow Fossil to bind to this low-numbered port. |
| 856 | 856 | |
| 857 | -We use of systemd’s template file feature to allow multiple Fossil | |
| 857 | +We use systemd’s template file feature to allow multiple Fossil | |
| 858 | 858 | servers running on a single machine, each on a different TCP port, |
| 859 | 859 | as when proxying them out as subdirectories of a larger site. |
| 860 | 860 | To add another project, you must first clone the base “machine” layer: |
| 861 | 861 | |
| 862 | 862 | ``` |
| @@ -938,17 +938,17 @@ | ||
| 938 | 938 | changed layers. Furthermore, when you base multiple containers |
| 939 | 939 | on a single image, they don’t make copies of the base layers; |
| 940 | 940 | they can share them, because base layers are immutable, thus |
| 941 | 941 | cannot cross-contaminate. |
| 942 | 942 | |
| 943 | - Because we use `sysetmd-nspawn --read-only`, we get *some* | |
| 943 | + Because we use `systemd-nspawn --read-only`, we get *some* | |
| 944 | 944 | of this benefit, particularly when using `machinectl` with |
| 945 | 945 | `/var/lib/machines` as a btrfs volume. Even so, the disk space |
| 946 | 946 | and network I/O optimizations go deeper in the Docker and Podman |
| 947 | 947 | worlds. |
| 948 | 948 | |
| 949 | -4. **Tooling.** Hand-creating and modifying those systemd | |
| 949 | +4. **Tooling.** Hand-creating and modifying those `systemd` | |
| 950 | 950 | files sucks compared to “`podman container create ...`” This |
| 951 | 951 | is but one of many affordances you will find in the runtimes |
| 952 | 952 | aimed at daily-use devops warriors. |
| 953 | 953 | |
| 954 | 954 | 5. **Network virtualization.** In the scheme above, we turn off the |
| @@ -960,19 +960,19 @@ | ||
| 960 | 960 | up in a single option, whereas `systemd-nspawn --port` does |
| 961 | 961 | approximately *none* of that despite the command’s superficial |
| 962 | 962 | similarity. |
| 963 | 963 | |
| 964 | 964 | From a purely functional point of view, this isn’t a huge problem if |
| 965 | - you consider the “inbound” service direction only, being external | |
| 965 | + you consider the inbound service direction only, being external | |
| 966 | 966 | connections to the Fossil service we’re providing. Since we do want |
| 967 | 967 | this Fossil service to be exposed — else why are we running it? — we |
| 968 | 968 | get all the control we need via `fossil server --localhost` and |
| 969 | 969 | similar options. |
| 970 | 970 | |
| 971 | 971 | The complexity of the `systemd` networking infrastructure’s |
| 972 | 972 | interactions with containers make more sense when you consider the |
| 973 | - “outbound” path. Consider what happens if you enable Fossil’s | |
| 973 | + outbound path. Consider what happens if you enable Fossil’s | |
| 974 | 974 | optional TH1 docs feature plus its Tcl evaluation feature. That |
| 975 | 975 | would enable anyone with the rights to commit to your repository the |
| 976 | 976 | ability to make arbitrary network connections on the Fossil host. |
| 977 | 977 | Then, let us say you have a client-server DBMS server on that same |
| 978 | 978 | host, bound to localhost for private use by other services on the |
| @@ -985,15 +985,15 @@ | ||
| 985 | 985 | This author expects that the set of considerations is broader than |
| 986 | 986 | presented here, but that it suffices to make our case as it is: if you |
| 987 | 987 | can afford the space of Podman or Docker, we strongly recommend using |
| 988 | 988 | either of them over the much lower-level `systemd-container` |
| 989 | 989 | infrastructure. You’re getting a considerable amount of value for the |
| 990 | -higher runtime cost; it isn’t simply overhead for little return. | |
| 990 | +higher runtime cost; it isn’t pointless overhead. | |
| 991 | 991 | |
| 992 | 992 | (Incidentally, these are essentially the same reasons why we no longer |
| 993 | 993 | talk about the `crun` tool underpinning Podman in this document. It’s |
| 994 | -even more limited, making it even more difficult to administer while | |
| 994 | +even more limited than `nspawn`, making it even more difficult to administer while | |
| 995 | 995 | providing no runtime size advantage. The `runc` tool underpinning |
| 996 | 996 | Docker is even worse on this score, being scarcely easier to use than |
| 997 | 997 | `crun` while having a much larger footprint.) |
| 998 | 998 | |
| 999 | 999 | [ndcmp]: https://wiki.archlinux.org/title/systemd-networkd#Usage_with_containers |
| 1000 | 1000 |
| --- www/containers.md | |
| +++ www/containers.md | |
| @@ -852,11 +852,11 @@ | |
| 852 | ``` |
| 853 | |
| 854 | You would also need to un-drop the `CAP_NET_BIND_SERVICE` capability |
| 855 | to allow Fossil to bind to this low-numbered port. |
| 856 | |
| 857 | We use of systemd’s template file feature to allow multiple Fossil |
| 858 | servers running on a single machine, each on a different TCP port, |
| 859 | as when proxying them out as subdirectories of a larger site. |
| 860 | To add another project, you must first clone the base “machine” layer: |
| 861 | |
| 862 | ``` |
| @@ -938,17 +938,17 @@ | |
| 938 | changed layers. Furthermore, when you base multiple containers |
| 939 | on a single image, they don’t make copies of the base layers; |
| 940 | they can share them, because base layers are immutable, thus |
| 941 | cannot cross-contaminate. |
| 942 | |
| 943 | Because we use `sysetmd-nspawn --read-only`, we get *some* |
| 944 | of this benefit, particularly when using `machinectl` with |
| 945 | `/var/lib/machines` as a btrfs volume. Even so, the disk space |
| 946 | and network I/O optimizations go deeper in the Docker and Podman |
| 947 | worlds. |
| 948 | |
| 949 | 4. **Tooling.** Hand-creating and modifying those systemd |
| 950 | files sucks compared to “`podman container create ...`” This |
| 951 | is but one of many affordances you will find in the runtimes |
| 952 | aimed at daily-use devops warriors. |
| 953 | |
| 954 | 5. **Network virtualization.** In the scheme above, we turn off the |
| @@ -960,19 +960,19 @@ | |
| 960 | up in a single option, whereas `systemd-nspawn --port` does |
| 961 | approximately *none* of that despite the command’s superficial |
| 962 | similarity. |
| 963 | |
| 964 | From a purely functional point of view, this isn’t a huge problem if |
| 965 | you consider the “inbound” service direction only, being external |
| 966 | connections to the Fossil service we’re providing. Since we do want |
| 967 | this Fossil service to be exposed — else why are we running it? — we |
| 968 | get all the control we need via `fossil server --localhost` and |
| 969 | similar options. |
| 970 | |
| 971 | The complexity of the `systemd` networking infrastructure’s |
| 972 | interactions with containers make more sense when you consider the |
| 973 | “outbound” path. Consider what happens if you enable Fossil’s |
| 974 | optional TH1 docs feature plus its Tcl evaluation feature. That |
| 975 | would enable anyone with the rights to commit to your repository the |
| 976 | ability to make arbitrary network connections on the Fossil host. |
| 977 | Then, let us say you have a client-server DBMS server on that same |
| 978 | host, bound to localhost for private use by other services on the |
| @@ -985,15 +985,15 @@ | |
| 985 | This author expects that the set of considerations is broader than |
| 986 | presented here, but that it suffices to make our case as it is: if you |
| 987 | can afford the space of Podman or Docker, we strongly recommend using |
| 988 | either of them over the much lower-level `systemd-container` |
| 989 | infrastructure. You’re getting a considerable amount of value for the |
| 990 | higher runtime cost; it isn’t simply overhead for little return. |
| 991 | |
| 992 | (Incidentally, these are essentially the same reasons why we no longer |
| 993 | talk about the `crun` tool underpinning Podman in this document. It’s |
| 994 | even more limited, making it even more difficult to administer while |
| 995 | providing no runtime size advantage. The `runc` tool underpinning |
| 996 | Docker is even worse on this score, being scarcely easier to use than |
| 997 | `crun` while having a much larger footprint.) |
| 998 | |
| 999 | [ndcmp]: https://wiki.archlinux.org/title/systemd-networkd#Usage_with_containers |
| 1000 |
| --- www/containers.md | |
| +++ www/containers.md | |
| @@ -852,11 +852,11 @@ | |
| 852 | ``` |
| 853 | |
| 854 | You would also need to un-drop the `CAP_NET_BIND_SERVICE` capability |
| 855 | to allow Fossil to bind to this low-numbered port. |
| 856 | |
| 857 | We use systemd’s template file feature to allow multiple Fossil |
| 858 | servers running on a single machine, each on a different TCP port, |
| 859 | as when proxying them out as subdirectories of a larger site. |
| 860 | To add another project, you must first clone the base “machine” layer: |
| 861 | |
| 862 | ``` |
| @@ -938,17 +938,17 @@ | |
| 938 | changed layers. Furthermore, when you base multiple containers |
| 939 | on a single image, they don’t make copies of the base layers; |
| 940 | they can share them, because base layers are immutable, thus |
| 941 | cannot cross-contaminate. |
| 942 | |
| 943 | Because we use `systemd-nspawn --read-only`, we get *some* |
| 944 | of this benefit, particularly when using `machinectl` with |
| 945 | `/var/lib/machines` as a btrfs volume. Even so, the disk space |
| 946 | and network I/O optimizations go deeper in the Docker and Podman |
| 947 | worlds. |
| 948 | |
| 949 | 4. **Tooling.** Hand-creating and modifying those `systemd` |
| 950 | files sucks compared to “`podman container create ...`” This |
| 951 | is but one of many affordances you will find in the runtimes |
| 952 | aimed at daily-use devops warriors. |
| 953 | |
| 954 | 5. **Network virtualization.** In the scheme above, we turn off the |
| @@ -960,19 +960,19 @@ | |
| 960 | up in a single option, whereas `systemd-nspawn --port` does |
| 961 | approximately *none* of that despite the command’s superficial |
| 962 | similarity. |
| 963 | |
| 964 | From a purely functional point of view, this isn’t a huge problem if |
| 965 | you consider the inbound service direction only, being external |
| 966 | connections to the Fossil service we’re providing. Since we do want |
| 967 | this Fossil service to be exposed — else why are we running it? — we |
| 968 | get all the control we need via `fossil server --localhost` and |
| 969 | similar options. |
| 970 | |
| 971 | The complexity of the `systemd` networking infrastructure’s |
| 972 | interactions with containers make more sense when you consider the |
| 973 | outbound path. Consider what happens if you enable Fossil’s |
| 974 | optional TH1 docs feature plus its Tcl evaluation feature. That |
| 975 | would enable anyone with the rights to commit to your repository the |
| 976 | ability to make arbitrary network connections on the Fossil host. |
| 977 | Then, let us say you have a client-server DBMS server on that same |
| 978 | host, bound to localhost for private use by other services on the |
| @@ -985,15 +985,15 @@ | |
| 985 | This author expects that the set of considerations is broader than |
| 986 | presented here, but that it suffices to make our case as it is: if you |
| 987 | can afford the space of Podman or Docker, we strongly recommend using |
| 988 | either of them over the much lower-level `systemd-container` |
| 989 | infrastructure. You’re getting a considerable amount of value for the |
| 990 | higher runtime cost; it isn’t pointless overhead. |
| 991 | |
| 992 | (Incidentally, these are essentially the same reasons why we no longer |
| 993 | talk about the `crun` tool underpinning Podman in this document. It’s |
| 994 | even more limited than `nspawn`, making it even more difficult to administer while |
| 995 | providing no runtime size advantage. The `runc` tool underpinning |
| 996 | Docker is even worse on this score, being scarcely easier to use than |
| 997 | `crun` while having a much larger footprint.) |
| 998 | |
| 999 | [ndcmp]: https://wiki.archlinux.org/title/systemd-networkd#Usage_with_containers |
| 1000 |