Add Datadog and ArgoCD questions
As well as exercises.
This commit is contained in:
parent
7cceb86b38
commit
cbdcfa3e4f
31
README.md
31
README.md
@ -2,9 +2,7 @@
|
|||||||
|
|
||||||
:information_source: This repo contains questions and exercises on various technical topics, sometimes related to DevOps and SRE
|
:information_source: This repo contains questions and exercises on various technical topics, sometimes related to DevOps and SRE
|
||||||
|
|
||||||
:bar_chart: There are currently **2415** exercises and questions
|
:bar_chart: There are currently **2466** exercises and questions
|
||||||
|
|
||||||
:books: To learn more about DevOps and SRE, check the resources in [devops-resources](https://github.com/bregman-arie/devops-resources) repository
|
|
||||||
|
|
||||||
:warning: You can use these for preparing for an interview but most of the questions and exercises don't represent an actual interview. Please read [FAQ page](faq.md) for more details
|
:warning: You can use these for preparing for an interview but most of the questions and exercises don't represent an actual interview. Please read [FAQ page](faq.md) for more details
|
||||||
|
|
||||||
@ -799,6 +797,33 @@ Logging<br>
|
|||||||
<summary>What is the difference between infrastructure monitoring and application monitoring? (methods, tools, ...)</summary><br><b>
|
<summary>What is the difference between infrastructure monitoring and application monitoring? (methods, tools, ...)</summary><br><b>
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
### Application Performance Management
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is Application Performance Management?</summary><br><b>
|
||||||
|
|
||||||
|
- IT metrics translated into business insights
|
||||||
|
- Practices for monitoring applications insights so we can improve performances, reduce issues and improve overall user experience
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Name three aspects of a project you can monitor with APM (e.g. backend)</summary><br><b>
|
||||||
|
|
||||||
|
- Frontend
|
||||||
|
- Backend
|
||||||
|
- Infra
|
||||||
|
- ...
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What can be collected/monitored to perform APM monitoring?</summary><br><b>
|
||||||
|
|
||||||
|
- Metrics
|
||||||
|
- Logs
|
||||||
|
- Events
|
||||||
|
Traces
|
||||||
|
</b></details>
|
||||||
|
|
||||||
## Prometheus
|
## Prometheus
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
|
2
faq.md
2
faq.md
@ -34,7 +34,7 @@ I don't have a definitive answer for this question, I'm exploring it myself from
|
|||||||
|
|
||||||
1. Search for them using search engines, documentation pages, ... this is part of being a DevOps engineer
|
1. Search for them using search engines, documentation pages, ... this is part of being a DevOps engineer
|
||||||
2. Use the communities: many people will be happy to help and answer your questions
|
2. Use the communities: many people will be happy to help and answer your questions
|
||||||
3. Ask us. If you want, you can contact me or even open an issue that is only a question, that's totally fine :)
|
3. Ask us. If you want, you can contact me or start a discussion on this project.
|
||||||
|
|
||||||
### Where the questions and answers are coming from?
|
### Where the questions and answers are coming from?
|
||||||
|
|
||||||
|
@ -2,15 +2,40 @@
|
|||||||
|
|
||||||
- [Argo](#argo)
|
- [Argo](#argo)
|
||||||
- [ArgoCD Exercises](#argocd-exercises)
|
- [ArgoCD Exercises](#argocd-exercises)
|
||||||
- [Argo Questions](#argo-questions)
|
|
||||||
- [ArgoCD 101](#argocd-101)
|
- [ArgoCD 101](#argocd-101)
|
||||||
|
- [ArgoCD Secrets](#argocd-secrets)
|
||||||
|
- [ArgoCD Helm](#argocd-helm)
|
||||||
|
- [Argo Questions](#argo-questions)
|
||||||
|
- [ArgoCD 101](#argocd-101-1)
|
||||||
- [Practical ArgoCD 101](#practical-argocd-101)
|
- [Practical ArgoCD 101](#practical-argocd-101)
|
||||||
|
- [CLI](#cli)
|
||||||
|
- [ArgoCD Configuration](#argocd-configuration)
|
||||||
- [Multi-Cluster Environment](#multi-cluster-environment)
|
- [Multi-Cluster Environment](#multi-cluster-environment)
|
||||||
- [Access Control](#access-control)
|
- [ArgoCD Application Health](#argocd-application-health)
|
||||||
|
- [ArgoCD Syncs](#argocd-syncs)
|
||||||
|
- [ArgoCD and Helm](#argocd-and-helm)
|
||||||
|
|
||||||
## ArgoCD Exercises
|
## ArgoCD Exercises
|
||||||
|
|
||||||
TODO
|
### ArgoCD 101
|
||||||
|
|
||||||
|
|Name|Topic|Objective & Instructions|Solution|Comments|
|
||||||
|
|--------|--------|------|----|----|
|
||||||
|
| Creating an App | App | [Exercise](exercises/app_creation/exercise.md) | [Solution](exercises/app_creation/solution.md)
|
||||||
|
| Syncing App - Git | Sync | [Exercise](exercises/sync_app_git/exercise.md) | [Solution](exercises/sync_app_git/solution.md)
|
||||||
|
| Syncing App - Cluster | Sync | [Exercise](exercises/sync_app_cluster/exercise.md) | [Solution](exercises/sync_app_cluster/solution.md)
|
||||||
|
|
||||||
|
### ArgoCD Secrets
|
||||||
|
|
||||||
|
|Name|Topic|Objective & Instructions|Solution|Comments|
|
||||||
|
|--------|--------|------|----|----|
|
||||||
|
| Secrets 101 | Secrets | [Exercise](exercises/secrets_101/exercise.md) | [Solution](exercises/secrets_101/solution.md)
|
||||||
|
|
||||||
|
### ArgoCD Helm
|
||||||
|
|
||||||
|
|Name|Topic|Objective & Instructions|Solution|Comments|
|
||||||
|
|--------|--------|------|----|----|
|
||||||
|
| Helm ArgoCD App | Secrets | [Exercise](exercises/argocd_helm_app/exercise.md) | [Solution](exercises/argocd_helm_app/solution.md)
|
||||||
|
|
||||||
## Argo Questions
|
## Argo Questions
|
||||||
|
|
||||||
@ -53,11 +78,10 @@ With ArgoCD it's really easy to roll back to a previous version because all the
|
|||||||
4. Push to image to a registry
|
4. Push to image to a registry
|
||||||
5. Update K8S manifest file(s) in a separate app config repository
|
5. Update K8S manifest file(s) in a separate app config repository
|
||||||
6. ArgoCD tracks changes in the app config repository. Since there was a change in the repository, it will apply the changes from the repo
|
6. ArgoCD tracks changes in the app config repository. Since there was a change in the repository, it will apply the changes from the repo
|
||||||
7.
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>True or False? ArgoCD support Kubernetes YAML files but not other manifests formats like Helm Charts and Kustomize</summary><br><b>
|
<summary>True or False? ArgoCD supports Kubernetes YAML files but not other manifests formats like Helm Charts and Kustomize</summary><br><b>
|
||||||
|
|
||||||
False. It supports Kubernetes YAML files as well as Helm Charts and Kustomize.
|
False. It supports Kubernetes YAML files as well as Helm Charts and Kustomize.
|
||||||
|
|
||||||
@ -113,6 +137,13 @@ Ella is right, ArgoCD is an extension of the cluster, that is very different fro
|
|||||||
"Application"
|
"Application"
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How ArgoCD makes access management in the cluster easier?</summary><br><b>
|
||||||
|
|
||||||
|
Instead of creating Kubernetes resources, you can use Git to manage who is allowed to push code, to review it, merge it, etc - either human users or 3rd party systems and services. There is no need to use ClusterRole or User resources in Kubernetes hence the management of access is much more simplified.
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
### Practical ArgoCD 101
|
### Practical ArgoCD 101
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -148,6 +179,77 @@ This section defines with which Kubernetes cluster the app in the tracked Git re
|
|||||||
AddProject
|
AddProject
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>True or False? ArgoCD sync period is 3 hours</summary><br><b>
|
||||||
|
|
||||||
|
False. ArgoCD sync period is 3 minutes as of today (and not hours).
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Describe shortly what ArgoCD does every sync period</summary><br><b>
|
||||||
|
|
||||||
|
1. Gathers list of all the apps to sync (those that are marked with "auto-sync")
|
||||||
|
2. Gets Git state for each repository
|
||||||
|
3. Performs comparison between the repository Git state and the Kubernetes cluster state
|
||||||
|
1. If states are different, the application marked as "out-of-sync" and further action might be taken (based on the configuration)
|
||||||
|
2. If states are equal, the application marked as "synced"
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
#### CLI
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Create a new application with the following properties:
|
||||||
|
|
||||||
|
* app name: some-app
|
||||||
|
* repo: https://fake.repo.address
|
||||||
|
* app path: ./app_path
|
||||||
|
* namespace: default
|
||||||
|
* cluster: my.kubernetes.cluster
|
||||||
|
</summary><br><b>
|
||||||
|
|
||||||
|
```
|
||||||
|
argocd app create some-app \
|
||||||
|
--project \
|
||||||
|
--repo https://fake.repo.address \
|
||||||
|
--path ./app_path \
|
||||||
|
--dest-namespace default \
|
||||||
|
--dest-server my.kubernetes.cluster
|
||||||
|
```
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>List all argocd apps</summary><br><b>
|
||||||
|
|
||||||
|
`argocd app list`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Print detailed information on the app called "some-app"</summary><br><b>
|
||||||
|
|
||||||
|
`argocd app get some-app`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
### ArgoCD Configuration
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Is it possible to change default sync period of ArgoCD?</summary><br><b>
|
||||||
|
|
||||||
|
Yes, it is possible by adding the following to the argocd-cm (ConfigMap):
|
||||||
|
|
||||||
|
```
|
||||||
|
data:
|
||||||
|
timeout.reconciliation: 300s
|
||||||
|
```
|
||||||
|
|
||||||
|
The value can be any number of seconds you would like to set.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What will be the result of setting <code>timeout.reconciliation: 0s</code>?</summary><br><b>
|
||||||
|
|
||||||
|
sync functionality will be disabled.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
### Multi-Cluster Environment
|
### Multi-Cluster Environment
|
||||||
|
|
||||||
@ -169,11 +271,73 @@ There are multiple ways to deal with it:
|
|||||||
2. Use overlays and Kustomize to control the context of where your changes synced based on the CI process/pipeline used.
|
2. Use overlays and Kustomize to control the context of where your changes synced based on the CI process/pipeline used.
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
### Access Control
|
### ArgoCD Application Health
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How ArgoCD makes access management in the cluster easier?</summary><br><b>
|
<summary>What are some possible health statuses for an ArgoCD application?</summary><br><b>
|
||||||
|
|
||||||
Instead of creating Kubernetes resources, you can use Git to manage who is allowed to push code, to review it, merge it, etc - either human users or 3rd party systems and services. There is no need to use ClusterRole or User resources in Kubernetes hence the management of access is much more simplified.
|
|
||||||
|
|
||||||
|
* Healthy
|
||||||
|
* Missing: resource doesn't exist in the cluser
|
||||||
|
* Suspended: resource is paused
|
||||||
|
* Progressing: resources isn't healthy but will become healthy or has the chance to become healthy
|
||||||
|
* Degraded: resource isn't healthy
|
||||||
|
* Unknown: it's not known what's the app health
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>True or False? A Deployment considered to be healthy if the Pods are running</summary><br><b>
|
||||||
|
|
||||||
|
Not exactly. A Deployment (as well as StatefulSet, ReplicaSet and DaemonSet) considered healthy if the desired state equals to actual/current state (this includes the number of replicas).
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>True or False? An ingress is considered healthy if status.loadBalancer.ingress list includes at least one value</summary><br><b>
|
||||||
|
|
||||||
|
True.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What can you tell about the health of custom Kubernetes resources?</summary><br><b>
|
||||||
|
|
||||||
|
The health of custom Kubernetes resources is defined by writing Lua scripts.
|
||||||
|
|
||||||
|
You find such list of scripts here: https://github.com/argoproj/argo-cd/tree/master/resource_customizations
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
### ArgoCD Syncs
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain manual syncs vs. automatic syncs</summary><br><b>
|
||||||
|
|
||||||
|
Automatic syncs means that once ArgoCD detected a change or a new version of your app in Git, it will apply the changes so the current/actual state can be equal to desired state.
|
||||||
|
|
||||||
|
With manual syncs, ArgoCD will identify there is a difference, but will do nothing to correct it.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain auto-pruning</summary><br><b>
|
||||||
|
|
||||||
|
If enabled, auto-pruning will remove resources when files or content is removed from a tracked Git repository.
|
||||||
|
|
||||||
|
If disabled, ArgoCD will not remove anything, even when content or files are removed.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Explain self-heal in regards to ArgoCD</summary><br><b>
|
||||||
|
|
||||||
|
Self-heal is the process of correcting the cluster state based on the desired state, when someone makes manual changes to the cluster.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
### ArgoCD and Helm
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What support is provided in ArgoCD for Helm?</summary><br><b>
|
||||||
|
|
||||||
|
ArgoCD is able to track packaged Helm chart in a sense where it will monitor for new versions.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>True or False? When ArgoCD tracks Helm chart the chart is no longer an Helm application and it's a ArgoCD app</summary><br><b>
|
||||||
|
|
||||||
|
True. Trying to execute commands like `helm ls` will fail because helm metadata doesn't exist anymore and the application is tracked as ArgoCD app.
|
||||||
</b></details>
|
</b></details>
|
22
topics/argo/exercises/app_creation/exercise.md
Normal file
22
topics/argo/exercises/app_creation/exercise.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
# App Creation
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have repository with some Kubernetes manifests
|
||||||
|
2. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Using the CLI or the UI, create a a new application with the following properties:
|
||||||
|
1. app name: app-demo
|
||||||
|
2. project: app-project
|
||||||
|
3. repository URL: your repo with some k8s manifests
|
||||||
|
4. namespace: default
|
||||||
|
2. Verify the app was created
|
||||||
|
3. Sync the app
|
||||||
|
4. Verify Kubernetes resources were created
|
||||||
|
5. Delete the app
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution
|
60
topics/argo/exercises/app_creation/solution.md
Normal file
60
topics/argo/exercises/app_creation/solution.md
Normal file
@ -0,0 +1,60 @@
|
|||||||
|
# App Creation
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have repository with some Kubernetes manifests
|
||||||
|
2. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Using the CLI or the UI, create a a new application with the following properties:
|
||||||
|
1. app name: app-demo
|
||||||
|
2. project: app-project
|
||||||
|
3. repository URL: your repo with some k8s manifests
|
||||||
|
4. namespace: default
|
||||||
|
2. Verify the app was created
|
||||||
|
3. Sync the app
|
||||||
|
4. Verify Kubernetes resources were created
|
||||||
|
5. Delete the app
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
### UI
|
||||||
|
|
||||||
|
1. Click on "New App"
|
||||||
|
1. Insert application name: `app-demo`
|
||||||
|
2. Insert project: `app-project`
|
||||||
|
3. Under source put the repository URL to your GitHub repo with Kubernetes manifests
|
||||||
|
1. Set the path for your application
|
||||||
|
4. Under destination put the address of your Kubernetes cluster and set namespace to `default`
|
||||||
|
5. Click on "Create"
|
||||||
|
2. Click on "Sync" button on the "app-demo" form
|
||||||
|
1. Click on "Synchronize"
|
||||||
|
3. Verify the Kubernetes resources were created
|
||||||
|
1. `kubectl get deployments`
|
||||||
|
4. Delete the app
|
||||||
|
|
||||||
|
### CLI
|
||||||
|
|
||||||
|
```
|
||||||
|
argocd app create app-demo \
|
||||||
|
--project app-project \
|
||||||
|
--repo https://fake.repo.address \
|
||||||
|
--path ./some_app_path \
|
||||||
|
--dest-namespace default \
|
||||||
|
--dest-server my.kubernetes.cluster
|
||||||
|
|
||||||
|
# Check app state
|
||||||
|
argocd app list
|
||||||
|
argocd app get app-demo
|
||||||
|
|
||||||
|
# Sync app state
|
||||||
|
argocd app sync app-demo
|
||||||
|
argocd app wait app-demo
|
||||||
|
|
||||||
|
# Verify kubernetes resources were created
|
||||||
|
kubectl get deployments
|
||||||
|
|
||||||
|
# Delete the app
|
||||||
|
argocd app delete app-demo
|
||||||
|
```
|
15
topics/argo/exercises/argocd_helm_app/exercise.md
Normal file
15
topics/argo/exercises/argocd_helm_app/exercise.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# ArgoCD Helm App
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. ArgoCD installed on the k8s cluster
|
||||||
|
3. Repository of an Helm chart
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Create a new app in ArgoCD that points to the repo of your Helm chart
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution
|
23
topics/argo/exercises/argocd_helm_app/solution.md
Normal file
23
topics/argo/exercises/argocd_helm_app/solution.md
Normal file
@ -0,0 +1,23 @@
|
|||||||
|
# ArgoCD Helm App
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. ArgoCD installed on the k8s cluster
|
||||||
|
3. Repository of an Helm chart
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Create a new app in ArgoCD that points to the repo of your Helm chart
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
```
|
||||||
|
argocd app create some-app \
|
||||||
|
--project default \
|
||||||
|
--repo https://repo-with-helm-chart
|
||||||
|
--path "./helm" \
|
||||||
|
--sync-policy auto \
|
||||||
|
--dest-namespace default \
|
||||||
|
--dest-server https://kubernetes.cluster
|
||||||
|
```
|
17
topics/argo/exercises/secrets_101/exercise.md
Normal file
17
topics/argo/exercises/secrets_101/exercise.md
Normal file
@ -0,0 +1,17 @@
|
|||||||
|
# ArgoCD Secrets 101
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Application k8s manifests with secrets
|
||||||
|
3. Kubeseal binary installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install bitnami sealed controller as ArgoCD app
|
||||||
|
2. Encrypt secrets and commit them to the repo with the k8s manifests
|
||||||
|
3. Create an app using the secrets you encrypted
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](soltuion.md) to view the solution
|
31
topics/argo/exercises/secrets_101/soltuion.md
Normal file
31
topics/argo/exercises/secrets_101/soltuion.md
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
# ArgoCD Secrets 101
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Running Kubernetes cluster
|
||||||
|
2. Application k8s manifests with secrets
|
||||||
|
3. Kubeseal binary installed
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Install bitnami sealed controller as ArgoCD app
|
||||||
|
2. Encrypt secrets and commit them to the repo with the k8s manifests
|
||||||
|
3. Create an app using the secrets you encrypted
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
1. Click on "New App"
|
||||||
|
1. app name: controller
|
||||||
|
2. project: default
|
||||||
|
3. sync policy: automatic
|
||||||
|
4. repository URL: a URL to bitnami sealed controller manifests
|
||||||
|
5. namespace: kube-system
|
||||||
|
|
||||||
|
2. Run the following for every secret: `kubeseal < some/secret.yml > sealed_secrets/some/encrypted_secret.yaml -o yaml`
|
||||||
|
|
||||||
|
3. Click on "New App"
|
||||||
|
1. app name: some-app
|
||||||
|
2. project: default
|
||||||
|
3. sync policy: automatic
|
||||||
|
4. repository URL: a URL to k8s manifests (including encrypted secrets)
|
||||||
|
5. namespace: default
|
20
topics/argo/exercises/sync_app_cluster/exercise.md
Normal file
20
topics/argo/exercises/sync_app_cluster/exercise.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
# Sync App - Cluster
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
1. Make sure you have an app deployed in the cluster and tracked by ArgoCD
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Verify the app is tracked by ArgoCD and in sync
|
||||||
|
2. . Make a change to your application by running a `kubectl` command. The change can anything:
|
||||||
|
1. Changing the tag of the image
|
||||||
|
2. Changing the number of replicas
|
||||||
|
3. You can go extreme and delete the resource if you would like :)
|
||||||
|
3. Check the app state in ArgoCD
|
||||||
|
4. Sync the app state
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution
|
48
topics/argo/exercises/sync_app_cluster/solution.md
Normal file
48
topics/argo/exercises/sync_app_cluster/solution.md
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
# Sync App - Cluster
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
1. Make sure you have an app deployed in the cluster and tracked by ArgoCD
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Verify the app is tracked by ArgoCD and in sync
|
||||||
|
2. . Make a change to your application by running a `kubectl` command. The change can anything:
|
||||||
|
1. Changing the tag of the image
|
||||||
|
2. Changing the number of replicas
|
||||||
|
3. You can go extreme and delete the resource if you would like :)
|
||||||
|
3. Check the app state in ArgoCD
|
||||||
|
4. Sync the app state
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
### UI
|
||||||
|
|
||||||
|
1. Click on the app in the UI
|
||||||
|
1. Make sure it's in sync and in "healthy" state
|
||||||
|
2. Make a check in the cluster
|
||||||
|
1. `kubectl scale --replicas=0 <DEPLOYMENT_NAME>`
|
||||||
|
2. `kubectl get rs <DEPLOYMENT_NAME>`
|
||||||
|
3. Go back to the UI and check the state of the app
|
||||||
|
1. If it's still in sync, make sure to click on "Refresh"
|
||||||
|
2. The app should be in "out-of-sync" state
|
||||||
|
3. Click on "Sync" and then on "Synchronize"
|
||||||
|
|
||||||
|
### CLI
|
||||||
|
|
||||||
|
```
|
||||||
|
# Check app state and verify it's in sync
|
||||||
|
argocd app get app-demo
|
||||||
|
|
||||||
|
# Run the following k8s commands (or any other commands that will change the state of your app)
|
||||||
|
kubectl scale --replicas=0 <DEPLOYMENT_NAME>
|
||||||
|
kubectl get rs <DEPLOYMENT_NAME>
|
||||||
|
|
||||||
|
# Check app state again
|
||||||
|
argocd app get app-demo
|
||||||
|
|
||||||
|
# Sync app state
|
||||||
|
argocd app sync app-demo
|
||||||
|
argocd app wait app-demo
|
||||||
|
```
|
68
topics/argo/exercises/sync_app_git/exercise.md
Normal file
68
topics/argo/exercises/sync_app_git/exercise.md
Normal file
@ -0,0 +1,68 @@
|
|||||||
|
# Sync App - Git
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have repository with some Kubernetes manifests
|
||||||
|
2. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Create a new application using the UI or CLI
|
||||||
|
1. App Name: app-demo
|
||||||
|
2. Project: project-demo
|
||||||
|
3. Kubernetes namespace: default
|
||||||
|
2. Sync the application
|
||||||
|
3. Verify the application is running by executing `kubectl get deploy` in the `default` namespace
|
||||||
|
4. Now make a change in your repository to one of the Kubernetes manifests (e.g. update deployment tag)
|
||||||
|
5. Go back to ArgoCD and check the state of the app
|
||||||
|
6. Sync the state of the application
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
Click [here](solution.md) to view the solution
|
||||||
|
|
||||||
|
### UI
|
||||||
|
|
||||||
|
1. Click on "New App"
|
||||||
|
1. Insert application name: `app-demo`
|
||||||
|
2. Insert project: `project-demo`
|
||||||
|
3. Under source put the repository URL to your GitHub repo with Kubernetes manifests
|
||||||
|
1. Set path of your application
|
||||||
|
4. Under destination put the address of your Kubernetes cluster and set namespace to `default`
|
||||||
|
5. Click on "Create"
|
||||||
|
2. Click on the newly created application
|
||||||
|
1. Click on the "sync button" and click on "Synchronize"
|
||||||
|
3. Make a change in your Git repo where the Kubernetes manifests are
|
||||||
|
1. `git add .`
|
||||||
|
2. `git commit -a`
|
||||||
|
3. `git push origin <BRANCH_NAME>`
|
||||||
|
4. Go back to ArgoCD UI and check the status of the app
|
||||||
|
1. You should see it's "out-of-sync". If you don't, you may want to click on "Refresh"
|
||||||
|
2. You can also click on "App diff" to see the difference that led to "out-of-sync"
|
||||||
|
5. Click on "Sync" and "Synchronize" to sync the application
|
||||||
|
|
||||||
|
### CLI
|
||||||
|
|
||||||
|
```
|
||||||
|
argocd app create app-demo \
|
||||||
|
--project project-demo \
|
||||||
|
--repo https://fake.repo.address \
|
||||||
|
--path ./some_app_path \
|
||||||
|
--dest-namespace default \
|
||||||
|
--dest-server my.kubernetes.cluster
|
||||||
|
|
||||||
|
# In the Git repo
|
||||||
|
cd <git repo>
|
||||||
|
vi <k8s manifest>
|
||||||
|
git add .
|
||||||
|
git commit -a
|
||||||
|
git push origin <BRANCH_NAME>
|
||||||
|
|
||||||
|
# Check app state
|
||||||
|
argocd app get app-demo
|
||||||
|
|
||||||
|
# Sync app state
|
||||||
|
argocd app sync app-demo
|
||||||
|
argocd app wait app-demo
|
||||||
|
```
|
66
topics/argo/exercises/sync_app_git/solution.md
Normal file
66
topics/argo/exercises/sync_app_git/solution.md
Normal file
@ -0,0 +1,66 @@
|
|||||||
|
# Sync App - Git
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
1. Make sure you have repository with some Kubernetes manifests
|
||||||
|
2. Make sure you have a Kubernetes cluster running with ArgoCD installed
|
||||||
|
|
||||||
|
|
||||||
|
## Objectives
|
||||||
|
|
||||||
|
1. Create a new application using the UI or CLI
|
||||||
|
1. App Name: app-demo
|
||||||
|
2. Project: project-demo
|
||||||
|
3. Kubernetes namespace: default
|
||||||
|
2. Sync the application
|
||||||
|
3. Verify the application is running by executing `kubectl get deploy` in the `default` namespace
|
||||||
|
4. Now make a change in your repository to one of the Kubernetes manifests (e.g. update deployment tag)
|
||||||
|
5. Go back to ArgoCD and check the state of the app
|
||||||
|
6. Sync the state of the application
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
### UI
|
||||||
|
|
||||||
|
1. Click on "New App"
|
||||||
|
1. Insert application name: `app-demo`
|
||||||
|
2. Insert project: `project-demo`
|
||||||
|
3. Under source put the repository URL to your GitHub repo with Kubernetes manifests
|
||||||
|
1. Set path of your application
|
||||||
|
4. Under destination put the address of your Kubernetes cluster and set namespace to `default`
|
||||||
|
5. Click on "Create"
|
||||||
|
2. Click on the newly created application
|
||||||
|
1. Click on the "sync button" and click on "Synchronize"
|
||||||
|
3. Make a change in your Git repo where the Kubernetes manifests are
|
||||||
|
1. `git add .`
|
||||||
|
2. `git commit -a`
|
||||||
|
3. `git push origin <BRANCH_NAME>`
|
||||||
|
4. Go back to ArgoCD UI and check the status of the app
|
||||||
|
1. You should see it's "out-of-sync". If you don't, you may want to click on "Refresh"
|
||||||
|
2. You can also click on "App diff" to see the difference that led to "out-of-sync"
|
||||||
|
5. Click on "Sync" and "Synchronize" to sync the application
|
||||||
|
|
||||||
|
### CLI
|
||||||
|
|
||||||
|
```
|
||||||
|
argocd app create app-demo \
|
||||||
|
--project project-demo \
|
||||||
|
--repo https://fake.repo.address \
|
||||||
|
--path ./some_app_path \
|
||||||
|
--dest-namespace default \
|
||||||
|
--dest-server my.kubernetes.cluster
|
||||||
|
|
||||||
|
# In the Git repo
|
||||||
|
cd <git repo>
|
||||||
|
vi <k8s manifest>
|
||||||
|
git add .
|
||||||
|
git commit -a
|
||||||
|
git push origin <BRANCH_NAME>
|
||||||
|
|
||||||
|
# Check app state
|
||||||
|
argocd app get app-demo
|
||||||
|
|
||||||
|
# Sync app state
|
||||||
|
argocd app sync app-demo
|
||||||
|
argocd app wait app-demo
|
||||||
|
```
|
@ -1,5 +1,48 @@
|
|||||||
# DataDog
|
# DataDog
|
||||||
|
|
||||||
|
- [DataDog](#datadog)
|
||||||
|
- [Questions](#questions)
|
||||||
|
- [Basics](#basics)
|
||||||
|
|
||||||
## Questions
|
## Questions
|
||||||
|
|
||||||
TODO
|
### Basics
|
||||||
|
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Describe at least three use cases for using something like Datadog. Can be as specific as you would like</summary><br><b>
|
||||||
|
|
||||||
|
* Monitor instances/servers downtime
|
||||||
|
* Detect anomalies and send an alert when it happens
|
||||||
|
* Service request or response latency
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What ways are there to collect or send data to Datadog?</summary><br><b>
|
||||||
|
|
||||||
|
* Datadog agent installed on the device or location which you would like to monitor
|
||||||
|
* Using Datadog API
|
||||||
|
* Built-in integrations
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is a host in regards to Datadog?</summary><br><b>
|
||||||
|
|
||||||
|
Any physical or virtual instance that is monitored with Datadog. Few examples:
|
||||||
|
|
||||||
|
- Cloud Instance, Virtual Machine
|
||||||
|
- Bare metal node
|
||||||
|
- Platform or service specific nodes like Kubernetes node
|
||||||
|
|
||||||
|
Basically any device or location that has Datadog agent installed and running on.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is a Datadog agent?</summary><br><b>
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What are Datadog agents?</summary><br><b>
|
||||||
|
</b></details>
|
@ -53,6 +53,7 @@ What's your goal?
|
|||||||
- [Gatekeeper](#gatekeeper)
|
- [Gatekeeper](#gatekeeper)
|
||||||
- [Policy Testing](#policy-testing)
|
- [Policy Testing](#policy-testing)
|
||||||
- [Helm](#helm)
|
- [Helm](#helm)
|
||||||
|
- [Commands](#commands)
|
||||||
- [Security](#security)
|
- [Security](#security)
|
||||||
- [Troubleshooting Scenarios](#troubleshooting-scenarios)
|
- [Troubleshooting Scenarios](#troubleshooting-scenarios)
|
||||||
- [Istio](#istio)
|
- [Istio](#istio)
|
||||||
@ -156,12 +157,14 @@ To understand what Kubernetes is good for, let's look at some examples:
|
|||||||
<summary>What fields are mandatory with any Kubernetes object?</summary><br><b>
|
<summary>What fields are mandatory with any Kubernetes object?</summary><br><b>
|
||||||
|
|
||||||
metadata, kind and apiVersion
|
metadata, kind and apiVersion
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>What is kubectl?</summary><br><b>
|
<summary>What is kubectl?</summary><br><b>
|
||||||
|
|
||||||
Kubectl is the Kubernetes command line tool that allows you to run commands against Kubernetes clusters. For example, you can use kubectl to deploy applications, inspect and manage cluster resources, and view logs.
|
Kubectl is the Kubernetes command line tool that allows you to run commands against Kubernetes clusters. For example, you can use kubectl to deploy applications, inspect and manage cluster resources, and view logs.
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -170,12 +173,14 @@ Kubectl is the Kubernetes command line tool that allows you to run commands agai
|
|||||||
* Deployment - creates the Pods () and watches them
|
* Deployment - creates the Pods () and watches them
|
||||||
* Service: route traffic to Pods internally
|
* Service: route traffic to Pods internally
|
||||||
* Ingress: route traffic from outside the cluster
|
* Ingress: route traffic from outside the cluster
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>Why there is no such command in Kubernetes? <code>kubectl get containers</code></summary><br><b>
|
<summary>Why there is no such command in Kubernetes? <code>kubectl get containers</code></summary><br><b>
|
||||||
|
|
||||||
Becaused container is not a Kubernetes object. The smallest object unit in Kubernetes is a Pod. In a single Pod you can find one or more containers.
|
Becaused container is not a Kubernetes object. The smallest object unit in Kubernetes is a Pod. In a single Pod you can find one or more containers.
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -184,6 +189,7 @@ Becaused container is not a Kubernetes object. The smallest object unit in Kuber
|
|||||||
- Always make sure Kubernetes YAML files are valid. Applying automated checks and pipelines is recommended.
|
- Always make sure Kubernetes YAML files are valid. Applying automated checks and pipelines is recommended.
|
||||||
- Always specify requests and limits to prevent situation where containers are using the entire cluster memory which may lead to OOM issue
|
- Always specify requests and limits to prevent situation where containers are using the entire cluster memory which may lead to OOM issue
|
||||||
- Specify labels to logically group Pods, Deployments, etc. Use labels to identify the type of the application for example, among other things
|
- Specify labels to logically group Pods, Deployments, etc. Use labels to identify the type of the application for example, among other things
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
### Cluster and Architecture
|
### Cluster and Architecture
|
||||||
@ -2117,18 +2123,20 @@ This one is based more on a personal experience and taste...
|
|||||||
<summary>Explain Kubernetes Secrets</summary><br><b>
|
<summary>Explain Kubernetes Secrets</summary><br><b>
|
||||||
|
|
||||||
Secrets let you store and manage sensitive information (passwords, ssh keys, etc.)
|
Secrets let you store and manage sensitive information (passwords, ssh keys, etc.)
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How to create a Secret from a key and value?</summary><br><b>
|
<summary>How to create a Secret from a key and value?</summary><br><b>
|
||||||
|
|
||||||
kubectl create secret generic some-secret --from-literal=password='donttellmypassword'
|
`kubectl create secret generic some-secret --from-literal=password='donttellmypassword'`
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How to create a Secret from a file?</summary><br><b>
|
<summary>How to create a Secret from a file?</summary><br><b>
|
||||||
|
|
||||||
kubectl create secret generic some-secret --from-file=/some/file.txt
|
`kubectl create secret generic some-secret --from-file=/some/file.txt`
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -2156,18 +2164,14 @@ data:
|
|||||||
password: mySecretPassword
|
password: mySecretPassword
|
||||||
```
|
```
|
||||||
</summary><br><b>
|
</summary><br><b>
|
||||||
|
|
||||||
Password isn't encrypted.
|
Password isn't encrypted.
|
||||||
You should run something like this: `echo -n 'mySecretPassword' | base64` and paste the result to the file instead of using plain-text.
|
You should run something like this: `echo -n 'mySecretPassword' | base64` and paste the result to the file instead of using plain-text.
|
||||||
|
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How to create a Secret from a configuration file?</summary><br><b>
|
<summary>What the following in a Deployment configuration file means?
|
||||||
|
|
||||||
`kubectl apply -f some-secret.yaml`
|
|
||||||
</b></details>
|
|
||||||
|
|
||||||
<details>
|
|
||||||
<summary>What the following in Deployment configuration file means?
|
|
||||||
|
|
||||||
```
|
```
|
||||||
spec:
|
spec:
|
||||||
@ -2179,8 +2183,22 @@ spec:
|
|||||||
key: password
|
key: password
|
||||||
```
|
```
|
||||||
</summary><br><b>
|
</summary><br><b>
|
||||||
|
|
||||||
USER_PASSWORD environment variable will store the value from password key in the secret called "some-secret"
|
USER_PASSWORD environment variable will store the value from password key in the secret called "some-secret"
|
||||||
In other words, you reference a value from a Kubernetes Secret.
|
In other words, you reference a value from a Kubernetes Secret.
|
||||||
|
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to commit secrets to Git and in general how to use encrypted secrets?</summary><br><b>
|
||||||
|
|
||||||
|
One possible process would be as follows:
|
||||||
|
|
||||||
|
1. You create a Kubernetes secret (but don't commit it)
|
||||||
|
2. You encrypt it using some 3rd party project (.e.g kubeseal)
|
||||||
|
3. You apply the seald/encrypted secret
|
||||||
|
4. You commit the the sealed secret to Git
|
||||||
|
5. You deploy an application that requires the secret and it can be automatically decrypted by using for example a Bitnami Sealed secrets controller
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
### Volumes
|
### Volumes
|
||||||
@ -2542,6 +2560,8 @@ Same as Conftest, it is used for policy testing and enforcement. The difference
|
|||||||
<summary>What is Helm?</summary><br><b>
|
<summary>What is Helm?</summary><br><b>
|
||||||
|
|
||||||
Package manager for Kubernetes. Basically the ability to package YAML files and distribute them to other users and apply them in the cluster(s).
|
Package manager for Kubernetes. Basically the ability to package YAML files and distribute them to other users and apply them in the cluster(s).
|
||||||
|
|
||||||
|
As a concept it's quite common and can be found in many platforms and services. Think for example on package managers in operating systems. If you use Fedora/RHEL that would be dnf. If you use Ubuntu then, apt. If you don't use Linux, then a different question should be asked and it's why? but that's another topic :)
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -2605,6 +2625,14 @@ someChart/ -> the name of the chart
|
|||||||
templates/ -> templates files :)
|
templates/ -> templates files :)
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How Helm supports release management?</summary><br><b>
|
||||||
|
|
||||||
|
Helm allows you to upgrade, remove and rollback to previous versions of charts. In version 2 of Helm it was with what is known as "Tiller". In version 3, it was removed due to security concerns.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
#### Commands
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How do you search for charts?</summary><br><b>
|
<summary>How do you search for charts?</summary><br><b>
|
||||||
|
|
||||||
@ -2620,9 +2648,27 @@ Or directly on the command line: `helm install --set some_key=some_value`
|
|||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>How Helm supports release management?</summary><br><b>
|
<summary>How do you list deployed releases?</summary><br><b>
|
||||||
|
|
||||||
Helm allows you to upgrade, remove and rollback to previous versions of charts. In version 2 of Helm it was with what is known as "Tiller". In version 3, it was removed due to security concerns.
|
`helm ls` or `helm list`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to execute a rollback?</summary><br><b>
|
||||||
|
|
||||||
|
`helm rollback RELEASE_NAME REVISION_ID`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to view revision history for a certain release?</summary><br><b>
|
||||||
|
|
||||||
|
`helm history RELEASE_NAME`
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How to upgrade a release?</summary><br><b>
|
||||||
|
|
||||||
|
`helm upgrade RELEASE_NAME CHART_NAME`
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
### Security
|
### Security
|
||||||
|
Loading…
Reference in New Issue
Block a user