跳到主要內容

發表文章

目前顯示的是有「DevOps」標籤的文章

容器執行的替代方案:Docker 之外的選擇

容器執行的替代方案:Docker 之外的選擇 在現代軟體開發與部署中,容器技術是不可或缺的工具。雖然 Docker 是最廣為人知的容器工具,但它並不是唯一的選擇。根據具體使用場景或環境需求,以下幾種 Docker 替代方案可能會是更適合的選擇。 1. Podman Podman 是一個與 Docker 兼容的容器執行環境,最大的特點是它以 daemonless 的方式來運行容器。 什麼是 daemonless? 在 Docker 的設計中,需要一個 Docker Daemon 的背景服務來管理和運行容器。這意味著每當啟動一個容器時,Docker Daemon 都會作為中介來處理指令。然而,Podman 的設計則是 "daemonless",也就是說,Podman 不需要一個持續運行的背景服務來管理容器。 用 Docker 的做法來解釋 在 Docker 中,當執行指令(例如 docker run )時,其實是通過 Docker CLI 向 Docker Daemon 發送請求,而 Docker Daemon 再負責實際執行容器。 在 Podman 中,執行指令(例如 podman run )時,這些操作是直接執行的,沒有背景服務作為中介,這樣的設計減少了潛在的資源消耗和安全風險。 優點: Daemonless : 提高安全性並減少系統資源佔用。 類似 Docker 的指令: 如果熟悉 Docker,轉換到 Podman 幾乎不需要額外學習成本(例如 podman run 替代 docker run )。 Rootless Containers: 提供更高的安全性,適合在需要多人共享的環境下使用。 缺點: 雖然 Podman 與 Docker 兼容,但某些較為複雜的 Docker 工具(例如 Docker Compose)可能需要額外配置或工具來支援。 在某些環境下,社群資源和技術支持可能不如 Docker 豐富。 範例指令: podman run -d --name my-container nginx 2. containerd containerd 是一個輕量級的容器執行環境,直接與 Linux 核心的容器功能進行整合。它常被用作 Kubernetes 的底層容器執行工具。 優點: 與 Kubernetes 無縫整合: Kubern...

DevSecOps:如何使用 Ansible Vault 在 GitLab CI/CD 中安全管理秘密資訊

DevSecOps:如何使用 Ansible Vault 在 GitLab CI/CD 中安全管理秘密資訊 前言 以下是關於如何在 **GitLab CI/CD** 中使用 **Ansible Vault** 建立安全的 CI/CD 管道的詳細步驟。這將指導你從加密秘密資訊開始,到設置管道進行部署的完整過程。 準備 1. GitLab 帳戶 :確保已擁有一個 GitLab 帳戶並且已經設置好一個 repository。 2. 本地安裝 Ansible :需要在本地安裝 Ansible 來加密/解密秘密文件。 第一步:設置 Ansible 並創建加密的文件 1. 安裝 Ansible :    首先,確保已在本地機器上安裝了 Ansible。在 Ubuntu 上運行以下命令來安裝它:    ```bash    sudo apt-get install ansible    ```    如果使用其他操作系統,請參考官方的 [Ansible 安裝指南](https://docs.ansible.com/ansible/latest/installation_guide/index.html)。 2. 創建一個秘密文件:    在本地的工作目錄中,創建一個包含敏感資訊的 YAML 文件,例如:    ```yaml    # secret_vars.yml    db_username: myuser    db_password: supersecurepassword    api_key: someAPIkey12345    ``` 3. 使用 Ansible Vault 加密文件:    運行以下命令來加密 `secret_vars.yml` 文件:    ```bash    ansible-vault encrypt secret_vars.yml    ```    系統會提示你輸入一個密碼。記住這個密碼,因為你需要在 G...

如何使用 Cloud Build 來達到自動化測試與佈署| Create a CI/CD Pipeline On Cloud Build

前言 GCP 的 Cloud Build 是個非常好用的 DevOps 工具, 對於使用 Cloud Source Repository 的開發者來說,  不需要繁複的設定,  就能快速的建立 CI/CD Pipeline, 使推送到 Cloud Source Repository 的交付能自動觸發 Cloud Build 的事件執行測試與部署  除此之外無伺服器的平台, 不需要額外管理 CI/CD 的伺服器, 也不避擔心 Scale 的問題,  這也是許多開發者選擇 Cloud Build 的原因之一 以下就簡單的帶各位了解如何在 Cloud Build 上建立 Pipeline 跑 CI/CD 的流程 首先, 建立 Pipeline 腳本 由於 Cloud Build 是基於容器的服務, 腳本上的指令都必須跑在容器的環境內, 所以在建立腳本的時候, 需要特別地指定執行環境的容器映像( 即 Builder 的映像), 如下 - name: 'gcr.io/cloud-builders/docker'   args: ['build', '-t', 'gcr.io/myproject/myapp', '.'] 目前 GCP 上已經內建了幾個常用的容器映像讓開發者使用, 所以想要實作 CI/CD 的 Pipeline 並不一定需要自己建立 Builder 的映像檔 預設所有要被執行的腳本都需要被定義在 cloudbuild.yaml 的檔案裡 內容如下 steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/myproject/myapp', '.'] - name: 'gcr.io/cloud-builders/docker'   args: ['push', 'gcr.io/myproject/myapp'] - name: 'gcr.io/cloud-buil...

Azure Logic Apps 如何設定Timeout來限制Action的執行時間: Logic App Timeout

Title: how to set timeout in Azure Logic App 前言 對開發人員來說, Logic Apps是個非常好用的工具, 特別是有DevOps需求, 或是想做自動化的開發者來說, 可以節省許多時間寫一堆Code或是腳本去串接服務 設計Logic Apps 直接在Azure Portal上定義Action的種類, Input是什麼就好了, 底層的事情就交給Azure 來幫我們處理 比如說, 我們可以設一個排程, 每隔一段時間就發個請求去搓一下某個Service是否還活著 Timeout 在某些情況下, 我們可能不希望Action的執行時間過長, 假設我們預期最多不超過10秒, 但因為訪問的端點有可能發生異常, 造成Actionc還傻傻地等待Server的回應 這種情況我們可以設Timeout讓Logic App把超時的Action殺掉 首先, 右鍵 > 選擇Settings Step 2. 找到Timeout的欄位設定Duration 這邊要注意填入的時間要使用ISO 8601 的格式 ISO 8601的規則  P (Period) T(duration) H (Hour) M(Minute) S(Second). 如果Timeout想設20秒的話可以表示成PT20S 設定好之後選擇Done ... 接下來就可以存檔跑看看結果了 ... 結果 如果有成功跑完的話, 會出現綠色小勾勾, 但如過被Timeout的話就沒有

[簡易教學] 如何使用Azure Pipeline 建立CICD管線自動編譯程式碼以及部屬至Azure APP Service

前言 最近一兩年微軟開始大力的推廣自家的DevOps工具, 可以感覺的出他們很想要搶下這塊市場, 這對開發者來說其實是件好事情, 表示我們的選擇可以更多元了, 不需要再侷限於Gitlab, Jenkins 等等 Aure Pipeline 用起來的感覺是蠻好上手的, 兩三下就能將.Net程式編譯打包然後部屬到Azure的雲上跑 以前用Gitlab作CI/CD時, 比較麻煩的是如果要Build .Net Framework的程式, 就需要特別自架runner跑在windows的機器上當作build machine, 而這台build machine還需要設定跟安裝某些套件才能讓整個自動化的流程運作起來, 光弄這些code 都不用寫了 TT 那這也是我們團隊開始接觸Azure DevOps的原因, 以下就簡單的帶各位了解一下怎麼在Azure DevOps 上建立Pipeline跑CI/CD的流程 Step 1. 建立組織 一開始Azure DevOps會要求開發者建立一個組織 Step 2. 建立專案 在組織底下我們可以建立多個專案 Step 3. 建立 Pipeline 選擇Pipelines > Builds Step 4. 設定Pipeline 選擇Source Code的來源 : 這邊示範從Gitlab伺服器上抓Code下來編譯 填入遠端倉庫的位址, 帳密 然後" 下一步 " 選擇Pipeline的範本 : 待會我們會根據這個範本作些微的調整, 讓他可以正常編譯程式最終部屬到Azure App Service上 設定與調整Pipeline範本: 這邊比較重要的部分是Azure帳號裡的訂閱ID, 以及要部屬的目標App Service 的名稱 最後按上方的" Save & Queue " 接下來Pipeline就會跑起來做事 結果 如果一切順利的話, 可以看到類似以下的結果