環境資訊中心綜合外電;姜唯 編譯;林大利 審校
本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※為什麼 USB CONNECTOR 是電子產業重要的元件?
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※台北網頁設計公司全省服務真心推薦
※想知道最厲害的網頁設計公司"嚨底家"!
※新北清潔公司,居家、辦公、裝潢細清專業服務
※推薦評價好的iphone維修中心
摘錄自2020年2月11日動物友善網報導
瓦昆費尼克斯(Joaquin Phoenix)以在電影《小丑》的精湛演技獲得了奧斯卡獎最佳男主角,除了感謝家人外,他更提到了社會不平等與動物權利。
瓦昆對現今的工廠化養殖感到痛心,他致詞時提到:「人們總覺得自己有權為一頭母牛人工授精,而當牠分娩時,我們便直接偷走牠的孩子,然後我們把牠的牛奶放進咖啡和麥片裡。人們都害怕改變,是因為我們必須有所犧牲,但人類在最好的情況下是富有愛、創造力和獨創性的,我們應當可以創造、發展和實施一套有益於所有有情眾生和環境的系統。」
瓦昆已經成為素食者多年,更長年投入動保運動。除了曾經替「終止玉林狗肉節」的活動拍攝宣傳短片外,更多次擔任善待動物組織PETA的廣告代言人,2017年宣傳反羊毛製品、2019年則是倡導純素飲食,更被PETA評選為「年度風雲人物」。
他的呼籲確實造成不小的影響,今年1月的金球獎在他的建議下,第一次採取全素晚宴,也獲得許多演員的響應,緊接而來的評論家選擇獎、演員工會獎也全都從善如流,改採素食晚宴。
※ 本文轉載自 動物友善網
本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※網頁設計公司推薦不同的風格,搶佔消費者視覺第一線
※Google地圖已可更新顯示潭子電動車充電站設置地點!!
※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計最專業,超強功能平台可客製化
摘錄自2020年3月16日香港01報導
香港海洋公園保育基金昨日(15日)接報通知跟進一宗鯨豚擱淺個案,在大嶼山沙螺灣發現一條長約1.7米的年幼雄性鯨豚,由於屍體已嚴重腐爛,物種有待確定。翻查過去半個月擱淺情況,已先後發現有五條鯨豚擱淺,累計本年度有15宗。
香港海洋公園保育基金在3月首半個月先後接報五宗鯨豚擱淺個案,除了上述個案,還包括在3月7日在南丫島發現一條長184厘米的成年雄性江豚;同日亦在鬼手岩發現一條長148厘米的亞成年江豚;3月8日在萬宜水庫石提旁發現一條長164厘米的成年雄性江豚;以及3月14日在大嶼山水口發現一條長133厘米的年幼江豚,牠們在發現時屍體均已嚴重腐爛。
本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益
※新北清潔公司,居家、辦公、裝潢細清專業服務
※別再煩惱如何寫文案,掌握八大原則!
※教你寫出一流的銷售文案?
※超省錢租車方案
※FB行銷專家,教你從零開始的技巧
摘錄自2020年3月29日中央社報導
美聯社報導,聯合國(UN)表示,派駐全球各地人員有86名通報感染2019冠狀病毒疾病(COVID-19,武漢肺炎)。同時禁止核子擴散條約的執行檢討會已決定延後舉行。
聯合國發言人杜雅里克(Stephane Dujarric)表示,多數染疫工作人員派駐歐洲,但在非洲、亞洲、中東及美國也有工作人員患病。為減少病毒傳播,聯合國絕大多數工作人員目前在家工作。
聯合國27日表示,由於武漢肺炎大流行,禁止核子擴散條約(Nuclear Non-Proliferation Treaty, NPT)的191個締約國已決定,將條約執行情況的檢討會延後舉行。杜雅里克稱,這項檢討會將在情況允許下儘快舉行,最晚不遲於2021年4月。
本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※新北清潔公司,居家、辦公、裝潢細清專業服務
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※超省錢租車方案
※教你寫出一流的銷售文案?
※網頁設計最專業,超強功能平台可客製化
想要理解對象什麼時候回收,就要理解到對象引用這個概念,於是有了下文
a.當內存不足,JVM開始垃圾回收,對於強引用的對象,就算是出現了00M也不會對該對象進行回收,死都不收。
b.強引用是我們最常見的普通對象引用,只要還有強引用指向一個對象,就能表明對象還“活着”,垃圾收集器不會碰這種對象。
在Java中最常見的就是強引用,把一個對象賦給一個引用變量,這個引用變量就是一個強引用。
當一個對象被強引用變量引用時,它處於可達狀態,它是不可能被垃圾回收機制回收的,即使該對象以後永遠都不會被用到JVM也不會回收。
因此強引用是造成Java內存泄漏的主要原因之一
c.對於一個普通的對象,如果沒有其他的引用關係,只要超過了引用的作用域或者顯式地將相應(強)引用賦值為null,一般認為就是可以被垃圾收集的了〈當然具體回收時機還是要看垃圾收集策略)。
案例:
package com.wfd360.demo03GC.referDemo; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 12:12 * @description */ public class StrongRefer { /** * 強引用的理解 * * @param args */ public static void main(String[] args) { Object obj1 = new Object(); // 建立強引用 Object obj2 = obj1; // 觀察obj1 和 obj2 的各種內存地址 System.out.println("obj1=" + obj1); System.out.println("obj2=" + obj2); // obj1創建可以回收的條件 obj1 = null; // gc回收 System.gc(); // 觀察各對象情況 System.out.println("obj1=" + obj1); System.out.println("obj2=" + obj2); } }
View Code
從測試結果課程看出,obj1的實際對象別沒有回收;
a.軟引用是用來描述一些還有用但並非必需的對象,需要用java.lang.ref.SoftReference類來實現。
b.對於軟引用關聯着的對象,在系統將要發生內存溢出異常之前,將會把這些對象列進回收範圍之中進行第二次回收。如果這次回收還沒有足夠的內存,才會拋出內存溢出異常。在JDK1.2之後,提供了Soft Reference類來實現軟引用。
c.軟引用通常用在對內存敏感的程序中,比如高速緩存就有用到軟引用,內存夠用的時候就保留,不夠用就回收!
案例:
package com.wfd360.demo03GC.referDemo; import java.lang.ref.SoftReference; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 12:12 * @description */ public class SoftRefer { /** * 軟引用的理解 * 通過設置jvm參數,在不同的條件下觀察 * * @param -Xms5m -Xmx5m -XX:+PrintGCDetails * @param args */ public static void main(String[] args) { // 測試內存充足(不回收軟引用) //testSoftReferNOGc(); // 測試內存不充足(回收軟引用) testSoftReferGc(); } /** * 模擬內存充足的情況 */ public static void testSoftReferNOGc() { Object obj1 = new Object(); // 建立軟引用 SoftReference softRefer = new SoftReference<>(obj1); // 觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); // obj1創建可以回收的條件 obj1 = null; // gc回收 System.gc(); // 再次觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); } /** * 模擬內存不足 * 1.設置較小的堆內存 * 2.創建大對象 * 3.jvm參 * -Xms5m -Xmx5m -XX:+PrintGCDetails */ public static void testSoftReferGc() { Object obj1 = new Object(); // 建立軟引用 SoftReference softRefer = new SoftReference<>(obj1); // 觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); // obj1創建可以回收的條件 obj1 = null; try { byte[] bytes = new byte[6 * 1024 * 1024]; } catch (Throwable e) { System.out.println("===============>error:" + e.getMessage()); } finally { // 再次觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); } } }
View Code
內存充足測試結果:
內存不充足測試結果:
實際案例
假如有一個應用需要讀取大量的本地數據(圖片、通訊率、臨時文件等):
如果每次讀取數據都從硬盤讀取則會嚴重影響性能,
如果一次性全部加載到內存中又可能造成內存溢出。
此時使用軟引用可以解決這個問題。
設計思路是:用一個HashMap來保存數據的路徑和相應數據對象關聯的軟引用之間的映射關係,在內存不足時,
JVM會自動回收這些緩存數據對象所佔用的空間,從而有效地避免了00M的問題。
Map<String,SoftReference>imageCache=new HashMap<String,SoftReference>();
a.弱引用也是用來描述非必需對象的,但是它的強度比軟引用更弱一些,被弱引用關聯的對象只能生存到下一次垃圾收集發生之前。
b..當垃圾收集器工作時,無論當前內存是否足夠,都會回收掉只被弱引用關聯的對象。在JDK1.2之後,提供廣Weak Reference類來實現弱引用。
c.弱引用需要用Java.lang.ref.WeakReference類來實現,它比軟引用的生存期更短.
案例:
package com.wfd360.demo03GC.referDemo; import java.lang.ref.WeakReference; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 12:12 * @description */ public class WeakRefer { /** * 弱引用的理解 * * @param args */ public static void main(String[] args) { Object obj1 = new Object(); // 建立弱引用 WeakReference softRefer = new WeakReference<>(obj1); // 觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); // obj1創建可以回收的條件 obj1 = null; // gc回收 System.gc(); // 再次觀察內存地址 System.out.println("obj1=" + obj1); System.out.println("softRefer=" + softRefer.get()); } }
View Code
查看API介紹:
測試代碼:
package com.wfd360.demo03GC.referDemo; import java.util.HashMap; import java.util.WeakHashMap; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 5:10 * @description <p> * 弱引用引用之:WeakHashMap * 以弱鍵 實現的基於哈希表的 Map。在 WeakHashMap 中,當某個鍵不再正常使用時,將自動移除其條目。 * 更精確地說,對於一個給定的鍵,其映射的存在並不阻止垃圾回收器對該鍵的丟棄,這就使該鍵成為可終止的,被終止, * 然後被回收。丟棄某個鍵時,其條目從映射中有效地移除,因此,該類的行為與其他的 Map 實現有所不同。 * </p> */ public class WeakReferMap { /** * 測試 HashMap 與 WeakHashMap 區別 * 測試邏輯: * 1.創建不同的map * 2.創建key value值 * 3.放入各自的map,並打印結果 * 4.將key設置為null,並打印結果 * 5.手動GC,並打印結果 * * @param args */ public static void main(String[] args) { hashMapMethod(); System.out.println("--------華麗的分割線--------"); weakHashMapMethod(); } /** * HashMap測試(強引用) */ private static void hashMapMethod() { HashMap<String, String> map = new HashMap<>(); String key = "key1"; String value = "HashMap-value"; map.put(key, value); System.out.println(map); key = null; System.out.println(map); System.gc(); System.out.println(map); } /** * 若引用(WeakHashMap測試) */ private static void weakHashMapMethod() { WeakHashMap<String, String> map = new WeakHashMap<>(); // 注意這裏的new一個字符串與直接寫key="key2"對測試結果是有區別的,詳細原因可以看之前講的內存分配 String key = new String("key2"); String value = "WeakHashMap-value"; map.put(key, value); System.out.println(map); key = null; System.out.println(map); System.gc(); System.out.println(map); } }
View Code
測試結果:
從測試結果可以看出:弱引用的map數據已經被回收。
代碼:
package com.wfd360.demo03GC.referDemo; import java.lang.ref.ReferenceQueue; import java.lang.ref.WeakReference; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 7:23 * @description */ public class QueueRefer { /** * 測試弱引用回收前,把數據放入隊列中 * * @param args * @throws InterruptedException */ public static void main(String[] args) throws InterruptedException { Object obj1 = new Object(); ReferenceQueue<Object> referenceQueue = new ReferenceQueue(); // 當GC釋放對象內存的時候,會將引用加入到引用隊列 WeakReference<Object> weakReference = new WeakReference<>(obj1, referenceQueue); System.out.println(obj1); System.out.println(weakReference.get()); System.out.println(referenceQueue.poll()); System.out.println("--------華麗的分割線--------"); obj1 = null; System.gc(); Thread.sleep(500); System.out.println(obj1); System.out.println(weakReference.get()); System.out.println(referenceQueue.poll()); } }
View Code
採用弱引用的方式測試結果:
從測試結果可以看出,需要回收的對象已經進入隊列。
採用軟引用的方式測試結果:
從測試結果可以看出,軟引用,沒有到達回收的條件,並沒有進行回收,也不會進入隊列;
1.虛引用需要java.lang.ref.PhantomReference類來實現。
2.與其他幾種引用都不同,虛引用並不會決定對象的生命周期。如果一個對象僅持有
虛引用,那麼它就和沒有任何引用一樣,在任何時候都可能被垃圾回收器回收,它不能單獨使用也不能通過它訪
問對象,虛引用必須和引用隊列(ReferenceQueue)聯合使用。
3.虛引用的主要作用是跟蹤對象被垃圾回收的狀態。僅僅是提供了一種確保對象被finalize以後,做某些事情的
機制。PhantomReference的get方法總是返回null,因此無法訪問對應的引用對象。其意義在於說明一個對象己
經進入俑finalization階段,可以被gc回收,用來實現比finalization機制更靈活的回收操作。
4.設置虛引用關聯的唯一目的,就是在這個對象被收集器回收的時候收到一個系統通知或者後續添加
進一步的處理。Java技術允許使用finalize()方法在垃圾收集器將對象從內存中清除出去之前做必要的清理工作。
代碼:
package com.wfd360.demo03GC.referDemo; import java.lang.ref.PhantomReference; import java.lang.ref.ReferenceQueue; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 7:44 * @description */ public class PhantomRefer { /** * 虛引用測試 * @param args * @throws InterruptedException */ public static void main(String[] args) throws InterruptedException { Object obj1 = new Object(); ReferenceQueue<Object> referenceQueue = new ReferenceQueue(); PhantomReference<Object> phantomReference = new PhantomReference<>(obj1,referenceQueue); System.out.println(obj1); System.out.println(phantomReference.get()); System.out.println(referenceQueue.poll()); System.out.println("--------華麗的分割線--------"); obj1 = null; System.gc(); Thread.sleep(500); System.out.println(obj1); System.out.println(phantomReference.get()); System.out.println(referenceQueue.poll()); } }
View Code
測試結果:
對象是否存活判斷流程:
1.可達性分析,看是否有GC Roots的引用鏈,如果沒有將做第一次標記;
2.檢查是否需要執行finalize()方法,
如果沒必要(之前執行過了),直接回收內存;
如果要執行finalize()方法,這個時候對象如果再次建立引用鏈(唯一自救機會),對象不會被回收,否則直接回收;
總結:
1.對象回收滿足兩個條件:
a.沒有引用鏈。
b.回收前會執行finalize()方法,如果執行finalize(),沒有再次建立連接(如果重新與引用鏈上的任意對象建立連接,例如給對象賦值,該對象都不會被回收)
2.在gc回收前會執行finalize()方法,只執行一次,並且是異步執行不保證執行成功,線程優先級低
代碼演示:
package com.wfd360.demo03GC.referDemo; /** * @author 姿勢帝-博客園 * @address https://www.cnblogs.com/newAndHui/ * @WeChat 851298348 * @create 06/20 8:34 * @description */ public class FinalizeGC { public static FinalizeGC obj1 = null; /** * 重寫finalize方法 * @throws Throwable */ @Override protected void finalize() throws Throwable { super.finalize(); System.out.println("執行finalize方法"); // 自救,在回收時建立引用鏈 FinalizeGC.obj1 = this; } public static void main(String[] args) throws InterruptedException { obj1 = new FinalizeGC(); obj1 = null; System.gc(); Thread.sleep(600); System.out.println("第一次自救成功:"+obj1); obj1 = null; System.gc(); Thread.sleep(600); System.out.println("第二次自救失敗,不會再次執行finalize方法:"+obj1); } }
View Code
測試結果:
完美!
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※為什麼 USB CONNECTOR 是電子產業重要的元件?
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※台北網頁設計公司全省服務真心推薦
※想知道最厲害的網頁設計公司"嚨底家"!
※新北清潔公司,居家、辦公、裝潢細清專業服務
※推薦評價好的iphone維修中心
四月中旬Hangfire團隊發布了1.7.11版本,在使用周期性作業調度過程中發現一個問題,這個問題應該一直未解決,故做此記錄,希望遇到的童鞋根據項目業務而避開這個問題。
我們依然是在控制台中進行測試,下載所需包請參考官方文檔,這裏不再敘述,首先我們在內存中存儲數據,如下:
var storageOpts = new MemoryStorageOptions(); GlobalConfiguration.Configuration.UseMemoryStorage(storageOpts); using var server = new BackgroundJobServer(); RecurringJob.AddOrUpdate("job1", () => Print1(), "*/10 * * * * *", TimeZoneInfo.Local); RecurringJob.AddOrUpdate("job2", () => Print2(), "*/10 * * * * *", TimeZoneInfo.Local); RecurringJob.AddOrUpdate("job3", () => Print3(), "*/10 * * * * *", TimeZoneInfo.Local);
public static void Print1() { Console.WriteLine("start1"); } public static void Print2() { Console.WriteLine("start2"); } public static void Print3() { Console.WriteLine("start3"); }
Hangfire已支持秒級(1.7+)周期作業調度,如上代碼,我們每隔10秒執行上述3個作業,打印如下:
基於內存存儲間隔10秒執行對應作業,根據上述打印結果來看沒有問題,接下來我們使用SQLite來存儲作業數據看看,首先下載Hangfire.SQLite包,針對控制台需進行如下配置
GlobalConfiguration.Configuration.UseSQLiteStorage("Data Source=./hangfire.db;");
當我們啟動控制台時一定會拋出如下異常,其異常旨在表明需要SQLite驅動
我們去下載微軟官方針對SQLite的驅動(Microsoft.Data.Sqlite)
接下來我們將發現對於每一個作業都會重複執行多次,如下:
猜測只會在SQLite數據庫中才會存在問題吧,為了解決這個問題,做了一點點嘗試,但還是無法從根本上完全解決,我們知道Hangfire服務的默認工作數量為當前機器的處理器數量乘以5即(Environment.ProcessorCount * 5),那麼我們嘗試給1是不是可以規避這個問題
var options = new BackgroundJobServerOptions() { WorkerCount = 1 }; using var server = new BackgroundJobServer(options);
上述設置后,我們可以看到貌似只執行了一次,但是這種情況還是是隨機的並不靠譜,比如多執行幾次看看,會出現如下可能情況
沒招了,找了下官方issue列表,發現此問題(https://github.com/mobydi/Hangfire.Sqlite/issues/2)一直處於打開狀態並未得到解決,所以要麼看看能否根據項目業務規避這個問題或者下載源碼自行調試解決
本文是在使用Hangfire過程中發現SQLite數據庫出現的問題,因針對Hangfire的SQLite具體實現並不是官方團隊所提供,所以暫不能確定到底是Hangfire.SQLite包提供者的問題,根據issue描述大概率是Hangfire的一個bug,希望在SQLite存儲作業等數據存在的問題引起使用者注意。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能
※台北網頁設計公司這麼多該如何選擇?
※智慧手機時代的來臨,RWD網頁設計為架站首選
※評比南投搬家公司費用收費行情懶人包大公開
※幫你省時又省力,新北清潔一流服務好口碑
※回頭車貨運收費標準
在前面爬蟲的相關介紹中,我們介紹了如何抓取靜態頁面信息。但是,在實際的網頁瀏覽過程中,我們可能會經常碰到各種需要進行交互的操作,典型的如輸入信息、點擊按鈕之類。
對於這種場景,之前的靜態頁面操作方式已經不能滿足需求,這時我們需要藉助新的工具,比如selenium或者PhantomJS。由於後者已經停止維護,推薦使用前者。
如果大家有做過web的自動化測試,相信對於selenium一定不陌生,測試人員經常使用它來進行自動化測試。
selenium最初是一個自動化web測試工具,通過代碼模擬人使用瀏覽器自動訪問目標站點並操作,比如跳轉、輸入、點擊、下拉等。
由於開發者的不斷完善,目前的功能越來越強大,基本支持各種交互操作。同時,不止支持有界瀏覽,還支持無界瀏覽。
正如我們前面講過的,爬蟲的本質過程就是模擬人對瀏覽器的操作過程。在爬蟲中使用,selenium主要是為了解決requests無法執行javaScript代碼的問題。
本質上是通過驅動瀏覽器,完全模擬瀏覽的操作,比如跳轉、輸入、點擊、下拉等…進而進行跳轉。
當然,它也有壞處,主要的壞處就是它的速度比較慢。原因是selenium在操作時,需要等瀏覽器對頁面的元素渲染好之後才能操作。而我們知道,由於頁面渲染過程需要加載各種資源,響應速度與網絡帶寬要求非常高。通常情況,它比靜態頁面的響應至少慢一個數量級。
在知道selenium是什麼以及有什麼用之後,我們來具體學習如何操作這個工具。
由於selenium本質是模擬人對瀏覽器進行輸入、選擇、點擊等操作,因此對於目標標籤的定位非常重要。
在前面的章節,我們對於如何定位目標標籤有過詳細的介紹,這裏就不再贅述。selenium對於目標標籤定位的方式本質與靜態的頁面一樣,只不過因為使用的包不同,因此在beautifulSoup中使用的是find和findAll,而在selenium中使用的接口有所變化。
下圖中已對各種定位方式進行了歸納總結:
在找到目標標籤之後,最重要的是對這些標籤進行模擬操作。Selenium庫下webdriver模塊常用方法主要分類兩類:一類是模擬瀏覽器、鍵盤操作,另一類是模擬鼠標操作。
模擬瀏覽器、鍵盤操作的方法歸納如下:
模擬鼠標操作的方法歸納如下:
在介紹了selenium相關的使用方法之後,我們來進行操作。這裏介紹兩個例子:第一個例子是模擬百度搜索,第二個例子是模擬自動登錄網易163郵箱發送郵件。
在開始示例之前我們需要安裝selinum插件包,同時還需要下載webdriver。在我們的示例中,需要是使用chrome瀏覽器進行操作,需要使用瀏覽器的驅動webdriver。
關於下載什麼版本的webdriver,可以在瀏覽器的屬性中查看,並在http://npm.taobao.org/mirrors/chromedriver/下載對應的版本就好,如果是其他的瀏覽器,則需要下載對應的瀏覽器驅動程序,這種不再做進一步介紹。
第一步還是需要打開目標的地址“w w w.baidu.com”,分析目標網頁中目標元素的特點,如下圖所示:
通過分析,我們很容易就找到搜索框的id為kw,點擊按鈕的id為su,餘下的就是使用方法進行模擬。
實現的代碼如下所示:
from selenium import webdriver
#get 方法 打開指定網址
driver=webdriver.Chrome()
driver.get('http://www.baidu.com')
#選擇網頁元素
element_keyword = driver.find_element_by_id('kw')
#輸入字符
element_keyword.send_keys('python 爬蟲')
#找到搜索按鈕
element_search_button = driver.find_element_by_id('su')
element_search_button.click()
driver.close()
操作過程跟上面相似,第一步也是分析目標網頁http://mail.163.com。
如下圖所示:
找到了目標標籤然後就是模擬登錄。
實現代碼如下:
# coding:UTF-8
import time
from selenium.webdriver.common.keys import Keys
from selenium import webdriver
driver = webdriver.Chrome()
driver.implicitly_wait(5)
driver.get('http://mail.163.com/')
driver.switch_to_frame(driver.find_element_by_tag_name('iframe'))
# driver.switch_to_frame('x-URS-iframe')
driver.find_element_by_name('email').clear()
driver.find_element_by_name('email').send_keys('郵箱地址')
driver.find_element_by_name('password').send_keys('郵箱密碼', Keys.ENTER)
# 跳轉頁面時,強制等待6s
time.sleep(6)
# 點擊寫信按鈕
driver.find_element_by_xpath("//div[@id='dvNavTop']/ul/li[2]/span[2]").click()
time.sleep(2)
# 收件人
driver.find_element_by_class_name('nui-editableAddr-ipt').send_keys('目標的郵箱')
driver.find_element_by_xpath("//input[@class='nui-ipt-input' and @type='text' and @maxlength='256']").send_keys(
u'測試') # 主題
xpath = driver.find_element_by_xpath("//div[@class='APP-editor-edtr']/iframe")
# 文本內容在iframe中
driver.switch_to_frame(xpath)
driver.find_element_by_xpath("//body[@class='nui-scroll' and @contenteditable='true']").send_keys(u'這是一個自動化測試郵件')
# 發送按鈕在iframe外,所以需要跳出
driver.switch_to_default_content()
# 發送
driver.find_element_by_xpath("//div[@class='nui-toolbar-item']/div/span[2]").click()
driver.close()
當然,在實際過程中,可能往往還有驗證碼的驗證。因為現在的驗證碼難度越來越大,形式也多種多樣,使用常規的方法很難解決,必須藉助機器學習或者第三方接口進行實現,將在後續單獨列一個章節進行介紹如何破解驗證碼。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計公司推薦不同的風格,搶佔消費者視覺第一線
※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※南投搬家公司費用需注意的眉眉角角,別等搬了再說!
※新北清潔公司,居家、辦公、裝潢細清專業服務
※教你寫出一流的銷售文案?
(1)API/utils文件夾下新建premission.py文件,代碼如下:
# utils/permission.py
class SVIPPremission(object):
message = "必須是SVIP才能訪問"
def has_permission(self,request,view):
if request.user.user_type != 3:
return False
return True
class MyPremission(object):
def has_permission(self,request,view):
if request.user.user_type == 3:
return False
return True
(2)settings.py全局配置權限
#全局
REST_FRAMEWORK = {
"DEFAULT_AUTHENTICATION_CLASSES":['API.utils.auth.Authentication',],
"DEFAULT_PERMISSION_CLASSES":['API.utils.permission.SVIPPremission'],
}
(3)views.py添加權限
from django.shortcuts import render,HttpResponse
from django.http import JsonResponse
from rest_framework.views import APIView
from API import models
from rest_framework.request import Request
from rest_framework import exceptions
from rest_framework.authentication import BaseAuthentication
from API.utils.permission import SVIPPremission,MyPremission
ORDER_DICT = {
1:{
'name':'apple',
'price':15
},
2:{
'name':'dog',
'price':100
}
}
def md5(user):
import hashlib
import time
#當前時間,相當於生成一個隨機的字符串
ctime = str(time.time())
m = hashlib.md5(bytes(user,encoding='utf-8'))
m.update(bytes(ctime,encoding='utf-8'))
return m.hexdigest()
class AuthView(APIView):
'''用於用戶登錄驗證'''
authentication_classes = [] #裏面為空,代表不需要認證
permission_classes = [] #不裏面為空,代表不需要權限
def post(self,request,*args,**kwargs):
ret = {'code':1000,'msg':None}
try:
user = request._request.POST.get('username')
pwd = request._request.POST.get('password')
obj = models.UserInfo.objects.filter(username=user,password=pwd).first()
if not obj:
ret['code'] = 1001
ret['msg'] = '用戶名或密碼錯誤'
#為用戶創建token
token = md5(user)
#存在就更新,不存在就創建
models.UserToken.objects.update_or_create(user=obj,defaults={'token':token})
ret['token'] = token
except Exception as e:
ret['code'] = 1002
ret['msg'] = '請求異常'
return JsonResponse(ret)
class OrderView(APIView):
'''
訂單相關業務(只有SVIP用戶才能看)
'''
def get(self,request,*args,**kwargs):
self.dispatch
#request.user
#request.auth
ret = {'code':1000,'msg':None,'data':None}
try:
ret['data'] = ORDER_DICT
except Exception as e:
pass
return JsonResponse(ret)
class UserInfoView(APIView):
'''
訂單相關業務(普通用戶和VIP用戶可以看)
'''
permission_classes = [MyPremission,] #不用全局的權限配置的話,這裏就要寫自己的局部權限
def get(self,request,*args,**kwargs):
print(request.user)
return HttpResponse('用戶信息')
# urls.py
from django.contrib import admin
from django.urls import path
from API.views import AuthView,OrderView,UserInfoView
urlpatterns = [
path('admin/', admin.site.urls),
path('api/v1/auth/',AuthView.as_view()),
path('api/v1/order/',OrderView.as_view()),
path('api/v1/info/',UserInfoView.as_view()),
]
# API/utils/auth/py
# auth.py
from rest_framework import exceptions
from API import models
from rest_framework.authentication import BaseAuthentication
class Authentication(BaseAuthentication):
'''用於用戶登錄驗證'''
def authenticate(self,request):
token = request._request.GET.get('token')
token_obj = models.UserToken.objects.filter(token=token).first()
if not token_obj:
raise exceptions.AuthenticationFailed('用戶認證失敗')
#在rest framework內部會將這兩個字段賦值給request,以供後續操作使用
return (token_obj.user,token_obj)
def authenticate_header(self, request):
pass
(4)測試
普通用戶訪問OrderView,提示沒有權限
普通用戶訪問UserInfoView,可以返回信息
(1)dispatch
def dispatch(self, request, *args, **kwargs):
"""
`.dispatch()` is pretty much the same as Django's regular dispatch,
but with extra hooks for startup, finalize, and exception handling.
"""
self.args = args
self.kwargs = kwargs
#對原始request進行加工,豐富了一些功能
#Request(
# request,
# parsers=self.get_parsers(),
# authenticators=self.get_authenticators(),
# negotiator=self.get_content_negotiator(),
# parser_context=parser_context
# )
#request(原始request,[BasicAuthentications對象,])
#獲取原生request,request._request
#獲取認證類的對象,request.authticators
#1.封裝request
request = self.initialize_request(request, *args, **kwargs)
self.request = request
self.headers = self.default_response_headers # deprecate?
try:
#2.認證
self.initial(request, *args, **kwargs)
# Get the appropriate handler method
if request.method.lower() in self.http_method_names:
handler = getattr(self, request.method.lower(),
self.http_method_not_allowed)
else:
handler = self.http_method_not_allowed
response = handler(request, *args, **kwargs)
except Exception as exc:
response = self.handle_exception(exc)
self.response = self.finalize_response(request, response, *args, **kwargs)
return self.response
(2)initial
def initial(self, request, *args, **kwargs):
"""
Runs anything that needs to occur prior to calling the method handler.
"""
self.format_kwarg = self.get_format_suffix(**kwargs)
# Perform content negotiation and store the accepted info on the request
neg = self.perform_content_negotiation(request)
request.accepted_renderer, request.accepted_media_type = neg
# Determine the API version, if versioning is in use.
version, scheme = self.determine_version(request, *args, **kwargs)
request.version, request.versioning_scheme = version, scheme
# Ensure that the incoming request is permitted
#4.實現認證
self.perform_authentication(request)
#5.權限判斷
self.check_permissions(request)
self.check_throttles(request)
(3)check_permissions
裏面有個has_permission這個就是我們自己寫的權限判斷
def check_permissions(self, request):
"""
Check if the request should be permitted.
Raises an appropriate exception if the request is not permitted.
"""
#[權限類的對象列表]
for permission in self.get_permissions():
if not permission.has_permission(request, self):
self.permission_denied(
request, message=getattr(permission, 'message', None)
)
(4)get_permissions
def get_permissions(self):
"""
Instantiates and returns the list of permissions that this view requires.
"""
return [permission() for permission in self.permission_classes]
(5)permission_classes
所以settings全局配置就如下
#全局
REST_FRAMEWORK = {
"DEFAULT_PERMISSION_CLASSES":['API.utils.permission.SVIPPremission'],
}
django-rest-framework內置權限BasePermission
默認是沒有限制權限
class BasePermission(object):
"""
A base class from which all permission classes should inherit.
"""
def has_permission(self, request, view):
"""
Return `True` if permission is granted, `False` otherwise.
"""
return True
def has_object_permission(self, request, view, obj):
"""
Return `True` if permission is granted, `False` otherwise.
"""
return True
我們自己寫的權限類,應該去繼承BasePermission,修改之前寫的permission.py文件
# utils/permission.py
from rest_framework.permissions import BasePermission
class SVIPPremission(BasePermission):
message = "必須是SVIP才能訪問"
def has_permission(self,request,view):
if request.user.user_type != 3:
return False
return True
class MyPremission(BasePermission):
def has_permission(self,request,view):
if request.user.user_type == 3:
return False
return True
(1)使用
(2)返回值
(3)局部
(4)全局
REST_FRAMEWORK = {
#權限
"DEFAULT_PERMISSION_CLASSES":['API.utils.permission.SVIPPremission'],
}
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※想知道最厲害的網頁設計公司"嚨底家"!
※幫你省時又省力,新北清潔一流服務好口碑
※別再煩惱如何寫文案,掌握八大原則!
※產品缺大量曝光嗎?你需要的是一流包裝設計!
Dragonfly 是一款基於 P2P 的智能鏡像和文件分發工具。它旨在提高文件傳輸的效率和速率,最大限度地利用網絡帶寬,尤其是在分發大量數據時,例如應用分發、緩存分發、日誌分發和鏡像分發。
在阿里巴巴,Dragonfly 每個月會被調用 20 億次,分發的數據量高達 3.4PB。Dragonfly 已成為阿里巴巴基礎設施中的重要一環。
儘管容器技術大部分時候簡化了運維工作,但是它也帶來了一些挑戰:例如鏡像分發的效率問題,尤其是必須在多個主機上複製鏡像分發時。
Dragonfly 在這種場景下能夠完美支持 Docker 和 PouchContainer。它也兼容其他格式的容器。相比原生方式,它能將容器分發速度提高 57 倍,並讓 Registry 網絡出口流量降低 99.5%。
Dragonfly 能讓所有類型的文件、鏡像或數據分發變得簡單而經濟。
更多請通過官方文檔了解。
這裏採用多機部署,方案如下:
應用 | IP |
---|---|
服務端 | 172.17.100.120 |
客戶端 | 172.17.100.121 |
客戶端 | 172.17.100.122 |
以docker方式部署,命令如下:
docker run -d --name supernode --restart=always -p 8001:8001 -p 8002:8002 \
dragonflyoss/supernode:0.3.0 -Dsupernode.advertiseIp=172.17.100.120
準備配置文件
Dragonfly 的配置文件默認位於 /etc/dragonfly
目錄下,使用容器部署客戶端時,需要將配置文件掛載到容器內。
為客戶端配置 Dragonfly Supernode 地址:
cat <<EOD > /etc/dragonfly/dfget.yml
nodes:
- 172.17.100.120
EOD
docker run -d --name dfclient --restart=always -p 65001:65001 \
-v /etc/dragonfly:/etc/dragonfly \
dragonflyoss/dfclient:v0.3.0 --registry https://index.docker.io
registry是倉庫地址,這裏使用的官方倉庫
我們需要修改 Dragonfly 客戶端機器(dfclient0
, dfclient1
)上 Docker Daemon 配置,通過 mirror 方式來使用 Dragonfly 進行鏡像的拉取。
在配置文件 /etc/docker/daemon.json
中添加或更新如下配置項:
{
"registry-mirrors": ["http://127.0.0.1:65001"]
}
然後重啟Docker
systemctl restart docker
在任意一台客戶端上進行測試,比如:
docker pull tomcat
查看client端的日誌,如果輸出如下,則表示是通過DragonFly來傳輸的。
docker exec dfclient grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log
2020-06-20 15:56:49.813 INFO sign:146-1592668602.159 : downloading piece:{"taskID":"4d977359836129ce2eec4b8418a7042c47db547a239e2a577ddc787ee177289c","superNode":"172.17.100.120","dstCid":"cdnnode:172.17.100.120~4d977359836129ce2eec4b8418a7042c47db547a239e2a577ddc787ee177289c","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}
如果需要查看鏡像是否通過其他 peer 節點來完成傳輸,可以執行以下命令:
docker exec dfclient grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log | grep -v cdnnode
如果以上命令沒有輸出結果,則說明鏡像沒有通過其他peer節點完成傳輸,否則說明通過其他peer節點完成傳輸。
服務端以Deployment的形式部署
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: supernode
name: supernode
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
app: supernode
template:
metadata:
labels:
app: supernode
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
spec:
containers:
- image: dragonflyoss/supernode:0.3.0
name: supernode
ports:
- containerPort: 8080
hostPort: 8080
name: tomcat
protocol: TCP
- containerPort: 8001
hostPort: 8001
name: register
protocol: TCP
- containerPort: 8002
hostPort: 8002
name: download
protocol: TCP
volumeMounts:
- mountPath: /etc/localtime
name: ltime
- mountPath: /home/admin/supernode/logs/
name: log
- mountPath: /home/admin/supernode/repo/
name: data
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
restartPolicy: Always
tolerations:
- effect: NoExecute
operator: Exists
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: ""
volumes:
- hostPath:
path: /etc/localtime
type: ""
name: ltime
- hostPath:
path: /data/log/supernode
type: DirectoryOrCreate
name: log
- hostPath:
path: /data/supernode/repo/
type: DirectoryOrCreate
name: data
---
kind: Service
apiVersion: v1
metadata:
name: supernode
namespace: kube-system
spec:
selector:
app: supernode
ports:
- name: register
protocol: TCP
port: 8001
targetPort: 8001
- name: download
protocol: TCP
port: 8002
targetPort: 8002
以hostNetwork的形式部署在master上。
部署過後可以看到supernode已經正常啟動了。
# kubectl get pod -n kube-system | grep supernode
supernode-86dc99f6d5-mblck 1/1 Running 0 4m1s
客戶端以daemonSet的形式部署,yaml文件如下:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: dfdaemon
namespace: kube-system
spec:
selector:
matchLabels:
app: dfdaemon
template:
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
labels:
app: dfdaemon
spec:
containers:
- image: dragonflyoss/dfclient:v0.3.0
name: dfdaemon
imagePullPolicy: IfNotPresent
args:
- --registry https://index.docker.io
resources:
requests:
cpu: 250m
volumeMounts:
- mountPath: /etc/dragonfly/dfget.yml
subPath: dfget.yml
name: dragonconf
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
restartPolicy: Always
tolerations:
- effect: NoExecute
operator: Exists
- effect: NoSchedule
operator: Exists
volumes:
- name: dragonconf
configMap:
name: dragonfly-conf
配置文件我們以configMap的形式掛載,所以我們還需要編寫一個configMap的yaml文件,如下:
apiVersion: v1
kind: ConfigMap
metadata:
name: dragonfly-conf
namespace: kube-system
data:
dfget.yml: |
nodes:
- 172.17.100.120
部署過後觀察結果
# kubectl get pod -n kube-system | grep dfdaemon
dfdaemon-mj4p6 1/1 Running 0 3m51s
dfdaemon-wgq5d 1/1 Running 0 3m51s
dfdaemon-wljt6 1/1 Running 0 3m51s
然後修改docker daemon的配置,如下:
{
"registry-mirrors": ["http://127.0.0.1:65001"]
}
重啟docker
systemctl restart docker
現在我們來拉取鏡像測試,並觀察日誌輸出。
下載鏡像(在master上測試的):
docker pull nginx
然後觀察日誌
kubectl exec -n kube-system dfdaemon-wgq5d grep 'downloading piece' /root/.small-dragonfly/logs/dfclient.log
看到日誌輸出如下,表示成功
2020-06-20 17:14:54.578 INFO sign:128-1592673287.190 : downloading piece:{"taskID":"089dc52627a346df2a2ff67f6c07497167b35c4bad2bca1e9aad087441116982","superNode":"172.17.100.120","dstCid":"cdnnode:192.168.235.192~089dc52627a346df2a2ff67f6c07497167b35c4bad2bca1e9aad087441116982","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}
今天的測試就到這裏,我這是自己的小集群實驗室,效果其實並不明顯,在大集群效果可能更好。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益
※新北清潔公司,居家、辦公、裝潢細清專業服務
※別再煩惱如何寫文案,掌握八大原則!
※教你寫出一流的銷售文案?
※超省錢租車方案
※FB行銷專家,教你從零開始的技巧
默認情況下,運行容器使用容器內的臨時存儲。Pods由一個或多個容器組成,這些容器一起部署,共享相同的存儲和其他資源,可以在任何時候創建、啟動、停止或銷毀。使用臨時存儲意味着,當容器停止時,寫入容器內的文件系統的數據將丟失。
當容器在停止時也需要持久的保存數據時,OpenShift使用Kubernetes持久卷(PVs)為pod提供持久存儲。
通常用於數據庫,啟動一個數據庫的pod時提供的默認臨時存儲。如果銷毀並重新創建數據庫pod,則銷毀臨時存儲並丟失數據。如果使用持久存儲,則數據庫將數據存儲到pod外部的持久卷中。如果銷毀並重新創建pod,數據庫應用程序將繼續訪問存儲數據的相同外部存儲。
持久卷(PV)是OpenShift資源,它只由OpenShift管理員創建和銷毀。持久卷資源表示所有OpenShift節點都可以訪問的網絡連接存儲。
持久性存儲組件:
OCP使用Kubernetes持久卷(PV)技術,允許管理員為集群提供持久性存儲。開發人員使用持久性卷聲明(PVC)請求PV資源,而不需要了解具體的底層存儲基礎設施。
Persistent Volume:PV是OpenShift集群中的資源,由PersistentVolume API對象定義,它表示集群中由管理員提供的現有網絡存儲的一部分。它是集群中的資源,就像節點是集群資源一樣。PV的生命周期獨立於使用PV的任何單獨pod。
Persistent Volume Claim:pvc由PersistentVolumeClaim API對象定義,該對象表示開發人員對存儲的請求。它與pod類似,pod消耗節點資源,而pvc消耗PV資源。
卷是掛載的文件系統,對pods及其容器可用,並且可以由許多本地或網絡連接的存儲進行備份。OpenShift使用插件來支持以下不同的後端用於持久存儲:
PV可以以resource provider的任何方式掛載在主機上,provider具有不同的功能,並且每個持久卷的訪問模式都設置為該特定卷支持的特定模式。例如,NFS可以支持多個讀/寫客戶端,但是特定的NFS PV可以在服務器上作為只讀導出。
每個PV接收自己的一組訪問模式,描述特定的持久卷的功能。
訪問模式見下錶:
PV claims與具有類似訪問模式的卷匹配。唯一的兩個匹配標準是訪問模式和大小。claim的訪問模式表示請求。因此,可以授予用戶更大的訪問權限,但絕不能減少訪問權限。例如,如果一個claim請求RWO,但是惟一可用的卷是NFS PV (RWO+ROX+RWX),那麼claim將匹配NFS,因為它支持RWO。
所有具有相同模式的卷都被分組,然後按大小(從最小到最大)排序。
master上負責將PV綁定到PVC上的service接收具有匹配模式的組,並在每個組上迭代(按大小順序),直到一個大小匹配為止,然後將PV綁定到PVC上。
PV Claims可以通過在storageClassName屬性中指定它的名稱來選擇性地請求特定的存儲類。只有與PVC具有相同存儲類名稱的請求類的pv才能綁定到PVC。
集群管理員可以為所有PVC設置一個默認存儲類,或者配置動態供應程序來服務一個或多個存儲類,這些存儲類將匹配可用PVC中的規範。
pv是集群中的資源,pvc是對這些資源的請求,也充當對資源的claim檢查。pv與PVCs的相互作用具有以下生命周期:
集群管理員創建任意數量的pv,這些pv表示集群用戶可以通過OpenShift API使用的實際存儲的信息。
用戶創建具有特定存儲量、特定訪問模式和可選存儲類的PVC。master監視新的pvc,要麼找到匹配的PV,要麼等待存儲類創建一個供應程序,然後將它們綁定在一起。
Pods使用claims作為卷。集群檢查查找綁定卷的聲明,併為pod綁定該卷。對於那些支持多種訪問模式的卷,用戶在將其聲明用作pod中的卷時指定需要哪種模式。
一旦用戶有了一個claim,並且該claim被綁定,綁定的PV就屬於用戶,使用過程中該PV都屬於該用戶。用戶通過在pod的Volume中包含一個持久的卷claim來調度pod並訪問其聲明的pv。
OpenShift使用隨機uid運行容器,因此將Linux用戶從OpenShift節點映射到NFS服務器上的用戶並不能正常工作。作為OpenShift pv使用的NFS共享必須遵從如下配置:
示例配置:
/var/export/vol *(rw,async,all_squash)
其他NFS export選項,例如sync和async,與OpenShift無關。如果使用任何一個選項,OpenShift都可以工作。但是,在高延遲環境中,添加async選項可以加快NFS共享的寫操作(例如,將image push到倉庫的場景)。
使用async選項更快,因為NFS服務器在處理請求時立即響應客戶端,而不需要等待數據寫到磁盤。
當使用sync選項時,則相反,NFS服務器只在數據寫到磁盤之後才響應客戶端。
注意:NFS共享文件系統大小和用戶配額對OpenShift沒有影響。PV大小在PV資源定義中指定。如果實際文件系統更小,則PV被創建並綁定。如果PV更大,OpenShift不會將使用的空間限製為指定的PV大小,並且允許容器使用文件系統上的所有空閑空間。OpenShift自身提供了存儲配額和存儲位置限制,可用於控制項目中的資源分配。
默認的SELinux策略不允許容器訪問NFS共享。必須在每個OpenShift實例節點中更改策略,方法是將virt_use_nfs和virt_sandbox_use_nfs變量設置為true。
1 # setsebool -P virt_use_nfs=true 2 # setsebool -P virt_sandbox_use_nfs=true
NFS支持OpenShift的Recyclable插件,根據在每個持久卷上設置的策略處理自動執行回收任務。
默認情況下,持久卷被設置為Retain。Retain reclaim策略允許手動回收資源。當刪除pv claim時,持久卷仍然存在,並且認為該卷已被釋放。但它還不能用於另一個claim,因為來自前一個claim的數據仍然保留在卷上。此時管理員可以手動回收卷。
NFS卷及其回收策略設置為Recycle,表示在從claim中釋放后將被清除。例如,當將NFS回收策略設置為Recycle后,在刪除用戶綁定到該卷的pv claim之後,會在該卷上運行rm -rf命令。在它被回收之後,NFS卷可以直接綁定到一個新的pv claim。
Supplemental group是常規的Linux組。當一個進程在Linux中運行時,它有一個UID、一個GID和一個或多個Supplemental group。可以為容器的主進程設置這些屬性。
Supplemental groupid通常用於控制對共享存儲的訪問,比如NFS和GlusterFS,而fsGroup用於控制對塊存儲(如Ceph的RBD活iSCSI)的訪問。
OpenShift共享存儲插件掛載卷,以便使掛載上的POSIX權限與目標存儲上的權限匹配。例如,如果目標存儲的所有者ID是1234,組ID是5678,那麼宿主節點和容器中的掛載將具有相同的ID。因此,容器的主進程必須匹配一個或兩個id,才能訪問該卷。
1 [root@node ~]# showmount -e 2 Export list for master.lab.example.com: 3 /var/export/nfs-demo * 4 [root@services ~]# cat /etc/exports.d/nfs-demo.conf 5 /var/export/nfs-demo 6 ... 7 [root@services ~]# ls -lZ /var/export -d 8 drwx------. 10000000 650000 unconfined_u:object_r:usr_t:s0 /var/export/nfs-demo
圖上示例,UID 10000000和組650000可以訪問/var/export/nfs-demo export。通常,容器不應該作為root用戶運行。在這個NFS示例中,如果容器不是作為UID 10000000運行的,並且不是組650000的成員,那麼這些容器就不能訪問NFS export。
fsGroup定義了pod的“file-system group”ID,該ID被添加到容器的supplemental group中。supplemental group ID應用於共享存儲,而fsGroup ID用於塊存儲。
塊存儲,如Ceph RBD、iSCSI和各種類型的雲存儲,通常專用於單個pod。與共享存儲不同,塊存儲由pod接管,這意味着pod(或image)定義中提供的用戶和組id應用於實際的物理塊設備,塊存儲通常不共享。
除了SCC之外,所有預定義的安全上下文約束都將seLinuxContext設置為MustRunAs。最可能匹配pod需求的SCC迫使pod使用SELinux策略。pod使用的SELinux策略可以在pod本身、image、SCC或project(提供默認值)中定義。
SELinux標籤可以在pod的securityContext中定義。,並支持user、role、type和level標籤。
如果不使用預先分配的值,則要求配置seLinuxOptions。使用seLinuxOptions作為默認值,從而針對seLinuxOptions驗證。
沒有提供默認,允許指定任何seLinuxOptions。
準備完整的OpenShift集群,參考《003.OpenShift網絡》2.1。
1 [student@workstation ~]$ lab deploy-volume setup
本實驗不詳解NFS的配置和創建,直接使用/root/DO280/labs/deploy-volume/config-nfs.sh腳本實現,具體腳本內容可通過以下方式查看。
同時NFS由services節點提供。
1 [root@services ~]# less -FiX /root/DO280/labs/deploy-volume/config-nfs.sh 2 [root@services ~]# /root/DO280/labs/deploy-volume/config-nfs.sh #創建NFS 3 Export directory /var/export/dbvol created. 4 [root@services ~]# showmount -e #確認驗證
1 [root@node1 ~]# mount -t nfs services.lab.example.com:/var/export/dbvol /mnt 2 [root@node1 ~]# mount | grep /mnt 3 [root@node1 ~]# ll -a /mnt/ #檢查相關權限
1 [root@node1 ~]# umount /mnt/ #卸載
提示:建議node2也做以上掛載測試,測試完成后建議下載,NFS共享在OpenShift需要的時候會自動掛載。
1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com 2 [student@workstation ~]$ less -FiX /home/student/DO280/labs/deploy-volume/mysqldb-volume.yml 3 apiVersion: v1 4 kind: PersistentVolume 5 metadata: 6 name: mysqldb-volume 7 spec: 8 capacity: 9 storage: 3Gi 10 accessModes: 11 - ReadWriteMany 12 nfs: 13 path: /var/export/dbvol 14 server: services.lab.example.com 15 persistentVolumeReclaimPolicy: Recycle 16 [student@workstation ~]$ oc create -f /home/student/DO280/labs/deploy-volume/mysqldb-volume.yml 17 [student@workstation ~]$ oc get pv #查看PV 18 NAME CAPACITYACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE 19 mysqldb-volume 3Gi RWX Recycle Available 1m
1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com 2 [student@workstation ~]$ oc new-project persistent-storage
1 [student@workstation ~]$ oc new-app --name=mysqldb \ 2 --docker-image=registry.lab.example.com/rhscl/mysql-57-rhel7 \ 3 -e MYSQL_USER=ose \ 4 -e MYSQL_PASSWORD=openshift \ 5 -e MYSQL_DATABASE=quotes 6 [student@workstation ~]$ oc status #確認驗證 7 In project persistent-storage on server https://master.lab.example.com:443 8 9 10 svc/mysqldb - 172.30.39.72:3306 11 dc/mysqldb deploys istag/mysqldb:latest 12 deployment #1 deployed 58 seconds ago - 1 pod
1 [student@workstation ~]$ oc describe pod mysqldb | grep -A2 'Volumes' #查看當前pod的Volume 2 Volumes: 3 mysqldb-volume-1: 4 Type: EmptyDir (a temporary directory that shares a pod's lifetime) 5 [student@workstation ~]$ oc set volumes dc mysqldb \ 6 --add --overwrite --name=mysqldb-volume-1 -t pvc \ 7 --claim-name=mysqldb-pvclaim \ 8 --claim-size=3Gi \ 9 --claim-mode='ReadWriteMany' #修改dc並創建PVC 10 [student@workstation ~]$ oc describe pod mysqldb | grep -E -A 2 'Volumes|ClaimName' #查看驗證
1 [student@workstation ~]$ oc get pvc #查看PVC 2 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 3 mysqldb-pvclaim Bound mysqldb-volume 3Gi RWX 2m
1 [student@workstation ~]$ oc get pod 2 NAME READY STATUS RESTARTS AGE 3 mysqldb-2-r7wz8 1/1 Running 0 4m 4 [student@workstation ~]$ oc port-forward mysqldb-2-r7wz8 3306:3306
1 [student@workstation ~]$ mysql -h127.0.0.1 -uose -popenshift \ 2 quotes < /home/student/DO280/labs/deploy-volume/quote.sql #填充數據測試 3 [student@workstation ~]$ mysql -h127.0.0.1 -uose -popenshift \ 4 quotes -e "select count(*) from quote;" #確認填充完成 5 [student@workstation ~]$ ssh root@services ls -la /var/export/dbvol #查看NFS服務端數據 6 …… 7 drwxr-x---. 2 nfsnobody nfsnobody 54 Jul 21 23:43 quotes 8 …… 9 [student@workstation ~]$ ssh root@services ls -la /var/export/dbvol/quotes 10 total 116 11 drwxr-x---. 2 nfsnobody nfsnobody 54 Jul 21 23:43 . 12 drwx------. 6 nfsnobody nfsnobody 4096 Jul 21 23:39 .. 13 -rw-r-----. 1 nfsnobody nfsnobody 65 Jul 21 23:39 db.opt 14 -rw-r-----. 1 nfsnobody nfsnobody 8584 Jul 21 23:43 quote.frm 15 -rw-r-----. 1 nfsnobody nfsnobody 98304 Jul 21 23:44 quote.ibd
1 [student@workstation ~]$ oc delete project persistent-storage #刪除項目 2 project "persistent-storage" deleted 3 [student@workstation ~]$ oc delete pv mysqldb-volume #刪除PV 4 persistentvolume "mysqldb-volume" deleted
刪除PV后驗證數據是否會長期保留。
1 [student@workstation ~]$ ssh root@services ls -la /var/export/dbvol 2 …… 3 drwxr-x---. 2 nfsnobody nfsnobody 54 Jul 21 23:43 quotes 4 …… 5 [student@workstation ~]$ ssh root@services rm -rf /var/export/dbvol/* #使用rm才可以徹底刪除
OCP內部倉庫是source-to-image(S2I)流程的一個重要組件,該流程用於從應用程序源代碼創建pod。S2I流程的最終輸出是一個容器image,它被推送到OCP內部倉庫,然後可以用於部署。
在生產環境中,通常建議為內部倉庫提供一個持久性存儲。否則,在重新創建registry pod之後,S2I創建的pod可能無法啟動。例如,在master節點重新啟動之後。
OpenShift安裝程序配置並啟動一個默認的持久倉庫,該倉庫使用NFS共享,由Inventory文件中的openshift_hosted_registry_storage_*變量定義。在生產環境中,Red Hat建議由外部專用的存儲提供持久性存儲,該服務器配置為彈性和高可用性。
高級安裝程序將NFS服務器配置為使用外部NFS服務器上的持久存儲,在[NFS]字段中定義的一個NFS服務器的列表。該服務器與openshift_hosted_registry_storage*變量一起使用,以配置NFS服務器。
示例配置:
1 [OSEv3:vars] 2 openshift_hosted_registry_storage_kind=nfs #定義OCP存儲後端 3 openshift_hosted_registry_storage_access_modes=['ReadWriteMany'] #定義訪問模式,默認為ReadWriteMany,表示允許多個節點以讀寫形式掛載 4 openshift_hosted_registry_storage_nfs_directory=/exports #定義NFS服務器上的NFS存儲目錄 5 openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)' #定義存儲卷的NFS選項。這些選項被添加到/etc/ exports.d/openshift-ansible.exports中。rw選項允許對NFS卷進行讀寫訪問,root_squash選項阻止遠程連接的根用戶擁有root特權,併為nfsnobody分配用戶ID 6 openshift_hosted_registry_storage_volume_name=registry #定義要用於持久倉庫的NFS目錄的名稱 7 openshift_hosted_registry_storage_volume_size=40Gi #定義持久卷大小 8 ... output omitted ... 9 [nfs] 10 services.lab.example.com
在為持久倉庫安裝和配置存儲之後,OpenShift在OpenShift項目中創建一個名為register-volume的持久卷。持久性卷的容量為40gb,並且根據定義設置了Retain策略。同時默認項目中的pvc調用pv。
1 [student@workstation ~]$ oc describe pv registry-volume 2 Name: registry-volume #定義持久卷名 3 Labels: <none> 4 Annotations: pv.kubernetes.io/bound-by-controller=yes 5 StorageClass: 6 Status: Bound 7 Claim: default/registry-claim #定義使用持久卷的聲明 8 Reclaim Policy: Retain #默認持久卷策略,具有Retain策略的卷在從其聲明中釋放后不會被擦除 9 Access Modes: RWX #定義持久卷的訪問模式,由Ansible inventory文件的openshift_hosted_registry_storage_access_modes=['ReadWriteMany']變量定義 10 Capacity: 40Gi #定義持久卷的大小,由Ansible inventory文件的openshift_hosted_registry_storage_volume_size變量定義 11 Message: 12 Source: #定義存儲後端的位置和NFS共享 13 Type: NFS (an NFS mount that lasts the lifetime of a pod) 14 Server: services.lab.example.com 15 Path: /exports/registry 16 ReadOnly: false 17 Events: <none>
運行以下命令,確認OpenShift內部倉庫已配置registry-volume作為默認的PersistentVolumeClaim。
1 [user@demo ~] oc describe dc/docker-registry | grep -A4 Volumes 2 Volumes: 3 registry-storage: 4 Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) 5 ClaimName: registry-claim 6 ReadOnly: false
OCP內部倉庫將image和metadata存儲為普通文件和文件夾,這意味着可以檢查PV源存儲,查看倉庫是否向其寫入了文件。
在生產環境中,這是通過訪問外部NFS服務器來完成的。但是,在本環境中,NFS共享是在services的VM上配置的,因此ssh至services查看,以便於驗證OCP內部倉庫成功將image存儲到持久存儲中。
示例:一個名為hello的應用程序在default命名空間中運行,下面的命令驗證圖像是否存儲在持久存儲中。
1 [user@demo ~] ssh root@master ls -l \ 2 /var/export/registryvol/docker/registry/v2/repositories/default/
準備完整的OpenShift集群,參考《003.OpenShift網絡》2.1。
[student@workstation ~]$ lab storage-review setup
本實驗不詳解NFS的配置和創建,直接使用/root/DO280/labs/deploy-volume/config-nfs.sh腳本實現,具體腳本內容可通過以下方式查看。
同時NFS由services節點提供。
1 [root@services ~]# less -FiX /root/DO280/labs/storage-review/config-review-nfs.sh 2 [root@services ~]# /root/DO280/labs/storage-review/config-review-nfs.sh #創建NFS 3 [root@services ~]# showmount -e #確認驗證
1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com 2 [student@workstation ~]$ less -FiX /home/student/DO280/labs/storage-review/review-volume-pv.yaml 3 apiVersion: v1 4 kind: PersistentVolume 5 metadata: 6 name: review-pv 7 spec: 8 capacity: 9 storage: 3Gi 10 accessModes: 11 - ReadWriteMany 12 nfs: 13 path: /var/export/review-dbvol 14 server: services.lab.example.com 15 persistentVolumeReclaimPolicy: Recycle 16 [student@workstation ~]$ oc create -f /home/student/DO280/labs/storage-review/review-volume-pv.yaml 17 [student@workstation ~]$ oc get pv #查看PV 18 NAME CAPACITYACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE 19 review-pv 3Gi RWX Recycle Available 13s
1 [student@workstation ~]$ less -FiX /home/student/DO280/labs/storage-review/instructor-template.yaml 2 [student@workstation ~]$ oc create -n openshift -f /home/student/DO280/labs/storage-review/instructor-template.yaml 3 #使用模板創建應用至openshift namespace中
1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com 2 [student@workstation ~]$ oc new-project instructor
瀏覽器訪問: https://master.lab.example.com
選擇Catalog
選擇PHP,並使用instructor-template。
設置Application Hostname,然後直接下一步,模板會創建一個數據庫服務器。
單擊Continue to project overview以監視應用程序的構建過程。從提供的服務框架中,單擊講師。單擊部署配置#1條目旁邊的下拉箭頭,打開部署面板。當構建完成時,build部分的Complete旁邊應該出現一個綠色的複選標記。
1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com 2 [student@workstation ~]$ oc get pod 3 NAME READY STATUS RESTARTS AGE 4 instructor-1-9fmct 1/1 Running 0 43s 5 instructor-1-build 0/1 Completed 0 2m 6 mysql-1-f7rrq 1/1 Running 0 2m 7 [student@workstation ~]$ oc port-forward mysql-1-f7rrq 3306:3306
1 [student@workstation ~]$ mysql -h127.0.0.1 -u instructor -ppassword \ 2 instructor < /home/student/DO280/labs/storage-review/instructor.sql 3 [student@workstation ~]$ mysql -h127.0.0.1 -u instructor -ppassword instructor -e "select * from instructors;" #查看 4
workstations的瀏覽器訪問:http://instructor.apps.lab.example.com
1 [student@workstation ~]$ lab storage-review grade #環境腳本判斷實驗
1 [student@workstation ~]$ oc login -uadmin -predhat 2 [student@workstation ~]$ oc delete project instructor 3 [student@workstation ~]$ oc delete pv review-pv 4 [student@workstation ~]$ ssh root@services 5 [root@services ~]# rm -rf /var/export/review-dbvol 6 [root@services ~]# rm -f /etc/exports.d/review-dbvol.exports
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※新北清潔公司,居家、辦公、裝潢細清專業服務
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※超省錢租車方案
※教你寫出一流的銷售文案?
※網頁設計最專業,超強功能平台可客製化