脚本: Ubuntu 自动备份 MySQL 数据库到 Google Drive / 百度云

by Leonn

Leonn的博客 / 2017-11-12 19:13

全文转载自Max的小站

简介

  • 数据库是网站最重要的东西,定时备份是肯定要做的。手动备份又浪费时间又容易忘记,干脆搞个自动备份脚本好了。

使用 Google Drive 备份

安装 GDrive

  • Ubuntu 14.04 64bit 版可用以下脚本直接安装 GDrive
wget http://box.maxfox.me/install-gdrive.sh && chmod +x install-gdrive.sh && ./install-gdrive.sh   

下载并配置脚本

  • 下载脚本:
wget http://box.maxfox.me/auto-backup-sql-gdrive.sh   
  • 然后编辑脚本,填上你需要备份的数据库名、数据库 root 用户密码、zip 压缩包密码等。
  • 别忘了用 chmod +x auto-backup-sql-gdrive.sh 给脚本执行权限。

使用百度云备份

安装 bypy

  • bypy 是国人用 python 开发的百度云客户端,开源项目地址:https://github.com/houtianze/bypy
  • 在安装 bypy 之前请确保你的服务器安装了以下依赖包:
apt install python-pip   pip install requests   
  • 安装 bypy 主程序:
pip install bypy   
  • 授权登陆百度云账号:
bypy info   

下载并配置脚本

  • 下载脚本:
wget http://box.maxfox.me/auto-backup-sql-baiduyun.sh   
  • 然后依然需要编辑脚本,填上你需要备份的数据库名、数据库 root 用户密码、zip 压缩包密码等。
  • 同样别忘了用 chmod +x auto-backup-sql-baiduyun.sh 给脚本执行权限。

备份的数据存储在“百度云盘 > 我的应用数据 >bypy”目录下

使用 cron 定时自动备份

  • 执行 crontab -e 编辑 cron 的配置文件,在最底部加入
0 4 * * * /root/backups/auto-backup-sql-gdrive.sh   

我的脚本文件放在 /root/backups/ 目录下,定时每天 4 点 0 分执行脚本

  • cron 的任务格式是:
minute   hour   day   month   week   command   

Shared via Inoreader

脚本: Ubuntu 自动备份 MySQL 数据库到 Google Drive / 百度云

【译】你可以用GitHub做的12件 Cool 事情

开源中国社区最新推荐博客 / 2017-11-13 23:08

原文链接

1 在 GitHub.com 编辑代码

我将从我认为大家都知道的一件事情开始(尽管我是直到一周前才知道)。

当你在 GitHub 查看文件时(任何文本文件,任何仓库中),右上角会有一个小铅笔图标,点击它就可以编辑文件了。完成之后点击 Propose file change 按钮 GitHub 将会自动帮你 fork 该项目并且创建一个 pull request

很厉害吧!他自动帮你 fork 了该 repo。

不再需要 fork , pull ,本地编辑再 push 以及创建一个 PR 这样的流程了。

这非常适合修复编写代码中出现的拼写错误和修正一个不太理想的想法。

2 粘贴图片

你不仅仅受限于输入文本和描述问题,你知道你可以直接从粘贴板中粘贴图片吗?当你粘贴时,你会看到图片已经被上传了(毫无疑问被上传到云端)之后会变成 Markdown 语法来显示图片。

3 格式化代码

如果你想写一段代码,你可以三个反引号开始 —— 就像你在研究MarkDown时所学到的 —— 之后 GitHub 会试着猜测你写的语言。

但如果你写了一些类似于 Vue, Typescript, JSX 这样的语言,你可以明确指定得到正确的高亮。

注意第一行中的

   ```jsx      

这意味着代码段将会呈现出:

(这个扩展于 gists 。顺便说一句,如果你使用 .jsx 后缀,就会得到JSX的语法高亮)

这是一个所有受支持的语法列表

4 在 PR 中用关键词关闭 Issues

假设你创建了一个用于修复 Issues #234 的 PR ,你可以在你 PR 的描述中填写 fixes #234 (或是在你 PR 任意评论中填写都是可以的)。 之后合并这个 PR 时将会自动关闭填写的 Issues。怎么样,很 cool 吧。

了解是更多相关的内容

5 链接到评论

你是否有过想要链接到特殊 comment 的想法但却无法实现?那是因为你不知道怎么做。朋友那都是过去式了,现在我就告诉你,点击用户名旁边的日期/时间即可链接到该 comment

6 链接到代码

我知道你想链接到具体的代码行上。

尝试:查看文件时,点击代码旁边的行号。

看到了吧,浏览器的 URL 已经被更新为行号了。如果你按住 shift,同时点击其他行号,URL 再次被更新,并且你也高亮显示页面中的一段代码。

分享这个 URL ,访问时将会链接到该文件已经选中的那些代码段。

但等一下,那指向的是当前的分支,如果文件发生了改变呢?也许一个在当前状态连接到文件的永久连接正是你想要的。

我很懒,所以用一张截图展示以上的所有操作。

谈到网址。。。

7 像命令行一样使用 GitHub 链接

使用 GitHub 自带的 UI 浏览也还不错,但有时直接在 URL 中输入是最快的方法。比如,我想跳转到我正在编辑的分支并和 master 进行对比,就可以在项目名称后面接上 /compare/branch-name

与选中分支的对比页将会显示出来:

以上就是和 master 分支的差异,如果想要合并分支的话,只需要输入 /compare/integration-branch...my-branch 即可。

你还可以利用快捷键达到同样的效果,使用 ctrl + L 或者 cmd + L 可以将光标移动到 URL 上(至少在 Chrome 中可以)。 加上浏览器的自动补全 —— 你就可以在两个分支之间轻松切换了。

8 在Issues创建列表

你想在你的 issue 中看到复选框列表吗?

你想在查看 issue 列表是它们以好看的 2 of 5 进度条呈现吗?

太好了!你可以用以下语法来创建一个交互性的复选框:

    - [ ] Screen width (integer)    - [x] Service worker support    - [x] Fetch support    - [ ] CSS flexbox support    - [ ] Custom elements      

是由一个空格、中横线、空格、左括号、空格(或者是 X )、右括号、空格以及一些文本组成。

你甚至可以真正的 选中/取消 这些复选框!基于某些原因,对于我来说你看起来像是技术魔力。是真的能够选中这些复选框!甚至它还更新了底层源码。

ps:以下包括第九点 基于GitHub的项目面板 由于用的不多就没有翻译。

10 GitHub wiki

作为一个像维基百科那样的非结构化的页面集合, GitHub Wiki的供给(我把它称之为 Gwiki ) 是一个非常棒的功能。

对于结构化的页面来说 —— 例如你的文档:不能说这个页面是其他页面的子页面,或则是有 “下一节”,“上一节” 这样的便捷按钮。并且 HanselGretel 也没有,因为结构化页面并没有 breadcrumbs 这样的设计。

我们继续,让 Gwiki 动起来,我从 NodeJS 的文档中复制了几页来作为 wiki 页面。然后创建了一个自定义侧边栏,帮助我更好地模拟一些实际的目录结构。尽管它不会突出显示你当前的页面位置,但侧边栏会一直存在。

这些链接需要你手动维护,但总的来说,我认为它可以做得很好。 如果需要的话可以看看

虽然它与 GitBook ( Redux 文档所使用的)或者是定制网站相比仍有差距。但在你的 repo 中它有 80% 完全值得信赖的。

我的建议是: 如果你已经有多个 README.md 文件,并且想要一些关于用户指南或更详细的文档的不同的页面,那么你应该选择 Gwiki

如果缺乏结构化/导航开始让你不爽的话,那就试试其
他的吧。

11 GitHub Pages

你可能已经知道使用 GitHub Pages 来托管一个静态网站。如果你不知道,现在就来学习,这一节是专门用于讨论使用 Jekyll 来构建一个站点的。

最简单的就是: GitHub Pages + Jekyll会通过一个漂亮的主题来渲染你的 README.md 文件。例如:通过 about-github 来查看的我的 README 页面。

如果我在 GitHub 中点击了 settings选项,切换到 Github Pages 设置,然后选择一个 Jekyll theme。。。

我就可以得到 Jekyll-themed 页面

从这点上我可以主要依据易编辑的 Markdown 文件来构建一个完整的静态站点。本质上是把 GitHub 变成了 CMS

虽然我没有实际使用过,但是 React Bootstrap 的网站都是使用它来构建的。所以它不会糟糕。

注意:它要求 Ruby 运行本地环境( Windows 自行安装, macOS 自带)。

12 把 GitHub 当做 CRM 使用

假设你有一个存有一些文本内容的网站,你不想将文本内容存储于真正的 HTML 源码中。

相反的,你想要将这些文本块存储于非开发人员能轻松的进行编辑的地方。可能是一个版本控制系统,甚至是一个审核流程。

我的建议是:使用 GitHub 厂库中的 Markdown 文件来存储这些文本内容,然后使用前端组件来拉取这些文本块并展示在页面上。

我是搞 React 的,所以这有一个 解析 Markdown 的组件例子,给定一些 Markdown 文件路径,它将会自动拉取并作为 HTML 显示出来。

   class Markdown extends React.Component {       constructor(props) {         super(props);                  // replace with your URL, obviously         this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';                  this.state = {           markdown: '',         };       }          componentDidMount() {         fetch(`${this.baseUrl}/${this.props.url}`)           .then(response => response.text())           .then((markdown) => {             this.setState({markdown});           });       }          render() {         return (           

); } }

奖励环节 —— GitHub 工具

我已经使用了 Octotree Chrome extension 有段时间了,现在我向大家推荐它! 无论你是在查看哪个 repo 它都会在左侧给你一个树状面板。

通过这个视频我了解到了 octobox,它是用于管理你的 GitHub Issues 收件箱,看起来相当不错! 以上就是我针对于octobox的全部想法。

其他

就是这样了!我希望这里至少有三件事是你还不知道的。

最后: hava a nice day!

个人博客:http://crossoverjie.top

Shared via Inoreader

【译】你可以用GitHub做的12件 Cool 事情

Namesco: 免费获取1年 .UK 和 .CO.UK域名

by Leonn

Leonn的博客 / 2017-11-13 20:47

我注册的时候需要验证信用卡,大佬有办法跳过的话,欢迎指教~

简介

  • Namesco (names.co.uk) 目前免费送一个UK和CO.UK域名,抓紧申请吧~
  • 仅限新用户,每用户只有一次机会。
  • 需要信用卡验证(会扣款1英镑)
  • 申请地址:https://www.names.co.uk

免费域名

原文

  • For a limited time, Namesco (names.co.uk) is giving you .CO.UK and .UK domains for FREE the first year of registrations. This offer entitles you to one .CO.UK and one .UK in a single transaction, limited to one transaction per account.

Shared via Inoreader

Namesco: 免费获取1年 .UK 和 .CO.UK域名

Raspberry Pi 的實作 – HomeKit 讓我們的家電更智慧,更像我們的家人

by Heracles Jam

IT 技術家 / 2017-11-13 16:26

用手機來控制家電設備超方便,只要打開 App、按個按鈕就 OK;可是,能不能連按鈕就不用按,只要動動櫻桃小口,講句話就行呢?!

想像一下,我們要用手機把客廳的燈打開,整個操作流程是:

  1. 拿出手機。
  2. 將手機解鎖。
  3. 找到控制電燈的 App。
  4. 執行這支 App。
  5. 把電燈打開。

如果不只電燈,我們打算連電視、音響、房門、冷氣、風扇、插座、門鈴 ……等等的設備也要用手機控制,首先得為這一堆設備裝上一大堆的 App。

how-to-building-apple-smart-home-solutio

每一家的App 的操作介面、設備規格、傳輸協定、系統需求統統不一樣,事先得先做好一堆參數設定才能使用。

此外,設備之間通常沒辦法跟其他設備協同運作,例如晚上想睡覺了,人是躺在床上,不必起床沒錯,可是,我們得再執行這一堆,把這些設備一個一個關掉才能安心。

別說要使用,光是想想就覺得夠累了,那也不過是把原來一堆實體遙控器換成 App 罷了,而這也是智慧家庭設備目前最大的問題 – 操作與整合不易,難以自動化。

Apple 為了要切入這塊市場,在 WWDC 2014 跟著 iOS8 一起推出 HomeKit 這個新服務,簡單的說,透過 iPhone/iPad 加上 Siri,就可以輕鬆控制所有的家電設備。

how-to-building-apple-smart-home-solutio

設定簡單、介面統一、操作方便,不用動手,只要動口,更重要的是所有的設備都在同一個生態系,依照我們設定的條件,讓這些設備自動啟用或關閉,而所有的設備串連在一起,還可以依情境同時對多個設備下命令。

不過通過 Apple 認證的配件不多,而且不便宜,那要如何把那些沒有原生支援 HomeKit 的設備加到家庭 App 裡來用呢?

這就是我們這次要實作的主角 – Homebridge 最最最重要的用途了。

事前準備

  • Rasberry Pi Zero / 1 / 2 / 3 均可,這次實作用的是 3B,別忘了先做好 基本設定
  • Raspbian Stretch 2017-09-07。
  • 支援 Wi-Fi 無線連接與控制的配件週邊。

開始安裝主程式

Homebridge 是用 JavaScript 撰寫,所以必須先把 Node.js 安裝起來才能執行。這次用的版本是 Node.js 8.x 版,相關說明請參閱 Node.js – Installing Node.js via package manager

先加入套件庫資訊。
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash –

how-to-building-apple-smart-home-solutio

再安裝 Nods.js。
sudo apt-get install -y nodejs

how-to-building-apple-smart-home-solutio

由於 CPU 架構不同,使用 Raspberry Pi Zero / 1 來實作的朋友,Node.js 的安裝方式請參閱 GitHub – sdesalas/node-pi-zero,選擇各版本的安裝指令。

安裝 Homebridge 之前,還必須先安裝這些相依套件。
sudo apt-get install -y libavahi-compat-libdnssd-dev

how-to-building-apple-smart-home-solutio

才能開始安裝 Homebridge 主程式。
sudo npm install -g –unsafe-perm homebridge

how-to-building-apple-smart-home-solutio

稍等一下下,很快就安裝好了。

how-to-building-apple-smart-home-solutio

修改設定

先建立管理 Homebridge 專用的使用者帳號與目錄。
sudo useradd –system homebridge
sudo mkdir /etc/homebridge

how-to-building-apple-smart-home-solutio

把網路卡的 MAC Address 記下來,如果網路卡的名稱不同,或是使用無線網路卡,記得把 eth0 改成該設備的名稱。
ip address show eth0 | grep link/ether | cut -c16-32 | tr a-z A-Z

how-to-building-apple-smart-home-solutio

建立 Homebridge 的主設定檔,用的是 JSON 格式,各個名詞代表的意義請參閱 HomeKit Glossary of Terms
sudo vi /etc/homebridge/config.json

how-to-building-apple-smart-home-solutio

輸入下列的內容。
{
  “bridge”: {
    “name”: “Homebridge”,
    “username”: “B8:27:EB:22:8D:E0“,
    “port”: 51234,
    “pin”: “123-45-678
  }
}

要修改的設定值有:

  • username – 剛剛取得的 MAC Address,英文字一定要大寫。
  • port – 傳輸資料用的通訊埠,建議從 49152 ~ 65535 之間選一個來用。
  • pin – 用來讓家庭 App 加入配件的代碼,格式一定要是 XXX-XX-XXX,數字任選,不能用英文字母跟特殊符號。

如果在修改主設定檔之後,Homebridge 服務無法啟動,可以把設定值貼到 JSONLint 來檢查一下。

how-to-building-apple-smart-home-solutio

Vaild Json 代表語法格式沒錯,Parse error 的話就看看是哪一行出錯。

接著,
為了讓服務在開機後自動啟動,有不少網友是用 screen 套件來執行,我不太喜歡這種方式,那只能執行,不能管理。所以,我選擇以 systemd 來管理,除了統一管理方式之外,啟動與停止服務也相對簡單多了。

建立 Homebridge 的相關服務設定檔。
sudo vi /etc/default/homebridge

how-to-building-apple-smart-home-solutio

輸入下列設定值。
# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
HOMEBRIDGE_OPTS=-U /etc/homebridge

# If you uncomment the following line, homebridge will log more
# You can display this via systemd’s journalctl: journalctl -f -u homebridge
# DEBUG=*

sudo vi /etc/systemd/system/homebridge.service

how-to-building-apple-smart-home-solutio

輸入下列設定值。
[Unit]
Description=Node.js HomeKit Server
After=syslog.target network-online.target

[Service]
Type=simple
User=homebridge
EnvironmentFile=/etc/default/homebridge
ExecStart=/usr/lib/node_modules/homebridge/bin/homebridge $HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

從家庭 App 加入配件

第一次先手動啟動 Homebridge 服務,這裡才可以看到讓家庭 App 掃瞄用的 HomeKit 代碼。
sudo homebridge -U /etc/homebridge -D

how-to-building-apple-smart-home-solutio

打開 iPhone 裡的 家庭 App。

how-to-building-apple-smart-home-solutio

第一次開啟的歡迎畫面,點選「開始使用」。

how-to-building-apple-smart-home-solutio

點選「加入配件」。

how-to-building-apple-smart-home-solutio

掃描剛剛在畫面上的 HomeKit 代碼,或是點選「沒有代碼或無法掃瞄」,手動輸入代碼也可以。

how-to-building-apple-smart-home-solutio

因為沒有通過 Apple 的官方認證,所以只能點選「強制加入」。

how-to-building-apple-smart-home-solutio

HomeKit 認證配件的 Logo 長這樣,跟 MFi 一樣要向 Apple 進貢才行。

how-to-building-apple-smart-home-solutio

稍等一下,Homebridge 配件就會被加入家庭 App 裡面。

how-to-building-apple-smart-home-solutio

房間名稱可以自行修改,配件名稱就不用了,因為我們會從 Homebridge 主設定檔裡修改。

how-to-building-apple-smart-home-solutio

直接點選「下一步」。

how-to-building-apple-smart-home-solutio

在「房間」頁籤裡,就可以看到我們加入的 Homebridge 配件。

how-to-building-apple-smart-home-solutio

按「Ctrl+C」將 Homebridge 服務中止。

how-to-building-apple-smart-home-solutio

讓 homebridge 帳號擁有專用目錄的存取權限。
sudo chown -R homebridge:homebridge /etc/homebridge

how-to-building-apple-smart-home-solutio

最後,重新載入 Homebridge 服務,並且讓它在開機後自動啟動。
sudo systemctl daemon-reload
sudo systemctl enable homebridge
sudo systemctl restart homebridge

how-to-building-apple-smart-home-solutio

安裝插件 (Plugin)

除了主程式之外,為了讓不符合 HomeKit 協定的 SmartHome 配件加入,我們必須安裝對應的插件,我們可以在 npm 官網用 homebridge-plugin 為關鍵字去搜尋可用的插件,2017/11/11 為止已經有 817 個。

how-to-building-apple-smart-home-solutio

我們先用 homebridge-openweathermap-temperature 來小試牛刀,可以從 OpenWeatherMap 取得氣溫預測資料。

how-to-building-apple-smart-home-solutio

使用 npm 指令來安裝。
sudo npm install -g homebridge-openweathermap-temperature

how-to-building-apple-smart-home-solutio

到 OpenWeatherMap 註冊一個帳號,取得 API Key。
https://home.openweathermap.org/api_keys

how-to-building-apple-smart-home-solutio

如果不知道所在位置的城市英文名稱,可以從 Weather maps 裡看到。

how-to-building-apple-smart-home-solutio

編輯 Homebridge 主設定檔。
sudo vi /etc/homebridge/config.json

how-to-building-apple-smart-home-solutio

“accessories”: [
  {
    “accessory”: “OpenweathermapTemperature”,
    “name”: “室外氣溫“,
    “url”: “http://api.openweathermap.org/data/2.5/weather?q=Taichung,TW&appid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  }
]

要修改的設定值有:

  • name – 在家庭 App 裡所顯示的配件名稱。
  • url – 所在位置的城市、國家,和剛剛申請的 32 碼 API Key。

重新啟動服務後就生效了。
sudo systemctl restart homebridge

馬上可以在家庭 App 裡看到它。

how-to-building-apple-smart-home-solutio

也可以用 S
iri 叫出來。

how-to-building-apple-smart-home-solutio

這些是我認為還蠻實用的插件。
很多朋友還會配合 小米的智能家庭套裝 來建置,例如:

如果自己的設備不支援 HomeKit,也找不到現成的插件,還可以參考 創客閣樓技術分享——用 RASPBERRY PI 打造專屬(偽)APPLE HOMEKIT 系統 釋出的原始碼,撰寫自己的專用插件。

最後,
再搭配 Apple TV 或 iPad ,讓它們成為家庭中樞之後,就可以在就可以在任何地方遙控這些配件,更可以讓它們依我們的要求自動化運作,而不需人為介入了。

how-to-building-apple-smart-home-solutio

注意事項

  • 一個 HomeBridge 服務最多只能加入 100 個 HomeKit 配件。

異常處理

常看到的錯誤訊息有這些:

how-to-building-apple-smart-home-solutio

*** WARNING *** The program ‘nodejs’ uses the Apple Bonjour compatibility layer of Avahi
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see http://0pointerde/avahi-compat?s=libdns_sd&e=nodejs
*** WARNING *** The program ‘nodejs’ called ‘DNSServiceRegister()’ which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see http://0pointerde/avahi-compat?s=libdns_sd&e=nodejs&f=DNSServiceRegister
開發者說這些錯誤訊息直接無視即可,看不下去的神人請自行動手 …… XD

No plugins found. See the README for information in installing plugins.
單純只是代表還沒安裝任何插件。

config.json (/etc/homebridge/config.json) not found.
找不到主設定檔,可能是還沒建立或是路徑指錯了。

how-to-building-apple-smart-home-solutio

gyp WARN EACCES user “root” does not have permission to access the dev dir “/root/.node-gyp/6.11.5”
用 sudo npm install -g homebridge 指令來安裝主程式時,若出現上面的錯誤訊息,就要改用 sudo npm install -g –unsafe-perm homebridge 指令才行。

參考資料

圖片來源

更新紀錄

  • 2017/11/13 撰文。

Shared via Inoreader

Raspberry Pi 的實作 – HomeKit 讓我們的家電更智慧,更像我們的家人

容器真的是万能吗?看完你会沉默

by 佚名

51CTO云计算 / 2017-11-13 16:29

麦克莱恩发明集装箱的时候,或许不会想到这种运输方式会推动经济的全球化发展。当一批批货物被打包搬上火车、轮船、飞机,集装箱不仅解决了装货慢、载量小的窘境,还将原来数月的运输时间从数月缩短至数天。当然,考虑到货物的多样性,以及具体使用情况,集装箱并非万能药。这就像是容器,将开发者的应用打包发布到Linux平台上不是一本万利,还要涉及部署成本、操作环境、安全性等问题。

容器真的是万能吗?看完你会沉默

2013年3月,PaaS服务商dotCloud(后来的Docker)将应用容器引擎Docker开源,代码托管在Github上。在此之前,容器技术已经在Linux和UNIX领域经历了十多年的变迁。从技术的角度来看,Docker基于沙箱机制可将任何应用集成在一个轻量化、可移植、标准化的容器中,核心问题就是利用Linux容器技术实现类似虚拟机的功能。然而,在一片为容器叫好的声音中,人们也要注意到这种技术的弱点。

用容器有代价

容器不是一刀切的解决方案,意味着使用者要具有相对应的专业知识,并且要确保基础设施的完整性,有了好地基才好盖房子。将容器集成部署到持续交付管道,使其自动化运转起来,需要在每次提交代码时执行一系列步骤,其中包括一次手动迁入代码库的操作。简单来说,管道的作用就是让容器在内部经过功能性测试,合格“上岗”。期间如果有一次执行延误,就会打破持续性,并且会错过发现问题的时机,导致后期投入更多精力来修补。要知道,在代码提交的几分钟内bug报错与数周后再察觉相比,前者的修复成本要小很多。

需要注意的是,Docker并不会重写代码,只是让跨平台部署变得容易了,想具有扩展性还是要由开发者亲自动手。Docker不是横跨所有系统,毕竟系统层的软件泊接不是停船装货那么简单。跨系统的时候,要先保证Docker自身的新版内核,并且底层是通用的,再小的差错率放大到成千上万台服务器上都是大风险。同时,规模化运行容器离不开管理和编排的支持,又是一笔投资开支。

容器不等于虚拟机

切勿以虚拟机的视角看待容器,其不是可以随意编辑或者删除的对象,遇到问题只能丢弃重建出一个新的。或许有开发者遇到这样的问题:容器执行过程中,修改了容器的内容(如配置文件信息),但因为修改出了问题,导致容器关闭后无法启动。为此,开发者只能创建新镜像,或者直接修改文件。

此外,Docker的资源隔离水平也比不上虚拟机,只能对一些资源共享,其他进程需要排队入列。容器在内核层面也是共享的,在某些环境中换取了高效率,但可用性和冗余也会受到影响。与独立内核的虚拟机不同,如果有一个容器内核损坏,其共享机制就会导致所有关联的容器遭殃。

生产环境缺陷

成熟的企业会使用才出现两年的数据库技术吗?更何况Docker只是一个工具,谈不上架构解决方案。前文提到,部署容器需要镜像管理、日志、监控、负载均衡等全流程的支持,并且升级后的向前兼容性较差,这也导致了容器在生产环境中的弱势,更不要说为大型应用程序创建映像。一些自建生产环境的用户会将Docker放在IaaS上,可能引发资源消耗超出容器实例所需的。而在网络层,并非所有容器都能被公网访问,这就要在网络设置时多多留意,为主机打补丁是常事儿。

部署过程中,Docker Compose与其他工具相比在生产环境配置时复杂度更高,volume绑定、端口对接、网络参数都要修改,并且需要调用很多脚本,以及外部数据库等工具。拿数据库管理来说,开发环境完全可以跨容器托管,但在生产环境就要考虑I/O性能等问题,用于确保高可用性和可靠的备份及存储。能力越大,需要注意的点就越多,容器可以将package直接从开发环境搬到生产环境,但在生产环境仍有要完善的地方。

容器离不开安全

围绕容器的安全性争议从未间断,风险是由内向外的,黑客可以通过破解容器来访问底层服务器,进而影响到云服务商的数据中心。另一方面,不同的镜像来源也让威胁变得难以预测。曾有数据显示,Docker Hub的容器镜像有超过30%保护高风险漏洞,而且这些还经常被下载的镜像。此时,容器就像潘多拉的魔盒一样,你永远不会知道里面到底有什么。

从规范性的角度来看,容器应用商店或许是个好办法。事实上,很多服务商甚至不知道自己的容器有问题,直到漏洞爆发才发现。通常,使用者应该选择熟识的服务商、避开那些长期没有更新过的容器。至于提供方,只能把控好代码质量,定期“体检”。

结语

未来,前沿技术、社区生态、企业支持将成为容器发展的三大基础,上云容器化已经成为趋势,但实际应用过程中还要根据自身业务特性做出判断,避开容器初期部署时的不稳定因素,这样才能将商业价值最大化。

【编辑推荐】

【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0

Shared via Inoreader

容器真的是万能吗?看完你会沉默