update docker

README.md

@@ -75,6 +75,24 @@ Gitee 镜像： <https://gitee.com/yunwei37/bpf-developer-tutorial>
 
 使用 Codespaces，您可以轻松地创建、管理和共享云端开发环境，从而将您的开发过程加速并使其更具可靠性。您可以在任何地方、任何设备上使用 Codespaces 进行开发，只需要一个具有 Web 浏览器的计算机即可。同时，GitHub Codespaces 还支持预先配置好的环境、自定义开发容器和可定制化的开发体验等功能，以满足您的开发需求。
 
+在 codespace 编写代码，提交后，Github Actions 会进行编译并自动发布容器镜像。接下来，你可以在任何地方使用 docker 一键运行这个 eBPF 程序，例如：
+
+```console
+$ sudo docker run --rm -it --privileged ghcr.io/eunomia-bpf/libbpf-rs-template:latest
+[sudo] password for xxx: 
+Tracing run queue latency higher than 10000 us
+TIME     COMM             TID     LAT(us)       
+12:09:19 systemd-udevd    30786   18300         
+12:09:19 systemd-udevd    30796   21941         
+12:09:19 systemd-udevd    30793   10323         
+12:09:19 systemd-udevd    30795   14827         
+12:09:19 systemd-udevd    30790   17973         
+12:09:19 systemd-udevd    30793   12328         
+12:09:19 systemd-udevd    30796   28721
+```
+
+![docker](imgs/docker.png)
+
 ## 为什么需要基于 libbpf 和 BPF CO-RE 的教程？
 
 > 历史上，当需要开发一个BPF应用时可以选择BCC 框架，在实现各种用于Tracepoints的BPF程序时需要将BPF程序加载到内核中。BCC提供了内置的Clang编译器，可以在运行时编译BPF代码，并将其定制为符合特定主机内核的程序。这是在不断变化的内核内部下开发可维护的BPF应用程序的唯一方法。在BPF的可移植性和CO-RE一文中详细介绍了为什么会这样，以及为什么BCC是之前唯一的可行方式，此外还解释了为什么 libbpf 是目前比较好的选择。去年，Libbpf的功能和复杂性得到了重大提升，消除了与BCC之间的很多差异(特别是对Tracepoints应用来说)，并增加了很多BCC不支持的新的且强大的特性(如全局变量和BPF skeletons)。