Category: docker

Enable-WindowsOptionalFeature -Online -FeatureName containers –All Install-Module -Name DockerMsftProvider -Repository PSGallery –Force Install-Package -Name docker -ProviderName DockerMsftProvider –verbose

Update the apt package index and install packages to allow apt to use repository over HTTPS: apt-get update apt-get install \ ca-certificates \ curl \ gnupg \ lsb-release Add Docker’s official GPG key: curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg Use the following command to set up the stable repository echo \ "deb [arch=$(dpkg …

Alpine FROM alpine:xxx apk upgrade --update-cache --available && \ apk add openssl && \ rm -rf /var/cache/apk/* ... Debian FROM debian:buster-slim apt upgrade openssl ...

Windows镜像动则几个G, 基于Windows Server Core的镜像5~10G, Windows节点上的kubelet在下载镜像的时候经常会cancel掉: Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled   造成这个问题的原因是因为默认的image pulling progress deadline是1分钟, 如果1分钟内镜像下载没有任何进度更新, 下载动作就会取消, 比较大的镜像就无法成功下载. 见官方文档: If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to docker. (default …

Kubernetes Linux Pod中，当通过kubectl删除一个Pod或rolling update一个Pod时, 每Terminating的Pod中的每个Container中PID为1的进程会收到SIGTERM信号, 通知进程进行资源回收并准备退出. 如果在Pod spec.terminationGracePeriodSeconds指定的时间周期内进程没有退出, 则Kubernetes接着会发出SIGKILL信号KILL这个进程。 通过 kubectl delete –force –grace-period=0 … 的效果等同于直接发SIGKILL信号. 但SIGTERM和SIGKILL方式在Windows Container中并不工作, 目前Windows Container的表现是接收到Terminating指令5秒后直接终止。。。 参见：https://v1-18.docs.kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-pod V1.Pod.terminationGracePeriodSeconds – this is not fully implemented in Docker on Windows, see: reference. The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down …

Let’s say: we need to add json file extension to the containerized IIS. Dockerfile: FROM {imageRegistry}/mcr.microsoft.com/dotnet/framework/aspnet:4.8-20200114-windowsservercore-ltsc2019 COPY . /inetpub/wwwroot WORKDIR /inetpub/wwwroot RUN C:\windows\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/requestFiltering /+"fileExtensions.[fileExtension='json',allowed='True']" ENV ASPNETCORE_URLS http://+:80 EXPOSE 80/tcp An error occurs during build docker image: Step 1/6 : FROM repo.q1lan.k8s:9999/mcr.microsoft.com/dotnet/framework/aspnet:4.8-20200114-windowsservercore-ltsc2019 ---> a5bc996f06b3 Step 2/6 : COPY . /inetpub/wwwroot …

Query Kubelet service Managed by nssm C:\k>sc qc kubelet [SC] QueryServiceConfig SUCCESS SERVICE_NAME: kubelet TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : C:\k\nssm.exe LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Kubelet DEPENDENCIES : docker SERVICE_START_NAME : LocalSystem Query kubelet AppParameters by nssm C:\k>nssm get kubelet Application C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\k>nssm get …

在Docker Swarm中通过Stack Deploy部署Service的时候，在Service中默认无法获取到客户端的IP地址, Github中有一个issue在track这个问题：Unable to retrieve user’s IP address in docker swarm mode 目前的解决方法或Workaround是把port改成host模式, 以kong为例. 默认的port发布模式: version: "3.7" services: kong-proxy: image: kong:1.0.3-alpine deploy: mode: global labels: - "tier=frontend" restart_policy: condition: any ports: - "80:8000" - "443:8443" depends_on: - database-postgresql environment: KONG_ADMIN_LISTEN: 0.0.0.0:8001, 0.0.0.0:8444 ssl KONG_DATABASE: postgres KONG_PG_DATABASE: kong KONG_PG_USER: kong KONG_PG_PASSWORD: PaSsW0rd KONG_PG_HOST: database-postgresql KONG_PG_PORT: "5432" …

Example of Pod: apiVersion: v1 kind: Pod metadata: name: hostaliases-pod spec: restartPolicy: Never hostAliases: - ip: "127.0.0.1" hostnames: - "foo.local" - "bar.local" - ip: "10.1.2.3" hostnames: - "foo.remote" - "bar.remote" containers: - name: cat-hosts image: busybox command: - cat args: - "/etc/hosts" Example of Deployment apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hostaliases-deployment spec: template: spec: …

场景 #1: 主机OS版本: Windows 10 1803 容器OS版本: Windows Server Core 1803 容器以默认的 hyperv 模式启动, 空器中的时间是一个莫名其妙的未来时间，比主机的时间提前10多个小时： 主机的时间是2018-8-15 17:XX:XX, 容器中的时间是2018-8-16 07:XX:XX 又一次代码修改重新构建了容器的镜像，重启了容器，容器的时间与主机的时间同步了 测试： 1. 当前实际时间为2018-8-16 16:XX:XX, 关掉主机中的自动设置时间, 修改主机的时间为2018-5-16 16:XX:XX，容器中的时间不变，重启容器后容器中的时间变成2018-8-16 09:XX:XX 2. 打开主机中自动设置时间，主机时间变回，2018-8-16 16:07:XX, 容器的时间也跟着同步成了2018-8-16 16:07:XX 3. 再次关掉主机中的自动设置时间，把主机时间改为2018-8-19 16:07:XX, 容器的时间马上跟着变成了2018-8-19 16:07:XX 4. 再次打开主机中的自动设置时间，主机时间变回2018-8-16 16:09:XX, 容器时间还维持在2018-8-19 16:XX:XX 5. 再次重启容器，容器的时间又与主机同步了 结论: 当容器中的时间比主机的时间晚时，与立即与主机时间同步，反之则不会同步。莫名其妙, 参见bug: https://github.com/moby/moby/issues/37283 场景 #2: 主机OS版本: Windows Server 2016 …