分类 Docker 下的文章

背景

因工作需要,在服务器通过docker部署了一个wiki.js服务,当初为了省事,通过docker-compose进行部署,同时把数据库连接信息也以环境变量的方式配置在了docker-compose.yml文件中了。

问题

但是最近公司重新部署了网络,数据库的服务ip地址已经发生了改变,导致wiki不能使用。
容器已经生成,修改compose文件已经没有任何意义,而这个服务已经用了很久,也不可能重新部署。这就需要一种可以动态修改容器环境变量的方式。

解决方案

好在经过查找,找到了,记录一下,以备后用。

// 查看容器id,通过以下命令,列出所有容器,记住需要修改的容器的id。
docker container ls -all

CONTAINER ID  IMAGE   COMMAND       CREATED   STATUS     PORTS   NAMES
c7266ebaf77d      requarks/wiki   "docker-entrypoint.s…"   3 months ago   Exited (137) 40 seconds ago  wiki

// 停止容器
docker stop wiki

// 停止Docker服务
service docker stop

// 修改 /var/lib/docker/containers/ID/config.v2.json 中对应的参数

// 启动Docker服务
service docker start

至此,问题解决。

说明

看标题很绕,那是因为我目前也不知道怎么处理,但是误打误撞找到了一个临时解决方案,为了防止以后复现此类问题无法解决,这里简单记录一下。

背景

springboot开发的项目、本地使用nexus搭建了maven库,使用gitlab做代码管理,同时配合jenkins进行自动部署。
整体流程就是提交代码到gitlab后,触发jenkins进行编译并部署到docker容器。开发过程中使用了一个第三方的jar包,手动上传到了nexus库中。

问题

清理了jenkins中的.m2缓存的包后,再次在jenkins中构建会提示如下错误:

Downloaded from maven-releases: http://我的nexusip/nexus/repository/maven-releases/e-iceblue/spire.presentation.free/3.9.0/spire.presentation.free-3.9.0.jar (37 MB at 64 MB/s)
[INFO] 
...
Waiting for Jenkins to finish collecting data
[ERROR] Failed to execute goal on project data-maintain: Could not resolve dependencies for project 我的项目:jar:0.0.1-SNAPSHOT: Could not find artifact e-iceblue:spire.presentation.free:jar:3.9.0 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR] 

这里的spire.presentation.free-3.9.0.jar便是我使用的第三方jar包,很明显前面已经从我的nexus库中下载了,但是后面又去repo.maven.apache.org中去查找没找的报错了。

解决方案

这个问题困扰了我好久,至今也没找到方案,不过阴差阳错间,找到了个临时方法。过程如下:

  1. pom文件中原本是这样的
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <repositories>
        <repository>
            <id>central</id>
            <url>http://我的nexus地址/nexus/repository/maven-releases</url>
        </repository>
    </repositories>

    <pluginRepositories>
        <pluginRepository>
            <id>central</id>
            <url>http://我的nexus地址/nexus/repository/maven-releases</url>
        </pluginRepository>
    </pluginRepositories>

    <modelVersion>4.0.0</modelVersion>
...
  1. 提交,并自动部署。会报上述错误。
  2. 将pom修改为:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <repositories>
        <repository>
            <id>com.e-iceblue</id>
            <url>http://repo.e-iceblue.cn/repository/maven-public/</url>
        </repository>
    </repositories>
    <modelVersion>4.0.0</modelVersion>
...
  1. 提交,并触发自动部署。仍会报错。
  2. 修改pom
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<!-- 删除了这些配置-->
    <modelVersion>4.0.0</modelVersion>
  1. 提交,并jenkins进行构建。
  2. 竟然好了。

总结

先这样吧,后面找到了具体原因,在更新。

背景

开发了springboot项目,部署到了docker上。运行后发现时间总是少8小时。其实可以确定就是时区的问题,苦于不是很熟悉这块内容,来来回回折腾了好几个小时才搞定。

处理过程

修改docker-compose文件

网上搜了下,发现很多这类问题的帖子,而且处理很简单,拷贝了一个,挂载localtime。

-v /etc/localtime:/etc/localtime

并且修改了宿主机的localtime,然而并没有解决,进入容器查看时间发现是对的,但是程序日志和存入数据库的时间依然不正确。

数据库时区设置

后来想着是不是数据库的时区问题,修改了数据库的时区

mysql> set global time_zone = '+8:00';
mysql> set time_zone = '+8:00';
mysql> flush privileges;

然而,还是没有解决。

timezone修改

后来发现是少修改了一个timezone。

解决方案

Dockerfile中添加了如下内容,将timezone设置为+8,问题解决。

RUN echo "Asia/Shanghai" > /etc/timezone && dpkg-reconfigure -f noninteractive tzdata

背景

为了方便,使用了docker部署了wordpress,通过nginx进行反向代理,并配置了域名,安装完成一切正常,但是在上传主题是出现了如下错误提示:

413 Request Entity Too Large

百度google一通后,在http{}中加入 client_max_body_size 10m;解决了。

然后上传文件,确出现了另一个错误提示:

The uploaded file exceeds the upload_max_filesize directive in php.ini.

解决方案

很明显,这是php上的限制,只需要修改php.in即可。
为了方便修改,我们在创建容器时,添加volumes将php配置映射到本地,完整的docker-compose.yml如下:

version: '3'
services:
  wordpress:
    image: wordpress:latest
    container_name: wordpress
    restart: always
    ports:
      - "9102:80"
    volumes:
      - ./html:/var/www/html
      - ./php:/usr/local/etc/php
    environment:
      WORDPRESS_DB_HOST: 10.0.4.5:3306
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: 123456
      WORDPRESS_DB_NAME: wp_demo

启动容器后,将php文件夹中的php.ini-production文件拷贝一份更名为:php.ini,编辑该文件,修改其中的upload_max_filesize项目的值,如下:

upload_max_filesize = 20M

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20

重启容器,即可解决问题。

背景

在云服务器上搭建了wordpress,为了方便部署,采用了docker方式,使用了9102的端口号。然后通过nginx进行反向代理,使用域名访问。

问题

nginx配置很简单,直接使用了proxy_pass配置到docker容器的wordpress地址,如下:

server {
    listen 80;
    server_name www.我的域名.com;
    location / {
        proxy_pass http://10.0.4.6:9102;
        proxy_set_header Host $host;
        proxy_set_header X-Forward-For $remote_addr;
        proxy_redirect off;
    }
}

配置完成后,访问域名进行安装,配置,都正常。管理后台也可正常访问。但是想要进入博客首页时,出了问题,直接跳转到了http://10.0.4.6:9102。很明显,这个地址是无法访问也是不对的。
总结下问题:域名+/其他页面的形式是可以正常访问的,但是如果只有域名来访问首页就会出现301重定向问题。

Request URL: http://我的域名.com/
Request Method: GET
Status Code: 301 Moved Permanently (from disk cache)
Remote Address: 127.0.0.1:8889
Referrer Policy: strict-origin-when-cross-origin

Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Thu, 19 Aug 2021 06:42:17 GMT
Location: http://10.0.4.5/
Server: nginx/1.21.1
X-Powered-By: PHP/7.4.22
X-Redirect-By: WordPress

解决方案:

多方查找,找到了方案,安装如下配置进行设置,即可解决。

server {
    listen       80;
    server_name  我的域名.com;
    
    set $node_port 9102;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://10.0.4.5:$node_port$request_uri;
        proxy_redirect off;
    }
}