Merge pull request docker#10310 from usha-mandya/get-started-patch

usha-mandya · web-flow · commit 7b7af317c483 · 2020-02-18T14:14:27.000Z
Get started updates: fix hyperlinks and review comments
diff --git a/get-started/index.md b/get-started/index.md
@@ -160,9 +160,9 @@ At this point, you've installed Docker Desktop on your development machine, and
 
 ## CLI references
 
-Further documentation for all CLI commands used in this article is available here:
+Refer to the following topics for further documentation on all CLI commands used in this article:
 
-- [`docker version`](https://docs.docker.com/engine/reference/commandline/version/)
-- [`docker run`](https://docs.docker.com/engine/reference/commandline/run/)
-- [`docker image`](https://docs.docker.com/engine/reference/commandline/image/)
-- [`docker container`](https://docs.docker.com/engine/reference/commandline/container/)
+- [docker version](https://docs.docker.com/engine/reference/commandline/version/)
+- [docker run](https://docs.docker.com/engine/reference/commandline/run/)
+- [docker image](https://docs.docker.com/engine/reference/commandline/image/)
+- [docker container](https://docs.docker.com/engine/reference/commandline/container/)
diff --git a/get-started/part2.md b/get-started/part2.md
@@ -12,14 +12,14 @@ Work through the orientation and setup in [Part 1](index.md).
 
 ## Introduction
 
-Now that we've set up our development environment, thanks to Docker Desktop,
-we can begin to develop containerized applications. In general, the development workflow looks like this:
+Now that you've set up your development environment, thanks to Docker Desktop,
+you can begin to develop containerized applications. In general, the development workflow looks like this:
 
 1. Create and test individual containers for each component of your application by first creating Docker images.
 2. Assemble your containers and supporting infrastructure into a complete application.
 3. Test, share, and deploy your complete containerized application.
 
-In this stage of the tutorial, let's focus on step 1 of this workflow: creating the images that our containers will be based on. Remember, a Docker image captures the private filesystem that our containerized processes will run in; we need to create an image that contains just what our application needs to run.
+In this stage of the tutorial, let's focus on step 1 of this workflow: creating the images that your containers will be based on. Remember, a Docker image captures the private filesystem that your containerized processes will run in; you need to create an image that contains just what your application needs to run.
 
 > **Containerized development environments** are easier to set up than traditional development environments, once you learn how to build images as we'll discuss below. This is because a containerized development environment will isolate all the dependencies your app needs inside your Docker image; there's no need to install anything other than Docker on your development machine. In this way, you can easily develop applications for different stacks without changing anything on your development machine.
 
@@ -114,27 +114,27 @@ CMD [ "npm", "start" ]
 COPY . .
 ```
 
-Writing a Dockerfile is the first step to containerizing an application. You can think of these Dockerfile commands as a step-by-step recipe on how to build up our image. This one takes the following steps:
+Writing a Dockerfile is the first step to containerizing an application. You can think of these Dockerfile commands as a step-by-step recipe on how to build up your image. This one takes the following steps:
 
 - Start `FROM` the pre-existing `node:current-slim` image. This is an *official image*, built by the node.js vendors and validated by Docker to be a high-quality image containing the Node.js Long Term Support (LTS) interpreter and basic dependencies.
 - Use `WORKDIR` to specify that all subsequent actions should be taken from the directory `/usr/src/app` *in your image filesystem* (never the host's filesystem).
 - `COPY` the file `package.json` from your host to the present location (`.`) in your image (so in this case, to `/usr/src/app/package.json`)
 - `RUN` the command `npm install` inside your image filesystem (which will read `package.json` to determine your app's node dependencies, and install them)
 - `COPY` in the rest of your app's source code from your host to your image filesystem.
 
-You can see that these are much the same steps you might have taken to set up and install your app on your host. However, capturing these as a Dockerfile allows us to do the same thing inside a portable, isolated Docker image.
+You can see that these are much the same steps you might have taken to set up and install your app on your host. However, capturing these as a Dockerfile allows you to do the same thing inside a portable, isolated Docker image.
 
-The steps above built up the filesystem of our image, but there are other lines in our Dockerfile.
+The steps above built up the filesystem of our image, but there are other lines in your Dockerfile.
 
-The `CMD` directive is our first example of specifying some metadata in our image that describes how to run a container based on this image. In this case, it's saying that the containerized process that this image is meant to support is `npm start`.
+The `CMD` directive is the first example of specifying some metadata in your image that describes how to run a container based on this image. In this case, it's saying that the containerized process that this image is meant to support is `npm start`.
 
 The `EXPOSE 8080` informs Docker that the container is listening on port 8080 at runtime.
 
-What you see above is a good way to organize a simple Dockerfile; always start with a `FROM` command, follow it with the steps to build up your private filesystem, and conclude with any metadata specifications. There are many more Dockerfile directives than just the few we see above; for a complete list, see the [Dockerfile reference](https://docs.docker.com/engine/reference/builder/).
+What you see above is a good way to organize a simple Dockerfile; always start with a `FROM` command, follow it with the steps to build up your private filesystem, and conclude with any metadata specifications. There are many more Dockerfile directives than just the few you see above. For a complete list, see the [Dockerfile reference](https://docs.docker.com/engine/reference/builder/).
 
 ## Build and test your image
 
-Now that we have some source code and a Dockerfile, it's time to build our first image, and make sure the containers launched from it work as expected.
+Now that you have some source code and a Dockerfile, it's time to build your first image, and make sure the containers launched from it work as expected.
 
 > **Windows users**: this example uses Linux containers. Make sure your environment is running Linux containers by right-clicking on the Docker logo in your system tray, and clicking **Switch to Linux containers** if the option appears. Don't worry - all the commands in this tutorial work the exact same way for Windows containers.
 
@@ -156,15 +156,15 @@ You'll see Docker step through each instruction in your Dockerfile, building up
     docker container run --publish 8000:8080 --detach --name bb bulletinboard:1.0
     ```
 
-    We used a couple of common flags here:
+    There are a couple of common flags here:
 
-    - `--publish` asks Docker to forward traffic incoming on the host's port 8000, to the container's port 8080 (containers have their own private set of ports, so if we want to reach one from the network, we have to forward traffic to it in this way; otherwise, firewall rules will prevent all network traffic from reaching your container, as a default security posture).
+    - `--publish` asks Docker to forward traffic incoming on the host's port 8000, to the container's port 8080. Containers have their own private set of ports, so if you want to reach one from the network, you have to forward traffic to it in this way. Otherwise, firewall rules will prevent all network traffic from reaching your container, as a default security posture.
     - `--detach` asks Docker to run this container in the background.
-    - `--name` lets us specify a name with which we can refer to our container in subsequent commands, in this case `bb`.
+    - `--name` specifies a name with which you can refer to your container in subsequent commands, in this case `bb`.
 
-    Also notice, we didn't specify what process we wanted our container to run. We didn't have to, since we used the `CMD` directive when building our Dockerfile; thanks to this, Docker knows to automatically run the process `npm start` inside our container when it starts up.
+    Also notice, you didn't specify what process you wanted your container to run. You didn't have to, as you've used the `CMD` directive when building your Dockerfile; thanks to this, Docker knows to automatically run the process `npm start` inside the container when it starts up.
 
-2.  Visit your application in a browser at `localhost:8000`. You should see your bulletin board application up and running. At this step, we would normally do everything we could to ensure our container works the way we expected; now would be the time to run unit tests, for example.
+2.  Visit your application in a browser at `localhost:8000`. You should see your bulletin board application up and running. At this step, you would normally do everything you could to ensure your container works the way you expected; now would be the time to run unit tests, for example.
 
 3.  Once you're satisfied that your bulletin board container works correctly, you can delete it:
 
@@ -176,7 +176,7 @@ You'll see Docker step through each instruction in your Dockerfile, building up
 
 ## Conclusion
 
-At this point, we've successfully built an image, performed a simple containerization of an application, and confirmed that our app runs successfully in its container. The next step will be to share your images on [Docker Hub](https://hub.docker.com/), so they can be easily downloaded and run on any destination machine.
+At this point, you've successfully built an image, performed a simple containerization of an application, and confirmed that your app runs successfully in its container. The next step will be to share your images on [Docker Hub](https://hub.docker.com/), so they can be easily downloaded and run on any destination machine.
 
 [On to Part 3 >>](part3.md){: class="button outline-btn" style="margin-bottom: 30px; margin-right: 100%"}
 
diff --git a/get-started/part3.md b/get-started/part3.md
@@ -42,7 +42,7 @@ At this point, you've set up your Docker Hub account and have connected it to yo
 
     ![make a repo](images/newrepo.png){:width="100%"}
 
-3.  Now we're ready to share our image on Docker Hub, but there's one thing we must do first: images must be *namespaced correctly* to share on Docker Hub. Specifically, images must be named like `<Docker ID>/<Repository Name>:<tag>`. We can relabel our `bulletinboard:1.0` image like this (of course, please replace `gordon` with your Docker ID):
+3.  Now you are ready to share your image on Docker Hub, but there's one thing you must do first: images must be *namespaced correctly* to share on Docker Hub. Specifically, you must name images like `<Docker ID>/<Repository Name>:<tag>`. You can relabel your `bulletinboard:1.0` image like this (of course, please replace `gordon` with your Docker ID):
 
     ```shell
     docker image tag bulletinboard:1.0 gordon/bulletinboard:1.0
@@ -60,9 +60,9 @@ At this point, you've set up your Docker Hub account and have connected it to yo
 
 ## Conclusion
 
-Now that your image is available on Docker Hub, you'll be able to run it anywhere. If you try to use it on a new machine that doesn't have it yet, Docker will automatically try and download it from Docker Hub. By moving images around in this way, you no longer need to install any dependencies except Docker on the machines you want to run our software on. The dependencies of containerized applications are completely encapsulated and isolated within your images, which we can share using Docker Hub as described above.
+Now that your image is available on Docker Hub, you'll be able to run it anywhere. If you try to use it on a new machine that doesn't have it yet, Docker will automatically try and download it from Docker Hub. By moving images around in this way, you no longer need to install any dependencies except Docker on the machines you want to run your software on. The dependencies of containerized applications are completely encapsulated and isolated within your images, which you can share using Docker Hub as described above.
 
-Another thing to keep in mind: at the moment, we've only pushed your image to Docker Hub; what about your Dockerfile? A crucial best practice is to keep these in version control, perhaps alongside your source code for your application. You can add a link or note in your Docker Hub repository description indicating where these files can be found, preserving the record not only of how your image was built, but how it's meant to be run as a full application.
+Another thing to keep in mind: at the moment, you've only pushed your image to Docker Hub; what about your Dockerfile? A crucial best practice is to keep these in version control, perhaps alongside your source code for your application. You can add a link or note in your Docker Hub repository description indicating where these files can be found, preserving the record not only of how your image was built, but how it's meant to be run as a full application.
 
 ## Where to go next
 
