Alpine 容器内安装命令时遇到坑-低调大师

Alpine 容器内安装命令时遇到坑

2021-02-20 761

导读

记录在 Alpine 容器内安装命令时遇到的一些问题，本篇文章会持续更新。

问题背景是在docker 容器内执行 docker 命令，执行时发现缺少某些依赖包，在安装依赖包时遇到一些难以解决的问题。

本文首发于 https://russellgao.cn/linux-alpine-apk/

如需转载，请加注原文出处。

在容器内执行 docker 命令

在 docker 容器执行 docker 命令，如启动新的容器，需要把主机的 docker sock 套接字映射到容器内。具体方法为:

# 宿主机上执行
docker run -v /usr/bin/docker:/bin/docker \
  -v /var/run/docker.sock:/var/run/docker.sock \
   xxx

error while loading shared libraries: libltdl.so.7

如果执行 docker 命令报错如下:

# 容器内执行 docker 命令， 如 docker --help
error while loading shared libraries: libltdl.so.7: cannot open shared object file: No such file or directory

说明缺少对应的依赖库，安装方法为 :

# 容器内执行
apk add --no-cache libltdl

如果是 Centos 容器:

# 容器内执行
yum install libtool-ltdl -y

如果是 Ubantu 容器:

# 容器内执行
sudo apt-get update
sudo apt-get install libltdl-dev

2 errors; 50 MiB in 38 packages

如果安装 libltdl 时报错如下：

# 容器内执行
apk add --no-cache libltdl 
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
2 errors; 50 MiB in 38 packages

说明没有安装成功，需要继续定位错误。这时候可以执行 apk update 更新一下本地索引 :

# 容器内执行
apk update
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
ERROR: http://mirrors.ustc.edu.cn/alpine/v3.4/main: Bad file descriptor
WARNING: Ignoring APKINDEX.0d9a6724.tar.gz: Bad file descriptor
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
ERROR: http://mirrors.ustc.edu.cn/alpine/v3.4/community: Bad file descriptor
WARNING: Ignoring APKINDEX.6a82a2a6.tar.gz: Bad file descriptor
2 errors; 38 distinct packages available

可以看到又报错了，这个错误说明文件描述符有问题，解决方法删除本地缓存目录并重新创建即可 :

# 容器内执行
rm -fr /var/cache/apk
mkdir -p mkdir /var/cache/apk

这时候再执行 apk update 就可以了

# 容器内执行
apk update -v 
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.6-316-g63ea6d0 [http://mirrors.ustc.edu.cn/alpine/v3.4/main]
v3.4.6-160-g14ad2a3 [http://mirrors.ustc.edu.cn/alpine/v3.4/community]
OK: 5984 distinct packages available

再次执行 apk add --no-cache libltdl 如果还是报错则可以执行 apk fix 进行修复 :

# 容器内执行
apk fix  
(1/2) Reinstalling busybox (1.24.2-r14)
Executing busybox-1.24.2-r14.post-upgrade
(2/2) [APK unavailable, skipped] Reinstalling glibc-bin (2.25-r0)
Executing busybox-1.24.2-r14.trigger
1 errors; 164 MiB in 56 packages
bash-4.3# 
bash-4.3# apk fix  -v
(1/1) [APK unavailable, skipped] Reinstalling glibc-bin (2.25-r0)
1 errors; 56 packages, 333 dirs, 7131 files, 164 MiB

从上面的信息可以看出，在 fix 阶段 fix glibc-bin 失败了，那就需要手动删除再重新安装了。

# 容器内执行
apk del  glibc-bin 
World updated, but the following packages are not removed due to:
  glibc-bin: glibc-i18n

1 errors; 164 MiB in 56 packages

可以如果要删除 glibc-bin 需要先删除 glibc-i18n

# 容器内执行
apk del  glibc-i18n 
(1/2) Purging glibc-i18n (2.25-r0)
(2/2) Purging glibc-bin (2.25-r0)
OK: 151 MiB in 54 packages

apk del  glibc-bin

这时候重新 fix :

# 容器内执行
apk fix  -v
OK: 54 packages, 256 dirs, 6543 files, 151 MiB

再次安装 libltdl

# 容器内执行
apk add -v --no-cache libltdl 
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.ustc.edu.cn/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
OK: 54 packages, 256 dirs, 6543 files, 151 MiB

可以看到问题完美解决。

总结

记录在 alpine 容器内安装库时遇到的坑，此篇文章持续更新。

微信关注我们

原文链接：https://my.oschina.net/russellgao/blog/4958097

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Wireshark数据抓包分析之传输层协议（TCP协议）

使用TCP协议传输数据相对来说更安全，因为通信双方拥有一个专属的通信通道，每发送一个数据包都有确认回复，若数据包丢失。如果发送放没收到确认包，就可以重发这个数据包。最经典的例子就是三次握手。三次握手是通信双方建立TCP连接前的必须步骤。第一次握手时请求方向接收方发送友好问候，请求建立连接。第二次握手接收方礼貌回复，表示收到请求。第三次握手请求方坚定交往信息，向接收方表示已做好了连接准备。于是双方的TCP连接就建好啦～完成三次握手后，双方就可以开始传输数据了。当然，握手很严谨，说再见也是一丝不苟的。详细内容可以在合天网安实验室里进行实验操作《Wireshark数据抓包分析之传输层协议（TCP协议）》了解。下面开始实战。根据已经搭建好的实验环境，本次实战步骤如下： 1．在测试环境使用发包工具和Wireshark抓取TCP三次握手和四次断开的数据包 2．详细分析TCP协议的三次握手以及四次断开。本次的任务可以拆分成：安装发包工具，配置TCP客户端（请求方），服务端（接收方），与学习Wireshark软件懂使用。咱开始吧～我们使用" TCP&UDP测试工具"来制作和发送T...

2021-02-20

612

目前，CNCF社区正持续发展，用户对开源技术的应用也越来越突出。这是CNCF第八次对云原生应用的采用情况进行调研。此次调研，CNCF收到了来自社区共计1324份有效样本，来自欧洲、北美、亚洲等主要地区，其中有30%以上是5000人规模以上企业，60%以上为100人规模企业和组织。从被调研对象来看，其中绝大多数为企业IT部门/组织，主要岗位包括SRE/DevOps工程师(43%)、软件架构师(35%)和后端开发人员(23%)。调研核心要点：在生产中应用容器的比例从去年的84%增长到今年的92%，相比2016年增长了300%。生产中应用Kubernetes的比例从去年的78%增长到今年的83%。 CNCF托管的所有项目中，相比上一年投入应用的项目至少有50%的增长。 82%的受访者在生产中应用CI/CD(持续集成和持续交付)。 30%的受访者在生产中应用无服务架构(serverless)。 27%的受访者在生产中应用服务网格(service mesh)，相比去年增长了50%。 55%的受访者在生产中的容器中运行有状态应用程序(stateful application)。以下为雷锋网...

2021-02-20

564

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。