Docker

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 1.前言 使用docker buildx 可以在一次build中生成支持多个平台的image。但在推动给私有仓库时，报"x509: certificate signed by unknown authority"。经过确认是，私有仓库使用的证书是自签名证书，导致SSL握手失败导致的。 2. 解决 docker buildx使用的builder配置方式与docker配置方式不同，需要在创建builder时，即指定 1) 创建配置文件 cat <<EOF > ./config.toml debug = true # root is where all buildkit state is stored. root = "/var/lib/buildkit" # insecure-entitlements allows insecure entitlements, disabled by default. insecure-entitlements = [ "network.host", "security.insecure"] [registry."my-registry.abc.local"] http = true insecure = true EOF 2) 创建builder 指定以./config.toml作为mybuilder的配置文件 docker buildx create --use --name=mybuilder —-config=./config.toml --bootstrap --bootstrap 表示启动builder ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1.简介 你听说过docker-compose吗？在萌叔看来，docker-compose相当于单机且简化版的k8s。 可以简单的编写一个yaml文件，在yaml文件指定多个container。然后可以通过docker-compose，一次性启动和停止多个服务。 它有几个应用场景： 开发 自动化测试 持续集成 特别是自动化测试这个场景。比如有一个服务依赖数据库MySQL，要完成自动化测试，显然我们需要一个干净的MySQL。用k8s来完成服务和MySQL的部署成本太高，有点杀鸡用牛刀的感觉。并且多个人同时运行的话，还有可能产生冲突。docker-compose由于是单机运行，可以确保多人同时运行互相不冲突。 2.minio示例 该示例包含一个由4个container组成的minio集群，以及一个nginx container对外暴露minio集群的管理后台和API接口 Deploy MinIO on Docker Compose 创建本地目录 mkdir -p ~/mydata/minio/data1-1 mkdir -p ~/mydata/minio/data1-2 mkdir -p ~/mydata/minio/data2-1 mkdir -p ~/mydata/minio/data2-2 mkdir -p ~/mydata/minio/data3-1 mkdir -p ~/mydata/minio/data3-2 mkdir -p ~/mydata/minio/data4-1 mkdir -p ~/mydata/minio/data4-2 编写nginx的配置文件 ~/mydata/minio/proxy.conf upstream minio_console { server minio1:9001 max_fails=3 fail_timeout=5s; server minio2:9001 max_fails=3 fail_timeout=5s; server minio3:9001 max_fails=3 fail_timeout=5s; server minio4:9001 max_fails=3 fail_timeout=5s; } upstream minio_api { # 多个服务之间可以通过服务名称相互访问 server minio1:9000 max_fails=3 fail_timeout=5s; server minio2:9000 max_fails=3 fail_timeout=5s; server minio3:9000 max_fails=3 fail_timeout=5s; server minio4:9000 max_fails=3 fail_timeout=5s; } server { listen 9001; location / { proxy_pass http://minio_console; } } server { listen 9000; location / { proxy_pass http://minio_api; } } 创建一个文件夹minio-distributed mkdir minio-distributed 编写docker compose需要的YAML文件 在minio-distributed目录下编写文件docker-compose.yaml 在docker的体系中，以包含docker-compose.yaml文件的文件夹作为一个项目，文件夹的名称就是项目名称。 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 警告：本文仅用于萌叔自己总结之用，对其它人而言可能毫无营养，没有阅读价值。 在k8s中要使用自己搭建的私有仓库，还需要一些额外的配置。 萌叔使用的harbor搭建的私有仓库 goharbor/harbor, 假定地址为 https://docker-harbor.vearne.cc 2. 配置过程 要能够成功拉去image，需要解决2个问题 2.1 TLS证书验证 由于我们的私有仓库，使用的自签名的证书，所以需要能够通过TLS的握手阶段对证书。 如果证书认证失败，你可能收到如下错误 [root@xx ~]# docker pull docker-harbor.vearne.cc/ut/helloworld:0.2.6 Error response from daemon: Get https://docker-harbor.vearne.cc/ut/helloworld:0.2.6: x509: certificate signed by unknown authority 一种做法是直接添加CA根证书到操作系统获得信任。但是萌叔尝试后，发现无效。 这里验证有效的做法是，使用dockerd的--insecure-registry参数 2.1.1 修改dockerd的配置文件 默认路径为/etc/docker/daemon.json { "insecure-registries" : ["docker-harbor.vearne.cc"] } 2.1.2 重启dockerd systemctl restart docker 2.2 登录 要想在宿主机拉取镜像，可以用 docker login docker-harbor.vearne.cc 在k8s集群中拉取镜像可以使用 kubectl create secret docker-registry regcred \ --docker-server=<你的镜像仓库服务器> \ --docker-username=<你的用户名> \ --docker-password=<你的密码> \ --docker-email=<你的邮箱地址> 创建一个密钥，用于拉取镜像 检查 Secret regcred kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode 输出和下面类似： ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 前段时间接手了一个前端项目。这个前端项目采用docker方式部署。有3套不同的环境，开发联调、测试、生产分别指向不同的后端API服务。 项目目录结构如下 ├── DockerfileDev ├── DockerfileProd ├── DockerfileTest ├── Makefile ├── README.md ├── config │ ├── api.dev.conf │ ├── api.prod.conf │ ├── api.test.conf │ └── nginx.conf ├── package.json ├── src ├── tsconfig.json └── yarn.lock config目录中是nginx相关的配置文件, 仅仅因为后端API服务地址不同，Dockerfile就有3个，对于开发联调、测试和生产环境的docker镜像也需要分别build，显然是非常低效的。 2. 改造 2.1 想法 最好的办法是在容器启动时，使用环境变量传入，动态修改nginx配置文件。 2.2 envsubst 查阅资料，发现一个shell命令 envsubst substitutes environment variables in shell format strings 它可以替换shell字符串中的环境变量 用法大致如下 root@i-bf77szgn:~# export API_HOST=vearne.com root@i-bf77szgn:~# echo "hello ${API_HOST}" | envsubst hello vearne.com 2.3 精简代码 在这种情况下，web.dev.conf、web.test.conf、web.prod.conf合并成一个文件default.template，通过环境变量传入后端API服务地址 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 删除image docker rmi myapp/base 2. 给image 打tag docker tag 4424b58cae58 myapp/base 3. 容器的存储层保存下来成为镜像 docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]] docker commit webserver nginx:v2

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 起因: 本文受到参考资料1的启发 我们线上的服务有不少都是部署在docker中，部署涉及的机器多大几十台， 服务发布时，要求前一个版本的容器必须优雅的退出。 docker容器中的进程是一个任务消费者。不断得从任务队列中取任务，然后进行执行(执行时间较长) 假定docker容器的name为test_v1 docker容器中的进程名为atm 也就是说不能简单的 docker rm -vf test_v1 docker run -d --name test_v1 test:v1 解决方案 1）方案1 首先，我想到的办法是在docker容器外部使用 ps -ef| grep atm |grep -v grep |awk '{print $2}'|xargs kill -15 容器中的进程捕获 SIGTERM 信号，优雅的退出，发现所有容器中的进程都退出后再执行发布逻辑 缺点： 这个方案肯定是没有问题的，但是如果进程同名，很有可能会导致误杀，而且从docker容器外部，传信号给容器内部的进程，感觉有点奇怪 2）方案2 幸运的看到了参考资料1 root@xxxx:~/test/docker/test_dk$ docker stop --help Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...] Stop a running container by sending SIGTERM and then SIGKILL after a grace period --help=false Print usage -t, --time=10 Seconds to wait for stop before killing it 在docker stop命令执行的时候，会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。在容器中的应用程序，可以选择忽略和不处理SIGTERM信号，不过一旦达到超时时间，程序就会被系统强行kill掉，因为SIGKILL信号是直接发往系统内核的，应用程序没有机会去处理它。在使用docker stop命令的时候，我们唯一能控制的是超时时间，比如设置为20秒超时: ...