Skip to content

Instantly share code, notes, and snippets.

@dejanu

dejanu/ops_jargon.md

Last active June 11, 2026 13:44
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save dejanu/a761175e9972d689421cbf435bf98223 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save dejanu/a761175e9972d689421cbf435bf98223 to your computer and use it in GitHub Desktop.
Download ZIP
Ops Jargon
Raw
ops_jargon.md

⚠️ Avoid being stuck in tutorial hell and always use the official documentation.

🚀 DevOps

  • Pipeline

An automated process that defines a series of stages or steps to build, test and deploy SW solutions.

  • Continuous Integration (CI)

The the process of merging code changes, testing them, and building resulting artifacts, as early in the application lifecycle as possible. The intention is to detect any potential issues in the development phase, since this minimizes the effort and cost involved in fixing them. Automated tests validate that code changes haven't introduced errors or regression issues.

  • Continuous Delivery/Deployment (CD)

The process of automated deployment of artifacts built as part of CI, making them available to their consumers. CD automates progression of these artifacts through different environments, such as testing, staging, and production.

For Continuous Delivery the final step (deployment to production) typically needs manual approval as a safeguard even though the deployment itself is automated, on the other hand Continuous Deployment removes the manual approval safeguard so successful changes automatically deploy to production.

  • Infrastructure as Code (IaC)

IaC defines infrastructure components such as servers, network devices, and databases by using code. Such code typically resides in a VCS (Version control system), and the use of declarative code to represent infra facilitates automated provisioning and configuration, enhancing efficiency, consistency, and scalability.

  • Idempotence

The characteristic of an action where the outcome is always the same, regardless of the number of times the action is performed.

  • Immutable

Data or objects whose state cannot be altered after they are created.

  • GitOps

Set of practices that require the desired state of the system (environment or cluster) to be stored in Git, using a declarative specification and it mainly focuses on managing Kubernetes.

🔭 Monitoring and Observability

  • Trace

A sequence of operations that together form a unique transaction handled by an application. Traces help understand the flow of requests through the system.

  • Span

Represents a single operation within a trace (in the context of tracing).

  • USE (Utilisation Saturation and Error)

Monitoring methodology centered on infrastructure (introduced by Brendan Gregg).

  • RED (Rate Errors Duration)

Monitoring methodology centered on applications, specifically on request tracking (introduced by Tom Wilkie)

  • SLA

Agreement, contractual obligation between stakeholders and clients which involves penalties

  • SLO

Oobjective, a target (measured over a period of time) for a desired goal e.g. availability, 95% of requests should be under 200ms

  • SLI

Measurement, indicator calculated as the number_of_good_events/total_no_of_events.

  • Technical debt

SW concept where prioritizing short-term/quick-and-dirty fixes, provides immediate speed, but creates "interest" in the future in the form of increased maintenance, bugs, and slower development speed.

👾 Kubernetes

  • Containers

Are unix processes not "lightweight VMs". Remember to use containers to Ship artifacts, not build environments. A container typically runs as a single Unix process, it is just a fancy way to run a process personal rant post

  • Microservices

Self-contained and “independent” services decoupled from each other that can communicate between them via Brokers (eg. RabbitMQ), Remote Procedure Calls (RPC), or REST APIs.

  • Workloads

Objects you use to manage and run your containers on the Kubernetes cluster.

  • Pod

Textbook definition is that the pod represents the smallest deployable units of computing that you can create and manage in Kubernetes, and in layman's terms a pod is a collection of one or more containers that we can treat as a single logical unit for our service.

  • Container runtime

Kubernetes doesn’t know how to run containers it relies on the container runtime for running and managing containers on a host system i.e. setting up namespaces and cgroups for containers.

  • Control Plane

Kubernetes orchestration layer, comprised of multiple components: kube-apiserver, etcd, kube-scheduler, kube-controller-manager.

  • Reconciliation loop

The core component that maintains the desired state for watched resources, by enabling the adjusting of the current state in order to match the desired state.

  • Service mesh

Dedicated infrastructure layer built right into an app, which enables service-to-service communication, e.g. Istio, Linkerd. Service meshes address this new set of challenges by managing traffic (communication) between services and adding reliability, observability, and security features uniformly across all services.

  • Service Discovery

Service discovery process keeps track of apps (instances) within the network so they can find one another when needed. A service discovery tool keeps track of the various nodes or endpoints that make up a service.

  • Sidecar

Design pattern in which two coupled containers share the same pod, more exactly they share the pod’s filesystem, and network namespaces, e.g. Envoy proxies.

  • Naked pod

A pod not bound to a replication controller. Naked pods will not be rescheduled in the event of node failure.

  • Static pod

A pod managed directly by the kubelet daemon on a specific node. Static pods allow a pod to run as soon as the kubelet is brought up bypassing the kube-scheduler.

  • Headless service

A service that doesn’t have the clusterIP address allocated, kube-proxy does not handle these Services.

  • CNI (Container Network Interface)

Specification that defines how network plugins should interact with container runtimes, basically it connects pods across nodes.

  • CSI (Container Storage Interface)

Standard for exposing arbitrary block and file storage systems to containerized workloads in Kubernetes, thus allowing third-party storage systems/vendors to integrate with Kubernetes by enabling dynamic storage provisioning.

  • CRI (Container Runtime Interface)

Kubernetes contacts kubelet to launch a pod, subsequently the kubelet communicates with different container runtime via CRI (using gRPC API calls)

  • Pod Disruption

The process of terminating Pods either voluntary or involuntarily.

  • Preemption

The process of terminating Pods with LOWER Priority so that Pods with HIGHER Priority can schedule on Nodes.

  • Eviction

The process of terminating one or more Pods on Nodes.

Docker

Docker

  • What is a container here, just a fancy way to run a process

  • After Docker installation, we have the hello world for containers. Using docker CLI we can do:

# list all containers from your machine (by all we mean running and also stopped). 
# The output should be empty (since there are no containers which have been ran)
docker ps -a

# list all images from your machine. 
# The output should be empty (since there are no images pulled on your machine)
docker images

# run your first container. 
# The container engine tried to find an image named hello-world, and it did not find it, 
# therefore it goes to its default Docker registry, which is Docker Hub, to look for an image named “hello-world
# It finds the image there, pulls it down, and then runs it in a container
docker run hello-world

# rerun commands. What are the changes?
docker ps -a
docker images

  • Docker flags (Display system-wide information and Go templates to manipulate the output format)

    • Search official images for desired : docker search --format "table {{.Name}}\t{{.StarCount}}\t{{.IsOfficial}}" <IMAGE>
    • Output image name and tag: docker images --format '{{.Repository}} and {{.Tag}}'
    • Output image name, tag and elapsed time + timestamp since the image has been created: docker images --format "{{.Repository}}:{{.Tag}} {{.CreatedSince}} --> {{.CreatedAt}}"
    • Inspect Cmd for desired : docker inspect -f '{{.Config.Cmd}}' <IMAGE>
    • Inspect Entrypoint for desired : docker inspect -f '{{.Config.Entrypoint}} <IMAGE>'
    • Inspect attached containers to bridge network: docker inspect network bridge --format "{{json .Containers }}"
    • Check root directory for Docker storage, defaults to /var/lib/docker: docker info -f 'Storage drive: {{.Driver}} and storage path {{.DockerRootDir}}'
    • Show docker disk usage docker system df
    • Inspect container runtimes: docker system info --format "{{.Runtimes}} {{.DefaultRuntime}}" or docker system info --format "Runtimes: {{.Runtimes}} with default {{ .DefaultRuntime }}"
    • Check container resource usage docker stats [OPTIONS] [CONTAINER], or docker stats --no-stream
    • Check events docker events --filter event=restart --since=60m or docker events --filter event=restart --since=60m > events.log 2>&1

  • Flow: Using a Dockerfile we build a Docker image, and using a Docker image we start/run a container.

flowchart LR;
		Dockerfile-->Image;
		Image-->Container;
Loading
  • Debug Docker with systemctl/service and journalctl
systemctl status docker
systemctl daemon-reload
systemctl start docker
service docker restart
journalctl -xeu docker.service
journalctl -u docker

Resources

Articles

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment