docs: corrections (#283)

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update NOTES.md

* Update devcontainer-template.json

src/docker-in-docker/NOTES.md

@@ -4,12 +4,12 @@ Dev containers can be useful for all types of applications including those that
 
 In many cases, the best approach to solve this problem is by bind mounting the docker socket, as demonstrated in [../docker-outside-of-docker](../docker-outside-of-docker). This template demonstrates an alternative technique called "Docker in Docker".
 
-This template's approach creates pure "child" containers by hosting its own instance of the docker daemon inside this container.  This is compared to the forementioned "docker-_outside-of_-docker" method (sometimes called docker-outside-of-docker) that bind mounts the host's docker socket, creating "sibling" containers to the current container.
+This template's approach creates pure "child" containers by hosting its own instance of the docker daemon inside this container.  This is compared to the forementioned "docker-_outside-of_-docker" method that bind mounts the host's docker socket, creating "sibling" containers to the current container.
 
 For this technique to work, the "Docker in Docker" Feature included in this template automatically forces the parent container to be run as `--privileged` and adds a `/usr/local/share/docker-init.sh` ENTRYPOINT script that, spawns the `dockerd` process.
 
-The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` proprty as follows:
+The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` property as follows:
 
 ```json
 "image": "mcr.microsoft.com/devcontainers/javascript-node:18-bullseye"
-```
+```

src/docker-outside-of-docker-compose/NOTES.md

@@ -12,9 +12,9 @@ FROM mcr.microsoft.com/devcontainers/javascript-node:18-bullseye
 
 ## Using bind mounts when working with Docker inside the container
 
-> **Note:** If you need to mount folders within the dev container into your own containers using docker-outside-of-docker, so you may find [Docker in Docker](../docker-in-docker) meets your needs better in some cases (despite a potential performance penalty).
+> **Note:** If you need to mount folders within the dev container into your own containers using docker-outside-of-docker, you may find [Docker in Docker](../docker-in-docker) meets your needs better in some cases (despite a potential performance penalty).
 
-In some cases, you may want to be able to mount the local workspace folder into a container you create while running from inside the dev container (e.g. using `-v` from the Docker CLI). The issue is that, with "Docker from Docker", containers are always created on the host. So, when you bind mount a folder into any container, you'll need to use the **host**'s paths.
+In some cases, you may want to be able to mount the local workspace folder into a container you create while running from inside the dev container (e.g. using `-v` from the Docker CLI). The issue is that, with "Docker outside of Docker", containers are always created on the host. So, when you bind mount a folder into any container, you'll need to use the **host**'s paths.
 
 In GitHub Codespaces, the workspace folder is **available in the same place on the host as it is in the container,** so you can bind workspace contents as you would normally.
 
@@ -40,4 +40,4 @@ By default, web frameworks and tools often only listen to localhost inside the c
 "forwardPorts": [9000]
 ```
 
-The `ports` property in `docker-compose.yml` [publishes](https://docs.docker.com/config/containers/container-networking/#published-ports) rather than forwards the port. This will not work in a cloud environment like Codespaces and applications need to listen to `*` or `0.0.0.0` for the application to be accessible externally. Fortunately the `forwardPorts` property does not have this limitation.
+The `ports` property in `docker-compose.yml` [publishes](https://docs.docker.com/config/containers/container-networking/#published-ports) rather than forwards the port. This will not work in a cloud environment like Codespaces and applications need to listen to `*` or `0.0.0.0` for the application to be accessible externally. Fortunately the `forwardPorts` property does not have this limitation.

src/docker-outside-of-docker/NOTES.md

@@ -4,21 +4,21 @@ Dev containers can be useful for all types of applications including those that
 
 This example illustrates how you can do this by running CLI commands and using the [Docker VS Code extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) right from inside your dev container. It installs the Docker extension inside the container so you can use its full feature set with your project.
 
-The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` proprty as follows:
+The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` property as follows:
 
 ```json
 "image": "mcr.microsoft.com/devcontainers/javascript-node:18-bullseye"
 ```
 
 ## Using bind mounts when working with Docker inside the container
 
-> **Note:** If you need to mount folders within the dev container into your own containers using docker-outside-of-docker, so you may find [Docker in Docker](../docker-in-docker) meets your needs better in some cases (despite a potential performance penalty).
+> **Note:** If you need to mount folders within the dev container into your own containers, you may find [Docker in Docker](../docker-in-docker) meets your needs better in some cases (despite a potential performance penalty).
 
-In some cases, you may want to be able to mount the local workspace folder into a container you create while running from inside the dev container (e.g. using `-v` from the Docker CLI). The issue is that, with "Docker from Docker", containers are always created on the host. So, when you bind mount a folder into any container, you'll need to use the **host**'s paths.
+In some cases, you may want to be able to mount the local workspace folder into a container you create while running from inside the dev container (e.g. using `-v` from the Docker CLI). The issue is that, with "Docker outside of Docker", containers are always created on the host. So, when you bind mount a folder into any container, you'll need to use the **host**'s paths.
 
 In GitHub Codespaces, the workspace folder is **available in the same place on the host as it is in the container,** so you can bind workspace contents as you would normally.
 
-However, for Dev Container for most Dev Container spec supporting tools, this is typically not the case. A simple way to work around this is to put `${localWorkspaceFolder}` in an environment variable that you then use when doing bind mounts inside the container.
+However, for most Dev Container spec supporting tools, this is typically not the case. A simple way to work around this is to put `${localWorkspaceFolder}` in an environment variable that you then use when doing bind mounts inside the container.
 
 Add the following to `.devcontainer.json`:
 
@@ -30,4 +30,4 @@ Then reference the env var when running Docker commands from the terminal inside
 
 ```bash
 docker run -it --rm -v "${LOCAL_WORKSPACE_FOLDER//\\/\/}:/workspace" debian bash
-```
+```

src/kubernetes-helm-minikube/NOTES.md

@@ -4,7 +4,7 @@ Dev containers can be useful for all types of applications including those that
 
 This example illustrates how you can do this by using CLIs ([kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), [Helm](https://helm.sh), Docker), the [Kubernetes extension](https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-kubernetes-tools), and the [Docker extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker) right from inside your dev container.  This definition builds up from the [docker-in-docker](../docker-in-docker) container definition along with a [minikube](https://minikube.sigs.k8s.io/docs/) installation that can run right inside the container. It installs the Docker and Kubernetes extensions inside the container so you can use its full feature set with your project.
 
-The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` proprty as follows:
+The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` property as follows:
 
 ```json
 "image": "mcr.microsoft.com/devcontainers/javascript-node:18-bullseye"
@@ -13,4 +13,4 @@ The included `.devcontainer.json` can be altered to work with other Debian/Ubunt
 
 ## Ingress and port forwarding
 
-When configuring [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) for your Kubernetes cluster, note that by default Kubernetes will bind to a specific interface's IP rather than localhost or all interfaces. This is why you need to use the Kubernetes Node's IP when connecting - even if there's only one Node as in the case of Minikube.
+When configuring [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) for your Kubernetes cluster, note that by default Kubernetes will bind to a specific interface's IP rather than localhost or all interfaces. This is why you need to use the Kubernetes Node's IP when connecting - even if there's only one Node as in the case of Minikube.

src/kubernetes-helm-minikube/devcontainer-template.json

@@ -2,7 +2,7 @@
     "id": "kubernetes-helm-minikube",
     "version": "2.2.2",
     "name": "Kubernetes - Minikube-in-Docker",
-    "description": "Access an embedded minikube instance or remote a Kubernetes cluster from inside a dev container. Includes kubectl, Helm, minikube, and the Docker.",
+    "description": "Access an embedded minikube instance from inside a dev container. Includes kubectl, Helm, minikube, and the Docker.",
     "documentationURL": "https://github.com/devcontainers/templates/tree/main/src/kubernetes-helm-minikube",
     "publisher": "Dev Container Spec Maintainers",
     "licenseURL": "https://github.com/devcontainers/templates/blob/main/LICENSE",

src/kubernetes-helm/NOTES.md

@@ -4,7 +4,7 @@
 
 Dev containers can be useful for all types of applications including those that also deploy into a container based-environment. While you can directly build and run the application inside the dev container you create, you may also want to test it by deploying a built container image into a local minikube or remote [Kubernetes](https://kubernetes.io/) cluster without affecting your dev container.
 
-The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` proprty as follows:
+The included `.devcontainer.json` can be altered to work with other Debian/Ubuntu-based container images such as `node` or `python`. For example, to use `mcr.microsoft.com/devcontainers/javascript-node`, update the `image` property as follows:
 
 ```json
 "image": "mcr.microsoft.com/devcontainers/javascript-node:18-bullseye"
@@ -13,10 +13,10 @@ The included `.devcontainer.json` can be altered to work with other Debian/Ubunt
 
 ## A note on Minikube or otherwise using a local cluster
 
-While this definition works with Minikube in most cases, if you hit trouble, make sure that your `~/.kube/config` file and Minikube certs reference your host's IP rather than `127.0.0.1` or `localhost` (since `localhost` resolve to the container itself rather than your local machine where Minikube is running).
+While this definition works with Minikube in most cases, if you hit trouble, make sure that your `~/.kube/config` file and Minikube certs reference your host's IP rather than `127.0.0.1` or `localhost` (since `localhost` resolves to the container itself rather than your local machine where Minikube is running).
 
-This should happen by default on Linux. On macOS and Windows, we recommend using the Kuberntes install that comes with Docker Desktop instead of Minikube to avoid these kinds of issues.
+This should happen by default on Linux. On macOS and Windows, we recommend using the Kubernetes install that comes with Docker Desktop instead of Minikube to avoid these kinds of issues.
 
 ## Ingress and port forwarding
 
-When configuring [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) for your Kubernetes cluster, note that by default Kubernetes will bind to a specific interface's IP rather than localhost or all interfaces. This is why you need to use the Kubernetes Node's IP when connecting - even if there's only one Node as in the case of Minikube. Port forwarding in Remote - Containers will allow you to specify `<ip>:<port>` in either the `forwardPorts` property or through the port forwarding UI in VS Code.
+When configuring [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) for your Kubernetes cluster, note that by default Kubernetes will bind to a specific interface's IP rather than localhost or all interfaces. This is why you need to use the Kubernetes Node's IP when connecting - even if there's only one Node as in the case of Minikube. Port forwarding in Remote - Containers will allow you to specify `<ip>:<port>` in either the `forwardPorts` property or through the port forwarding UI in VS Code.