docker

Set up a registry mirror

Once the registry is running and either exposed on the local network with HTTP or via the Internet with HTTPS, you'll need to configure Docker and potentially buildx too.

You can see how we do this within a Firecracker VM, to access the registry over the local Ethernet bridge: https://github.com/self-actuated/hub-mirror/blob/master/action.yml

For the Docker daemon, edit /etc/docker/daemon.json.

{
  "insecure-registries" : ["192.168.128.1:5000" ],
  "registry-mirrors": ["http://192.168.128.1:5000"]
}

Give each mirror under registry-mirrors and include the URL scheme
If you're using HTTP, without TLS, you need to specify insecure-registries

Then make sure you reload Docker:

(
sudo systemctl daemon-reload && \
sudo systemctl restart docker
)

To try it out, run docker run -ti alpine:latest, you should see the images when you run sudo find /var/lib/registry/

Buildx is a little more complicated to configure.

Create a buildkit.toml

[registry."docker.io"]
  mirrors = ["192.168.128.1:5000"]
  http = true
  insecure = true

[registry."192.168.128.1:5000"]
  http = true
  insecure = true

You can omit http and insecure if you're using TLS and HTTPS.

Then, create a new buildx builder and tell Docker to use it:

docker buildx create --config ~/buildkitd.toml --name mirrored
docker buildx use mirrored

Finally, the buildx command will reference buildkit's configuration instead of Docker's and any base images will be pulled through the mirror.

docker buildx build -f Dockerfile .

We have a custom GitHub Action that makes all of the above just one line:

jobs:
    build:
        runs-on: actuated
        steps:

        - uses: self-actuated/hub-mirror@master

        - name: Pull image using cache
            run: |
            docker pull alpine:latest

TLS is better

We used HTTP for the registry as it's accessed over a kind of loopback device between the VM and the server, however I'd recommend always using TLS where you can.

Perhaps you could even setup your registry on the Internet and use free Let's Encrypt certificates. Caddy or Nginx are simple enough to configure for that.

Then, if you're worried about bandwidth charges - Linode, DigitalOcean and Hetzner all have generous amounts included with 5-10 USD / mo VMs.

And you could also set up an IP allow list, so only your servers or build machines can consume your bandwidth allowance.

Setting up multiple mirrors

ou may want multiple mirrors if you pull images from both docker.io and another registry like gcr.io, ecr.io, ghcr.io or quay.io.

The Docker documentation says that dockerd itself can only support a mirror of the Docker Hub itself. And any information that I found about multiple mirrors only applied to Kubernetes or to buildx.

Each registry mirror needs to run on its own HTTP port and if you're using TLS, will require its own distinct TLS certificate.

For instance, here are the things to change for a second registry mirroring ghcr.io:

storage:
  filesystem:
-    rootdirectory: /var/lib/registry
+    rootdirectory: /var/lib/registry-ghcr

proxy:
-  remoteurl: https://registry-1.docker.io
+  remoteurl: https://ghcr.io
-  username: $USERNAME

http:
-  addr: 192.168.128.1:5000
+  addr: 192.168.128.1:5001

So then, buildx or cri (when using Kubernetes) need to be configured to pull from either of these endpoints.

192.168.128.1:5000 mirrors docker.io
192.168.128.1:5001 mirrors ghcr.io

dockerd itself, can have two mirrors defined, but in my experience it was unable to pull from the mirror for ghcr.io.

So let's look at buildx:

[registry."docker.io"]
  mirrors = ["192.168.128.1:5000"]
  http = true
  insecure = true

[registry."192.168.128.1:5000"]
  http = true
  insecure = true

[registry."ghcr.io"]
  mirrors = ["192.168.128.1:5001"]
  http = true
  insecure = true

[registry."192.168.128.1:5001"]
  http = true
  insecure = true

There's two ways to know if the cache is being used:

Check the filesystem for the path set under rootdirectory
Enable the access logs for the registry itself

To enable access logs change

log:
  accesslog:
-    disabled: true
+    disabled: false   
-  level: warn
+  level: debug
  formatter: text

In my testing, after running buildx create and buildx use, I then needed a Dockerfile that used both the Docker Hub and GHCR:

FROM alpine:3.17 as alpine
FROM ghcr.io/openfaasltd/figlet as figlet

RUN echo -n "Mirror" | figlet

Running the build with docker buildx build -t mirror-test . gave me access logs on both registries and files under the respective /var/lib/ folders.

For Kubernetes configuration, you need to update the CRI plugin in containerd's toml file: Configure Image Registry.

Beware that CRI is an abstraction layer that sits between containerd and the kubelet, configuring this will not affect buildx, containerd or dockerd.

camunda

docker pull camunda/camunda-bpm-platform:latest
docker run -d --name camunda -p 8080:8080 camunda/camunda-bpm-platform:latest
# open browser with url: http://localhost:8080/camunda-welcome/index.html

如何在 Ubuntu 22.04 中删除并阻止 Snap 应用程序

一、snap 版本docker卸载与安装docker

snap 卸载docker

sudo snap remove --purge docker

snap 安装docker

snap install docker 二、apt-get 版本docker卸载与安装

卸载

通用卸载方法

sudo apt-get remove docker sudo apt-get remove --auto-remove docker

使用dpkg查询已安装包，针对性删除

查询相关软件包

dpkg -l | grep docker

删除这个包

sudo apt remove --purge docker.xxx

如果使用如上方法没法删除，试试如下命令

sudo apt-get remove --purge docker.xxx

注意：开始之前，请备份您的应用数据，例如 Firefox 书签。请注意，完成本教程后，Ubuntu 软件也将被删除。

步骤 1. 删除 Snap 应用程序和守护进程按键盘上的 Ctrl+Alt+T 打开终端窗口。打开后，一一运行以下命令。

1.) 列出所有已安装的 snap 应用程序：

snap list 默认情况下，它们是 Snap Store（Ubuntu 软件）、Firefox、默认主题和一些核心包。

2.) 逐个删除应用程序，首先删除 Firefox 和 Snap-store，然后是主题包、gnome 平台（在沙箱中），最后是基础包和 snapd 守护程序。注意：包名称可能会因“快照列表”输出而异。

sudo snap remove --purge firefox sudo snap remove --purge snap-store sudo snap remove --purge gnome-3-38-2004 同时运行 snap remove 命令来删除“gtk-common-themes”、“snapd-desktop-integration”、“bare”、“core20”，最后是“snapd”。

将运行中的Docker容器保存为镜像首先，我们需要找到正在运行的容器的ID或名称。可以通过运行docker ps命令来查看当前运行的容器列表。然后，使用以下命令将容器保存为镜像：

docker commit <容器ID或名称> <镜像名称>:<标签>

例如，如果容器的ID是abc123，我们想将其保存为名为my_image的镜像，并打上latest标签，则可以使用以下命令：

docker commit abc123 my_image:latest

将镜像保存为tar文件接下来，我们可以将刚刚创建的镜像保存为tar文件，以便于后续的传输和共享。使用以下命令可以将镜像保存为tar文件：

docker save -o <tar文件名>.tar <镜像名称>:<标签>

例如，如果要将my_image镜像保存为tar文件，可以使用以下命令：

docker save -o my_image.tar my_image:latest

完成后，会在当前目录下生成一个名为my_image.tar的tar文件。将镜像tar文件复制到本地最后，我们可以将生成的tar文件复制到本地，以便于后续的使用。可以使用以下命令将tar文件复制到本地：

docker load -i <tar文件名>.tar

例如，如果要将my_image.tar文件复制到本地，可以使用以下命令：

docker load -i my_image.tar

完成上述步骤后，我们就成功将Docker容器打包成镜像并保存到本地了。使用docker images命令可以查看本地所有的镜像列表，其中应该包含了刚刚创建的my_image镜像。需要注意的是，在将镜像保存为tar文件时，默认情况下会保存在当前目录下。如果需要指定保存路径，可以使用绝对路径或相对路径来指定tar文件的保存位置。例如，使用以下命令可以将镜像保存到指定目录：

docker save -o /path/to/directory/my_image.tar my_image:latest

注意事项和最佳实践

在运行Docker容器时，最好先将要使用的所有数据和配置都准备好，并保存在本地或云存储中。这样在将容器打包成镜像时，可以避免数据丢失或配置错误等问题。在将容器打包成镜像时，最好给镜像指定一个有意义的名称和标签。这样可以方便后续的识别和使用。例如，可以使用项目名称、环境、版本等信息来命名和标签镜像。在将镜像保存为tar文件时，建议定期备份。这样可以避免数据丢失或损坏等问题。同时，也可以在不同的机器或环境中进行测试和验证。

在将镜像复制到本地时，建议使用最新的Docker版本。这样可以确保兼容性和安全性等问题得到更好的保障。

制作空白的最小化镜像

下载文件系统

下载地址 https://alpinelinux.org/downloads/ * 编写dockerfile

文件内容 ```
FROM scratch

ADD alpine-minirootfs.tgz /

CMD ["/bin/sh"]

```