Added instructions on checking and stopping containers. Added brief s…

…ummary. Added brief introduction.

README.md

@@ -2,8 +2,9 @@
 
 **Disclaimer**: I am not an expert. I'm quite the opposite. I usually learn just enough to accomplish what I need, and I move on. Do not take what I write here as best practice! This is only intended to expose the potential of technologies. I always recommend reading the official documentation or tutorials, and ideally, translating them if necessary :D
 
+Today, I'd like to tell you about Docker. We're going to create some mock services and automate running them in containerized, source-controlled infrastructure using Docker. What does this mean?
 
-Today, I'd like to tell you about Docker, but first, a word about a preceding alternative. Most people are familiar with virtual machines: you setup an OS the way you want, create an image of it, use some hypervisor to host virtual machines, and deploy your images at will. For many years, this has been an effective method to diversify the usage of physical compute resources. However, virtualization has its downsides. Entire operating systems have a pretty large amount of overhead in terms of resource usage. Boot times can be painful. Virtual disk images are large, making it a pain to move things around, and they're a pain to create. (This has been mitigated by Vagrant, but that's also a recent development.) This works, and it has worked for many years. However, are there alternatives?
+First, a word about a preceding alternative. Most people are familiar with virtual machines: you setup an OS the way you want, create an image of it, use some hypervisor to host virtual machines, and deploy your images at will. For many years, this has been an effective method to diversify the usage of physical compute resources. However, virtualization has its downsides. Entire operating systems have a pretty large amount of overhead in terms of resource usage. Boot times can be painful. Virtual disk images are large, making it a pain to move things around, and they're a pain to create. (This has been mitigated by Vagrant, but that's also a recent development.) This works, and it has worked for many years. However, are there alternatives?
 
 Enter Docker. Docker uses what are called "containers" instead of virtual machines. These utilize Linux cgroups (or Hyper-V on Windows) to create an isolated but low-overhead operating environment. Containers have noticeably less overhead than virtual machines, and startup is wicked fast. Docker specifically provides a wealth of tools to make working with containers easy and even pleasant. Similar to Vagrant, you can define a text file called a Dockerfile that defines how the container is configured. There's a collection of CLI tools for building Docker images from Dockerfiles, pushing and pulling images from Dockerhub or Docker registry (git -> Github : Docker -> Dockerhub), and managing containers. There are also a wealth of tools to orchestrate Docker containers. We'll cover what orchestration is and means later in this post.
 
@@ -62,11 +63,17 @@ CMD ./server.bash
 ```
 
 This is Dockerfile syntax. You can see the full docs here: https://docs.docker.com/engine/reference/builder/
+
 A Dockerfile defines a Docker image. This can be compared to a virtual machine image. Again, a Dockerfile is much like a Vagrantfile if you're familiar with Vagrant.
+
 `FROM` indicates that we're going to inherit from another Dockerfile. Yes, Docker supports inheritance. It's lovely. Basically, this image will start from the mentioned image, and we'll build on top of it. Where does this other Dockerfile/image come from? Docker Hub! https://hub.docker.com/ In this case, we're going to base our image on CentOS.
+
 `RUN` is simply a way to run a command to help setup the image. In this case, we're installing `ncat` since we'll need it for the demo.
+
 `ADD` is how you get files from your filesystem into the image. Here, we're just copying everything in our directory to the image's working directory. I'm lazy.
+
 `EXPOSE` tells the container which ports will need network access. This is important if you're expected inbound network requests.
+
 `CMD` is the command that will run when the container is started.
 Viola! We have our first Dockerfile setup. Let's run it:
 ```
@@ -89,6 +96,19 @@ The `-d` flag tells Docker to detach from the container, meaning it will run in
 
 Congratulations! You have your first docker container running!
 
+However, let's clean up after ourselves. Let's see what containers are currently running:
+```
+docker ps
+```
+![Output of docker ps](images/ps_output.png)
+You can see the container, its ID, the image it's based on, the currently running command, its name, and other info. Docker will generate names for containers if you don't provide one.
+
+Let's make sure to stop the container, since we won't use this specific one anymore. Since my container's name is `suspicious_jackson`, I can simply do
+```
+docker stop suspicious_jackson
+```
+Using the container's ID works, too. If you run `docker ps` again after this, you'll see no containers running.
+
 Fancy, huh? Let's get more fancy.
 
 Make a separate folder called client, and drop this bash script in there:
@@ -122,8 +142,11 @@ CMD ./client.bash $server $port
 ```
 
 You'll notice this file is slightly different.
+
 `ARG` allows our container to take arguments, meaning we can configure some things at image build time.
+
 `ENV` sets environment variables within the container.
+
 In this case, we're taking arguments to the container, making them available to the shell environment, then passing them as inputs to our bash script. This script just makes an HTTP request to the given server at the given port repeatedly with a 1-second delay. Let's see them work together.
 
 Now, there is a way to get these two containers talking to each other running manually, but that's dumb. It's a lot of effort. There's an easier way.
@@ -152,11 +175,16 @@ services:
 ```
 
 This file will allow us to use the `docker-compose` command to build and run multiple containers that are networked together to talk to each other.
+
 `version` refers to the version of docker-compose we're using.
+
 `services` is where we define each of the services we'll run in containers.
+
 `args` corresponds to the arguments we defined in our Dockerfile.
+
 `links` establishes links between services, where the linked service has a hostname entry with the name of the service. So from the client, we can reference the server container as `server` since we defined the link and service as `server`.
-The rest you can kind of figure out. If not, ask in a comment!
+
+I won't cover the rest, but if things are unclear to you, ask in a comment! No judgement here :)
 
 From here, we can simply run the below:
 ```
@@ -169,6 +197,16 @@ We could do more! There are prebuilt images for all sorts of things, like databa
 
 In production, you could use Docker Swarm, Kubernetes, or Mesos to orchestrate and manage containers for your various services. Easy, observable, fault tolerant.
 
+We did a lot today!
+* Installing Docker
+* Creating a Dockerfile
+* Building a Docker image
+* Running a Docker container
+* Defining services using `docker-compose`
+* Running multiple services in a network
+
+Great job!
+
 For now, this blog entry is long enough. :) Thank you for your time! I hope you found the material helpful. Please comment with any questions, comments, or suggestions. Also let me know if you have any requests for technologies you'd like me to cover!
 
 Huge thanks to Jiyoung with Django Girls Seoul for translating! You should definitely check them out if Python and/or Django are in your future. I also recommend my own meetup, Learn Teach Code Seoul. If you think this blog was good work, it's a testament to how well our two groups collaborate together, so you should check out both!