Merge !1625: docker: improvements and fixes

Dockerfile

@@ -6,7 +6,6 @@ FROM debian:12 AS build
 ENV OBS_REPO=knot-resolver-latest
 ENV DISTROTEST_REPO=Debian_12
 
-
 RUN apt-get update -qq && \
 	apt-get -qqq -y install \
 		apt-transport-https ca-certificates wget \
@@ -25,11 +24,19 @@ RUN cd /source && \
 	git submodule update --init --recursive && \
 	git config --global user.name "Docker Build" && \
 	git config --global user.email docker-build@knot-resolver && \
-	sed s/knot-resolver/root/g -i meson_options.txt && git commit -a -m TMP && \
+	\
+	# Replace 'knot-resolver' user and group with 'root'
+	# in meson_options.tx and python/knot_resolver/constants.py.
+	# This is needed for the file/directory permissions validation
+	# and then for the proper functioning of the resolver.
+	sed s/knot-resolver/root/g -i meson_options.txt && \
+	sed 's/USER.*/USER = "root"/g' -i python/knot_resolver/constants.py && \
+	sed 's/GROUP.*/GROUP = "root"/g' -i python/knot_resolver/constants.py && \
+	git commit -a -m TMP && \
+	\
 	/root/.local/bin/apkg build-dep -y && \
 	/root/.local/bin/apkg build
 
-
 # Real container
 FROM debian:12-slim AS runtime
 
@@ -57,16 +64,18 @@ RUN apt-get install -y /pkg/*/*.deb && \
 	apt-get remove -y -qq curl gnupg2 && \
 	apt-get autoremove -y && \
 	apt-get clean && \
-	rm -rf /var/lib/apt/lists/* && \
-	mkdir /config
+	rm -rf /var/lib/apt/lists/*
 
-COPY etc/config/config.example.docker.yaml /config/config.yaml
+COPY etc/config/config.example.docker.yaml /etc/knot-resolver/config.yaml
 
 LABEL cz.knot-resolver.vendor="CZ.NIC"
 LABEL maintainer="[email protected]"
 
 # Export plain DNS, DoT, DoH and management interface
 EXPOSE 53/UDP 53/TCP 443/TCP 853/TCP 5000/TCP
 
+# Prepare shared config
+VOLUME /etc/knot-resolver
+
 ENTRYPOINT ["/usr/bin/knot-resolver"]
-CMD ["-c", "/config/config.yaml"]
+CMD ["-c", "/etc/knot-resolver/config.yaml"]

NEWS

@@ -1,10 +1,6 @@
 Knot Resolver 6.0.9 (2024-mm-dd)
 ================================
 
-Incompatible changes
---------------------
-- -f/--forks is removed (#631, !1602)
-
 Improvements
 ------------
 
@@ -20,6 +16,7 @@ Improvements
 - extended_errors: answer with EDE in more cases (!1585, !1588, !1590, !1592)
 - local-data: make DNAMEs work, i.e. generate CNAMEs (!1609)
 - daemon: use connected UDP sockets by default (#326, !1618)
+- docker: multiplatform builds (#922, !1623, !1625)
 
 Bugfixes
 --------
@@ -29,6 +26,7 @@ Bugfixes
 
 Incompatible changes
 --------------------
+- -f/--forks is removed (#631, !1602)
 - gnutls < 3.4 support is dropped, released over 9 years ago (!1601)
 - libuv < 1.27 support is dropped, released over 5 years ago (!1618)
 

doc/user/deployment-docker.rst

@@ -2,20 +2,49 @@
 Docker
 ******
 
-
 .. note::
 
-    Before version 6, our Docker images were not meant to be used in production. This is no longer the case and with the introduction of ``kres-manager``, Knot Resolver runs in containers without any issues.
+    Before version 6, our Docker images were not intended for production use due to the lack of ``systemd`` in Docker and
+    the inability to manage the multiple independent parts of the resolver.
+    This is no longer the case since the introduction of the Manager that automatically control other parts of the resolver.
+
+Knot Resolver official Docker image can be found at `Docker Hub <https://hub.docker.com/r/cznic/knot-resolver>`_.
+First you can try running the container in interactive mode.
+
+.. code-block:: bash
+
+    $ docker run --rm -ti --network host docker.io/cznic/knot-resolver:6
+
+For more robust deployments you will also probably need to configure network, for that see `Docker networking <https://docs.docker.com/engine/network/>`_.
+
+Now you can try sending a query to the resolver using `kdig <https://www.knot-dns.cz/docs/latest/html/man_kdig.html>`_.
 
-An official Docker image can be found on `Docker Hub <https://hub.docker.com/r/cznic/knot-resolver>`_. The image contains Knot Resolver as if it was installed from our official distro packages.
+.. code-block:: bash
+
+    $ kdig example.com @127.0.0.1
+    $ kdig nic.cz @127.0.0.1#443 +https
+
+The image contains full Knot Resolver installation, so there shouldn't be much difference between running it natively and running it in a container.
+The configuration file is located at ``/etc/knot-resolver/config.yaml`` and the cache is at ``/var/cache/knot-resolver``.
+
+We recommend persistent configuration across container restarts,
+for more see `Docker persisting container data <https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/>`_.
 
 .. code-block:: bash
 
-    docker run --rm -ti -P docker.io/cznic/knot-resolver
+    $ docker volume create config
+    $ docker run --rm -ti --network host -v config:/etc/knot-resolver docker.io/cznic/knot-resolver:6
+
+After a configuration change there is no need to restart the entire container, just tell the resolver to reload the configuration.
+Get ``CONTAINER_ID`` using the ``docker ps`` command or give your container name with the ``--name`` argument at container startup.
+
+.. code-block:: bash
 
-The configuration file is located at ``/etc/knot-resolver/config.yaml`` and the cache is at ``/var/cache/knot-resolver``. We recommend configuring a persistent cache across container restarts.
+    $ docker exec -it CONTANER_ID kresctl reload
 
 .. warning::
 
-    While the container image contains normal installation of Knot Resolver and there shouldn't be any differences between running it natively and in a container, we (the developers) do not have any experience using the Docker image in production. Especially, beware of running the DNS resolver with a software defined network (i.e. in Kubernetes). There will likely be some performance penalties for doing so. We haven't done any measurements comparing different types of installations so we don't know the performance differences. If you have done some measurements yourself, please reach out to us and we will share it here with everyone else.
-
+    Beware of running the container with a software defined network (i.e. in Kubernetes).
+    This will likely to result in some performance losses.
+    We haven't done any measurements comparing different types of installations so we don't know the performance differences.
+    If you have done your own measurements yourself, please contact us and we will share it with everyone else.