浅谈本站nginx的Dockerfile
因为项目的更换，经常需要接触web环境的搭建。搭建的步骤基本上大同小异的，经常会因为测试和生产环境而重复进行两次同样的操作，在还原和误操作等方面也经常浪费许多时间。接触了docker之后，有一种相见恨晚的感觉，即使在开发的时候，也可以尽量少的污染到系统，软件依赖的问题也同时得到了解决。对于喜欢升级系统或软件的人来说，在折腾的路上，减少了许多头疼的事情。
在搭建本站的前期，去看了nginx官方的Dockerfile，其实是看不太懂的。以往搭建都是通过编译源码并且支持brotli压缩算法的形式进行的。因此，基于过往经验，编写了比较符合个人习惯的Dockerfile。
搭建nginx环境主要分为用户创建、编译及运行依赖安装、日志和运行目录创建并分配权限、nginx和openssl以及brotli下载、nginx编译的步骤。根据环境需求也可以省略某些操作。
载体系统和通用参数
FROM alpine:3.11
LABEL maintainer="kotomi@kotomiko.com"
ARG BUILD_ROOT=/usr/local/nginx
ARG CACHE_ROOT=/var/cache/nginx
ARG NGINX_VERSION=1.16.1
Java源码解析之LinkedBlockingQueue
LinkedBlockingQueue是BlockingQueue基于链表的实现，正如其名称的自描述一样“链表，阻塞，队列”。是面向生产者-消费者模式的典型例子。LinkedBlockingQueue的实现使用了入队和出队的概念管理同步。所有的入队操作使用一把锁，所有的出队操作使用另一把锁。同一时间入队和出队都各自只能有一个线程处于活跃状态，但入队与出队是可以并发运行的。先了解下LinkedBlockingQueue的实现约定。
- 保证线程安全，关于锁，阻塞和唤醒的操作由内部封装
- 以FIFO(先进先出)的方式操作元素，元素被添加在尾部，从头部移除或查看
- 不接受null，入队会进行非空检查
- 如果不显式的设置，最大值将是
Integer.MAX_VALUE，理论上的无界队列
| - | 不阻塞，抛出异常 | 不阻塞，返回特殊值 | 阻塞 | 阻塞但允许超时 |
|---|---|---|---|---|
| 入队 | add(e) | offer(e) | put(e) | offer(e, time, unit) |
| 出队 | remove() | poll() | take() | poll(time ,unit) |
| 查看 | element() | peek() | 不支持 | 不支持 |
Nginx关于https的相关配置
web安全的话题是绕不开https的，即使站点的安全配置很完备，也无法阻止中间人对header和html文档的更改。https用于web消息传输的加密，使得中间人查看明文信息的成本大大提高，相应的降低了各种攻击的可能性。但并不是拥有https就万无一失了，无论是软件漏洞还是密钥强度或是配置的疏忽，都依然会成为短板的存在。持续了解web的各种配置，也是对自已知识范围的扩展，本篇文章，列举一些关于本站的https相关配置。
本站是从Let's Encrypt机构申请的https证书，它是一个免费的证书申请机构，并且被主流浏览器所支持。每一次证书的发行有效期为90天，续订支持自动化脚本。官方推荐使用Certbot进行证书的自动申请及续订。本着折腾的想法，本站使用acme-tiny管理续订。
申请证书
创建私钥
# mkdir -p <path>/https/ # cd <path>/https openssl genrsa 4096 > account.key #生成私钥 openssl genrsa 4096 > domain.key #生成证书签名请求文件 # openssl版本1.1.1及以上
http安全相关响应头(response header)备忘整理
网站上线了好几天，一直在完善nginx相关的配置，有种换个角度看http的感觉。通过各种header与浏览器进行交互的时候，浏览器是如何处理它们的，web一般有哪些安全相关的header是需要留意的，为此查询了很多博客和文档。也借此机会，作为首篇文章，汇总整理一下常用的安全相关response header。
Content-Security-Policy 内容安全策略(CSP)
Content-Security-Policy: item; item;
可以严格限制网站中一切资源的来源和形式还有要不要被执行和加载等一系列行为。比如图片只可以从某个地址加载，js和css只能通过外部文件的形式加载，ajax只能访问配置的站点。最主要是可以防止跨站脚本攻击(XSS)。对于论坛类允许用户输入且会被他人浏览的网站来说，用户输入的内容应当是被过滤和转义的，因为里面可能包含可以被浏览器运行的代码。下面以本站的配置为起点，介绍一下CSP的语法和作用
Content-Security-Policy: default-src https:; style-src-elem https://cdn.jsdelivr.net; img-src https://www.kotomiko.com https://kotomiko.com; font-src data:;
这是本站目前的配置方式。
default-src https:
所有的请求必须是HTTPS的包括静态资源。
default-src是大部份选项的缺省设置，如果具体的设置没有被找到，缺省就会被使用。所以很典型的用法就是缺省设置最严格，再针对网站的需要放开更细一步的限制。如：