Lab 2
Details for MPCS 51221
Each
lab will consist of a small problem and details of
how to proceed. Each lab is intended to give every student hands-on
experience with the core technologies utilized during the course.
A student may concentrate, as a team member, on one technology over
another for the final project, but labs are designed to give each and
every student exposure to all the technologies that come into
play. You need to submit labs to the TAs for
grading--see submission instructions below.
Generally, unless otherwise specified, you will have one week to
complete each assigned lab.
See
the syllabus for information on grading. Turning in lab
assignments on time is required, without exception, and all late deliveries will be penalized,
regardless of cause.
Submit your
assignments to the subversion repository according to the
directions on the syllabus page.
You
may write these solutions in either
Java or C++...your choice.
Lab 2
Due: 5:00 pm, Tuesday, November 7, 2017
Problem
1: Playing With Docker Some More:
BACKGROUND:
Like
all
programming problems, learning a new technology is not an exercise in
reading but rather and exercise in typing. This lab is designed
to
give you more hands-on experience in some fundamental skills in Docker. You
will generally find the References section below helpful in addition to
the required and recommended reading. When we talk about
"Docker", we are talking specifically about the Stable Community Edition
of Docker, which is the version we will be using in this class.
The Stable Community Edition provides the basic container engine and
built-in orchestration, networking, and security.
WHAT YOU NEED TO DO:
STEP 1:
First,
make sure docker is running either on your laptop (Option I from the first lab) or
in your VM (Option II from the first lab). If you are working in a VM, do the
following commands inside your Ubuntu (or Redhat, etc.) VirtualBox VM.
There are two
shell scripts that you will use to document your work with this lab (that utilize the script command), one
if you're working on linux, and the other if you're working on MacOS.
Contact the TA if you're working on Windows. We will be looking
to see if you have successfully run all the commands required in the
lab. Note that you may "play around" further with options and
other commands, even as you work through the lab. Therefore if
your script output shows additional commands etc., that's perfectly
fine (in fact it's great!). We will simply be grading the subset
of required commands that you are to follow when working through the
this lab and subsequent labs, and will ignore any output that we see
that is not part of the lab requirements.
Create
a working directory (perhaps something like "~/mpcs51212/lab2" and in
that directory type either runscript.linux.sh or
runscript.mac.sh. That will launch a new shell (in your same
window), but all your commands and output will be recorded in a
file with an extension of "*.out". Once you are finished with
Step 3 of this lab, simply type "exit" or press "^d" and you will exit
the subshell and your activity will be saved in the script output. Your script output will be saved in
a file with your login id and a date-time stamp. The filename
will look something like "mark.Tue.Sep.19.17-59-26.CDT.2017.out".
Your userid and time stamp will of course be different. This is
the file you will submit for grading per the submission instructions below.
STEP 2:
Continued intro to docker images and containers with a few examples
For
this secoond lab, we are going to run a few more commands which will give you a little more experience in working within
Docker. Make sure you have your runscript working before continuing.
Also,
make sure docker is running either on your laptop (Option I from the first lab) or
in your VM (Option II from the first lab). If you are working in a VM, do the
following commands inside
your Ubuntu VirtualBox VM.
Create
a working directory (perhaps something like "~/mpcs51212/lab2" and in
that directory type either runscript.linux.sh or
runscript.mac.sh. That will launch a new shell (in your same
window), but all your commands and output will be recorded in a
file with an extension of "*.out". Once you are finished with
Step 3 of this lab, simply type "exit" or press "^d" and you will exit
the subshell and your activity will be saved. It will be saved in
a file with your login id and a date-time stamp. The filename
will look something like "mark.Tue.Sep.19.17-59-26.CDT.2017.out".
Your userid and time stamp will of course be different. This is
the file you will submit for grading.
Ok,
great. Last week you worked a little with docker images and
containers. But you may be left with a big "so what?".
Well, let's do a little more with a docker container. Let's hop
into it and snoop around a little. Again, make sure you have your
runscript executing so you can save your command output.
In a separate terminal window, open an editor and create and save a
file called [yourloginid].Lab2.responses. When you see the prompt
RESPOND #: below in this lab, you will write your answers into this
file (Make sure you note the RESPOND prompt (such as "What did that docker run command you just executed above do?" so we will know what
you're responding to). You will submit this response file along
with all other supporting documents (ie your script file, etc.).
STEP 3:
Execute the following commands when instructed to do so.
How do we launch a container and keep it running? Basically there are two ways:
pass the -it flags to either docker run or docker exec and launch a shell (/bin/bash):
EXECUTE: docker run -it ubuntu:14.04 /bin/bash
Now, exit your container by either typing exit or pressing Ctrl-d:
EXECUTE: exit [or press ^d]
RESPOND: What did that docker run command you just executed above do?
Now, run the image and pass it the –id flag (daemon interactive):
EXECUTE: docker ps
EXECUTE: docker run -id ubuntu:14.04
EXECUTE: docker ps
RESPOND: What do you see and what did you learn from this?
EXECUTE: docker exec -it f62568d02b31 /bin/bash
[of course you will use the appropriate container id (or name) from the docker ps
command for YOUR container id...NOT f62568d02b31 above. You can
use docker ps [-a] to find this id]
Ok, great, but notice every time we run a docker images, we seem to be
“collecting” containers....wouldn’t it be nice to be able to save and
work in a single container? We can. First, let’s stop our
Ubuntu container:
EXECUTE: docker stop f62568d02b31
[of course you will use the appropriate container id from the docker ps command for YOUR container id...]
wait for it, may take a few seconds to shut down...]
Let's now erase all the ubuntu:14.04 containers we've amassed so far:
EXECUTE: docker rm $(docker ps -a |grep 14.04|awk '{print $1}')
RESPOND: What just happened?
EXECUTE: docker run -id --name [youruserid]_ubuntu ubuntu:14.04
[supply your own usesrID above in the command]
RESPOND: What just happened? Is your userid image currently
running in a container or not? How do find out if it's running?
EXECUTE: docker exec -it [youruserid]_ubuntu /bin/bash
Ok, great, now we’re in our container. Now what? Well,
let’s update the Ubuntu operating system with the latest release:
[execute these commands INSIDE your Ubuntu container...]
EXECUTE: uname -a
EXECUTE: apt-get update
RESPOND: What just happened?
Now download the vi editor:
EXECUTE: apt-get install vim
EXECUTE: which vim
EXECUTE: cd /; ls -la; whoami
RESPOND: What did you learn from executing those commands?
Now, exit your container by either typing exit or pressing Ctrl-d:
EXECUTE: exit [or press ^d]
You have now exited your container and are back at your OS prompt.
EXECUTE: docker stats -a --no-stream
RESPOND: What is all this info? What does it mean?
EXECUTE: docker stop [youruserid]_ubuntu
EXECUTE: docker ps
RESPOND: What does docker stop do (be specific about the signal)?
Now, start your container again:
docker start [youruserid]_ubuntu
Open another terminal window, and:
EXECUTE: docker kill [youruserid]_ubuntu
RESPOND: What just happened? Be specific about signals
Now share a directory from your hard drive with your container (cd to /tmp)
On your host system (or inside you virtualbox VM), create a new
directory under your home directory called “lab2” (if you already have
that directory, fine, use it). Now create a new file called
lab2.txt in your lab2 directory and edit its contents to be "I love
docker".
EXECUTE: docker run -it -v ~/lab2:/clab2 ubuntu:14.04 /bin/bash
Now, from within your container:
EXECUTE: cat /clab2/lab2.txt
EXECUTE: ls –la /clab2
RESPOND: Discuss what just happened. Be specific about the docker run command above and the effect of the -v flag...
Now, remove the container you just created...whatever its name or id.
Now, suppose we’d like to copy our ~/lab2/lab2.txt file into your [youruserid]_ubuntu container. How would you do that?
EXECUTE: docker cp ~/lab2/lab2.txt [youruserid]_ubuntu:/clab2
RESPOND: Is your [youruserid]_ubuntu running? Does it
matter to the docker cp command whether the container is actually
running?
EXECUTE: docker exec -it marks_ubuntu /bin/bash
Now, inside your container:
EXECUTE: ls -la ~/clab2
RESPOND: What do you see?
EXECUTE: cat ~/clab2/lab2.txt
RESPOND: What do you see?
EXECUTE: vi ~/clab2/lab2.txt
Now modify its contents in some way.
Now exit your container.
EXECUTE: docker cp [youruserid]_ubuntu:/awesome2 .
cat ~/lab2/lab2.txt
RESPOND: What do you see?
Now make this all permanent by saving a new image based on your
modified container. That way, you can use [youruserid]_ubuntu for
all sorts of new purposes:
EXECUTE: docker images
EXECUTE: docker commit [youruserid]_ubuntu ubuntu:[youruserid]_update
ESXECUTE: docker images
RESPOND: What just happened? What is the difference between the outputs of the two docker images commands above?
EXECUTE: docker inspect ubuntu:[youruserid]_update
RESPOND: What is all this information, in summary?
One last thing to do. Let's practice saving a contiainer image to
a tarball so we can share our images and containers with others.
If you need to (run docker images to find out), get down busybox again:
EXECUTE (only if you don't have busybox from last week's lab): docker run busybox echo Hello 51221 Class Peeps!
Now, let’s copy that container to a tarball:
EXECUTE: docker ps –a
$ docker ps -a
CONTAINER ID
IMAGE
COMMAND
CREATED
STATUS
PORTS NAMES
27945f906b5d
busybox "echo Hello 51221
..." 13 days
ago Exited (0) About an
hour
ago
gallant_kowalevski
Now, let’s export it to a tarball (you will need to change "gallant_kowalevski" to whatever name YOUR container has):
EXECUTE: docker export gallant_kowalevski > update.tar
Now, let's import that new container image:
EXECUTE: docker import – update < update.tar
Now, let’s see our newly imported image:
EXECUTE: docker images
Now, run our new image to instantiate a container:
EXECUTE: docker run -it update echo Hello 51221 Class Peeps!
Finally, start the new container once again and watch it execute
[substitute YOUR appropriate container NAME instead of
elated_blackwell]:
EXECUTE: docker start -i elated_blackwell
Enough hand-holding. Now, let's get used to networking with the Apache HTTP Server.
Here's your final task:
Download an apache httpd image, make sure it's running, and make sure
you have exposed (linked) port 8080 to your host from your container
(you'll likely need to edit httpd.conf), and create a tarball
(docker export) and gzip your tarball and submit it as per the
instructions below. Before submitting it, make sure you can
hit your web server from your host operating system's browser (or
curl), as that's how it will be graded. Finally, talk with your
team members about how you might incorporate a web server into your
final project solution.
Make sure you SAVE YOUR SCRIPT FILE.
References:
You
may find the following references helpful (in addition to the links from previous labs):
Ubuntu package commands
General Docker Tutorial Links
Docker Cheat Sheet
Submitting:
Create
a Bitbucket Repository called Lab 2. Upload your Lab 2 script output and any
supporting materials to this repo, including your response file. Make sure that the user name
"johnhb" has access to this repo. Please include a README text file
that contains any instructions for
the TAs to assist with grading, and design notes are often the most
useful thing you can provide. We do not usually need any info on how to
compile your code unless your code layout is arcane.