School of Computer Science Dr.
COMP5349: Cloud Computing Sem. 1/2022
Week 3: Docker Tutorial
Learning Objectives
Copyright By PowCoder代写 加微信 powcoder
10.03.2022
• Get familiar with Docker key components like docker daemon, registry, containers and images by going through the official tutorial.
• Understand Docker networking and storage options as demonstrated in the official tutorial.
• Briefly explore the Linux kernel’s name space feature such as file system and process.
The lab uses the sample application used in Docker Get Started documentation. The official documentation assumes a local installation; you may follow it on your own com- puter.
We adapted it for use in a Cloud environment so that all students can have a consistent experience. This setting also allows for more interesting observations. This involves run- ning containers on a virtual machine. Similar to week 2 lab, we are working on command line most of the time.
Lab Exercises
Question 1: Start a standard Ubuntu EC2 instance and connect to it
Start an EC2 instance using AMI ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-202111 You can find the AMI from Community AMIs tab by searching “ubuntu”1. This AMI can
run on a range of instance types. You can use a very small instance. However, to get rea-
sonable performance, you are recommended to use a t2.small or t2.medium instance.
In this lab, the instance is expected to receive requests on the following tcp ports:
• port 3000 for a simple Node.js web server • port 3030 for another Node.js web server
1The lab can run on any supported Ubuntu version, if you prefer Ubuntu 18 or 16, you can use the respective AMI
Make sure you include security rules to allow TCP connections from any node to those ports on the instance. You may practice setting up a security group with a proper name like “standalone-docker-container” (an example can be seen in Figure 1).
Figure 1: Sample Security Group
In the launching step, remember to use the key pair you generated in week 2 lab.
After the instance is launched, use a terminal window or Putty to connect to it as ubuntu.
Question 2: Install Docker Engine
Install Docker engine following the official installation guide for Ubuntu OS. The guide describes several installation methods. We recommend you follow the steps as described in Install using the repository.
After installing Docker, you should also follow the Post-installation steps for Linux to set up the docker group and to add the current user to docker group.
Question 3: Basic Docker Usage
The steps described here are adapted/adopted from Part 2: Sample Application of the official Docker tutorial. We use the command line instead of the Docker Dashboard that is available for Windows and macOS.
The sample application is a simple Node.js, a to-do list manager. Run the following command from user ubuntu’s home directory to get the application’s source code:
git clone https://github.com/docker/getting-started.git
This creates a sub-directory “getting-started” representing the local repository of the re- mote Docker “getting-started” repository. The application source code and relevant con- figuration are stored in the sub-directory “app”. Change the present working directory to “app”:
cd getting-started/app/
Create a file named Dockerfile in the “app” directory with the following contents.
# syntax=docker/dockerfile:1
FROM node:12-alpine
RUN apk add –no-cache python2 g++ make
WORKDIR /app
RUN yarn install –production
CMD [“node”, “src/index.js”]
EXPOSE 3000
Build the image using the following command:
docker build -t getting-started .
The “-t” option specifies the name of the image that we can refer to later. The “.” at the end of the docker build command indicates the location of the Dockerfile, which is the current directory
Start the container with the following command:
docker run -dp 3000:3000 –name c1 getting-started
The “-d” flag specifies that we are running the new container in “detached” mode (in the background).
The “-p” flag creates a mapping between the host’s port 3000 to the container’s port 3000. The “–name” flag specifies a name for the container for easy reference. A random name
will be chosen if no name is given.
Run the following curl command to visit your Web server from the same SSH window.
curl http://localhost:3000
If your request returns a valid HTML page, your container has started correctly.
Now start a browser on the your own computer and change the DNS part of the URL to your EC2 instance’s public DNS address to visit your application from a different host.
To test your understanding,
• Describe the network traffic flow after a request is sent from your lab workstation’s
browser window to the web server running inside the container. • How can we run two Web servers on the same host?
Question 4: Create a different image and run a second Web server
The steps in this section are adapted/adopted from part 3:Updating the application of the Docker official tutorial.
The application’s source code “app.js” is stored in the directory “src/static/js/”. Update line 56 of the source code to use the new empty text as follows:
No items yet! Add one above!
Updated:
You have no todo items yet! Add one above!
Return to the directory ~/getting-started/app. Run the following command to build a
new image “getting-started-2” using the updated source code as follows:
docker build -t getting-started-2 .
Start a new container(“c2”) using the new image as follows.
docker run -dp 3030:3000 –name c2 getting-started-2
Note that the port mapping has changed to “3030:3000” in the above command. This means we are mapping host port 3030 to container port 3000 for this container. We cannot use the same mapping because the host port 3000 has been used by the first container. The image name is changed to “getting-started-2”.
Now use the following curl command to check that the container has successfully started.
curl http://localhost:3030
Once confirmed, try to access the second Web server from your own computer.
Question 5: Using Volumes in Docker
This exercise demonstrates the volumes storage option in Docker. Some steps are adapt- ed/adopted from Part 5: Persist the DB of the official Docker tutorial.
Thetodo appisdesignedtostoreitsdatainanSQLiteDatabaseat/etc/todos/todo.dbs. By default, changes to the database are reflected within the container only and will be lost after the container is stopped. Volumes provide an easy way to use the host machine file system from inside a container. This exercise illustrate the difference by having two containers with different storage options.
a) Start container “c3” using volume
Stop the container “c2” as follows: docker stop c2
Once it is stopped, remove it as follows:
docker rm c2
Create a volume as follows:
docker volume create todo-db
Then start container “c3” using the volume just created as follows:
docker run -dp 3030:3000 -v todo-db:/etc/todos –name c3 getting-started-2
In the above command, the “-v” flag specifies a volume mount. In particular, it spec- ifies that the volume “todo-db” should be mounted on the folder “/etc/todos”. This makes it possible to persist the state change happening inside the container. Such persistence is not supported in the first container.
b) Making changes and observe the impact of different storage option
Access the newly started container from your computer using port 3030. Add some todo items in the applications running on port 3000 and on port 3030. Then stop both and remove the containers; then start a new container based on getting-started and getting started-2 respectively. You should see that the changes made in application running on port 3000 disappears while the changes made in application running on port 3030 are still there.
Question 6: Mount a Host Directory inside Container
There are various options to instruct a container to use the host file system as its storage. The option is specified when starting the container. The named volume option used in previous section is suitable for persisting application data that should only be updated from the application/container. It is preferred if we simply want to store data and don’t
need to worry about where the data is stored. Another option bind mounts allow us to control the exact mount point on the host. This is useful if we need to make update outside the application/container. One such scenario is to use a bind mount to mount the source code into the container so that code modifications do not require image rebuilding and container restarting.
a) Start a container with bind mount
The steps here are adapted/adopted from Part 6: Use bind mounts of the Docker official tutorial.
The following commands will stop container “c1” listening on port 3000; change the present directory to ~/getting-started/app; then start a new container “c4”.
docker stop c1
cd ~/getting-started/app
docker run -dp 3000:3000 \
-w /app -v “$(pwd):/app” \
–name c4 \
node:12-alpine \
sh -c “yarn install && yarn run dev”
The “-w” flag creates and sets the working directory that all subsequent commands will run from. This is similar to the “WORKDIR /app” command in the Dockerfile we created early.
The “-v” flag bind mounts the current directory (expressed as $(pwd)) from the host in the container into the /app directory.
Because the source code folder is mounted after the container starts, we cannot in- clude the dependency installation and application start commands in the image. In- stead, we start from the basic node.js image: node:12-alpine and run the installation and application start command after the container starts. The last line of the command starts a shell(sh) in the container and run two yarn command to install dependency and start the node.js application.
b) Container and Host File System
To understand what happens when container “c4” starts, let’s start another container “c5” from the basic node.js image as follows.
docker run -dit –name c5 node:12-alpine sh
The “-dit” flag specifies that we want to start an interactive process (-it) such as a shell in the container and that the container should run in detached mode (-d).
node:12-alpine is the image name with Alpine Linux and node.js. This is also the image used in starting container “c4”.
“sh” is a shell Alpine provides.
No port mapping is specified as we do not expect to publish any port inside the con- tainer.
The docker exec command allows us to run new commands inside a Docker con- tainer. We use it to inspect container file system and process in this section.
Use docker exec
docker exec c4 pwd
docker exec c5 pwd
You will notice that the present working directory of c5 shell is root directory “\” while the present working directory of c4 shell is “\app”. This is the effect of the “-w” option when starting c4. You also notice that each container has its own file system starting from root directory. Run the same command on container c3 and you will find its present working directory is also “\app”.
Now use docker exec
You can also use the docker exec
c) Effect of Bind Mount
Access the application running in container “c4”from your own computer.
Now update line 109 of the source code (src/static/js/app.js) as follows:
{submitting ? ‘Adding…’ : ‘Add Item’} Updated:
{submitting ? ‘Adding … ‘ : ‘Add’}
This will change the text in the “Add Item” button to “Add”. Such a change will take effect immediately inside the container. Refreshing the browser will load the new index page with the button text changed to “Add”. There is no need to create a new image or to restart the container.
References
• Docker Getting Started. • Docker run reference
• Docker exec reference
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com