mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-02-14 09:39:56 +00:00
Fix overflow in intro material
This commit is contained in:
@@ -16,27 +16,21 @@ We will:
|
||||
|
||||
---
|
||||
|
||||
## Building Images Interactively
|
||||
## The plan
|
||||
|
||||
As we have seen, the images on the Docker Hub are sometimes very basic.
|
||||
1. Create a container (with `docker run`) using our base distro of choice.
|
||||
|
||||
How do we want to construct our own images?
|
||||
2. Run a bunch of commands to install and set up our software in the container.
|
||||
|
||||
As an example, we will build an image that has `figlet`.
|
||||
3. (Optionally) review changes in the container with `docker diff`.
|
||||
|
||||
First, we will do it manually with `docker commit`.
|
||||
4. Turn the container into a new image with `docker commit`.
|
||||
|
||||
Then, in an upcoming chapter, we will use a `Dockerfile` and `docker build`.
|
||||
5. (Optionally) add tags to the image with `docker tag`.
|
||||
|
||||
---
|
||||
|
||||
## Building from a base
|
||||
|
||||
Our base will be the `ubuntu` image.
|
||||
|
||||
---
|
||||
|
||||
## Create a new container and make some changes
|
||||
## Setting up our container
|
||||
|
||||
Start an Ubuntu container:
|
||||
|
||||
@@ -107,7 +101,7 @@ As explained before:
|
||||
|
||||
---
|
||||
|
||||
## Commit and run your image
|
||||
## Commit our changes into a new image
|
||||
|
||||
The `docker commit` command will create a new layer with those changes,
|
||||
and a new image using this new layer.
|
||||
@@ -119,7 +113,13 @@ $ docker commit <yourContainerId>
|
||||
|
||||
The output of the `docker commit` command will be the ID for your newly created image.
|
||||
|
||||
We can run this image:
|
||||
We can use it as an argument to `docker run`.
|
||||
|
||||
---
|
||||
|
||||
## Testing our new image
|
||||
|
||||
Let's run this image:
|
||||
|
||||
```bash
|
||||
$ docker run -it <newImageId>
|
||||
@@ -131,6 +131,8 @@ root@fcfb62f0bfde:/# figlet hello
|
||||
|_| |_|\___|_|_|\___/
|
||||
```
|
||||
|
||||
It works! 🎉
|
||||
|
||||
---
|
||||
|
||||
## Tagging images
|
||||
|
||||
@@ -141,7 +141,7 @@ Why did we use JSON syntax for our `ENTRYPOINT`?
|
||||
|
||||
* When CMD or ENTRYPOINT use string syntax, they get wrapped in `sh -c`.
|
||||
|
||||
* To avoid this wrapping, you must use JSON syntax.
|
||||
* To avoid this wrapping, we can use JSON syntax.
|
||||
|
||||
What if we used `ENTRYPOINT` with string syntax?
|
||||
|
||||
@@ -178,8 +178,6 @@ $ docker run figlet salut
|
||||
\/ \_/|_/|__/ \_/|_/|_/
|
||||
```
|
||||
|
||||
Great success!
|
||||
|
||||
---
|
||||
|
||||
## Using `CMD` and `ENTRYPOINT` together
|
||||
@@ -227,9 +225,8 @@ $ docker build -t figlet .
|
||||
Successfully built 6e0b6a048a07
|
||||
```
|
||||
|
||||
And run it:
|
||||
Run it without parameters:
|
||||
|
||||
.small[
|
||||
```bash
|
||||
$ docker run figlet
|
||||
_ _ _ _
|
||||
@@ -237,7 +234,15 @@ $ docker run figlet
|
||||
| | _ | | | | __ __ ,_ | | __|
|
||||
|/ \ |/ |/ |/ / \_ | | |_/ \_/ | |/ / |
|
||||
| |_/|__/|__/|__/\__/ \/ \/ \__/ |_/|__/\_/|_/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Overriding the image default parameters
|
||||
|
||||
Now let's pass extra arguments to the image.
|
||||
|
||||
```bash
|
||||
$ docker run figlet hola mundo
|
||||
_ _
|
||||
| | | | |
|
||||
@@ -245,7 +250,8 @@ $ docker run figlet hola mundo
|
||||
|/ \ / \_|/ / | / |/ |/ | | | / |/ | / | / \_
|
||||
| |_/\__/ |__/\_/|_/ | | |_/ \_/|_/ | |_/\_/|_/\__/
|
||||
```
|
||||
]
|
||||
|
||||
We overrode `CMD` but still used `ENTRYPOINT`.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -112,6 +112,7 @@ them.
|
||||
|
||||
Here is the file used in the demo:
|
||||
|
||||
.small[
|
||||
```yaml
|
||||
version: "2"
|
||||
|
||||
@@ -130,6 +131,7 @@ services:
|
||||
redis:
|
||||
image: redis
|
||||
```
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -126,13 +126,16 @@ $ docker run -d --name es --net dev elasticsearch:2
|
||||
|
||||
Now, create another container on this network.
|
||||
|
||||
.small[
|
||||
```bash
|
||||
$ docker run -ti --net dev alpine sh
|
||||
root@0ecccdfa45ef:/#
|
||||
```
|
||||
]
|
||||
|
||||
From this new container, we can resolve and ping the other one, using its assigned name:
|
||||
|
||||
.small[
|
||||
```bash
|
||||
/ # ping es
|
||||
PING es (172.18.0.2) 56(84) bytes of data.
|
||||
@@ -145,6 +148,7 @@ PING es (172.18.0.2) 56(84) bytes of data.
|
||||
rtt min/avg/max/mdev = 0.114/0.149/0.221/0.052 ms
|
||||
root@0ecccdfa45ef:/#
|
||||
```
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
@@ -155,6 +159,7 @@ class: extra-details
|
||||
In Docker Engine 1.9, name resolution is implemented with `/etc/hosts`, and
|
||||
updating it each time containers are added/removed.
|
||||
|
||||
.small[
|
||||
```bash
|
||||
[root@0ecccdfa45ef /]# cat /etc/hosts
|
||||
172.18.0.3 0ecccdfa45ef
|
||||
@@ -167,6 +172,7 @@ ff02::2 ip6-allrouters
|
||||
172.18.0.2 es
|
||||
172.18.0.2 es.dev
|
||||
```
|
||||
]
|
||||
|
||||
In Docker Engine 1.10, this has been replaced by a dynamic resolver.
|
||||
|
||||
@@ -358,6 +364,7 @@ Each ElasticSearch instance has a name (generated when it is started). This name
|
||||
|
||||
Try the following command a few times:
|
||||
|
||||
.small[
|
||||
```bash
|
||||
$ docker run --rm --net dev centos curl -s es:9200
|
||||
{
|
||||
@@ -365,9 +372,11 @@ $ docker run --rm --net dev centos curl -s es:9200
|
||||
...
|
||||
}
|
||||
```
|
||||
]
|
||||
|
||||
Then try it a few times by replacing `--net dev` with `--net prod`:
|
||||
|
||||
.small[
|
||||
```bash
|
||||
$ docker run --rm --net prod centos curl -s es:9200
|
||||
{
|
||||
@@ -375,6 +384,7 @@ $ docker run --rm --net prod centos curl -s es:9200
|
||||
...
|
||||
}
|
||||
```
|
||||
]
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ At the end of this section, you will be able to:
|
||||
|
||||
---
|
||||
|
||||
## Using a Docker container for local development
|
||||
## Containerized local development environments
|
||||
|
||||
We want to solve the following issues:
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Implementing multi-stage builds for our C program
|
||||
## Multi-stage builds for our C program
|
||||
|
||||
We will change our Dockerfile to:
|
||||
|
||||
@@ -65,7 +65,7 @@ The resulting Dockerfile is on the next slide.
|
||||
|
||||
---
|
||||
|
||||
## Revised Dockerfile implementing multi-stage build
|
||||
## Multi-stage build `Dockerfile`
|
||||
|
||||
Here is the final Dockerfile:
|
||||
|
||||
@@ -89,7 +89,7 @@ docker run hellomultistage
|
||||
|
||||
---
|
||||
|
||||
## Comparing single-stage and multi-stage image sizes
|
||||
## Comparing single/multi-stage build image sizes
|
||||
|
||||
List our images with `docker images`, and check the size of:
|
||||
|
||||
|
||||
@@ -85,16 +85,8 @@ The `docker inspect` command will output a very detailed JSON map.
|
||||
```bash
|
||||
$ docker inspect <containerID>
|
||||
[{
|
||||
"AppArmorProfile": "",
|
||||
"Args": [],
|
||||
"Config": {
|
||||
"AttachStderr": true,
|
||||
"AttachStdin": false,
|
||||
"AttachStdout": true,
|
||||
"Cmd": [
|
||||
"bash"
|
||||
],
|
||||
"CpuShares": 0,
|
||||
...
|
||||
(many pages of JSON here)
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ We will see an example in the following slides.
|
||||
|
||||
class: extra-details
|
||||
|
||||
## Sharing web application logs with another container
|
||||
## Sharing app server logs with another container
|
||||
|
||||
Let's start a Tomcat container:
|
||||
|
||||
@@ -311,9 +311,9 @@ QUIT
|
||||
|
||||
---
|
||||
|
||||
## What happens when you remove containers with volumes?
|
||||
## Volumes lifecycle
|
||||
|
||||
* Volumes are kept around.
|
||||
* When you remove a container, its volumes are kept around.
|
||||
|
||||
* You can list them with `docker volume ls`.
|
||||
|
||||
@@ -371,9 +371,9 @@ $ docker inspect <yourContainerID>
|
||||
|
||||
---
|
||||
|
||||
## Sharing a single file between the host and a container
|
||||
## Sharing a single file
|
||||
|
||||
The same `-v` flag can be used to share a single file.
|
||||
The same `-v` flag can be used to share a single file (instead of a directory).
|
||||
|
||||
One of the most interesting examples is to share the Docker control socket.
|
||||
|
||||
@@ -381,8 +381,11 @@ One of the most interesting examples is to share the Docker control socket.
|
||||
$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker sh
|
||||
```
|
||||
|
||||
Warning: when using such mounts, the container gains root-like access to the host.
|
||||
It can potentially do bad things.
|
||||
From that container, you can now run `docker` commands communicating with
|
||||
the Docker Engine running on the host. Try `docker ps`!
|
||||
|
||||
.warning[Since that container has access to the Docker socket, it
|
||||
has root-like access to the host.]
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user