Skip to main content

Comparing common docker and cri commands

 

Comparing docker and crictl command line options

Docker and CRI (Container Runtime Interface) are two popular ways to manage and run containers on a Linux system. Both technologies offer a set of commands and tools for working with containers, but there are some key differences between the two. In this blog post, we will compare some common Docker and CRI commands to help you understand the similarities and differences between the two technologies.

First, let's take a look at the docker run command. The docker run command is used to start a new container from an image. The command takes a number of options, such as the image name, ports to expose, and environment variables to set. The docker run command also allows you to specify a command to run inside the container, which is useful for running a specific application or service.

In contrast, the equivalent command in CRI is the crictl run command. The crictl run command also starts a new container from an image, but it takes a different set of options and arguments. For example, instead of specifying ports to expose, you would specify the container's network namespace. Additionally, crictl run command also takes an additional option --runtime which allows you to specify the runtime to use (e.g. containerd).

Another common command is the docker ps command, which is used to list all running containers. The docker ps command lists information about each container, including the container ID, image name, status, and ports that are exposed.

The equivalent command in CRI is the crictl ps command. Like the docker ps command, crictl ps also lists all running containers and displays information about each container. However, the crictl ps command takes a different set of options and arguments, and the output format may also be different.

Both docker stop and crictl stop commands are used to stop a running container. Similarly, both docker rm and crictl rm commands are used to remove a container.

Another common command is the docker logs command, which is used to view the logs of a running container. The equivalent command in CRI is crictl logs command. Both commands take the same options, such as the container ID or name, and display the logs in the same format.

In addition to these commands, both Docker and CRI also provide other tools and features for managing and working with containers. For example, Docker provides the Docker Engine, which is the underlying technology that runs containers on a host. CRI, on the other hand, provides a set of APIs and libraries that allow different container runtimes (e.g. containerd, cri-o) to integrate with Kubernetes, which is a popular container orchestration system.

One of the main differences between Docker and CRI is that Docker is a complete container platform that includes both the runtime and the management tools, while CRI is focused on providing a consistent interface for different container runtimes to integrate with Kubernetes. This means that if you're using Kubernetes, you'll likely be using CRI and a container runtime like containerd, rather than Docker directly.

In conclusion, both Docker and CRI are powerful tools for managing and running containers on a Linux system. While there are some similarities between the two technologies, there are also some key differences, particularly in terms of the commands and tools that are available. Understanding these differences can help you make the best choice for your specific use case and environment.





















Comments

Popular posts from this blog

Manual Kubernetes TLS certificate renewal procedure

Intro Kubernetes utilizes TLS certificates to secure different levels of internal and external cluster communication.  This includes internal services like the apiserver, kubelet, scheduler and controller-manager etc. These TLS certificates are created during the initial cluster installation and are usually valid for 12 months. The cluster internal certificate authority (CA) certificate is valid for ten years. There are options available to automate certificate renewals, but they are not always utilised and these certs can become out of date. Updating certain certificates may require restarts of K8s components, which may not be fully automated either. If any of these certificates is outdated or expired, it will stop parts or all of your cluster from functioning correctly. Obviously this scenario should be avoided - especially in production environments. This blog entry focuses on manual renewals / re-creation of Kubernetes certificates. For example, the api-server certificate below...

Analysing and replaying MySQL database queries using tcpdump

Why There are situations where you want to quickly enable query logging on a MySQL Database or trouble shoot queries hitting the Database server in real-time. Yes, you can enable the DB query log and there are other options available, however the script below has helped me in many cases as it is non intrusive and does not require changing the DB server, state or configuration in any way. Limitations The following only works if the DB traffic is not encrypted (no SSL/TLS transport enabled). Also this needs to be run directly on the DB server host (as root / admin). Please also be aware that this should be done on servers and data you own only. Script This script has been amended to suit my individual requirements. #!/bin/sh tcpdump -i any -s 0 -l -w - dst port 3306 | strings | perl -e ' while(<>) { chomp; next if /^[^ ]+[ ]*$/;   if(/^(ALTER|COMMIT|CREATE|DELETE|DROP|INSERT|SELECT|SET|UPDATE|ROLLBACK)/i) {     if (defined $q) { print "$q\n"; }     $q=$_; ...

Deprecating Networking Ingress API version in Kubernetes 1.22

  Intro Kubernetes deprecates API versions over time. Usually this affects alpha and beta versions and only requires changing the apiVersion: line in your resource file to make it work. However with this Ingress object version change, additional changes are necessary. Basics For this post I am quickly creating a new cluster via Kind (Kubernetes in Docker) . Once done, we can see which API versions are supported by this cluster (version v1.21.1). $ kubectl api-versions | grep networking networking.k8s.io/v1 networking.k8s.io/v1beta1 Kubernetes automatically converts existing resources internally into different supported API versions. So if we create a new Ingress object with version v1beta1 on a recent cluster version, you will receive a deprecation warning - and the same Ingress object will exist both in version v1beta1 and v1. Create $ cat ingress_beta.yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata:   name: clusterpirate-ingress spec:   rules:  ...