├── 1-building-first-image
    └── README.md
├── 2-image-dive
    └── README.md
├── 3-docker-compose
    ├── README.md
    ├── docker-compose.yml
    ├── images
    │   └── dig-output.png
    └── src
    │   └── index.php
└── README.md


/1-building-first-image/README.md:
--------------------------------------------------------------------------------
  1 | # Hands-on #1
  2 | 
  3 | In this first hands-on exercise, we're going to build our first container image, push it to Docker Hub, and then run a container using that image.
  4 | 
  5 | **If you haven't done so yet**, [create a Docker Hub account](https://hub.docker.com/). You will need this to access Play with Docker and sharing images through Docker Hub.
  6 | 
  7 | ## Getting Started
  8 | 
  9 | For the workshop, we will be using Play with Docker, a tool created by several Docker Captains to help you get up and running. Beyond it being a great tool, we don't have to rely on the conference's network speeds, as the containers and images are running remotely.
 10 | 
 11 | 1. Open your web browser to [http://play-with-docker.com](http://play-with-docker.com).
 12 | 2. Login using your Docker Hub account. If you don't have an account yet, [you can do so here](https://hub.docker.com).
 13 | 
 14 | 
 15 | ## Creating and running our first Image
 16 | 
 17 | As we discussed, images are best created and maintained using Dockerfiles. These files are simple text files that provide instructions on how to create a container image.
 18 | 
 19 | 1. In the PWD console, create a folder named `exercise1`.
 20 | 2. In the `exercise1` directory, create a file named `index.php`. In that file, we're going to create the simplest PHP application:
 21 | 
 22 |     ```php
 23 |     <?php phpinfo();
 24 |     ```
 25 | 
 26 | 3. Now, create a file named `Dockerfile`. In the file, put the following:
 27 | 
 28 |     ```
 29 |     FROM php:7-apache
 30 |     COPY index.php /var/www/html
 31 |     ```
 32 | 
 33 |    - The `FROM` command tells the builder that our container image will base from the `php:7-apache` image. Any instructions we perform afterwards will add additional layers.
 34 |    - The `COPY` command causes the local `index.php` file to be placed into the file system we are creating for our container image at `/var/www/html`.
 35 | 
 36 | 4. At this point, let's build our image! Run the following command:
 37 | 
 38 |     ```
 39 |     docker build -t my-first-php-image .
 40 |     ```
 41 | 
 42 |     - The `-t` flag indicates a 'tag', or a name that we want to apply to the image. We can then use that to start a container from that name (which we'll do next).
 43 |     - The trailing `.` tells the Docker Engine that the Dockerfile and build context to be used is the current directory. The build context indicates the root of files we will use in the Dockerfile (like the copying of the index.php file).
 44 | 
 45 | 5. Let's run our container image! Run the following command:
 46 | 
 47 |     ```
 48 |     docker container run -p 80:80 -d my-first-php-image
 49 |     ```
 50 | 
 51 |     - The `-p` flag tells the Docker Engine that we want to create a mapping of port 80 on the host (the left-side of the argument) to port 80 of the container (the right side). 
 52 |     - The `-d` flag tells the Docker Engine that we want to run the new container in 'detached mode'. In other words, simply run it in the background.
 53 | 
 54 | 6. At this point, you should see a small badge appear at the top of the page with the number '80' in it. Clicking this badge will open a URL to port 80 for your container.
 55 | 
 56 | Congrats! You've now created and run your first container image!
 57 | 
 58 | 
 59 | ## Sharing the Image
 60 | 
 61 | The image you just created exists only on the machine that performed the build. So, if we want to share the image, we need to push it to a registry. Think of a registry as a code repo. It's sole purpose is to share container images.
 62 | 
 63 | 1. In order to push to Docker Hub, we need to authenticate. Do this by running:
 64 | 
 65 |     ```
 66 |     docker login
 67 |     ```
 68 | 
 69 | 2. All images (except Official Images) in Docker Hub are namespaced. For example, if I push images, they aren't going to simply named `my-first-php-image`, as it doesn't convey _who_ it comes from, but creates a nightmare trying to ensure my image doesn't collide with yours. To fix this, my image would be named `mikesir87/my-first-php-image`. Using the `docker tag` command, we can provide another name for the image we built earlier.
 70 | 
 71 |     ```
 72 |     # Replace mikesir87 with your Docker Hub username
 73 |     docker tag my-first-php-image mikesir87/my-first-php-image
 74 |     ```
 75 | 
 76 | 3. Now that we're authenticated and we have our image tagged correctly, let's push it!
 77 | 
 78 |     ```
 79 |     # Replace mikesir87 with your Docker Hub username
 80 |     docker push mikesir87/my-first-php-image
 81 |     ```
 82 | 
 83 | 4. Open your browser to [Docker Hub](https://hub.docker.com) and you should see the new repo! Feel free to click on it and see the "Pushed X minutes ago."
 84 | 
 85 | 
 86 | ## Running our Image
 87 | 
 88 | With PWD, it's easy to get a new instance. With it being a new instance, the only way our app can run is if we pull the image.
 89 | 
 90 | 1. Click the 'Create Instance' button in the left navigation menu.
 91 | 2. In the terminal for our new instance, run the following:
 92 | 
 93 |     ```
 94 |     # Replace mikesir87 with your Docker Hub username
 95 |     docker container run -p 80:80 -d mikesir87/my-first-php-image
 96 |     ```
 97 | 
 98 |     We'll see the image get pulled from Docker Hub and start up. Magic, huh?
 99 | 
100 | 3. Click on the '80' badge and see the app!
101 | 
102 | 
103 | ## Wrap-up
104 | 
105 | While this was a pretty simple application, let's think about what was needed to run the application. 
106 | 
107 | - We needed a PHP runtime engine, an Apache HTTP server, and a PHP script. Before containers, we would have needed to have a machine that had the correct versions installed and make the script available. But, **our container image shipped everything it needed to run.**
108 | - We created our container image using a Dockerfile, which assures our application is consistent no matter where we build it. With it being a text file, the full environment of our application can be version controlled!
109 | 
110 | When you're done, place the Post-It note on the back of your laptop monitor.
111 | 


--------------------------------------------------------------------------------
/2-image-dive/README.md:
--------------------------------------------------------------------------------
 1 | # Hands-on #2
 2 | 
 3 | In this hands-on demo, we're going to do a little bit of a deep-dive into container images and learn a valuable lesson in the process!
 4 | 
 5 | ## Overview
 6 | 
 7 | We have come across a "mystery" image that we're not too familiar with what it is or what's contained. Before running it, we want to find out what's in the image and if there are potentially any issues with it.
 8 | 
 9 | 
10 | ## Looking at the image history
11 | 
12 | Every image is composed of immutable layers. When each layer is created, the executing instruction is recorded and saved. Let's take a look at our mystery image and see what we can figure out just from the history.
13 | 
14 | 1. Remove the PWD instances you already created and create a new instance (get a fresh start).
15 | 2. Run `docker pull mikesir87/mystery-image`. This will pull the image that we are going to use.
16 | 3. Run `docker image history mikesir87/mystery-image`. This display all of the layers, as well as the command.
17 | 3. One thing you'll notice as that the instructions are truncated. By adding the `--no-trunc` flag (strange how the flag to not truncate is truncated, right?), we can see the full output.
18 | 
19 |     ```
20 |     docker image history --no-trunc mikesir87/mystery-image
21 |     ```
22 | 
23 |     If we look at the output, we see several references to npm, node, and others. So, it looks like we're looking at a Node app of some sort. Cool!
24 | 
25 | 
26 | ## Diving into the Image
27 | 
28 | When Docker pulls an image, each layer is pulled individually. However, there may be times in which you want to export or save an image to move it somewhere else (like an airgapped network). Fortunately, we can use this same approach to dive into each of the layers.
29 | 
30 | 1. In your instance, let's save our image. When you run the command, the outcome is a stream of a tarball (similar to a ZIP file) containing the image. We could save the tar to ship around, but in our case, we will extract it immediately.
31 | 
32 |     ```
33 |     docker image save mikesir87/mystery-image | tar -x
34 |     ```
35 | 
36 |     Run `ls` to look at the contents. We'll see lots of folders with super long names, a `manifest.json`, and a few other metadata files.
37 | 
38 | 2. Since we're going to be looking at several JSON objects, let's install the `jq` utility.
39 | 
40 |     ```
41 |     apk add --update jq
42 |     ```
43 | 
44 | 3. Now, let's look at the `manifest.json`. Run the following command:
45 | 
46 |     ```
47 |     jq . manifest.json
48 |     ```
49 | 
50 |     Looking at the output, we'll see several keys. If we look at the `layers` key, we'll see file paths to various tar files. Each of these contains the file system changes that occurred while that layer was being built. Let's take a look at one.
51 | 
52 | 4. Let's take a look at layer starting with `6a6d515f`. Judging by the image history and the order of the layers in the `manifest.json`, this should be the layer that's copying lots of files in. Let's take a look!
53 | 
54 |     ```
55 |     cd 6a6d515f9f7dec5f2a0a705bf7640376132e7d78773fc96faae5990ffd543bc5
56 |     tar xvf layer.tar
57 |     ```
58 | 
59 |     Looking at the output, we see lots of files being copied in. Cool! One file that _might_ be of interest could be the `app/src/settings.js` file. Let's take a look at that.
60 | 
61 |     ```
62 |     cat app/src/settings.js
63 |     ```
64 | 
65 |     **Oh no!** This looks like something that shouldn't have been in the image! You've captured the flag!!!
66 | 
67 | 
68 | ## Handling file deletions
69 | 
70 | Now that you've captured the flag, let's see if the details are in the final image. If we run `docker container run -it mikesir87/mystery-image ls /app/src`, we see the `index.js` file. But, we don't see the `settings.js` file. What gives?
71 | 
72 | Remember that image layers are immutable. Once created, the layer is never changed. So, how are file removals represented in the layer's tar? Let's take a look.
73 | 
74 | 1. The final layer is the one in which the `/app/src/settings.js` file is being removed (remember from the image history output earlier?). Get its id from the `manifest.json`
75 | 
76 |     ```
77 |     jq . manifest.json
78 |     ```
79 | 
80 | 2. With the layer, let's output the contents of the tar, but display only files containing the name `settings`
81 | 
82 |     ```
83 |     tar tvf [LAYER_ID]/layer.tar | grep settings
84 |     ```
85 | 
86 | What you should see is a file named `/app/src/.wh.settings.js`. This is the whiteout file we talked about earlier. When the layers are merged together, this file tells the unioned filesystem to ignore the file found in a previous layer.
87 | 
88 | 
89 | ## Takeaways
90 | 
91 | - **NEVER** copy credentials into an image. Even if they are deleted, you're still shipping them around and then can still be extracted.
92 | - Clean up your image as you go. Even if you delete files (uninstall packages as an example), you are still shipping them in the original layer.
93 | 


--------------------------------------------------------------------------------
/3-docker-compose/README.md:
--------------------------------------------------------------------------------
  1 | # Docker Compose Hands-on
  2 | 
  3 | In the workshop, we talked about creating a basic multi-service application. But, the final compose file wasn't _quite_ ready to run an application. While both the app and database would launch, there's no app code to connect to it and the application doesn't have the necessary dependencies installed to use MySQL. So, let's fix all of this!
  4 | 
  5 | ## Setup
  6 | 
  7 | 1. In a new PWD instance, clone this repo:
  8 | 
  9 |     ```
 10 |     git clone https://github.com/mikesir87/dceu-2018-workshop.git
 11 |     cd dceu-2018-workshop
 12 |     ```
 13 | 
 14 |     We will be using this as the starting point for our workshop.
 15 | 
 16 | ## Replacing the App Image
 17 | 
 18 | As mentioned in the overview, the base `php:7-apache` image doesn't have the necessary MySQL extensions installed. To fix this, we will create our own image and update our compose file to use it!
 19 | 
 20 | 1. In the workshop directory, create a new `Dockerfile`. In it, place the following:
 21 | 
 22 |     ```
 23 |     FROM php:7-apache
 24 |     RUN docker-php-ext-install mysqli
 25 |     ```
 26 | 
 27 |     The `php` image includes a few helper scripts to install extensions. We're simply using that script to install the extension.
 28 | 
 29 | 2. Update the compose file to use this image to add the `build` instruction:
 30 | 
 31 |     ```
 32 |     services:
 33 |       app:
 34 |         build: ./
 35 |     ```
 36 | 
 37 |     The `build` instruction tells Compose to build an image using the Dockerfile found in the current directory (`./`) and then use that as the image.
 38 | 
 39 | 3. Remove the `image` declaration from the `app` service.
 40 | 
 41 | 4. Now, if you run `docker-compose up -d`, you should see an image be created and the application attempt to start. If we open the app at [http://localhost/](http://localhost), we get the following error:
 42 | 
 43 | > Connection failed: No such file or directory
 44 | 
 45 | 
 46 | ## Connecting to the Database
 47 | 
 48 | If you look in the `src/index.php` file, you'll see some connection details at the top of the file. In order for the app to work, we need to get an actual connection to the database.
 49 | 
 50 | When Docker starts a container, it makes itself the DNS resolver for all requests (DNS is used to lookup an IP address for a hostname). While many applications may connect to a database using an IP address, DNS is a _fantastic_ way to do service discovery (finding out where things are).
 51 | 
 52 | 1. Let's get into the PHP container and see if it can find the database.
 53 | 
 54 |    ```
 55 |    docker exec -ti 3-docker-compose_app_1 bash
 56 | 
 57 |    # Now, you have a bash inside the container. Let's install dig
 58 |    apt update && apt install dnsutils
 59 | 
 60 |    dig mysql
 61 |    ```
 62 | 
 63 |    What you should is an `A` record returned that shows the name `mysql` resolving to an IP address. It may case, it resolved to `172.19.0.2` (see below).
 64 | 
 65 |    ![Dig output](./images/dig-output.png)
 66 | 
 67 | 2. Let's verify that that is indeed the IP address for the container. First, we have to drop out of our container and get back on to the host.
 68 | 
 69 |     ```
 70 |     exit
 71 |     ```
 72 | 
 73 |     You should now see a prompt simply starting with `$`.
 74 | 
 75 | 3. Let's look at the MySQL container and see what IP address it was given.
 76 | 
 77 |    ```
 78 |    docker container inspect 3-docker-compose_mysql_1
 79 |    ```
 80 | 
 81 |    This is pretty overwhelming, but it shows _all_ details for a container. If we look through the JSON, we'll see `NetworkSettings` -> `Networks` -> `3-compose-file` -> `IPAddress` is the same as what we saw in our `dig` command. Cool!
 82 | 
 83 |    A simpler way to get the IP address is using "filters" on the result
 84 | 
 85 |    ```
 86 |    docker container inspect 3-docker-compose_mysql_1 -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'
 87 |    ```
 88 | 
 89 | 4. Now that we know the hostname for sure, let's update the `index.php` file.
 90 | 
 91 |    ```
 92 |    $DB_HOST = 'mysql';
 93 |    ```
 94 | 
 95 | 5. Open up the app and you should now see the current time, as reported by the database!
 96 | 
 97 | 
 98 | ## Wrap-up
 99 | 
100 | In this hands-on, we updated the compose file to use a custom image, rather than an image directly from Docker Hub. We then looked a little bit into container network and service discovery using DNS. And, finally, we got our app working.
101 | 
102 | Hooray!
103 | 


--------------------------------------------------------------------------------
/3-docker-compose/docker-compose.yml:
--------------------------------------------------------------------------------
 1 | version: "3.7"
 2 | 
 3 | services: 
 4 |   app:
 5 |     image: php:7-apache
 6 |     ports:
 7 |       - 80:80
 8 |     volumes:
 9 |       - ./src:/var/www/html
10 |   mysql:
11 |     image: mysql:5.7
12 |     environment:
13 |       MYSQL_ROOT_PASSWORD: secret
14 |       MYSQL_DATABASE: workshop
15 |     volumes:
16 |       - mysql-data:/var/lib/mysql
17 | 
18 | volumes:
19 |   mysql-data:
20 | 


--------------------------------------------------------------------------------
/3-docker-compose/images/dig-output.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/aboullaite/docker101-workshop/91278bcf6e8f8a34155893f5f7e4e2830b2976db/3-docker-compose/images/dig-output.png


--------------------------------------------------------------------------------
/3-docker-compose/src/index.php:
--------------------------------------------------------------------------------
 1 | <?php
 2 | 
 3 | $DB_HOST = 'localhost';
 4 | $DB_USER = 'root';
 5 | $DB_PASSWORD = 'secret';
 6 | $DB_NAME = 'workshop';
 7 | 
 8 | $conn = new mysqli($DB_HOST, $DB_USER, $DB_PASSWORD, $DB_NAME);
 9 | if ($conn->connect_error) 
10 |     die("Connection failed: " . $conn->connect_error);
11 | 
12 | $sql = "SELECT LOCALTIMESTAMP() as time FROM DUAL";
13 | $row = $conn->query($sql)->fetch_assoc();
14 | echo $row['time'];
15 | $conn->close();
16 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Docker 101 tour
2 | 
3 | The materials of Docker Morocco tour.
4 | This work is mainly inspired by [Michael Irwin and Ell Marquez](https://github.com/mikesir87/dceu-2018-workshop) worksop at DockerCon EU 2018!
5 | 


--------------------------------------------------------------------------------