This commit is contained in:
abregman 2021-10-24 11:06:32 +03:00
parent de98eabea0
commit 7a653a5f12
5 changed files with 211 additions and 8 deletions

View File

@ -88,6 +88,7 @@
|Name|Topic|Objective & Instructions|Solution|Comments|
|--------|--------|------|----|----|
| Set up a CI pipeline | CI | [Exercise](exercises/devops/ci_for_open_source_project.md) | | |
| Containerize an Application | Containers |[Exercise](exercises/devops/containerize_app.md)|[Solution](exercises/devops/solutions/containerize_app.md)
| Deploy to Kubernetes | Deployment | [Exercise](exercises/devops/deploy_to_kubernetes.md) | [Solution](exercises/devops/solutions/deploy_to_kubernetes/README.md) | |
### DevOps Self Assessment
@ -2186,9 +2187,11 @@ Learn more about it [here](https://aws.amazon.com/sqs)
## Network
<details>
<summary>What is Ethernet?</summary><br><b>
<summary>What do you need in order to communicate?</summary><br><b>
Ethernet simply refers to the most common type of Local Area Network (LAN) used today. A LAN—in contrast to a WAN (Wide Area Network), which spans a larger geographical area—is a connected network of computers in a small area, like your office, college campus, or even home.
- A common language (for the two ends to understand)
- A way to address who do you want to communicate with
- A Connection (so the content of of the communication can reach the recipients)
</b></details>
<details>
@ -2198,6 +2201,12 @@ A set of protocols that define how two or more devices can communicate with each
To learn more about TCP/IP, read [here](http://www.penguintutor.com/linux/basic-network-reference)
</b></details>
<details>
<summary>What is Ethernet?</summary><br><b>
Ethernet simply refers to the most common type of Local Area Network (LAN) used today. A LAN—in contrast to a WAN (Wide Area Network), which spans a larger geographical area—is a connected network of computers in a small area, like your office, college campus, or even home.
</b></details>
<details>
<summary>What is a MAC address? What is it used for?</summary><br><b>
@ -5660,7 +5669,8 @@ resource "aws_instance" "tf_aws_instance" {
|--------|--------|------|----|----|
|Running Containers|Intro|[Exercise](exercises/containers/running_containers.md)|[Solution](exercises/containers/solutions/running_containers.md)
|Working with Images|Image|[Exercise](exercises/containers/working_with_images.md)|[Solution](exercises/containers/solutions/working_with_images.md)
|My First Dockerfile|Dockerfile|[Exercise](exercises/write_dockerfile_run_container.md)|[Solution](exercises/write_dockerfile_run_container.md)
|My First Dockerfile|Dockerfile|[Exercise](exercises/containers/write_dockerfile_run_container.md)|
|Run, Forest, Run!|Restart Policies|[Exercise](exercises/containers/run_forest_run.md)|[Solution](exercises/containers/solutions/run_forest_run.md)
### Containers Self Assesment
@ -5711,6 +5721,15 @@ You should choose containers when:
* Running multiple versions or instances of a single application
</b></details>
<details>
<summary>Describe the process of containerizing an application</summary><br><b>
1. Write a Dockerfile that includes your app (including the commands to run it) and its dependencies
2. Build the image using the Dockefile you wrote
3. You might want to push the image to a registry
4. Run the container using the image you've built
</b></details>
#### Containers - OCI
<details>
@ -5784,6 +5803,14 @@ False. You have to stop the container before removing it.
3. containerd and runc are instructed (by the daemon) to create and start the container
</b></details>
<details>
<summary>How to run a container in the background?</summary><br><b>
With the -d flag. It will run in the background and will not attach it to the terminal.
`docker container run -d httpd` or `podman container run -d httpd`
</b></details>
#### Containers - Images
<details>
@ -5958,6 +5985,12 @@ True.
`docker manifest inspect <name>`
</b></details>
<details>
<summary>How to check what a certain container image will execute once we'll run a container based on that image?</summary><br><b>
Look for "Cmd" or "Entrypoint" fields in the output of `docker image inspec <image name>`
</b></details>
#### Containers - Volume
<details>
@ -5969,17 +6002,33 @@ True.
#### Containers - Dockerfile
<details>
<summary>What is Dockerfile</summary><br><b>
<summary>What is a Dockerfile?</summary><br><b>
Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.
Different container engines (e.g. Docker, Podman) can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text file that contains all the instructions for building an image which containers can use.
</b></details>
<details>
<summary>What is the first line in all Dockefiles and what does it mean?</summary><br><b>
The first instruction is `FROM <image name>`<br>
It specifies the base layer of the image to be used. Every other instruction is a layer on top of that base image.
</b></details>
<details>
<summary>List five different instructions that are available for use in a Dockerfile</summary><br><b>
* WORKDIR: sets the working directory inside the image filesystems for all the instructions following it
* EXPOSE: exposes the specified port (it doesn't adds a new layer, rather documented as image metadata)
* ENTRYPOINT: specifies the startup commands to run when a container is started from the image
</b></details>
<details>
<summary>What is the difference between ADD and COPY in Dockerfile?</summary><br><b>
COPY takes in a src and destination. It only lets you copy in a local file or directory from your host (the machine building the Docker image) into the Docker image itself.
ADD lets you do that too, but it also supports 2 other sources. First, you can use a URL instead of a local file / directory. Secondly, you can extract a tar file from the source directly into the destination.
Although ADD and COPY are functionally similar, generally speaking, COPY is preferred. Thats because its more transparent than ADD. COPY only supports the basic copying of local files into the container, while ADD has some features (like local-only tar extraction and remote URL support) that are not immediately obvious.
COPY takes in a source and destination. It lets you copy in a file or directory from the build context into the Docker image itself.<br>
ADD lets you do the same, but it also supports two other sources. You can use a URL instead of a file or directory from the build context. In addition, you can extract a tar file from the source directly into the destination.
Although ADD and COPY are functionally similar, generally speaking, COPY is preferred. Thats because its more transparent than ADD. COPY only supports the basic copying of files from build context into the container, while ADD has some features (like local-only tar extraction and remote URL support) that are not immediately obvious.
</b></details>
<details>
@ -6280,6 +6329,21 @@ False. Communication between client and server shouldn't be done over HTTP since
Basically, the Docker daemon will only accept secured connections with certificates from trusted CA.
</b></details>
<details>
<summary>What forms of self-healing options available for Docker containers?</summary><br><b>
Restart Policies. It allows you to automatically restart containers after certain events.
</b></details>
<details>
<summary>What restart policies are you familiar with?</summary><br><b>
* always: restart the container when it's stopped (not with `docker container stop`)
* unless-stopped: restart the container unless it was in stopped status
* no: don't restart the container at any point (default policy)
* on-failure: restart the container when it exists due to an error (= exit code different than zero)
</b></details>
## Kubernetes
<a name="kubernetes"></a>
@ -13474,6 +13538,20 @@ DNS
https://idiallo.com/blog/c10k-2016
</b></details>
## Storage
<details>
<summary>What types of storage devices are there?</summary><br><b>
</b></details>
<details>
<summary>What is a filesystem?</summary><br><b>
</b></details>
<details>
<summary>Explain Dark Data</summary><br><b>
</b></details>
## HR
These are not DevOps related questions as you probably noticed, but since they are part of the DevOps interview process I've decided it might be good to keep them

View File

@ -0,0 +1,31 @@
## Run, Forest, Run!
### Objective
Learn what restart policies do and how to use them
### Requirements
Make sure Docker is installed on your system and the service is started
```
# Fedora/RHEL/CentOS
rpm -qa | grep docker
systemctl status docker
```
### Instructions
1. Run a container with the following properties:
* image: alpine
* name: forest
* restart policy: always
* command to execute: sleep 15
2. Run `docker container ls` - Is the container running? What about after 15 seconds, is it still running? why?
3. How then can we stop the container from running?
4. Remove the container you've created
5. Run the same container again but this time with `sleep 600` and verify it runs
6. Restart the Docker service. Is the container still running? why?
8. Update the policy to `unless-stopped`
9. Stop the container
10. Restart the Docker service. Is the container running? why?

View File

@ -0,0 +1,71 @@
## Run, Forest, Run!
### Objective
Learn what restart policies do and how to use them
### Requirements
Make sure Docker is installed on your system and the service is started
```
# Fedora/RHEL/CentOS
rpm -qa | grep docker
systemctl status docker
```
### Instructions
1. Run a container with the following properties:
* image: alpine
* name: forest
* restart policy: always
* command to execute: sleep 15
`docker run --restart always --name forest alpine sleep 15`
2. Run `docker container ls` - Is the container running? What about after 15 seconds, is it still running? why?
It runs even after it completes to run `sleep 15` because the restart policy is "always". This means that Docker will keep restarting the **same** container even after it exists.
3. How then can we stop the container from running?
The restart policy doesn't apply when the container is stopped with the command `docker container stop`
4. Remove the container you've created
```
docker container stop forest
docker container rm forest
```
5. Run the same container again but this time with `sleep 600` and verify it runs
```
docker run --restart always --name forest alpine sleep 600
docker container ls
```
6. Restart the Docker service. Is the container still running? why?
```
sudo systemctl restart docker
```
Yes, it's still running due to the restart policy `always` which means Docker will always bring up the container after it exists or stopped (not with the stop command).
8. Update the policy to `unless-stopped`
`docker update --restart unless-stopped forest`
9. Stop the container
`docker container stop forest`
10. Restart the Docker service. Is the container running? why?
```
sudo systemctl restart docker
```
No, the container is not running. This is because we changed the policy to `unless-stopped` which will run the container unless it was in stopped status. Since before the restart we stopped the container, Docker didn't continue running it after the restart.

View File

@ -0,0 +1,23 @@
## Containerize an Application
1. Clone an open source project you would like to containerize. A couple of suggestions:
```
https://github.com/bregman-arie/node-hello-world
https://github.com/bregman-arie/flask-hello-world
```
`git clone https://github.com/bregman-arie/node-hello-world`
2. Write a Dockerfile you'll use for building an image of the application (you can use any base image you would like)
```
FROM alpine
LABEL maintainer="your name/email"
RUN apk add --update nodejs nodejs-npm
COPY . /src
WORKDIR /src
RUN npm install
EXPOSE 8080
ENTRYPOINT ["node", "./app.js"]
```