Shulou(Shulou.com)06/01 Report--

How to use Podman, many beginners are not very clear about it. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Podman was originally part of the CRI-O project, but was later split into a separate project called libpod. The experience of using Podman is similar to that of Docker, except that Podman does not have daemon. In the past, when using Docker CLI, Docker CLI would say "I want to start a container" to Docker Engine through gRPC API, and then Docker Engine would start a container through OCI Container runtime (the default is runc). This means that the process of the container cannot be a child of Docker CLI, but a child of Docker Engine.

Podman is simple and rough. Instead of using Daemon, it starts the container directly through OCI runtime (which is also runc by default), so the process of the container is a child of podman. This is more like Linux's fork/exec model, while Docker uses the C / S (client / server) model. The fork/exec model has many advantages compared with the Candace S model, such as:

The system administrator can know who started a container process.

If you use cgroup to impose some restrictions on podman, then all containers created will be restricted.

SD_NOTIFY: if the podman command is put into the systemd unit file, the container process can return a notification via podman indicating that the service is ready to receive the task.

Socket activation: you can pass the connected socket from systemd to podman and to the container process for use.

Needless to say, let's go straight to the actual combat session. This article will teach you how to deploy a static blog with podman, and add the container where the blog is located to the Envoy mesh through Sidecar mode.

1. Scheme architecture

My deployment scenario involves two layers of Envoy:

First, there will be a front-end agent running a separate container. The job of the front-end agent is to provide visitors with an entry to forward access requests from outside to specific back-end services.

Second, the blog static page is provided by nginx and runs an Envoy container in Sidecar mode, which shares network nemspace with nginx.

All Envoy form a mesh and then share routing information between them.

I have previously written an article about deploying hugo static blogs with Docker and configuring HTTPS certificates. This article uses the same scheme, except that docker is replaced with podman. For more information, please refer to enabling TLS verification for Envoy.

two。 Deploy hugo and sidecar proxy

My blog is a static page generated through hugo, which can be put into nginx, as can other static website tools (such as hexo, etc.). What I need to do now is to let the nginx container and the envoy container share the same network namespace, while also allowing the front-end agent to make service discovery through the domain name. In the past, it was very simple to use docker, just use docker-compose, podman is more troublesome, it can not use docker-compose, service discovery seems to be out of order.

Finally found a project called podman-compose on Github, thought it was saved, tried it and found that it still didn't work. When podman-compose created a container, it would convert the field network_mode: "service:hugo" into the parameter network service:hugo of podman CLI, resulting in container creation failure, and the error message was CNI network "service:hugo" not found. Change the field value to network_mode: "container:hugo_hugo_1" starts successfully, but raises another problem: podman-compose creates a pod for each service (the name of the pod is the directory name of the docker-compose.yml), and then adds a container to the pod. I can't put front-end agents and back-end services into the same pod, can I? You can only create two directories for the front-end agent and hugo, and then create a docker-compose.yml. This problem is solved, and here comes the next problem. Podman-compose does not support service discovery through service name. After scraping around, we find that it supports links (that is, adding a parameter-- add-host). However, links only takes effect under the same pod. I have split it into two pod. Links is out of reach, and it is still useless. What can I do? the only way now is to hand off the command line.

I mentioned a new term called pod above. I will take 30 seconds to give you a brief introduction. If you are a heavy user of Kubernetes, you should be familiar with this word, but it does mean podman pod, which means the same thing. First, create a pause container, and then create a business container. The business container shares various linux namespace of the pause container. So containers in the same pod can easily communicate with each other through localhost. Not only that, podman can also export pod to Kubernetes's declarative resource definition, for example:

First create a pod:

$podman pod create-name hugo

View pod:

$podman pod lsPOD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID88226423c4d2 hugo Running 2 minutes ago 2 7e030ef2e7ca

Start a hugo container in this pod:

$podman run-d-pod hugo nginx:alpine

View the container:

$podman psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES3c91cab1e99d docker.io/library/nginx:alpine nginx-g daemon o. 3 minutes ago Up 3 minutes ago reverent_kirch

View all containers, including pause containers:

$podman ps-aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES3c91cab1e99d docker.io/library/nginx:alpine nginx-g daemon o. 4 minutes ago Up 4 minutes ago reverent_kirch7e030ef2e7ca k8s.gcr.io/pause:3.1 6 minutes ago Up 6 minutes ago 88226423c4d2-infra

View all containers, including the pause container, and display the pod id to which the container belongs:

$podman ps-apCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD3c91cab1e99d docker.io/library/nginx:alpine nginx-g daemon o. 4 minutes ago Up 4 minutes ago reverent_kirch 88226423c4d27e030ef2e7ca k8s.gcr.io/pause:3.1 6 minutes ago Up 6 minutes ago 88226423c4d2-infra 88226423c4d2

View the resource usage of processes in pod:

$podman pod top hugoUSER PID PPID% CPU ELAPSED TTY TIME COMMANDroot 1 0 0.000 8m5.045493912s? 0s nginx: master process nginx-g daemon off Nginx 6 1 0.000 8m5.045600833s? 0s nginx: worker processnginx 7 1 0.000 8m5.045638877s? 0s nginx: worker process0 10 0.000 9m41.051039367s? 0s / pause

Export pod as a declarative deployment manifest:

$podman generate kube hugo > hugo.yaml

View the contents of the deployment list:

$cat hugo.yaml# Generation of Kubernetes YAML is still under developmentalism # Save the output of this file and use kubectl create-f to import# it into Kubernetes.## Created with podman-1.0.2-devapiVersion: v1kind: Podmetadata: creationTimestamp: 2019-10-17T04:17:40Z labels: app: hugo name: hugospec: containers:-command:-nginx-- g-daemon off Env:-name: PATH value: / usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin-name: TERM value: xterm-name: HOSTNAME-name: container value: podman-name: NGINX_VERSION value: 1.17.4-name: NJS_VERSION value: 0.3.5-name: PKG_RELEASE value: " 1 "image: docker.io/library/nginx:alpine name: reverentkirch resources: {} securityContext: allowPrivilegeEscalation: true capabilities: {} privileged: false readOnlyRootFilesystem: false workingDir: / status: {}

How is it? does it have a familiar smell? This is a kubernetes-compatible pod definition. You can deploy it directly in the Kubernetes cluster via kubectl apply-f hugo.yaml or directly through podman. The steps are as follows:

Delete the previously created pod first:

$podman pod rm-f hugo

Then create the pod from the deployment manifest:

$podman play kube hugo.yaml

Going back to the previous question, if you create a pod through a declarative definition, you still can't solve the problem of service discovery unless you change to a CNI plug-in that supports static IP, and these CNI plug-ins that support static IP need etcd as a database. That's all I have, but I don't want to add another etcd.

First I want to create a hugo container and specify the IP of the container:

$podman run-d-name hugo\-ip=10.88.0.10\-v / opt/hugo/public:/usr/share/nginx/html\-v / etc/localtime:/etc/localtime\ nginx:alpine

Create another envoy container to share the network namespace with the hugo container:

$podman run-d-name hugo-envoy\-v / opt/hugo/service-envoy.yaml:/etc/envoy/envoy.yaml\-v / etc/localtime:/etc/localtime\-- net=container:hugo envoyproxy/envoy-alpine:latest

The service-envoy.yaml is as follows:

Static_resources: listeners:-address: socket_address: address: 0.0.0.0 port_value: 8080 filter_chains:-filters:-name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http access_log:-name: envoy.file_access_log config: Path: "/ dev/stdout" route_config: name: local_route virtual_hosts:-name: service domains:-"*" routes:-match: prefix: "/" route: Cluster: local_service http_filters:-name: envoy.router config: {} clusters:-name: local_service connect_timeout: 0.25s type: strict_dns lb_policy: round_robin hosts:-socket_address: address: 127.0.0.1 port_value: 80admin: access_log_path: "/ dev/null" address : socket_address: address: 0.0.0.0 port_value: 8081

For more information, please see enabling TLS verification for Envoy.

At the beginning of this article, it is mentioned that the container created by podman is a child process of podman. In fact, podman consists of two parts, one is podman CLI, and the other is container runtime,container runtime, which is responsible for conmon. It mainly includes monitoring, logging, TTY allocation and chores similar to out-of-memory situations. That is, conmon is the parent process of all containers.

Conmon needs to do all the things that systemd doesn't or doesn't want to do. Even if CRI-O does not directly use systemd to manage containers, it allocates containers to sytemd-compliant cgroup so that regular systemd tools such as systemctl can see container resource usage.

$podman psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES42762bf7d37a docker.io/envoyproxy/envoy-alpine:latest / docker-entrypoin... About a minute ago Up About a minute ago hugo-envoyf0204fdc9524 docker.io/library/nginx:alpine nginx-g daemon o. 2 minutes ago Up 2 minutes ago hugo

Students who are not familiar with cgroup can refer to the following series:

In-depth understanding of the Linux Cgroup series (1): basic concepts

In-depth understanding of Linux Cgroup series (2): playing with CPU

In-depth understanding of Linux Cgroup series (3): memory

In-depth understanding of Kubernetes resource limitations: CPU

Practice of Kubernetes memory resource limitation

Detailed explanation of Kubernetes Pod expulsion

Students with zero foundation suggest upgrading from top to bottom according to the above catalogue. good luck!

3. Deploy the front-end agent

This is very simple, just create the container directly:

$podman run-d-name front-envoy\-add-host=hugo:10.88.0.10\-v / opt/hugo/front-envoy.yaml:/etc/envoy/envoy.yaml\-v / etc/localtime:/etc/localtime\-v / root/.acme.sh/yangcs.net:/root/.acme.sh/yangcs.net\-- net host envoyproxy/envoy

Since there is no way to automatically discover services, you need to manually add hosts to the container through the parameter-- add-host. Cluster is added by domain name in the configuration file of envoy. The content of front-envoy.yaml is as follows:

Static_resources: listeners:-address: socket_address: address: 0.0.0.0 port_value: 80 filter_chains:-filters:-name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http access_log:-name: envoy.file_access_log config: Path: "/ dev/stdout" route_config: virtual_hosts:-name: backend domains:-"*" routes:-match: prefix: "/" redirect: https_redirect: True response_code: "FOUND" http_filters:-name: envoy.router config: {}-address: socket_address: address: 0.0.0.0 port_value: 443 filter_chains:-filter_chain_match: server_names: ["yangcs.net" "www.yangcs.net"] tls_context: common_tls_context: alpn_protocols: H3 tls_params: tls_maximum_protocol_version: TLSv1_3 tls_certificates:-certificate_chain: filename: "/ root/.acme.sh/yangcs.net/fullchain.cer" private_key: Filename: "/ root/.acme.sh/yangcs.net/yangcs.net.key" filters:-name: envoy.http_connection_manager config: codec_type: auto stat_prefix: ingress_http route_config: name: local_route virtual_hosts:-name: backend domains: "yangcs.net"-"www.yangcs.net" routes:-match: prefix: "/ admin" route: prefix_rewrite: "/" cluster: envoy-ui-match: Prefix: "/" route: cluster: hugo response_headers_to_add:-header: key: "Strict-Transport-Security" value: "max-age=63072000 IncludeSubDomains Preload "http_filters:-name: envoy.router config: {} clusters:-name: hugo connect_timeout: 0.25s type: strict_dns lb_policy: round_robin http2_protocol_options: {} hosts:-socket_address: address: hugo port_value: 8080admin: access_log_path:" / dev/null "address: socket_ Address: address: 0.0.0.0 port_value: 8001

For more information, please see enabling TLS verification for Envoy.

You can now access the blog website through the public network domain name. If you have any other applications, you can refer to the steps in section 2, and then recreate the front-end agent and add the-- add-host parameter. Take my website https://www.yangcs.net as an example:

I seem to have revealed something terrible. Stop here, don't say it, and don't ask.

4. Self-booting

Because podman no longer uses the daemon management service, the-- restart parameter is deprecated, so if you want to boot the container automatically, you can only manage it through systemd. First create a systemd service profile:

$vim / etc/systemd/system/hugo_ container.service[ Description=Podman Hugo ServiceAfter=network.targetAfter=network- online.target] Type=simpleExecStart=/usr/bin/podman start-a hugoExecStop=/usr/bin/podman stop-t 10 hugoRestart= always [install] WantedBy=multi-user.target$ vim / etc/systemd/system/hugo-envoy_ container.service [Unit] Description=Podman Hugo Sidecar ServiceAfter=network.targetAfter=network-online.targetAfter=hugo_ container.service [Service] Type=simpleExecStart=/usr/bin/podman start-a hugo-envoyExecStop=/usr/bin/podman stop-t 10 hugo-envoyRestart=always [Install] WantedBy=multi-user.target$ vim / etc/systemd/system/front-envoy_ container.service[ Unit] Description=Podman Front Envoy ServiceAfter=network.targetAfter=network-online.targetAfter=hugo_container.service hugo-envoy_ container.service[ service] Type=simpleExecStart=/usr/bin/podman start-a front-envoyExecStop=/usr/bin/podman stop-t 10 front-envoyRestart=always [Install] WantedBy=multi-user.target

Then stop the previously created container, note: stop, not delete!

$podman stop $(podman ps-aq)

Finally, these containers are started through the systemd service.

$systemctl start hugo_container$ systemctl start hugo-envoy_container$ systemctl start front-envoy_container

Set self-boot.

$systemctl enable hugo_container$ systemctl enable hugo-envoy_container$ systemctl enable front-envoy_container

After that, systemd automatically starts the corresponding container for this service after each system restart.

4. Summary

The above are all the changes to migrate the blog from Docker to Podman, but on the whole, it is rather tortuous, because Podman is designed for Kubernetes, and I ask too much, just a resource-strapped vps, that is, I don't want to go to Kubernetes or etcd. I want to do both sidecar and automatic service discovery. What can I do? I'm also desperate. I can't complain about podman. In order to avoid leaving the impression that "podman is not easy to use", I would like to make a statement.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.