mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-18 12:29:18 +00:00
Tweaks / formating / English
This commit is contained in:
Jerome Petazzoni
@@ -1,22 +1,25 @@
|
||||
## Jenkins/Jenkins-X
|
||||
## Jenkins / Jenkins-X
|
||||
|
||||
- Multi purpose CI
|
||||
- Multi-purpose CI
|
||||
|
||||
- Self-hosted CI for kubernetes
|
||||
|
||||
- testing in namespace, feature branch
|
||||
- Testing in namespace, feature branch
|
||||
|
||||
<!-- FIXME explain what the line above means? -->
|
||||
|
||||
.small[
|
||||
```shell
|
||||
$ curl -L "https://github.com/jenkins-x/jx/releases/download/v2.0.1103/jx-darwin-amd64.tar.gz" | tar xzv "jx"
|
||||
$ ./jx boot
|
||||
curl -L "https://github.com/jenkins-x/jx/releases/download/v2.0.1103/jx-darwin-amd64.tar.gz" | tar xzv jx
|
||||
./jx boot
|
||||
```
|
||||
]
|
||||
|
||||
---
|
||||
## Gitlab
|
||||
|
||||
- repository + registry + ci/cd integrated all-in-one
|
||||
## GitLab
|
||||
|
||||
- Repository + registry + CI/CD integrated all-in-one
|
||||
|
||||
```shell
|
||||
helm repo add gitlab https://charts.gitlab.io/
|
||||
@@ -24,13 +27,14 @@ helm install gitlab gitlab/gitlab
|
||||
```
|
||||
|
||||
---
|
||||
## Tekton/knative
|
||||
## Tekton / knative
|
||||
|
||||
- knative is serverless project from google
|
||||
|
||||
- Tekton leverage knative to run pipeline
|
||||
- Tekton leverages knative to run pipelines
|
||||
|
||||
---
|
||||
|
||||
## ArgoCD
|
||||
|
||||
.small[
|
||||
@@ -38,3 +42,8 @@ helm install gitlab gitlab/gitlab
|
||||
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
|
||||
```
|
||||
]
|
||||
|
||||
<!--
|
||||
FIXME I think we should add some details about these projects,
|
||||
otherwise it feels like an enumeration
|
||||
-->
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
## Exercise - build in kubernetes
|
||||
## Exercise - building with Kubernetes
|
||||
|
||||
Go to https://github.com/enix/kubecoin
|
||||
- Let's go to https://github.com/enix/kubecoin
|
||||
|
||||
and follow the instructions to complete the exercise #1
|
||||
- Our goal is to follow the instructions and complete exercise #1
|
||||
|
||||
@@ -1,72 +1,84 @@
|
||||
# OpenTelemetry
|
||||
|
||||
*OpenTelemetry* is a "tracing" framework. It's a fusion of two other frameworks:
|
||||
*opentracing* and *opencensus*.
|
||||
*OpenTelemetry* is a "tracing" framework.
|
||||
|
||||
The goal is to have deep integration with software languages and application framework to
|
||||
enable deep dive tracing of different events accross different components
|
||||
It's a fusion of two other frameworks:
|
||||
*OpenTracing* and *OpenCensus*.
|
||||
|
||||
Its goal is to provide deep integration with programming languages and
|
||||
application frameworks to enabled deep dive tracing of different events accross different components.
|
||||
|
||||
---
|
||||
|
||||
## Span ! span ! span !
|
||||
|
||||
- A unit a tracing is called a `span`.
|
||||
- A unit of tracing is called a *span*
|
||||
|
||||
- A span has a start time and and stop time and an ID.
|
||||
- A span has: a start time, a stop time, and an ID
|
||||
|
||||
- It represent an action that took some time to complete
|
||||
- It represents an action that took some time to complete
|
||||
|
||||
ex: call to function `B`, DB transation, REST call to a backend...
|
||||
(e.g.: function call, database transaction, REST API call ...)
|
||||
|
||||
- A span could have a parent and could be parent of multiple child spans.
|
||||
- A span can have a parent span, and can have multiple child spans
|
||||
|
||||
ex: during the call to function `B`, a sub call to `C` and `D` has been issued
|
||||
(e.g.: when calling function `B`, sub-calls to `C` and `D` were issued)
|
||||
|
||||
- Think of it as a "tree" of calls
|
||||
|
||||
---
|
||||
|
||||
## Distributed tracing
|
||||
|
||||
- This could be applied to multiple components
|
||||
- When two components interact, their spans can be connected together
|
||||
|
||||
ex: If microservice `A` send REST call to microservice `B`
|
||||
- Example: microservice `A` sends a REST API call to microservice `B`
|
||||
|
||||
- `A` will have a span for the call to `B`
|
||||
|
||||
- `B` will have a span for the call from `A`
|
||||
(that normally starts shortly after, and finishes shortly before)
|
||||
- the span of `A` will be the parent of the span of `B`,
|
||||
so that they join the same "tree" of call
|
||||
<br/>(that normally starts shortly after, and finishes shortly before)
|
||||
|
||||
- the span of `A` will be the parent of the span of `B`
|
||||
|
||||
- they join the same "tree" of calls
|
||||
|
||||
<!-- FIXME the thing below? -->
|
||||
|
||||
details: `A` will send headers (depends of the protocol used) to tag the span ID,
|
||||
so that `B` can generate child span and joining the same tree of call
|
||||
|
||||
---
|
||||
|
||||
## Centrally stored
|
||||
|
||||
- We do have "spans", ok. But what do we do with that ?
|
||||
- What do we do with all these spans?
|
||||
|
||||
- We store them.
|
||||
- We store them!
|
||||
|
||||
- In the previous exemple:
|
||||
|
||||
- `A` will send trace to it's local agent
|
||||
- `A` will send trace information to its local agent
|
||||
- `B` will do the same
|
||||
- Every span will ends up in the same DB so that we can reconstruct the "tree" of call
|
||||
later on and analyze it.
|
||||
- every span will end up in the same DB
|
||||
- at a later point, we can reconstruct the "tree" of call and analyze it
|
||||
|
||||
- there is multiple implementation of those agents + DB + WebUI. The most famous opensource ones:
|
||||
- There are multiple implementations of this stack (agent + DB + web UI)
|
||||
|
||||
- Zipkin
|
||||
- Jaeger
|
||||
(the most famous open source ones are Zipkin and Jaeger)
|
||||
|
||||
---
|
||||
## Distributed sampled
|
||||
|
||||
- Huh, we store all of them ? (that could be a lot of storage)
|
||||
## Data sampling
|
||||
|
||||
- No, we could apply sampling, to reduce storage/network footprint.
|
||||
- Do we store *all* the spans?
|
||||
|
||||
- Smart sampling is applied directly in the application to save CPU if span is not needed.
|
||||
(it looks like this could need a lot of storage!)
|
||||
|
||||
- It also insures that if a span is mark as sampled, all child-span are sampled together
|
||||
- No, we can use *sampling*, to reduce storage and network requirements
|
||||
|
||||
- Smart sampling is applied directly in the application to save CPU if span is not needed
|
||||
|
||||
- It also insures that if a span is marked as sampled, all child span are sampled as well
|
||||
|
||||
(so that the tree of call is complete)
|
||||
|
||||
@@ -1,15 +1,24 @@
|
||||
# Prometheus
|
||||
|
||||
Prometheus is monitoring system with small storage io footprint. It's quite ubiquitous
|
||||
Prometheus is monitoring system with small storage io footprint.
|
||||
|
||||
in the kubernetes world. This section is not a description
|
||||
It's quite ubiquitous in the Kubernetes world.
|
||||
|
||||
This section is not a description
|
||||
|
||||
## Prometheus endpoint
|
||||
<!--
|
||||
FIXME maybe just use prometheus.md and add this file after it?
|
||||
This way there is not need to write a Prom intro.
|
||||
-->
|
||||
|
||||
The goal here is to expose an HTTP endoint for prometheus. Sample response:
|
||||
---
|
||||
|
||||
## Prometheus exporter
|
||||
|
||||
We want to provide a Prometheus exporter.
|
||||
|
||||
A Prometheus exporter is an HTTP endpoint serving a response like this one:
|
||||
|
||||
.small[
|
||||
```
|
||||
# HELP http_requests_total The total number of HTTP requests.
|
||||
# TYPE http_requests_total counter
|
||||
@@ -19,68 +28,119 @@ The goal here is to expose an HTTP endoint for prometheus. Sample response:
|
||||
# Minimalistic line:
|
||||
metric_without_timestamp_and_labels 12.47
|
||||
```
|
||||
]
|
||||
|
||||
|
||||
To achieve this multiple strategies could be used:
|
||||
|
||||
- developping in the application itself (especialy if it's already an httpserver)
|
||||
|
||||
- using building blocks that may already expose such endpoint (puma, uwsgi)
|
||||
|
||||
- Add sidecar exporter that leverage an already existing monitoring channel (ex: JMX)
|
||||
|
||||
---
|
||||
## Developing prometheus endpoint
|
||||
|
||||
- Using prometheus client libraries is often the easier
|
||||
## Implementing a Prometheus exporter
|
||||
|
||||
- Offer multiple ways of integrations:
|
||||
Multiple strategies can be used:
|
||||
|
||||
- from: I run already a web server, just add a monitoring route
|
||||
- Implement the exporter in the application itself
|
||||
|
||||
- to: please run a full web server in a thread.
|
||||
(especially if it's already an HTTP server)
|
||||
|
||||
- Use building blocks that may already expose such an endpoint
|
||||
|
||||
(puma, uwsgi)
|
||||
|
||||
- Add a sidecar exporter that leverages and adapts an existing monitoring channel
|
||||
|
||||
(e.g. JMX for Java applications)
|
||||
|
||||
---
|
||||
|
||||
## Implementing a Prometheus exporter
|
||||
|
||||
- The Prometheus client libraries are often the easiest solution
|
||||
|
||||
- They offer multiple ways of integration, including:
|
||||
|
||||
- "I'm already running a web server, just add a monitoring route"
|
||||
|
||||
- "I don't have a web server (or I want another one), please run one in a thread"
|
||||
|
||||
- Client libraries for various languages:
|
||||
|
||||
Links (do you see a pattern ?):
|
||||
- https://github.com/prometheus/client_python
|
||||
|
||||
- https://github.com/prometheus/client_ruby
|
||||
|
||||
- https://github.com/prometheus/client_golang
|
||||
|
||||
(Can you see the pattern?)
|
||||
|
||||
---
|
||||
## Add sidecar Exporter
|
||||
|
||||
- There is plenty of already existing "exporter":
|
||||
## Adding a sidecar exporter
|
||||
|
||||
- https://prometheus.io/docs/instrumenting/exporters/
|
||||
- There are many exporters available already:
|
||||
|
||||
- Those are "translators" from one monitoring channel to another
|
||||
https://prometheus.io/docs/instrumenting/exporters/
|
||||
|
||||
- Writing your own is not complicated (using previous client libraries)
|
||||
- These are "translators" from one monitoring channel to another
|
||||
|
||||
- Try to not expose monitoring channel more than needed. Often localhost is enough
|
||||
(sidecars run in the same network namespace as other containers)
|
||||
- Writing your own is not complicated
|
||||
|
||||
(using the client libraries mentioned previously)
|
||||
|
||||
- Avoid exposing the internal monitoring channel more than enough
|
||||
|
||||
(the app and its sidecars run in the same network namespace,
|
||||
<br/>so they can communicate over `localhost`)
|
||||
|
||||
---
|
||||
## Ok! and then change prometheus conf ?
|
||||
|
||||
- Well, not really. It achievable this way, but...
|
||||
## Configuring the Prometheus server
|
||||
|
||||
- Prometheus has good service discovery paired with kubernetes.
|
||||
- We need to tell the Prometheus server to *scrape* our exporter
|
||||
|
||||
- Depending on how we installed prometheus, we just need:
|
||||
- Prometheus has a very flexible "service discovery" mechanism
|
||||
|
||||
- pods annotations:
|
||||
(to discover and enumerate the targets that it should scrape)
|
||||
|
||||
```
|
||||
annotations:
|
||||
prometheus.io/port: 9090
|
||||
prometheus.io/path: /metrics
|
||||
```
|
||||
- Depending on how we installed Prometheus, various methods might be available
|
||||
|
||||
- *service monitor* custom resource object
|
||||
.small[
|
||||
https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitor
|
||||
]
|
||||
---
|
||||
|
||||
*Note: More on prometheus next day*
|
||||
## Configuring Prometheus, option 1
|
||||
|
||||
- Edit `prometheus.conf`
|
||||
|
||||
- Always possible
|
||||
|
||||
(we should always have a Prometheus configuration file somewhere!)
|
||||
|
||||
- Dangerous and error-prone
|
||||
|
||||
(if we get it wrong, it is very easy to break Prometheus)
|
||||
|
||||
- Hard to maintain
|
||||
|
||||
(the file will grow over time, and might accumulate obsolete information)
|
||||
|
||||
---
|
||||
|
||||
## Configuring Prometheus, option 2
|
||||
|
||||
- Add *annotations* to the pods or services to monitor
|
||||
|
||||
- We can do that if Prometheus is installed with the official Helm chart
|
||||
|
||||
- Prometheus will detect these annotations and automatically start scraping
|
||||
|
||||
- Example:
|
||||
```yaml
|
||||
annotations:
|
||||
prometheus.io/port: 9090
|
||||
prometheus.io/path: /metrics
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuring Prometheus, option 3
|
||||
|
||||
- Create a ServiceMonitor custom resource
|
||||
|
||||
- We can do that if we are using the CoreOS Prometheus operator
|
||||
|
||||
- See the [Prometheus operator documentation](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) for more details
|
||||
|
||||
Reference in New Issue
Block a user