背景

写了个wpf程序,需要在服务器上运行一下,开发的时候使用的net core 3.1,服务器上未安装,安装需要重启电脑,明显不可以。

解决

将wpf打包成自宿主的程序,包含所有运行环境一块打包出来。

打包方法

在项目目录下执行如下命令:

dotnet publish -r win-x64 -c Release --self-contained

这里配置了程序在Windows 64位下运行。

提示如下表示已经生成完成了,直接拷贝

PS F:\test> dotnet publish -r win-x64 -c Release --self-contained
用于 .NET 的 Microsoft (R) 生成引擎版本 17.0.0-preview-21501-01+bbcce1dff
版权所有(C) Microsoft Corporation。保留所有权利。

  正在确定要还原的项目…
  所有项目均是最新的,无法还原。
  你正在使用 .NET 的预览版。请查看 https://aka.ms/dotnet-core-preview
  test -> F:\test\bin\Release\netcoreapp3.1\win-x64\test.dll
  test -> F:\test\bin\Release\netcoreapp3.1\win-x64\publish\
PS F:\test>

拷贝到服务器上,双击打开直接使用即可,无需再安装运行时。

说明

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

背景

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;
    }
}