作者： htynkn

之前一直使用的是阿里云上ubuntu 12.04系统，为了使用docker方便有过一次升级，不过那个时候升级比较粗暴，我直接更新了源，然后用apt-get upgrade升的级。

今天想升级到16.04才突然发现了do–release–upgrade，整个过程轻松加愉快。

直接运行

sudo do-release-upgrade -d

升级之后检查一下

lsb_release -a

…

最近由于各种原因，需要将之前的一个网站关闭。

关闭之后因为域名没有到期，所以还是希望能够有一个静态页面让平时的常客至少下载一下存档，所以就做了一个静态网站。

因为静态网站只有一个页面和一个zip存档，所以需要在nginx中将所有请求都转发到这个页面上。

配置如下：

location / {
    try_files $uri /index.html;
}

这样的话默认请求存在的文件的时候就会直接访问这些文件，否则就会跳转回首页。…

Jenkins应该是最常用的CI/CD工具了，而Jenkins也有官方的Docker版本，可以很方便的获得一个可用的Jenkins。

但是大部分时候我们期待的是从Docker启动Jenkins之后一切环境都是准备就绪的，比如对应的插件啥的。

对于插件来说还比较简单，直接提供一个plugin.txt文件即可

credentials:1.18
maven-plugin:2.7.1

Jenkins的任务是可以在master直接运行的，但是很多时候，特别会需要很多不同构建环境的时候我们就会需要多个不同的Jenkins Slave了。

Docker-Compose可以做到启动多个容器，这样我们就可以直接在其中就行配置了，比如一个java7的Slave，一个java8的，再来一个node的，但是最后还是需要到jenkins中添加这些Slave。

Jenkins提供了Groovy脚本来实现一些配置和功能，比如需要修改执行器数量（默认为2），可以使用一些

import jenkins.model.*
Jenkins.instance.setNumExecutors(5)

对于添加Slave的脚本就稍微复杂一些，需要用到import hudson.plugins.sshslaves.*

大概的脚本如下

List<Entry> env = new ArrayList<Entry>();
  EnvironmentVariablesNodeProperty envPro = new EnvironmentVariablesNodeProperty(env);
  Slave slave = new DumbSlave(
                    "java-7-node","",
                    "/var/jenkins_home",
                    "1",
                    Node.Mode.NORMAL,
                    "agent-node-label",
                    new SSHLauncher("java-7-node",22,"jenkins","password","","","","",""),
                    new RetentionStrategy.Always(),
                    new 

之前用的ubuntu一直配置的上海交通大学的源，速度也不错，最近升级到16.04以后又准备继续使用，突然发现可以直接使用mirrors自动选择最合适的源。

默认的可用的列表文件在这里 http://mirrors.ubuntu.com/mirrors.txt

在source.list直接使用

deb mirror://mirrors.ubuntu.com/mirrors.txt xenial main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-updates main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-backports main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-security main restricted universe multiverse

Spring Boot提供了一个很便利的命令bootRun来快速启动应用，项目中的依赖会在启动时作为classpath的一部分传递给java，但是windows系统下有一个问题，如果classpath很长的时候就会直接报错，无法运行。但是如果你生成jar文件，再运行jar文件本身就不会遇到这个问题。

bootRun是一个很便利的功能，自然我们不希望这个功能无法使用，有个取巧的办法。

首先生成一个jar，这个jar文件的manifest中包含了所有依赖，然后bootRun直接依赖这个jar。

task pathingJar(type: Jar) {
    dependsOn configurations.runtime
    appendix = 'pathing'
 
    doFirst {
        manifest {
            attributes "Class-Path": configurations.runtime.files.collect {
                it.toURL().toString().replaceFirst(/file:/+/, '/')
            }.join(' ')
        }
    }
}
 
bootRun {
    dependsOn pathingJar
    doFirst {
        classpath = files("$buildDir/classes/main", "$buildDir/resources/main", pathingJar.archivePath)
    }