标签: alpine-linux

如何在基于 alpine 的映像上安装 python3 和 python3-pip（不使用 python 映像）？

 $ apk add --update python3.8 python3-pip
 ERROR: unsatisfiable constraints:
   python3-pip (missing):
     required by: world[python3-pip]
   python3.8 (missing):
     required by: world[python3.8]

我有一个Go二进制文件我试图在Alpine Docker图像上运行.

这适用于Docker Go二进制文件.

docker run -it alpine:3.3 sh
apk add --no-cache curl

DOCKER_BUCKET=get.docker.com
DOCKER_VERSION=1.9.1
curl -fSL "https://${DOCKER_BUCKET}/builds/Linux/x86_64/docker-$DOCKER_VERSION" -o /usr/local/bin/docker
chmod +x /usr/local/bin/docker
docker help
Usage: docker [OPTIONS] COMMAND [arg...]
...

但是,对于我要安装的Go二进制文件.

RACK_BUCKET=ec4a542dbf90c03b9f75-b342aba65414ad802720b41e8159cf45.ssl.cf5.rackcdn.com
RACK_VERSION=1.1.0-beta1
curl -fSL "https://${RACK_BUCKET}/${RACK_VERSION}/Linux/amd64/rack" -o /usr/local/bin/rack
chmod +x /usr/local/bin/rack

rack help
sh: rack: not found

/usr/local/bin/rack help
sh: /usr/local/bin/rack: not found

ls -al /usr/local/bin/
total 43375
drwxr-xr-x    2 root     root          1024 Jan 11 18:10 .
drwxr-xr-x    8 root     root          1024 Jan 11 18:09 ..
-rwxr-xr-x    1 root …

灵感来自问题为什么Java 11基础Docker镜像如此之大？(openjdk:11-jre-slim)我发现Java世界中的这个话题还没有解决.

至于07 Dec 2018存在共同的问题/陷阱(在上面的票证中讨论):

• JRE不作为单独的"包"分发.应该使用JDK的模块

• Oracle OpenJDK 11不支持Linux Alpine,因此无法轻松创建轻量级图像

  • 同时,当前稳定的Debian版本仍然没有Java 11软件包(Ubuntu在openjdk-11软件包下安装了Java 10),这就是为什么不稳定的sid版本用于基础docker映像的原因

• 目前可用的Oracle openjdk-11映像构建了未剥离的libjvm.so模块,该模块有数百兆字节,必须单独剥离:

  • 从openjdk创建的jlink运行时映像大小(特别是libjvm.so)非常庞大.预计它要小得多.
  • 解决方案:https://github.com/docker-library/openjdk/issues/217#issuecomment-436079779

由于这些问题,即使是简洁的 Oracle Java 11基础映像也非常繁重,并且被认为是不稳定的:https://hub.docker.com/_/openjdk/

所以问题是:

什么是构建和提供Java 11应用程序作为docker镜像的优化或推荐方法？

我想在正在运行的docker容器中执行netstat以查看打开的TCP套接字及其状态.但是,在我的一些docker容器上,netstat不可用.有没有办法通过一些docker API获得开放套接字(及其状态,以及它们连接的IP地址,如果有的话)而不使用netstat？(顺便说一句,我的容器使用docker-proxy - 也就是说,没有直接桥接)

我想我可以直接查看/ proc文件系统,但是在那一点上,我可能还将docker cp netstat放入容器并执行它.我想知道码头可能提供的任何设施.

当使用Alpine图像创建Dockerfiles时,我经常看到它的使用apk --no-cache以及其他时间它被提交,而我看到了rm /var/cache/apk/*.

我很想知道利用--no-cache消除以后需要做的事情rm /var/cache/apk/*.我还想知道一种风格是否比另一种更受青睐.

我正在运行 alpine 的 docker swarm 管理器节点上安装 aws-cli（Linux 0317632a4ad9 4.9.59-moby #1 SMP Thu Mar 1 20:54:00 UTC 2018 x86_64 Linux）。Alpine 的 aws-cli 包目前列在边缘分支 (1.18.55.r0) 的社区存储库中。我修改了/etc/apk/repositories为针对此 repo。

安装过程中寻找 py3-urllib3，但我解决了这个问题，最后得到了一个没有错误的全新安装，如下所示：

  ~ $ sudo apk add aws-cli@edge-comm
    fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
    ERROR: unsatisfiable constraints:
      py3-urllib3-1.25.9-r0:
        masked in: @edge
        satisfies: py3-botocore-1.16.12-r0[py3-urllib3<1.26]

    ~ $ sudo apk add py3-urllib3@edge aws-cli@edge-comm
    (1/23) Installing groff (1.22.3-r1)
    (2/23) Installing py3-six (1.10.0-r6)
    (3/23) Installing py3-dateutil (2.6.0-r1)
    (4/23) Installing libpng (1.6.37-r0)
    (5/23) Installing freetype (2.7.1-r2)
    (6/23) Installing libjpeg-turbo (1.5.3-r2)
    (7/23) Installing lcms2 …

我有一个只包含两个文件的目录,Dockerfile并且sayhello.sh:

.
??? Dockerfile
??? sayhello.sh

在Dockerfile读

FROM alpine
COPY sayhello.sh sayhello.sh
CMD ["sayhello.sh"]

并且sayhello.sh包含简单

echo hello

在Dockerfile成功生成:

kurtpeek@Sophiemaries-MacBook-Pro ~/d/s/trybash> docker build --tag trybash .
Sending build context to Docker daemon 3.072 kB
Step 1/3 : FROM alpine
 ---> 665ffb03bfae
Step 2/3 : COPY sayhello.sh sayhello.sh
 ---> Using cache
 ---> fe41f2497715
Step 3/3 : CMD sayhello.sh
 ---> Using cache
 ---> dfcc26c78541
Successfully built dfcc26c78541

但是,如果我尝试run它,我会收到一个executable file not …

我有一个从 GitLab 部署我的容器的管道。上次部署是 5 天前，没有任何问题。今天我部署它并收到以下错误：

$ apk add --no-cache curl python py-pip
 fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
 fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
 ERROR: unsatisfiable constraints:
   python (missing):
     required by: world[python]

我的工作定义是：

my-deploy:
  type: my-deploy
  image: docker:stable
  script:
    - apk update
    - apk add --no-cache curl python py-pip <-- Here the erorr happens
    ...

是否有最佳实践在docker alpine linux基础映像上设置glibc并使用正确的路径,以便任何生成的进程可以正确引用已安装的libc库的位置？

alpine docker镜像和busybox docker镜像有什么区别？

当我检查他们的码头文件时，alpine 是这样的（对于 Alpine v3.12 - 3.12.7）

FROM scratch
ADD alpine-minirootfs-3.12.7-x86_64.tar.gz /
CMD ["/bin/sh"]

busybox是这样的

FROM scratch
ADD busybox.tar.xz /
CMD ["sh"]

但正如https://alpinelinux.org/about/所说

Alpine Linux 是围绕musl libc和busybox构建的。

那么到底有什么区别呢？

我也很好奇许多 docker 镜像（nodejs/nginx/php 仅举几例）提供基于 alpine 的镜像，但不提供基于 busybox 的镜像。这是为什么 ？那么 busybox 图像的用例是什么？我需要强调的是，我并不是在寻找关于为什么 A 比 B 更好或反之亦然的答案或软件推荐。

我的 alpine docker遇到间歇性DNS 查找失败的情况，如此处musl-libc - Alpine 的最大弱点和此处Alpine 是否在 Kubernetes 中存在已知的 DNS 问题？说。这是我提出问题的原因之一。

PS，https://musl.libc.org/说“musl 是构建在 …