該
這是首選的原因是因為它使用一種稱為GitOps的方法，并且可以輕松地與任何 CI/CD 工具結合使用，由于 ArgoCD 正在執行實際部署，因此更容易切換。此外，它還提供了一個很好的 UI，可以為不習慣每天使用 Kubernetes 的人提供清晰易懂的資訊。
說了這么多，完全取決于您想要采取的路徑，但請記住，kubectl apply -f k8s/您的 Jenkinsfile中的一個簡單內容將完全滿足您的要求，并且只需要您將kubeconfig 檔案放置在正在運行的管道可以訪問它的地方（您可以通過執行類似的操作來指定路徑kubectl --kubeconfig /path/to/kubeconfig apply -f k8s/）。
uj5u.com熱心網友回復：
根據您的承諾水平和所需的 DevOps 集成自動化水平，有一些解決方案：
- 快速而骯臟的解決方案 - 如果您將
oc命令列工具插入 Jenkins 代理\從站（通常最好在機器或虛擬機上運行），您可以創建一個環境變數來保存應用程式名稱，只要您使用oc new-app或類似的，您可以執行oc import-image后跟 ImageStream 名稱 nad 它將檢查 docker repo 標簽中版本哈希的更改（如果哈希更改，它將更新它）。在此處檢查基本令牌注入以避免密碼通過 git 溢位。
示例 Jenkinsfile 片段：
pipeline {
agent { 'jenkins_slave_vm' }
environment {
SERVICE='myapp'
}
stages {
stage('build&push') {
steps {
sh "docker build -t myrepo/${SERVICE}:latest -f Dockerfile.production ."
sh "docker push myrepo/${SERVICE}:latest"
}
}
stage('deploy') {
steps {
sh "oc login --token=${OC_IMAGE_UPDATE_TOKEN}"
sh "oc import-image ${SERVICE}"
}
}
}
}
- 更強大的企業解決方案 - 使用 Jenkins 的 k8s\openshift 插件（不同的插件），通用的 k8s 插件用于啟動具有所需環境的 pod（如前端應用程式的節點），在使用結束時重新關閉，運行使用 openshift BuildConfig 物件構建 docker\container 影像并基于任一
Dockerfile配置的行為S2I或完全由 openshift 使用該pipeline方法管理的構建階段（盡管與其他兩個相比更復雜且平臺投入更多），這里是對 openshift 4.6 的最新解釋雖然自 3.x 版以來也存在。這種方法允許更具宣告性、可重現性和長期一致的構建策略，并且是我們當前組織目前正在使用的一種方法，用于節省資源和最初隨著容器的興起而帶來的一致性。
管道示例
- 中途 - 使用來自 SCM 平臺的 webhook 觸發 openshift 構建（可以在此處查看）。消除了 Jenkins 的一些依賴（并且個人沒有測驗過）但是如果你真的不能用其他選項做到這一點，這可能是最后一根稻草。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/326753.html