Update Docker links in docs

- Update links for redirects and content changes
- Add link to OrbStack as macOS Docker Desktop alternative
  - https://formulae.brew.sh/cask/orbstack
  - https://orbstack.dev/

docs/contributing.md

@@ -82,8 +82,9 @@ As explained in the [VSCode docs](https://code.visualstudio.com/docs/containers/
     -   A **container** is a running image.
     -   The **[Dockerfile](https://docs.docker.com/engine/reference/builder/)** tells Docker how to build the container.
 -   To [get started with Docker](https://www.docker.com/get-started):
-    -   Ubuntu Linux: follow the [instructions for Ubuntu Linux](https://docs.docker.com/install/linux/docker-ce/ubuntu/), making sure to follow the [postinstallation steps](https://docs.docker.com/install/linux/linux-postinstall/) to activate the Docker daemon.
-    -   macOS and Windows: install [Docker Desktop](https://www.docker.com/products/docker-desktop) (available [via Homebrew](https://formulae.brew.sh/cask/docker) with `brew install --cask docker`).
+    -   Linux: follow the [Docker Engine installation instructions](https://docs.docker.com/engine/install/), making sure to follow the [postinstallation steps](https://docs.docker.com/engine/install/linux-postinstall/) to activate the Docker daemon.
+    -   macOS: install [Docker Desktop](https://www.docker.com/products/docker-desktop) (available [via Homebrew](https://formulae.brew.sh/cask/docker) with `brew install --cask docker`) or an alternative like [OrbStack](https://orbstack.dev/) (available [via Homebrew](https://formulae.brew.sh/cask/orbstack) with `brew install --cask orbstack`).
+    -   Windows: install [Docker Desktop](https://www.docker.com/products/docker-desktop).
 
 <details><summary>Expand this details element for more <a href="https://docs.docker.com/engine/reference/commandline/cli/">useful Docker commands</a>.</summary>
 
@@ -126,7 +127,7 @@ docker cp [container_name]:/path/to/file destination.file
 
 ### Building development images
 
-Note that Docker builds use BuildKit. See the [BuildKit docs](https://github.com/moby/buildkit/blob/HEAD/frontend/dockerfile/docs/syntax.md) and [Docker docs](https://docs.docker.com/develop/develop-images/build_enhancements/).
+Note that Docker builds use BuildKit. See the [BuildKit docs](https://github.com/moby/buildkit/blob/HEAD/frontend/dockerfile/docs/reference.md) and [Docker docs](https://docs.docker.com/build/buildkit/).
 
 To build the Docker images for each stage:
 

docs/docker.md

@@ -220,7 +220,7 @@ The _Dockerfile_ could look like this:
     # ENTRYPOINT and CMD already included in base image
     ```
 
-Organizing the _Dockerfile_ this way helps [leverage the Docker build cache](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache). Files and commands that change most frequently are added last to the _Dockerfile_. Next time the image is built, Docker will skip any layers that didn't change, speeding up builds.
+Organizing the _Dockerfile_ this way helps [leverage the Docker build cache](https://docs.docker.com/build/cache/). Files and commands that change most frequently are added last to the _Dockerfile_. Next time the image is built, Docker will skip any layers that didn't change, speeding up builds.
 
 The image could then be built with:
 
@@ -409,8 +409,7 @@ A _Dockerfile_ equivalent to the Alpine Linux example might look like the follow
     For more info, see:
 
     -   [br3ndonland/inboard#54](https://github.com/br3ndonland/inboard/pull/54)
-    -   [BuildKit docs: Dockerfile frontend syntaxes](https://github.com/moby/buildkit/blob/HEAD/frontend/dockerfile/docs/syntax.md)
+    -   [BuildKit docs: Dockerfile frontend syntaxes](https://github.com/moby/buildkit/blob/HEAD/frontend/dockerfile/docs/reference.md)
     -   [BuildKit releases: dockerfile/1.4.0](https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.4.0)
     -   [Docker blog 2021-07-30: Introduction to heredocs in Dockerfiles](https://www.docker.com/blog/introduction-to-heredocs-in-dockerfiles/)
-    -   [Docker docs: Develop with Docker - Build images with BuildKit](https://docs.docker.com/develop/develop-images/build_enhancements/)
-    -   [Docker docs: Dockerfile reference - BuildKit](https://docs.docker.com/engine/reference/builder/#buildkit)
+    -   [Docker docs: BuildKit](https://docs.docker.com/build/buildkit/)

docs/index.md

@@ -43,7 +43,7 @@ http :80  # HTTPie: https://httpie.io/
 This project was inspired in part by [tiangolo/uvicorn-gunicorn-docker](https://github.com/tiangolo/uvicorn-gunicorn-docker). In addition to the benefits described in the [justification section](#justification), inboard also has the following advantages:
 
 -   **One repo**. The tiangolo/uvicorn-gunicorn images are in at least three separate repos ([tiangolo/uvicorn-gunicorn-docker](https://github.com/tiangolo/uvicorn-gunicorn-docker), [tiangolo/uvicorn-gunicorn-fastapi-docker](https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker), and [tiangolo/uvicorn-gunicorn-starlette-docker](https://github.com/tiangolo/uvicorn-gunicorn-starlette-docker)), with large amounts of code duplication, making maintenance difficult for an [already-busy maintainer](https://github.com/encode/uvicorn/pull/705#issuecomment-660042305). This repo combines three into one.
--   **One _Dockerfile_.** This project leverages [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/) to produce multiple Docker images from one _Dockerfile_.
+-   **One _Dockerfile_.** This project leverages [multi-stage builds](https://docs.docker.com/build/building/multi-stage/) to produce multiple Docker images from one _Dockerfile_.
 -   **One Python requirements file.** This project uses [Hatch](https://hatch.pypa.io/latest/) for dependency management with a single _pyproject.toml_.
 -   **One logging configuration.** Logging a Uvicorn+Gunicorn+Starlette/FastAPI stack is unnecessarily complicated. Uvicorn and Gunicorn use different logging configurations, and it can be difficult to unify the log streams. In this repo, Uvicorn, Gunicorn, and FastAPI log streams are propagated to the root logger, and handled by the custom root logging config. Developers can also supply their own custom logging configurations.
 -   **One programming language.** Pure Python with no shell scripts.