github/container.training
1
0
Fork 0
mirror of https://github.com/jpetazzo/container.training.git synced 2026-07-26 00:06:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #465 from soulshake/aj-wework

Browse Source 
wording tweaks
This commit is contained in:
Jérôme Petazzoni
2019-05-28 01:54:15 +02:00
committed by GitHub
parent a90dcf1d9a db961b486f
commit 964b92d320
15 changed files with 39 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
slides/containers/Ambassadors.md
View File

@@ -150,7 +150,7 @@ Different deployments will use different underlying technologies.
* Ad-hoc deployments can use a master-less discovery protocol
like avahi to register and discover services.
* It is also possible to do one-shot reconfiguration of the
ambassadors. It is slightly less dynamic but has much less
ambassadors. It is slightly less dynamic but has far fewer
requirements.
* Ambassadors can be used in addition to, or instead of, overlay networks.

14
slides/containers/Application_Configuration.md
View File

@@ -98,13 +98,13 @@ COPY prometheus.conf /etc
* Allows arbitrary customization and complex configuration files.
* Requires to write a configuration file. (Obviously!)
* Requires writing a configuration file. (Obviously!)
* Requires to build an image to start the service.
* Requires building an image to start the service.
* Requires to rebuild the image to reconfigure the service.
* Requires rebuilding the image to reconfigure the service.
* Requires to rebuild the image to upgrade the service.
* Requires rebuilding the image to upgrade the service.
* Configured images can be stored in registries.
@@ -132,11 +132,11 @@ docker run -v appconfig:/etc/appconfig myapp
* Allows arbitrary customization and complex configuration files.
* Requires to create a volume for each different configuration.
* Requires creating a volume for each different configuration.
* Services with identical configurations can use the same volume.
* Doesn't require to build / rebuild an image when upgrading / reconfiguring.
* Doesn't require building / rebuilding an image when upgrading / reconfiguring.
* Configuration can be generated or edited through another container.
@@ -198,4 +198,4 @@ E.g.:
- read the secret on stdin when the service starts,
- pass the secret using an API endpoint.
- pass the secret using an API endpoint.

2
slides/containers/Background_Containers.md
View File

@@ -257,7 +257,7 @@ $ docker kill 068 57ad
The `stop` and `kill` commands can take multiple container IDs.
Those containers will be terminated immediately (without
the 10 seconds delay).
the 10-second delay).
Let's check that our containers don't show up anymore:

12
slides/containers/Cmd_And_Entrypoint.md
View File

@@ -222,16 +222,16 @@ CMD ["hello world"]
Let's build it:
```bash
$ docker build -t figlet .
$ docker build -t myfiglet .
...
Successfully built 6e0b6a048a07
Successfully tagged figlet:latest
Successfully tagged myfiglet:latest
```
Run it without parameters:
```bash
$ docker run figlet
$ docker run myfiglet
_ _ _ _
| | | | | | | | |
| | _ | | | | __ __ ,_ | | __|
@@ -246,7 +246,7 @@ $ docker run figlet
Now let's pass extra arguments to the image.
```bash
$ docker run figlet hola mundo
$ docker run myfiglet hola mundo
_ _
| | | | |
| | __ | | __, _ _ _ _ _ __| __
@@ -262,13 +262,13 @@ We overrode `CMD` but still used `ENTRYPOINT`.
What if we want to run a shell in our container?
We cannot just do `docker run figlet bash` because
We cannot just do `docker run myfiglet bash` because
that would just tell figlet to display the word "bash."
We use the `--entrypoint` parameter:
```bash
$ docker run -it --entrypoint bash figlet
$ docker run -it --entrypoint bash myfiglet
root@6027e44e2955:/#
```

2
slides/containers/Container_Engines.md
View File

@@ -164,7 +164,7 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes).
* Run each container in a lightweight virtual machine.
* Requires to run on bare metal *or* with nested virtualization.
* Requires running on bare metal *or* with nested virtualization.
---

4
slides/containers/First_Containers.md
View File

@@ -259,7 +259,7 @@ bash: figlet: command not found
* work on project
* when done, shutdown VM
* when done, shut down VM
* next time we need to work on project, restart VM as we left it
@@ -281,7 +281,7 @@ bash: figlet: command not found
* work on project
* when done, shutdown container
* when done, shut down container
* next time we need to work on project, start a new container

14
slides/containers/Local_Development_Workflow.md
View File

@@ -156,7 +156,7 @@ Option 3:
* Use a *volume* to mount local files into the container
* Make changes locally
* Changes are reflected into the container
* Changes are reflected in the container
---
@@ -176,7 +176,7 @@ $ docker run -d -v $(pwd):/src -P namer
* `namer` is the name of the image we will run.
* We don't specify a command to run because it is already set in the Dockerfile.
* We don't specify a command to run because it is already set in the Dockerfile via `CMD`.
Note: on Windows, replace `$(pwd)` with `%cd%` (or `${pwd}` if you use PowerShell).
@@ -192,7 +192,7 @@ The flag structure is:
[host-path]:[container-path]:[rw|ro]
```
* If `[host-path]` or `[container-path]` doesn't exist it is created.
* `[host-path]` and `[container-path]` are created if they don't exist.
* You can control the write status of the volume with the `ro` and
`rw` options.
@@ -255,13 +255,13 @@ color: red;
* Volumes are *not* copying or synchronizing files between the host and the container.
* Volumes are *bind mounts*: a kernel mechanism associating a path to another.
* Volumes are *bind mounts*: a kernel mechanism associating one path with another.
* Bind mounts are *kind of* similar to symbolic links, but at a very different level.
* Changes made on the host or on the container will be visible on the other side.
(Since under the hood, it's the same file on both anyway.)
(Under the hood, it's the same file anyway.)
---
@@ -273,7 +273,7 @@ by Chad Fowler, where he explains the concept of immutable infrastructure.)*
--
* Let's mess up majorly with our container.
* Let's majorly mess up our container.
(Remove files or whatever.)
@@ -319,7 +319,7 @@ and *canary deployments*.
<br/>
Use the `-v` flag to mount our source code inside the container.
3. Edit the source code outside the containers, using regular tools.
3. Edit the source code outside the container, using familiar tools.
<br/>
(vim, emacs, textmate...)

6
slides/containers/Orchestration_Overview.md
View File

@@ -119,7 +119,7 @@ Now, how are things for our IAAS provider?
- Solution: *migrate* VMs and shutdown empty servers
(e.g. combine two hypervisors with 40% load into 80%+0%,
<br/>and shutdown the one at 0%)
<br/>and shut down the one at 0%)
---
@@ -127,7 +127,7 @@ Now, how are things for our IAAS provider?
How do we implement this?
- Shutdown empty hosts (but keep some spare capacity)
- Shut down empty hosts (but keep some spare capacity)
- Start hosts again when capacity gets low
@@ -175,7 +175,7 @@ In practice, these goals often conflict.
- 16 GB RAM, 8 cores, 1 TB disk
- Each week, your team asks:
- Each week, your team requests:
- one VM with X RAM, Y CPU, Z disk

4
slides/containers/Training_Environment.md
View File

@@ -45,13 +45,13 @@ individual Docker VM.*
- The Docker Engine is a daemon (a service running in the background).
- This daemon manages containers, the same way that an hypervisor manages VMs.
- This daemon manages containers, the same way that a hypervisor manages VMs.
- We interact with the Docker Engine by using the Docker CLI.
- The Docker CLI and the Docker Engine communicate through an API.
- There are many other programs, and many client libraries, to use that API.
- There are many other programs and client libraries which use that API.
---

8
slides/containers/Working_With_Volumes.md
View File

@@ -33,13 +33,13 @@ Docker volumes can be used to achieve many things, including:
* Sharing a *single file* between the host and a container.
* Using remote storage and custom storage with "volume drivers".
* Using remote storage and custom storage with *volume drivers*.
---
## Volumes are special directories in a container
Volumes can be declared in two different ways.
Volumes can be declared in two different ways:
* Within a `Dockerfile`, with a `VOLUME` instruction.
@@ -163,7 +163,7 @@ Volumes are not anchored to a specific path.
* Volumes are used with the `-v` option.
* When a host path does not contain a /, it is considered to be a volume name.
* When a host path does not contain a `/`, it is considered a volume name.
Let's start a web server using the two previous volumes.
@@ -189,7 +189,7 @@ $ curl localhost:1234
* In this example, we will run a text editor in the other container.
(But this could be a FTP server, a WebDAV server, a Git receiver...)
(But this could be an FTP server, a WebDAV server, a Git receiver...)
Let's start another container using the `webapps` volume.

2
slides/k8s/daemonset.md
View File

@@ -371,7 +371,7 @@ But ... why do these pods (in particular, the *new* ones) have this `app=rng` la
- Bottom line: if we remove our `app=rng` label ...
... The pod "diseappears" for its parent, which re-creates another pod to replace it
... The pod "disappears" for its parent, which re-creates another pod to replace it
---

2
slides/k8s/kubectlexpose.md
View File

@@ -81,7 +81,7 @@ Under the hood: `kube-proxy` is using a userland proxy and a bunch of `iptables`
.exercise[
- In another window, watch the pods (to see when they will be created):
- In another window, watch the pods (to see when they are created):
```bash
kubectl get pods -w
```

2
slides/k8s/namespaces.md
View File

@@ -8,7 +8,7 @@
- That would require updating the code
- There as to be a better way!
- There has to be a better way!
--

2
slides/k8s/rollout.md
View File

@@ -28,7 +28,7 @@
- there will therefore be up to `maxUnavailable`+`maxSurge` pods being updated
- We have the possibility to rollback to the previous version
- We have the possibility of rolling back to the previous version
<br/>(if the update fails or is unsatisfactory in any way)
---

2
slides/k8s/versions-k8s.md
View File

@@ -29,7 +29,7 @@ class: extra-details
- Kubernetes 1.13 only validates Docker Engine versions [up to 18.06](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#external-dependencies)
- Is this a problem if I use Kubernetes with a "too recent" Docker Engine?
- Is it a problem if I use Kubernetes with a "too recent" Docker Engine?
--