Merge pull request #16819 from docker/chrisward/get-started-tweaks

Small tweaks to get started guide

.github/vale/Vocab/Industry/accept.txt

@@ -70,3 +70,5 @@ kubefwd
 ktunnel
 macOS
 minikube
+sandbox
+sandboxed

get-started/02_our_app.md

@@ -6,7 +6,7 @@ redirect_from:
 description: Containerize and run a simple application to learn Docker
 ---
 
-For the rest of this guide, you will be working with a simple todo
+For the rest of this guide, you'll be working with a simple todo
 list manager that's running in Node.js. If you're not familiar with Node.js,
 don't worry. This guide doesn't require JavaScript experience.
 

get-started/03_updating_app.md

@@ -83,7 +83,7 @@ To remove a container, you first need to stop it. Once it has stopped, you can r
 ### Remove a container using Docker Desktop
 
 1. Open Docker Desktop to the **Containers** view.
-2. Select the trash can icon under the **Actions** column for the old container that you want to delete.
+2. Select the trash can icon under the **Actions** column for the old, currently running container that you want to delete.
 3. In the confirmation dialog, select **Delete forever**.
 
 <hr>

get-started/05_persisting_data.md

@@ -53,7 +53,8 @@ What you'll see is that the files created in one container aren't available in a
     $ docker run -it ubuntu ls /
     ```
 
-    And look! There's no `data.txt` file there! That's because it was written to the scratch space for
+    In this case the command lists the files in the root directory of the container.
+    Look, there's no `data.txt` file there! That's because it was written to the scratch space for
     only the first container.
 
 4. Go ahead and remove the first container using the `docker rm -f <container-id>` command.

get-started/06_bind_mounts.md

@@ -6,7 +6,7 @@ keywords: >
 description: Using bind mounts in our application
 ---
 
-In the previous chapter, we talked about and used a volume mount to persist the
+In [part 5](./05_persisting_data.md), we talked about and used a volume mount to persist the
 data in our database. A volume mount is a great choice when you need somewhere
 persistent to store your application data.
 
@@ -157,7 +157,7 @@ So, let's do it!
      server. If we look in the `package.json`, we'll see that the `dev` script
      starts `nodemon`.
 
-3. You can watch the logs using `docker logs`. You'll know you're ready to go
+3. You can watch the logs using `docker logs <container-id>`. You'll know you're ready to go
    when you see this:
 
    ```console

get-started/07_multi_container.md

@@ -9,12 +9,12 @@ application stack. The following question often arises - "Where will MySQL run?
 container or run it separately?" In general, **each container should do one thing and do it well.** A few
 reasons:
 
-- There's a good chance you'd have to scale APIs and front-ends differently than databases
+- There's a good chance you'd have to scale APIs and front-ends differently than databases.
-- Separate containers let you version and update versions in isolation
+- Separate containers let you version and update versions in isolation.
 - While you may use a container for the database locally, you may want to use a managed service
   for the database in production. You don't want to ship your database engine with your app then.
 - Running multiple processes will require a process manager (the container only starts one process), 
-  which adds complexity to container startup/shutdown
+  which adds complexity to container startup/shutdown.
 
 And there are more reasons. So, we will update our application to work like this:
 

get-started/08_using_compose.md

@@ -29,7 +29,7 @@ $ docker compose version
 
 ## Create the Compose file
 
-1. At the root of the app project, create a file named `docker-compose.yml`.
+1. At the root of the `/getting-started/app` folder, create a file named `docker-compose.yml`.
 
 2. In the compose file, we'll start off by defining the list of services (or containers) we want to run as part of our application.
 
@@ -190,7 +190,6 @@ At this point, our complete `docker-compose.yml` should look like this:
 
 
 ```yaml
-
 services:
   app:
     image: node:18-alpine
@@ -278,7 +277,7 @@ Compose and used to group the containers together. By default, the project name
 
 ![Docker Dashboard with app project](images/dashboard-app-project-collapsed.png)
 
-If you twirl down the app, you will see the two containers we defined in the compose file. The names are also a little
+If you click the disclose arrow next to **app**, you will see the two containers we defined in the compose file. The names are also a little
 more descriptive, as they follow the pattern of `<service-name>-<replica-number>`. So, it's very easy to
 quickly see what container is our app and which container is the mysql database.
 

get-started/11_what_next.md

@@ -4,7 +4,7 @@ keywords: get started, setup, orientation, quickstart, intro, concepts, containe
 description: Making sure you have more ideas of what you could do next with your application
 ---
 
-Although we're done with our workshop, there's still a LOT more to learn about containers!
+Although we're done with our get started guide, there's still a LOT more to learn about containers!
 We're not going to go deep-dive here, but here are a few other areas to look at next!
 
 ## Container orchestration
@@ -44,9 +44,9 @@ We recommend the video workshop from DockerCon 2022. Watch the video below or us
 
 ## Creating a container from scratch
 
- If you'd like to see how containers are built from scratch, Liz Rice from Aqua Security has a fantastic talk in which she creates a container from scratch in Go. While the talk does not go into networking, using images for the filesystem, and other advanced topics, it gives a deep dive into how things are working.
+If you'd like to see how containers are built from scratch, Liz Rice from Aqua Security has a fantastic talk in which she creates a container from scratch in Go. While the talk does not go into networking, using images for the filesystem, and other advanced topics, it gives a deep dive into how things are working.
 
- <iframe src="https://www.youtube-nocookie.com/embed/8fi7uSYlOdc" style="max-width: 100%; aspect-ratio: 16 / 9;" width="560" height="auto" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+<iframe src="https://www.youtube-nocookie.com/embed/8fi7uSYlOdc" style="max-width: 100%; aspect-ratio: 16 / 9;" width="560" height="auto" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ## Language-specific guides
 

get-started/index.md

@@ -61,10 +61,10 @@ Welcome! We're excited that you want to learn Docker.
 
 This guide contains step-by-step instructions on how to get started with Docker. Some of the things you'll learn and do in this guide are:
 
-- Build and run an image as a container
+- Build and run an image as a container.
-- Share images using Docker Hub
+- Share images using Docker Hub.
-- Deploy Docker applications using multiple containers with a database
+- Deploy Docker applications using multiple containers with a database.
-- Run applications using Docker Compose
+- Run applications using Docker Compose.
 
 Before you get to the hands on part of the guide, you should learn about containers and images.
 
@@ -73,10 +73,10 @@ Before you get to the hands on part of the guide, you should learn about contain
 Simply put, a container is a sandboxed process on your machine that is isolated from all other processes on the host machine. That isolation leverages [kernel namespaces and cgroups](https://medium.com/@saschagrunert/demystifying-containers-part-i-kernel-space-2c53d6979504),
 features that have been in Linux for a long time. Docker has worked to make these capabilities approachable and easy to use. To summarize, a container:
 
-- is a runnable instance of an image. You can create, start, stop, move, or delete a container using the DockerAPI or CLI.
+- Is a runnable instance of an image. You can create, start, stop, move, or delete a container using the DockerAPI or CLI.
-- can be run on local machines, virtual machines or deployed to the cloud.
+- Can be run on local machines, virtual machines or deployed to the cloud.
-- is portable (can be run on any OS).
+- Is portable (can be run on any OS).
-- is isolated from other containers and runs its own software, binaries, and configurations.
+- Is isolated from other containers and runs its own software, binaries, and configurations.
 
 ## What is a container image?