Docker 教程：如何將Helix QAC作為容器創建并運行

在此 Docker 教程中，你將學習如何創建Helix QAC并將其作為容器化鏡像運行。

Docker的基本定義是一種開源和流行的操作系統級虛擬化（通常稱為“容器化”）技術，它是輕量級的，可移植的，并且主要在Linux和Windows上運行。Docker使使用容器創建、部署和運行應用程序變得更加容易。

從根本上說，容器只是一個正在運行的進程，并應用了一些附加的封裝功能。借助容器，開發人員（和DevOps管理員）可以將應用程序與運行應用程序所需的一切（包括代碼、運行時、庫、配置的環境變量和配置文件）打包在一起，并將其全部作為一個包提供。

還值得一提的是，Docker可以立即啟動，并具有用于版本控制和組件可重用的內置機制。這些Docker容器可以通過公共Docker中心或私有存儲庫共享，從而使其易于訪問和使用。

以下是 Docker 的一些最顯著的優勢：

• 快速部署：Docker 可以為每個進程創建一個容器，然后可以根據需要快速啟動和刪除該容器，而無需啟動平臺操作系統 （OS）。這將部署過程時間縮短到幾秒鐘 此外，Docker鏡像啟動幾乎是實時響應的。
• 可移植性：Docker 允許將經過測試的容器化應用程序部署到運行Docker的任何其他系統，并確保其執行方式與您測試時完全相同。Docker鏡像可以與其他團隊共享。
• 性能：盡管虛擬機 （VM） 是容器的替代方法，但VM具有操作系統，而Docker容器則沒有。這意味著容器的占用空間比VM小，創建速度更快，并且啟動和刪除時間更快。
• 持續集成效率：Docker 使你能夠構建容器鏡像，并在從開發、測試到部署的每個步驟中使用它。此外，您還可以分離不相關的步驟并且并行地運行它們，從而縮短從生成階段到生產部署階段所需的時間。這減少了設置環境和調試特定于環境的問題的時間，使它們更可靠，更易于維護。

但是，Docker 存在一些限制，盡管它們對Docker靜態分析器的設置的影響很小甚至為零，但了解這些限制對您來說仍然很重要。

• Docker 不能替代虛擬機：許多在 VM 中運行的應用都可以移動到容器中，但這并不意味著它們都可以或應該移動到容器中。例如：具有嚴格法規要求的行業可能無法將容器交換為VM，因為VM比容器提供更多的隔離。
• 容器中的數據：有時容器確實會出現故障，在這種情況下，它需要備份和恢復策略。雖然有幾種解決方案，但沒有一個是自動化的或者尚不可擴展的。另一個限制是，除非您在容器關閉之前先將其保存在某個位置，否則當它關閉時，其中的所有數據都會永遠消失。
• 跨平臺兼容性：如果應用程序被設計為在特定平臺（如 Windows OS 平臺或Linux）上的Docker容器中運行，這是一個主要問題，因為它無法在任何其他平臺上運行。但是，虛擬機不受此限制的約束，因此該限制使 Docker 對一些由Windows和Linux服務器組成的高度異構環境的吸引力降低。
• 使用圖形界面運行應用程序：通常，Docker 設計用于托管在命令行上運行的應用程序。雖然我們有幾種方法（如使用X11轉發或MobaXterm）可以在 Docker 容器內運行圖形界面，但這些過程很笨拙。因此，我們可以說Docker對于需要豐富接口的應用程序來說不是一個好的解決方案。

為了幫助將靜態分析工具設置為 Docker 并解決這些限制，我將把設置分解為三個簡單的部分。

第一部分：準備Docker引擎

1. 從此站點下載并安裝適用于您選擇的操作系統 （OS） 平臺的Docker引擎：https://docs.docker.com/engine/install
2. 要驗證 Docker 引擎是否已正確安裝，請運行名為“hello-world”的示例Docker鏡像。使用以下命令示例：

• $ sudo docker run hello-world
• 該命令將下載一個簡單的“hello-world”測試Docker鏡像，并在容器中運行它。因此，當容器運行時，它會打印消息并退出。

我們的 Docker 容器教程的下一部分的目標是將Docker容器設置為作為Helix 靜態代碼分析工具運行。有幾種方法可以配置 Docker 鏡像以支持不同的編碼合規性模塊，例如MISRA、AUTOSAR、CWE、CERT和靜態代碼掃描工具等。

但是，在本教程中，我將僅演示如何使用一些重要組件構建特定的 Docker 鏡像，我們將在Docker容器中將這些組件用作Helix QAC工具 （DaaQT）。

此外，我將討論在運行分析掃描工具時如何處理項目數據配置的持久性，以便您可以將Helix QAC項目規范和項目支持配置文件存儲在docker容器之外，例如prqa項目文件夾和pqraproject.xml.支持的文件。

即使 Docker 容器執行完成并關閉，對這些文件所做的任何更改都將保持不變。從docker執行上的生成到生成的任何生成腳本更改都將輸出到主機上映射的外部項目文件夾，并保持持久性。

第 II 部分：創建、生成和運行

首先，讓我們確定我選擇用于構建 docker 鏡像的一些組件及其基本說明。

• Helix QAC-2022.2 （C/C++靜態分析解析器）
• ASCM-3.3.0（AYTOSARC++14 編碼合規性）
• M3CM-3.3.0 （MISRAC 2012 編碼合規性）
• MCPP-2.3.0（MISRAC++ 2008 編碼合規性）
• CERTCCM-2.3.0（對C的安全編碼標準支持）
• CERTCCPCM-2.3.0（支持 CPP 的安全編碼標準）

接下來，下載您試用（或已購買）的Helix QAC解析器工具和編碼合規性模塊，并將這些安裝文件放在主機上的已知文件夾位置。

• 在我的示例中，將有六個文件（一個解析器工具文件和五個編碼合規性模塊）。

接下來，創建一個docker構建腳本文件。例如，我將文件命名為“qacDockerfile”，沒有文件擴展名（默認名稱為“dockerfile”）。docker引擎將使用此文件創建docker鏡像?；旧?，它有一個命令列表，可以發送給docker引擎，以自上而下的順序執行它們。。

然后將這些文件（包括qacDockerfile）放在DaaQT文件夾中。這些是生成此docker鏡像所需的唯一文件。另外，請注意，我已經將它們放在“vDockerBuilds/DaaQT”文件夾下。

以下是“qac文檔”腳本文件的內容以及一些說明。

• 第 1 行是使用Ubuntu 22.04作為基本鏡像開始的。
• 第 4 行至第7行使Ubuntu操作系統保持最新狀態，并允許時區設置。
• 第 10 行是可選的，但建議添加這些有用的工具，因為Ubuntu基礎鏡像是準系統鏡像。
• 第 15 行將安裝基本的構建工具、gnu編譯器依賴項和任何支持文件。此步驟對于編譯器工具鏈使用需求會有所不同。但是，在我的示例案例中，此圖像將使用gcc/g++ 11編譯器。
• 第 19 行和第20行指示Docker引擎創建一個名為“QacWorkspace”的工作目錄，所有子順序命令都將使用該目錄。
• 第 25 行將所有安裝文件的權限更改為可執行文件。
• 第 28 行以靜默模式安裝Helix-QAC解析器工具并接受許可協議。
• 第 31 行至第35行以靜默模式安裝選定的編碼合規性模塊，并接受許可協議。
• 第 38 行正在清理安裝文件，以使docker鏡像盡可能小的占用空間。

接下來，要構建 docker 鏡像，我們需要運行以下命令：

$> docker build --pull --no-cache -f qacDockerfile -t qacscatools：22v2.

• 拉取和無緩存參數是為了確保它始終獲取最新的 ubuntu 鏡像，并從頭開始構建docker鏡像。
• -f 是qac Docker文件名稱，默認情況下，原始名稱是dockerfile。
• -t 是格式“名稱：標簽”，因此名稱是“qacscatools”，標簽是“22v2”，以指示使用了哪個Helix-QAC工具版本。
• 不要忘記末尾的“點”，這表明它是一個本地目錄。

構建鏡像過程完成后，您可以看到最后兩行消息，這些消息指示寫入文件并標記鏡像。若要驗證生成是否成功，請運行以下命令以顯示所有可用 Docker 鏡像的列表。

• $>docker images

（注意：在上圖中，圖像標記 ID 為bd8c9d08dc4d。）

第三部分：在本地項目上運行 DaaQT

在使用此 docker 容器化鏡像（Docker作為QAC工具– DaaQT）在本地桌面項目上運行任何靜態代碼分析之前，我們需要確?？梢栽L問許可證服務器以獲得使用該工具的權限。

在我的示例中，我將使用外部遠程 Reprise 許可證管理服務器來請求要使用的許可證。

首先，我們需要創建一個本地項目運行腳本，該腳本知道在何處以及如何訪問遠程 Reprise 許可證服務器。此項目運行腳本還必須知道Helix QAC Dashboard服務器所在的位置，以便在分析運行完成后上載項目診斷消息結果。

讓我們回顧一下名為“runQACSCA.sh”的腳本文件及其內容。我將逐步提供一些關于它的作用的解釋。

• 第 3 行是對桌面計算機上項目文件夾名稱的引用。
• 第 7 行是Helix QAC Dashboard服務器上的項目持有者的名稱，用于上載診斷消息和項目信息。
  （注意：第 8 行可用于與本地文件夾名稱匹配。）
• 第 9 行到第11行是有關Helix QAC Dashboard服務器的信息，例如URL地址（或FQDN）、服務器端口和許可證服務器端口。
• 第 14 行是本地桌面項目工作區名稱“服務器URL地址”（或FQDN）、服務器端口和“許可證服務器端口”。
• 第 15 行和第16行引用了Helix QAC解析器工具所在的內部docker鏡像，以及映射項目工作區位置。
• 第 19 行用于使Docker與許可證服務器通信，以請求工具許可證以供使用。
• 第 25 行將Docker鏡像設置為映射的項目工作區所在的正確入口點。
• 第 28 行到第29行是選擇要用于項目的規則配置文件之一。這些默認文件名是為特定規則組配置標識的。您可以通過合并任何一個或多個規則配置文件來創建自己的客戶RCF文件，但是，自定義RCF文件需要在Helix QAC桌面GUI應用程序中完成，然后才能使用。此外，新的自定義名稱需要與默認文件名不同。
• 第 34 行和第35行用于映射到要使用的編譯器工具鏈。對于我的例子，我已經映射到使用任何一個GNU C/CPP 11.2版本。
• 第 38 行是創建PRQA項目配置并設置要求項目配置。
• 第41行允許Helix QAC監控和跟蹤如何使用其命令在本地構建項目的方式。
• 如果項目需要執行一些關系跨模塊分析 （RCMA） 和/或多線程分析 （MTA），則通常使用第44行和第45行。
• 第 47 行至第49行是選擇一個編碼合規性模塊，用于滿足您的編碼合規性需求。請確保此設置與第28行到第31行的RCF設置匹配。
• 第 52 行是使用上述所有配置和設置參數對項目執行靜態代碼分析。
• 第55行是將項目分析掃描結果上傳到Helix QACDashboard服務器，并將其放在項目支架中。上載的信息是包含診斷消息和項目配置設置的源代碼文件。

運行以下 docker 命令，這些命令會將本地項目卷映射到docker項目卷，以便保留分析數據文件。請密切注意ENTRYPOINT參數，其中腳本文件“runQACSCA.sh”將從項目根文件夾執行。

以下是帶有一些解釋的Docker命令：

• docker run --rm -it -v ~/ProjectsSandbox/MyCppCodeQac:/QacWorkspace/MyCppCodeQac--entrypoint=/QacWorkspace/MyCppCodeQac/runQACSCA.sh qacscatools:22v2“run”，就是執行。
• “-it”以交互方式運行Docker（所以你會得到一個帶有STDIN的偽TTY）。
• “--rm”使Docker在容器退出時自動將其刪除。
• “-v”表示卷映射本地主機卷：DockerVolume。
• “--entrypoint”表示登錄時從哪里開始，命令行開始運行帶有說明內容的位置/file_name.sh。

您還可以使用 shell 腳本來運行它，而不必記住在命令行上鍵入所有這些參數。除了不必記住所有這些細節之外，這還允許我們對腳本文件進行最小的更改，以適應其他類似的項目。

對于我的示例，我創建了一個名為“runDaaQT.sh”的shell腳本。

顯示 docker 命令行用法的屏幕截圖。

顯示 shell 腳本用法的屏幕截圖。

（可選）還可以為 CMakeNinja 項目運行此Docker容器，它的命令行與之前演示的項目類似。此項目使用 CMake 和Ninja命令行構建系統。

要使用類似的命令行或 shell 腳本文件，您需要在命令行中對正確項目卷 （CMakeNinja） 名稱的命令語法進行一些編輯，如下所示：

$> docker run --rm -it -v ~/QacProjectsSandbox/CMakeNinja:/QacWorkspace/CMakeNinja--entrypoint=/QacWorkspace/CMakeNinja/runQACSCA.sh qacscatools:22v2

CMakeNinja項目的命令行用法截圖。