摘要：自動(dòng)調(diào)整圖片在此過程中，我開始思考一個(gè)問題既然和七牛云都提供基于地址的圖片變換，那么它們是怎么做到的呢根據(jù)我對(duì)的粗淺了解，最笨的方法可以直接以讀文件的方式從硬盤先讀取圖片的源文件，然后經(jīng)轉(zhuǎn)換后再以流的方式輸出給頁(yè)面，但這樣效率肯定極低。

無(wú)圖，純干貨，信息量較大，慎入！

最近幾天的成果，濃縮下來就是這么一行代碼：

document.getElementById("img1").src = "http://www.mysite.com/imgproxy" + imgproxy(document.getElementById("img1").getAttribute("data-src"), 135, 85);

最初的時(shí)候只是看我的個(gè)人博客圖片大小高低不一，比較難看，試圖找一種方法能夠統(tǒng)一各圖片的高度。在網(wǎng)上搜索的結(jié)果是，發(fā)現(xiàn)了幾個(gè)Jykell的插件，例如jekyll-picture-tag，通過這個(gè)過程學(xué)到了不少東西，比如img標(biāo)簽除了有srcset以外，還有一個(gè)額外的Picture標(biāo)簽等等。本來想用這個(gè)插件，但另外一個(gè)插件jekyll-cloudinary的作者說Picture標(biāo)簽并不好，應(yīng)該直接使用Cloudinary的服務(wù)。

由此而想起在我上一篇文章中提到過的一篇教程中談到過的用國(guó)內(nèi)的七牛云做圖床，于是開始嘗試把我網(wǎng)站文章中用到的圖片往七牛云搬家，圖片搬家不是問題，但又想在博客網(wǎng)站上增加https服務(wù)，于是在問過我的朋友馬壯之后，在Cloudflare上開通了https服務(wù)，但這又造成另外一個(gè)問題：七牛云上雖然放了我的圖片，但是七牛云本身不支持https服務(wù)，于是又得想辦法把圖片搬到Cloudinary。

至此我個(gè)人的博客算是可以告一段落。平心而論，七牛云的預(yù)置功能還是很不錯(cuò)的，至少它對(duì)于URL的處理方式比Cloudinary要簡(jiǎn)單，但唯一的遺憾是它不支持https。而如果圖片不支持https而網(wǎng)站使用https的話，Chrome會(huì)在Console里報(bào)警告錯(cuò)誤，而我對(duì)網(wǎng)站的要求是：一個(gè)警告都不能有。

在此過程中，我開始思考一個(gè)問題：既然Cloudinary和七牛云都提供基于URL地址的圖片變換，那么它們是怎么做到的呢？根據(jù)我對(duì)PHP的粗淺了解，最笨的方法可以直接以PHP讀文件的方式從硬盤先讀取圖片的源文件，然后經(jīng)轉(zhuǎn)換后再以流的方式輸出給頁(yè)面，但這樣效率肯定極低。于是經(jīng)過搜索后發(fā)現(xiàn)了很多人推薦的libvips庫(kù)，再進(jìn)一步搜索，在Github上發(fā)現(xiàn)了有很多顆星的imgproxy這個(gè)庫(kù)，似乎這就是我想要的東西。

于是我開始嘗試動(dòng)手往公司的服務(wù)器上部署imgproxy。但這時(shí)候遇到一個(gè)問題，在CentOS上，imgproxy并沒有yum安裝包，還需要先手工安裝libvips，然后再編譯，而最要命的是，公司的服務(wù)器在國(guó)內(nèi)，無(wú)法通過wget的方式直接安裝國(guó)外的軟件包，由此而我需要先把安裝包下載到本地，然后再上傳到公司的服務(wù)器上。這時(shí)候我又想取個(gè)巧，使用iterm內(nèi)置的scp用鼠標(biāo)拖拽的方式上傳文件。按照操作步驟的說明，安裝好了之后卻發(fā)現(xiàn)iterm的scp按鈕依然是灰色的，這時(shí)才發(fā)現(xiàn)是由于服務(wù)器上的fish版本過低，只有1.3，而最新的已經(jīng)是2.6了。于是安裝2.6的repo，嘗試更新fish，卻總是報(bào)沖突。由此而想到將fish 1.3先卸載，就在這時(shí)災(zāi)難發(fā)生了。

我直接執(zhí)行了yum remove fish，但是在做這一步之前，我沒有將root用戶的shell切換回bash，由此而導(dǎo)致了root用戶找不到它的shell，因?yàn)樗€在試圖尋找fish。這是一個(gè)致命的錯(cuò)誤，我記得自己當(dāng)時(shí)隱隱約約有預(yù)感，但還是沒有特別在意，覺得也許Linux系統(tǒng)會(huì)自動(dòng)為root用戶賦予一個(gè)缺省的shell。結(jié)果我高估了Linux系統(tǒng)的能力。

退出登錄之后，我發(fā)現(xiàn)root用戶登錄不上了！如果不仔細(xì)觀察的話，你會(huì)感覺它的不能登錄的癥狀和密碼錯(cuò)誤非常類似，但實(shí)際表現(xiàn)其實(shí)略有不同，在SSH端是不大看得出來的。我的第一反應(yīng)是，如果root用戶無(wú)法通過SSH登錄了，那么應(yīng)該通過console端登錄。

但當(dāng)天下午，令人驚訝的是連console端也登不上了！這時(shí)候我意識(shí)到問題嚴(yán)重了。在網(wǎng)上搜索的結(jié)果是有人說應(yīng)該以runlevel 1的方式登錄，然后嘗試修復(fù)/etc/shadow。但我完全不了解對(duì)于一臺(tái)云主機(jī)應(yīng)該如何進(jìn)入runlevel 1。只好提工單給客服。而客服的技術(shù)水平大家應(yīng)該是知道的，只是建議我重置密碼之后再嘗試一下。而重置密碼必須要關(guān)機(jī)再重啟，就這樣來回折騰了很久也修不好。

在經(jīng)過了漫長(zhǎng)的等待之后，終于驚動(dòng)了一個(gè)技術(shù)人員。他指出如果我必須要進(jìn)runlevel 1的話，可以在系統(tǒng)開機(jī)的前3秒之間按下鍵盤的e鍵，然后就可以進(jìn)入runlevel 1了。

但問題是這是一臺(tái)云主機(jī)，如何能在開機(jī)前3秒按鍵呢？好在現(xiàn)在云主機(jī)的console功能非常發(fā)達(dá)，你可以開著console重啟，這時(shí)候網(wǎng)絡(luò)斷掉，然后不停地刷新console，你會(huì)在電腦開機(jī)的一瞬間看到一個(gè)有字的黑畫面，這時(shí)候迅速按下e鍵也能進(jìn)入系統(tǒng)。然后再次按下e，把啟動(dòng)模式修改為Linux single。

按照他的指導(dǎo)，我終于能夠以runlevel 1的方式進(jìn)入了系統(tǒng)，首先嘗試用/etc/passwd重建/etc/shadow，再次重啟，無(wú)果，還是登錄不進(jìn)去。至此為止，所有關(guān)于密碼的努力均告失敗。我想，唯一的辦法只能嘗試看能不能切換root用戶的shell：

chsh -s /bin/bash

把root用戶的shell切換成bash之后，再次重啟電腦，果然可以成功登錄了！

接下來，我還是需要安裝fish，但yum install fish結(jié)果fish還是1.3。我還要繼續(xù)上次不成功的征程。再次把fish從1.3換成2.6。依然沖突。這次我學(xué)精了，我先把root的shell腳本切換成bash，然后yum remove fish，再次安裝，發(fā)現(xiàn)這個(gè)fish 1.3的來源是一個(gè)不知什么時(shí)候裝上的名叫dag的repo，于是嘗試把這個(gè)dag的repo禁止掉：

yum-config-manager --disable dag

然后再次安裝，終于裝上了fish 2.6。

至此，基本所有阻塞性因素都消除了，我開始將libvips的代碼拖拽進(jìn)服務(wù)器，然后編譯。但這時(shí)候問題又來了，imgproxy必須運(yùn)行在docker里，而說明文檔上只說需要自己build一個(gè)docker，但并沒有指明以什么操作系統(tǒng)為基礎(chǔ)去build，好在官方提供了一個(gè)它們自己的docker文件，可以直接運(yùn)行imgproxy。

??！早知如此，我何必折騰這么一大圈？還差點(diǎn)毀掉了我的系統(tǒng)。不過好在學(xué)到了不少東西。好吧，于是我們開始直接安裝使用imgproxy官方提供的docker：

$ docker pull darthsim/imgproxy:latest
$ docker run -e IMGPROXY_KEY=$YOUR_KEY -e IMGPROXY_SALT=$YOUR_SALT -p 8080:8080 -t darthsim/imgproxy

但是這個(gè)imgproxy的使用方式又是非常的不友好，它完全不像七牛云或者Cloudinary那樣直接在URL地址上構(gòu)建就行了，它需要自己根據(jù)自己的key和salt產(chǎn)生簽名，然后再用簽名構(gòu)建URL，它給了各種語(yǔ)言的例子，唯獨(dú)沒有java的，最后我只好根據(jù)它自己的javascript語(yǔ)言的例子構(gòu)建一個(gè)js代碼，用于替換頁(yè)面中的圖片鏈接。

但問題又來了，它給定的這個(gè)包是一個(gè)node的js腳本，里面有require語(yǔ)句，無(wú)法直接用于瀏覽器。這時(shí)候又得請(qǐng)出browerify，用它來編譯node的腳本為可以供瀏覽器直接使用的腳本。好在過程并不復(fù)雜，編譯之后得到的bundle.js文件，我們直接在頁(yè)面中引用就行了。于是就得到了本文開頭的一行代碼：

以及相關(guān)的js:

window.imgproxy = function (url, width, height) {
  const crypto = require("crypto")

  const KEY = "somekey"
  const SALT = "somesalt"

  const urlSafeBase64 = (string) => {
    return new Buffer(string).toString("base64").replace(/=/g, "").replace(/+/g, "-").replace(///g, "_")
  }

  const hexDecode = (hex) => Buffer.from(hex, "hex")

  const sign = (salt, target, secret) => {
    const hmac = crypto.createHmac("sha256", hexDecode(secret))
    hmac.update(hexDecode(salt))
    hmac.update(target)
    return urlSafeBase64(hmac.digest())
  }

  const resizing_type = "fit"
  const gravity = "no"
  const enlarge = 0
  const extension = "jpg"
  const encoded_url = urlSafeBase64(url)
  const path = `/${resizing_type}/${width}/${height}/${gravity}/${enlarge}/${encoded_url}.${extension}`

  const signature = sign(SALT, path, KEY)
  const result = `/${signature}${path}`
  return result;
}

當(dāng)然你需要npm install crypto，然后編譯：

browserify main.js > bundle.js

你可以把你自己得到的URL去和這個(gè)網(wǎng)站生成的URL做對(duì)比，如果完全一致，就說明你的代碼配置正確，否則就還是有可能不成功。

這就是這兩天來的結(jié)果。我學(xué)到了不少東西，你學(xué)到了嗎？